How did you incorporate the GitHub contribution history into your grading?
I don’t. I think this would be very hard to do.
Did you manually pair students, or randomly, or let them pick?
Students have to work with a different person each class. They need to fill out a Google sheet in each class, listing the person they are working with that day. (Each students lists a partner, so there are duplicates. Parsing this (dirty!) data later in the semester can be a fun exercise.) This guarantees that students will work with 20 or so different partners over the course of the semester. However, students don’t have complete freedom to choose since I organize the lecture hall by student housing. From my syllabus:
Class Room Seating
Seating is organized, by campus geography, into several large “Groups” of 20 to 30 students. First Years, Eliot House, Quadlings, et cetera. Details depend on enrollment.
Students work in “Pairs” of two “Partners.” Sometimes, this will be “side-by-side,” each of you with a computer open, each writing code, but talking with each other throughout. Other times, we will “pair program,” meaning just one computer open and both of your collaborating on a single project. You will work with a different partner every class.
If you are the stronger student in a Pair, do not simply charge ahead. Instead, make sure that your classmate keeps up with you. Help each other! If you aren’t talking with each other often, then you are doing it wrong.
Pairs will always be grouped into larger “Circles,” generally of 6 students total. All these students will be from the same Group. Make sure to introduce yourself to everyone in your circle at the start of class. There will be a quiz. Most Circles will include students you have worked with before, but please try to meet everyone in your larger Group.
Record the name of your Partner in the Google sheet for the day.
How much were you able to monitor the activities and encouraged students to truly be working together? I’ve found the “stronger student does all the work” to be a common problem in group work, especially in intro classes.
I agree that this is a problem and it is something I struggle with. (Much of the syllabus material quoted above is new for this semester.) I am interested in other approaches. Initial thoughts:
I randomly cold-call students during class. This gives an incentive to weaker students to work as best they can since I might call on them. At the least, they need to understand and be able to explain what their stronger peer has come up with.
The first third of the semester is “programming-in-pairs,” meaning that each student has to write their own code. This certainly helps to keep both students involved. Even if the stronger student is the one actually figuring stuff out, the weaker student still needs to write down the code and get it to work.
If a student has not made much progress when I call on him, I will then call on his partner. If the partner has a good answer, I will gently shame her by asking why she did not take the time to explain things to her partner. We are all in this together! I note in the syllabus that helping your partner is part of class participation, which is graded.
Later in the semester, we do true pair programming, meaning only one student with her laptop open at a time. (I think using GitHub helps. Indeed, I am not sure if I would bother with real pair programming if we were not using Git/Github.) This forces the students to work together, at least when the weaker student is doing the typing.
Again, all this is occurring during class when, depending on class size, monitoring is much easier.
Summary: The big win is students programming in pairs, both with their laptops open but forced to work together by cold-calling and moral suasion. Highly recommended!