Amazing Professor John David N. Dionisio’s at Loyola Marymount University shares how he gave students feedback before / after GitHub:
I’ve read this article a few times now, and this approach is exactly what I want to do for my students. However, I cannot wrap my brain around how to actually (technically) comment on my students code in their respective assignment repositories.
I simply cannot find any comment functionality within the GitHub.com site.
This teacher uses the GitHub pull requests feature to review and comment on student work.
Pull requests with Markdown support are a great place to have a consistent thread of feedback. And this clear signal of, “I now accept your work”—like building a relationship of submitting your work for someone to look at, and after we workshop it for a little bit, I now accept your work.
Quick overview of how those work:
Feel free to start a new thread specifically focusing on how to implement pull requests with your students for the first time & any best practices from the teachers here.
Thank you for your quick reply.
I just need to fully understand: So this teacher would clone his student’s repo, make corrections, then create the pull request and in the request apply his comments and advice?
@BrianEmilius think his workflow is:
- Student forks repo, makes changes to files as their assignment
- Student submits pull request back to the assignment repo
- Prof. Dionisio begins his review of the PR and either approves or requests changes
Does that help?
This workflow is perhaps even better than how I imagined it, as the student has better control over his own fork, than a classroom issued repo.
Thank you for the reply
Thanks for your interest and kind words! The workflow has evolved a little over the past few years. Originally, I had students create their own repositories and they would make me a collaborator on those repos. That then allowed me to add comments to their commits directly.
Some assignments would involve students’ contributing work to a pre-existing repo. For that situation, I have them do pull requests. That does not usually happen until upper division—one must realize that for many of these students, the very concept of version control is something that they are also still learning. So I start them with just doing commits—which I just refer to as “saving your work without throwing away your prior saves”—then when they are more comfortable with the idea of multiple development tracks, I start using pull requests.
The original “make me a collaborator on your repo” model shifted recently with the advent of GitHub Classroom. I have since switched fully to that and will likely stay with it for self-contained assignments. With GitHub Classroom, I prepare a “proto” repo which the students then clone (by accepting an invitation link to the assignment). The GitHub Classroom setup allows me to automatically become a collaborator (an owner, in fact) of that repository. So the students don’t need to deal with adding collaborators anymore. They also don’t need their own private repositories because GitHub Classroom provides that for them.
But past that, the flow remains the same: students commit or submit pull requests to a repository in which I have at least collaborator privileges, and as such I can then supply comments as shown in the blog post.
Hope that helps—let me know if you need further information!
I like “proto” quite a bit
Classroom definitely helps newbies onboard to GitHub with less friction, so we do see it used more for 100-level courses.
We’ve just updated the README which you may find useful:
@dondi thank you very much for your detailed rundown of the technical process itself - along with some didactic thoughts
It very much helped me understand how your workflow is, and I imagine this is how I will approach it myself, when we (my colleagues and I) implement classroom fully in August - our dean set aside a full week of training for this, so I imagine we will get really deep into classroom and its many possibilities.
You’re welcome @BrianEmilius! Looks like your dean is going all-in on this, which is great to hear!
At the risk of going too deep into technical detail, I should mention one more thing: there is actually an additional layer of git activity happening with my work flow. When one teaches the same course over multiple terms, one builds a library of potential assignments to give out. So what I have done is maintain multiple longitudinal repositories representing the various assignments I could give out. I then revise them over time as they get updated.
However, I don’t use those repositories as the “protos” for GitHub Classroom, because otherwise my whole commit history will be exposed to the students. Not necessarily harmful, but potentially distracting (and it balloons the size of the git clones over time). So, when I am ready to turn something into a GitHub Classroom assignment, I actually push my “long-lived” repo into a new repository, and I squash the commits so that the history is gone from the new repository. That is the repository that I designate as the GitHub Classroom “proto” repo.
I realize that this might be TMI, but I figured I may as well document this detail while it is fresh in my mind. Please feel free to ignore it if this consideration does not apply to how you plan to use GitHub. Thanks!
@dondi no, this helps a lot! Thanks again
Hi @dondi. Thanks for the great blog post. I’m a little bit confused about how this works with the GitHub Classroom model. Let’s say I create an assignment through GitHub Classroom, so that each student in the class gets their own repo with that assignment that they can work off of. Do you have them create a new branch so that they can submit a pull request to the master than you can then comment on? Or do you have a system that avoids them having to do much else other than clone, do the assignment, and then commit their changes and push?
Thanks, glad you like the blog post! Students may use pull requests/branches for their work, but because they each get their own repository, for simplicity I forego that and have them just commit to
master (of their repository). Commits are commentable on a line-by-line basis and so that is what I use.
The one case where I use pull requests is when their assignment involves a fork of a pre-existing, public repository. But in that case, I’m actually not using the GitHub Classroom assignment mechanism because I maintain the fork relationship.
It might not have come across that GitHub Classroom assignments do not create forks; they create complete autonomous copies of the original repo. (well, at least they didn’t create forks as of last semester—I know that a lot of work has been happening this summer so I’ll have to see what’s new for the next term )
I guess the bottom line is that the repositories created by GitHub Classroom assignments are fully functioning GitHub repositories with all of the features that come with them. Instructors are free to pick and choose which features of a GitHub repository to use. It is solely my choice that I have them use a simpler submission model (commit and push to
master)—mainly because I frequently teach courses where GitHub (or the very concept of version control even) is new to students. If a class cohort is known to be more experienced with GitHub, PRs and branches are certainly fair game.
Hope this helps!
Thanks for the extended response @dondi. I guess I haven’t used commenting on commits before, but does that mean you go to each student’s repo, click on their commit history, and go through each one and comment? Or is there a way to generally comment on all of their commits? Sorry for all the questions, I’m just not clear on the exact workflow here.
No worries @jfiksel —and indeed your question is precisely one of the reasons for switching to a PR-based submission model instead of direct commits. It just so happens that for the courses I’ve been teaching, the assignment is either sufficiently small, or the commits sufficiently infrequent, that the per-commit reading is tolerable. I do agree that past a certain threshold, a PR may be called for, at the cost of a little more up-front training if there are students who are unfamiliar with branching/forking.
Interesting. From this conversation, I think it would be great if GitHub Classroom had a feature that supported feedback on assignments assigned through GitHub Classroom. I’m not quite sure how this would work, as it seems the main feature of Classroom is to basically make repos for all the students for each assignment. Perhaps some kind of a command, either through the GitHub website or command line, that automatically creates to a new branch, pushes, and then creates a pull request that the teacher can then leave markdown comments on. Although I’m the TA for my class, I’ve talked to the professors, and we’re all a bit hesitant to teach branching when
- The students are completely new to Git/GitHub and might already be overwhelmed
- We dont want to make Git/GitHub the focus of the class, but rather a convenient tool for interacting with students’ code during assignments
After reading @dondi 's original workflow, I’m going to try to use pull requests in order to provide comments. However, I too don’t want to introduce branching and pull requests in my one of my classes; so, I plan to personally branch the student’s repository and submit a pull request solely for the purpose of being able to leave contextual comments. Students could then view the pending pull request to see my feedback. I will try this out when the new school year starts…
Sounds good @gcschmit, that approach looks like a good balance between the convenience of a pull request for keeping a set of changes together, vs. spending a lot of initial time with getting students accustomed to branches and PRs. Hope it goes well!
Voy a enseñarle a mis Profesores.
Using pull requests to provide contextual feedback to students is working well. I recorded a screencast of me providing feedback on a student lab and made a short post on my blog with the video and a brief explanation. I hope this is useful!