Contextual Feedback Using GitHub Pull Requests

3 Replies

After reading @dondi’s workflow for using pull requests to provide feedback to students, I wanted to try it this semester. I wasn’t exactly sure what steps were involved, but I found a workflow that worked for me and I wanted to share it. I decided that a screencast would be an easier way to illustrate the steps rather than trying to type every step.

In general, the key is to edit one of the student’s files (the edit is simply to provide an opportunity to comment in the pull request) so a branch and pull request can be created. At this point, comments can be left where each change was made.

In the past, I’ve provided feedback as comments via Canvas’ SpeedGrader. This new approach is much better in that the code on which I’m providing feedback is adjacent to the specific comment. Once students see that the assignment is marked complete in Canvas, they check the “feedback” pull request to review my comments. If they have questions or if they have answers to questions that I’ve asked, they can continue this conversation in the pull request. While this isn’t a traditional use for pull requests, it works well and it’s good for students to be familiar with participating in conversations for pull requests.

Please comment if you have any suggestions to improve this workflow or if you have any questions!

3 thoughts on “Contextual Feedback Using GitHub Pull Requests”

  1. Andy "SuperFly" Rundquist

    Love this, but watching the video it’s a little clicky. When you’re doing a bunch do you batch things (like going into Bluejay to see them run)?

    Reply ↓
    1. geoff Post author

      This past time, I worked through one student at a time. I’ll see if that becomes cumbersome in the future. For a more complicated lab, I may leave feedback as comments in the code which would still show up as changes in the pull request. This would allow me to stay in BlueJ and not comment on the GitHub web site. I do know some teachers have scripts that clone all student repositories at once. Regardless, while there are a lot of steps, there a fewer for me than what I did last year!

      Reply ↓
  2. alexchaffee

    Here’s my grading-via-PRs workflow, without the need to make an edit :

    1. Create a source repo
    2. In that source repo, create a branch named template
    3. Use GitHub Classroom to create an assignment based on that repo
    4. Students work on master and push to master, just like always
    5. Graders create a PR inside the student’s repo using master on the right side and selecting template on the left side (base)
    6. The PR remains open and absorbs revised commits as usual, allowing either line-based or PR-based discussions
    7. When the grader is finished they can close the PR or just leave it open — the point being, you don’t ever merge/rebase/squash

    I’m still experimenting with it but it seems to work well enough.

    Reply ↓

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.