Stories from the GitHub Classroom: Changing Practice, one Pull Request at a Time
--
Before we get started, I’d like to introduce myself. My name is John Britton and I’m the Education Liaison at GitHub.
I have a background in educational technology with a specific focus on training software developers.
In essence, my job is to help you get the most out of GitHub in your teaching
Over the past few years, I’ve had the opportunity to observe the ways educators have used GitHub in the classroom, and I’ve noticed a trend: many educators do not use pull requests in their courses.
That’s a shame, because they’re a really powerful way spark collaboration and improve the learning experience.
--
Enough about me, let’s talk about GitHub:
GitHub is a platform for collaborating on software. It’s a place for you to keep your code, share it with others, and communicate about changes as you make them.
In this talk, we’ll learn about how a key feature of GitHub, the pull request, can be used as a teaching tool.
* Show of hands, how many of you use GitHub on a regular basis?
* And of that group, how many of you are currently using GitHub with your students?
* And finally, how many of you feel that you are using pull requests to their full potential?
--
But first things first: What is a pull request?
(Ask audience)
“A pull request is a proposal to introduce changes, a distinct set of commits, into a project. It’s a conversation about code. When a pull request is sent, interested parties can review the changes, discuss potential modifications, and even revise the proposal by pushing follow-up commits, if necessary.”
Let’s talk about two ways to think about pull requests…
--
From the literal perspective, a pull request is just a piece of software, a feature of our tool. It’s the sum a collection of commits, or snapshots, of a project over time.
It’s a place to view the changes being introduced to a project and have a conversation around them.
--
As ReadWriteWeb put it in their guide to pull request etiquette: opening a new pull request is like saying to a project maintainer: “Hey, I think you missed a spot.”
It’s a way to fill in a gap in an existing project.
--
Pull requests are the medium through which collaborators contribute to a project on GitHub.
* Found a spelling mistake? Submit a pull request.
* Adding a new feature? Submit a pull request.
* Fixing a bug? Submit a pull request.
It’s the place where we take action on our projects
--
Pull requests are also a mode of communication, they’re a way to talk about a project with code attached.
How many of you have ever received a bug report like this: “It was working yesterday, but now I’m getting an error.”?
Pull requests go a step farther, by allowing contributors to communicate necessary changes and attach a possible solution to the problem at the same time.
They’re a place to discuss the discrete set of code that’s being changed.
--
To me, pull requests are more than the sum of their parts. They’re not just a collection of commits and conversation, they’re also a philosophy.
Just as well designed features often benefit from following a pattern or design philosophy, software projects and their communities can benefit from the habit of using pull requests and adopting the philosophy that they embody.
Let’s talk a bit about that philosophy.
--
First of all, projects that use pull requests signal to the community “We’re always learning. We’re open to changes and new ideas.”
--
It’s acknowledging that the project is not static and can always be improved.
“We know this isn’t perfect, or finished.”
Pull requests give observers a sense of velocity. They’re proof that a project is in motion.
If a project you’re looking at has a few open pull requests and a history of merged pull requests it’s easy to come to the conclusion that the project is active and healthy.
On the flip side, if a project has no recent pull requests, folks often draw the conclusion that a project is inactive.
--
They’re an invitation to come into a project and collaborate.
Seeing a history of pull requests makes people feel welcome. They can see how new ideas are received and can learn what to expect before making a their first contribution to a project.
--
A simple way to think of the philosophy behind pull requests is “social coding.”
Pull requests take a stand on openness, collaboration and culture. They facilitate transparent development, conversation, and iteration.
When you bring GitHub into your classroom and start using pull requests you can bring this philosophy to your students and unlock the power of “social learning.”
I’m going to show you how the values of pull requests have been applied to teaching in practice.
--
How can we relate pull requests to best practices for teaching?
Just as pull requests enable communities of practice to form around software projects, they can also enable communities of learning to form around that same work.
--
Working with educators from Stanford, MIT, CU Boulder, UC Berkeley, Delft University of Technology, RIT and EPFL, we’ve observed 3 key shifts in practice by teachers that use GitHub in the classroom…
--
The first shift is a move from “skill-and-drill” to an applied approach where students work on real projects.
For example:
Armando Fox at UC Berkeley has each team in his Engineering Software as a Service course work with a non-profit organization on a real project with real requirements determined by the “customer.”
--
The second shift we’ve observed is a increased emphasis on “soft skills” like collaboration and feedback, as opposed to strictly focusing on problem sets and lectures.
For example:
Arie van Deurson, from Delft University of Technology requires students in his Software Architecture course to complete a written review of another team’s contribution to an open source project.
--
The third common shift we saw amongst teachers using GitHub in their courses was away from a top down model of instruction, where information is solely passed from the teacher to students directly…
to a model where instruction is augmented by the students themselves and outside mentors.
For example:
Students in Remy DeCausemakers course, Humanitarian Free and Open Source Software at Rochester Institute of Technology receive mentorship from maintainers of open source projects and have the opportunity to earn credit for sharing their knowledge at local meetups and regional hackathons.
--
Overall we’ve seen a shift from the traditional thinking about the classroom as a place for lectures to referring to the classroom as a community.
When we think about the classroom as a community, it’s easy for the learning and relationships that begin in the course to extend well beyond the semester.
--
Further, given these shifts, there’s a thin line that is blurring as the classroom begins to look more and more like the real world of software development.
By moving from traditional one to many instruction to the networked instruction enabled by treating the classroom as a community, students are exposed to an environment with a flat structure of networked communication where information is constantly moving in many directions.
Pull requests enable this structure, that closely mirrors industry and the open source world, providing students with valuable, real-world experience.
--
We’ve talked a bit about the shift towards treating the classroom as a community, but how exactly do pull requests foster this environment?
Depending on how they are used, they build: teaching, cognitive and social presence.
--
First let’s describe how we’re framing community: a group of folks who help each other.
Clay Shirky: when describing how the PERL community worked (vs. AT&T) said:
“Do the people who like it take care of each other?”
--
We’re pretty sympathetic to Garrison’s Community of Inquiry model -- that a strong educational experience is made up of Cognitive, Teaching and Social presence
We’ll show you how pull requests can help build each aspect.
--
First, let’s talk about teaching presence.
A key to establishing teaching presence is facilitating communication, and pull requests are a great way to do that.
--
This is a quote from Jim Baker, from the University of Colorado in Boulder. He had students submit labs and homework assignments using pull requests in his Computer Science 1 course.
(read quote)
Students had the ability to get feedback and talk about their code as they worked on it. They used the task list feature in GitHub, to describe their plan of attack and update others on their progress.
When they got stuck, they were able to get help from the community and they were even awarded extra credit for finding bugs in assignments and fixing them.
--
An often overlooked feature of pull requests, is the fact that they can be created as a work in progress.
It’s not necessary to fully complete a feature or assignment before opening a pull request. Because pull requests represent a conversation about the attached code, they make for a great way to share progress along the way to a solution.
I recommend getting your students into the habit of opening pull requests early, so that they can show their progress and get help along the way.
--
As students make progress and update their pull requests, it’s possible to run automated tests using a continuous integration service like TravisCI or your own build service.
Instructors and TAs can receive notifications on build status as students update their pull requests and can proactively provide feedback and encouragement as necessary.
--
Next, let’s talk about how pull requests can establish cognitive presence and help students create meaning out of their experiences.
Teachers, peers, and mentors can use pull requests to help students with setting direction and determining project goals.
When used in an open environment, they also give students access to a wider network of expertise from the open source community.
--
We’ve observed cases of students finding mentors “upstream.”
There are a number of added benefits to finding external mentors, including: subject matter expertise, social pressure, and relationships that last beyond the semester.
--
At Delft University of Technology, Arie van Deursen had his Software Architecture students interact directly with open source project maintainers in part through pull requests.
(read quote)
Students were required to find relatively large open source projects and identify stakeholders to contact and work with.
When contributions were successfully merged upstream, the maintainers welcomed more participation from students, building longer term relationships with them.
--
As a way to scaffold students into the open source community, Remy DeCausemaker from RIT, made the first assignment for his students in Humanitarian Free and Open Source Software to submit a patch to a project.
Students were also given the option to submit additional patches for extra credit.
--
Students were motivated by the presence of external mentors and in some cases they extended themselves beyond expectations.
(read quote)
Real project stakeholders and mentors can cultivate an “academic mindset” in which the student is aware that folks are there to help them succeed.
--
Finally, with regard to the community of inquiry model, let’s talk about social presence.
Pull requests help give learners the feeling of “having people in the room” that can understand them, are like them, and will help them.
--
When a pull request is submitted, the author’s profile information is presented along with a showcase of previous contributions.
This additional information helps build a sense of more than just an avatar when reviewing a pull request, especially in first time interactions.
When encountering a new user for the first time, one can use this information to determine how to best communicate with this person.
--
In “Impression Formation in Online Peer Production: Activity Traces and Personal Profiles in GitHub” Jennifer Marlow et al. wrote:
(read quote)
Over time, pull requests paint a picture of a person and their contribution style that can be used by others to establish an impression of the individual via the substance of and types of projects contributed to.
--
Peer review is another way to motivate and promote interaction to build social presence.
Pull requests enable peer review to an amazing degree. Users have the ability to review changes, leave inline comments, and revise work over time.
They can do all of this while maintaining a full history of the process including revisions, review comments and their associated resolutions.
--
The lightest weight option for peer review is simply to open issues against a project repository.
This is from Reuben Binns, PhD researcher at the University of Southampton.
(read quote)
In this case, peers can suggest changes as issues and mark them as “read.”
--
If students are working on individual projects, that is they aren’t all doing exactly the same thing, it’s reasonable and effective for you to assign them to peer review each other’s code and potentially even submit pull requests with improvements.
Pull requests include a diff with associated changes, where comments can be left inline with code.
(play)
Here you can see a simple diff showing changes to a project’s README.md file.
--
Alternatively, you can assign an entire repository for feedback and require a qualitative report on the project rather than a line by line code review like in this data cleaning course from John’s Hopkins University that was available via Coursera.
--
Pull requests enable a community of inquiry and support a pedagogy that is project-based, community-driven and models the values of open source.
--
That’s all well and good, but it sure does sound like a lot of work.
Believe it or not, pull requests can actually make your life as a teacher easier.
--
By assigning real-world projects, the likelyhood of opportunistic cheating goes down. There’s no “right solution” that can be downloaded.
Finding and using libraries online, so long as the code is properly attributed, should be encouraged.
In industry, nobody wants to reinvent the wheel, so we should make sure our students are learning how to find and reuse software responsibly.
--
Another great advantage to using pull requests and real world projects is that you can reuse the same syllabus and prompts from semester to semester without worrying about students submitting code from a previous semester.
--
Assigning real-world projects encourages learners to find other teaching resources besides you.
For example…
--
If you design short, one or two-week, sprints with weekly check ins, students are less likely to fall behind.
By using pull requests, you and your TAs will be able to more easily keep track of how well a particular student or group is making progress.
--
Learners find mentors upstream, and by marking work in progress pull requests, they can get review and help from peers and mentors outside the university.
--
Grading group work is smoother thanks to the qualitative data from checkins and showing work early using work in progress pull requests.
Dean James Larus, said about his Software Engineering course at EPFL:
(read quote)
--
Overall, using pull requests and project based assignments can be less work than you think and will give you and your students a greater payoff in the end.
They’ll get valuable experience with real world tools, build the soft skills necessary for collaborative software development, and learn to find mentorship and motivation from outside the classroom.
--
If you like what you’ve heard here, and want to get started, we can help.
We have resources available for you to bring GitHub into your classroom.
GitHub is free for educational use, just head to education.github.com to get started.
--
While you’re there, you’ll also find our classroom guide with full instructions on setting up GitHub for your class.
--
You can send your students to the GitHub Education site to sign up for the GitHub Student Developer Pack.
The pack gives them free access to GitHub and a variety of other professional developer tools, all free of charge.
--
Lastly, we have written case studies with more detail on the courses I’ve mentioned in this talk.
If you’re using GitHub in your class now, We’d love to interview you about specifics. Please come find me at the booth in the exhibit hall.
--
Here are some references and further reading.
--
You can find me on the internet @johndbritton.
All the resources I mentioned are available at education.github.com, you can also get in touch with us through the site.
johndbritton
utokyoissr2360
ueokande
.png){kind=avatar}
residentniigata
amarelo_n24
fullfull
classijp
signer
gmoriki
miyayou
satoru_higuchi
codeforeveryone
miholovesq
bcantrill
aki_iinuma
scottboms
bluesmoon
eitanlees
sugarenia
colly
csswizardry
denniskardys
swwweet
paulrobertlloyd
jakevdp