Plymouth University, Bristol University, University of West England

GitHub for the Classroom

Sep 18, 2017

This article was origionally posted on www.elliotblackburn.com.

As many of you know, I am both a University student, and a strong advocate of git. I think education and version control fit together like two peas in a pod. I’ve been banging on about it for ages in person, and after reading through this great article from Alexey Zagalsky I thought I should make my own proposal. I’m not going to discuss the reasons I think it should be used as I’ve gone on about that enough in the past. Instead I’m providing a proposal for how a University course (or module) should use git and GitHub.

GitHub account per student and staff member

This is pretty straight forward, each student and staff member involved will need a GitHub account. With the GitHub Education scheme you can even get a bunch of free stuff, including some free private repositories.

Chances are that you and the students will use this for work outside of the classroom. This gives a great “foot-in-the-door” for both git and github. You’ll be encouraging open source contributions right from the get go. What’s more, all the students work can be attributed to them for when they leave. GitHub is used by a lot of developers, being able to have a profile that has been active for a while before applying for jobs is a great start for any student.

Organisation for your department

This is the first step, you’ll want an organisation for your department. You’ll have all of your staff added to this as people that can create new repositories and push commits to them directly. Pretty simple, set up a nice logo and fill out the profile and you’re good to go!

Module Repository

This repository is what it says on the tin. A repository for a module is a great place to start and gives you a single place to put all of the module resources. GitHub has great support for markdown so you should be able to easily and quickly format any documents.

Lecture content

Generally I’d expect to see a markdown document per lecture / lab. This would give a really clean and fast way to navigate the module content. Using markdown you can also include any images, diagrams, and code snippets. You can also really easily turn a markdown file into slides using things like Remark, this way you don’t have to duplicate the information just to present it.

A student will be able to see the repository and clone it down to have all the module content in one easy place on their computer. As updates are you released, students can instantly see them and take the changes if they want local copies. Alternatively they can just use GitHub to view them all in the browser.

Issues

This is where it starts getting fun. Students should be encouraged to create issues to ask questions, this way it’s totally public and everyone can see them. As a teacher, you can easily triage them using tags and even close them when they’re finished with. Now, not only can a student submit a query very quickly and easily but you can also get others involved. If another student has a similar question then they can tag onto it and you can create a literal discussion that is logged forever, all without the pain of email. In addition, you can also mention other staff members to draft in their expertise if a question is a bit out of your field.

Pull Requests

Pull requests work on several levels and provide huge room for collaboration between staff and students.

One great benefit is you can challenge students to improve the material themselves. Anything from spelling mistakes to unclear wording can all be resolved by the students. It’s like crowd sourcing your material, students will be quick to pick up on possible changes when they’ve been using the material to study from and you may not have looked at it for weeks. If they spot something that should be changed, whether it be a mistake or an improvement then they can contribute it. If the change is good, you can merge it into the repository and they get credit against their profile for the change.

Assignments

Again, this is a place that GitHub really thrives. Students are always collaborating on work, so why not encourage it and actually observe it? You may find a few of the quiet ones actually much stronger when collaborating on projects.

Completing the work

GitHub themselves provide a number of ways you can handle assignments. The first is to use forks and the second is to use sandboxes. Forks are nice and easy and great for assignments that can benefit from collaboration. Simply create a repository for the assignment and put the brief in there with any associated files. Then have each student fork the repository and complete the assignment. You can now encourage them to take a look at other students progress, work to solve problems together, leave comments on commits or create issues. This potentially allows you to give them credit for their contribution to other peoples projects, perhaps someone asks them a question about their solution, a well constructed explanation could earn them some kudos.

The second approach is useful for assignments that need to be private for some reason. You can use the teachers_pet tool to create a private repository per student within seconds! This allows you to monitor each students progress but have their work remain private between you and them.

Collecting the work

Time to collect the work? Simply use the teachers_pet clone_repos command to clone all repos that match a specific name criteria straight onto your computer. No need to go off and find them, no need to create an obscure locking features, you can simply do it on the deadline. Even better, set up a little script that’ll do it automatically on the deadline! If you’re lucky, I’ll whip this one up for you a bit later and add it as an edit.

Grading

I’m not going to go into too much depth here, but this opens the possibility of peer code review! You can post your comments and others can post theirs, your students can actually learn from each other and have it displayed and saved for them without the need to email out the feedback.