Efficient feedback without using Pull requests

I thought Issues could be managed to work a lot like comments in a word processing program, but it seems to be far from the case. Adding comments to a single Issue (on a 1-program, 1-Issue model) involves a lot of jumping around if I want to link to code blocks directly. This difficulty is not raised in the otherwise great topic 🏫 Using Issues to Give Feedback to Students

I should have been using Pull requests all along, especially since (I have just found), they are so well supported in VS Code. But this brings up the issue (ha) of complexity. I teach an introductory grade 11 course and it already takes considerable time getting the students properly installed and running code from the command line. I’m not sure I want to get into branches and fixing commits made to the wrong branch, etc. that are all part of the territory of Pull requests. There will always be that one kid who will just never quite get it and whose stuff will be a mess in constant need of adjusting.

I’m wondering how other teachers have solved this feedback problem with their most novice students. Copy-paste into the LMS or a doc / download + extract + run / feedback in the LMS or doc? I’ve been trying to eliminate that download + extract phase by having cloned repos and using GitHub across the board.

If your goal is to provide students with meaningful feedback, you can simply use the Pull Requests mechanism in such a way that all the complexity stays under your responsibility.

Here’s a draft:

  • The teacher creates the branch review off of the last commit of the starter code.
  • The teacher brings up the PR with review as the base branch and master (or how they like to call it these days the main) as the compare branch.
  • The teacher and the student do use the PR dashboard with the specific purpose of exchanging comments only. Thus, no need for dealing with rebasing/pushing/merging stuff: just inline review!

As you can see, students are not required to do branching: you do it and only for the sake of the review.
Also, everything runs online within GitHub.

You can make the PR draft to prevent merging, even though merging in review won’t cause any headache. After all, review is only a dummy branch you can remove once done (or leave it, it doesn’t hurt).

I’ve used this workflow and it works pretty well!

2 Likes

We use a simpler model in our introductory project class. We require write access to student repositories, which allows us to create a feedback directory in their repository. We then commit and push feedback on each deliverable in a separate subdirectory under feedback that is associated with that deliverable.

We don’t cover (or encourage) branching and merging, because as physcrowley points out, there is a minority who will get their repositories completed FUBARed; with 250+ project groups, this minority becomes a serious timesink. Pull requests will be completely beyond this minority.

1 Like

I like this idea.

  • it works because I distribute my course repo as a GitHub Classroom assignment, so the permissions are already correctly set-up
  • I can work in my IDE without context switching
  • it is simple, and my students can also contribute to the feedback, just like with Issues or PRs.

I was also thinking of creating Issues in advance for groups of exercises and for projects, then having students close them, instead of the other way around. This - I now realise - is basically what was suggested in that blog post.

What’s changed is that I figured out how to configure VS Code’s PR and Issues extension to search for specific issues based on state and who performed the action → I can see a list of both open and closed issues in the repo. I still have to hop over to GitHub if I want to write comments on the issue, though :cry:


That’s 3 new ideas since I originally posted! I will definitely be able to provide more efficient feedback next time around.

1 Like

I like this idea of using issues to give students tasks to do in their assignment.

I have a bit of down time, so I’ve created a workflow that will run when students accept an assignment through GitHub Classroom (provided the feedback PR is enabled). The workflow creates a project and adds issues created from markdown files. https://github.com/markpatterson27/GitHub-Classroom-Prepopulate-Issues if anyone wants to try it out.

As for other methods of feedback, I’ve been experimenting with adding feedback messages to grading tests that are run through autograding, then auto-posting those feedback messages to the feedback PR when grading is run.

Something like this:

It still needs some work, but it saves students having to dig though action logs to find where they’ve gone wrong.

© 2017 GitHub, Inc.
with by
GitHub Education