@gcschmit this is great, thanks!
Thanks everyone for sharing your experiences, this has been super helpful. Most of the comments reflect my own observations this year as I have adopted GitHub for teaching and collaboration. Specifically, balancing the problem solving/algorithmic part, with its instantiation in a programming language, while using a sophisticated but extremely useful ecosystem (GitHub). I will be sharing more notes in the coming weeks. So far students are engaged with using version control, and I have been sharing with them ideas, lessons learned, and reasons why it is a great tool. Overall the reception has been super positive. Since I am developing a new CS pedagogical framework anchored on a socio-technical approach, I find GitHub a great ecosystem for it. Stay tuned!
When an assignment is created from a template repository, it seems natural that we should be able to create a pull request with the original repository as BASE and the student repository (master branch) as HEAD, and make comments inside that PR. However, the original repository doesn’t show up as a possible BASE. I’ve tried messing with both the UI and the URL to no avail.
It seems that the student repos are not proper forks of the template repo, but instead are bare unlinked copies. Why not? Doesn’t that make the tag line “GitHub Classroom: The GitHub workflow, scaled for the needs of students” a bit misleading, since it is not the GitHub workflow (with code review discussions centered around PRs) and instead requires us to manually fork student repos from the template (like @gcschmit mentions above) ?
@alexch using the template repository as the
base in the PR will generate lots of clutter if you consider the number of students and would go against the principle of sandboxing the students’ work in isolation for commenting/grading purposes. For example, it won’t suit the case of private assignments.
By contrast, the students are supposed to open up a PR within their assignment repos, which originally contain an exact copy of the template repo. This way, the GitHub workflow is preserved.
Thanks for your reply, but I don’t follow. What do you mean by sandboxing? If a PR is opened but not merged (and instead marked as “closed” when the discussion and grading is complete), where is the clutter?
As other commenters have pointed out, requiring students to – (a) create a local branch, (b) use and push that branch but leave
master alone, and © correctly create a PR against the master branch of the same repo – requires extra training on Git and GitHub before they can use GHC for even a simple one-file assignment. I prefer to teach my students the basics of git (clone, add, commit, “git push origin master”) and get them used to that for several weeks or months before teaching branching and merging.
I’m thinking of patching https://github.com/education/classroom to add a “fork or copy” button so an instructor can decide on a per-assignment basis which flow to use. (Naturally the default would remain “copy”.) Sound interesting?
@pattacini Oh, do you mean that the PRs would all be listed inside the template repo’s issues list? And that the students would all be able to see each others’ PRs and discussions, since they’d be in the template repo and not the student repo? That does sound like a tradeoff but it’s one I’m personally willing to make, since I encourage my students to look at each others’ work.
Another option would be to keep the “copy” flow, but add a branch (named e.g.
template, initially pointing at
master but never moved) to make it possible in a single step to open a PR inside the student repo. That PR would contain the differences between
master (current work) and
template (initial structure or empty file).
Students can still look at each other’s work when assignments repos are public. All those repos, indeed, will be visible from within the GitHub organization the instructors do use for the classroom.
Branches and tags of the starter code (the template repo) are retained and copied as they are into the assignment repos. This way, the instructor can prepare the template without forcing the students to branch off themselves.
Anyway, creating a branch using the GitHub UI (not the Git CLI) is as easy as pressing a button.
Okay! Here’s my grading-via-PRs workflow, requiring no extra steps for the student and only one odd step for the teacher (#2). PR discussions are much better than normal single-commit line-based comments since they are tied to all the students’ work, not just a particular commit, which might be incomplete or changed later.
- Create a source repo
- In that source repo, create a branch named
- Use GitHub Classroom to create an assignment based on that repo
- Students work on master and push to master, just like always
- Graders create a PR inside the student’s repo using
masteron the right side and selecting
templateon the left side, i.e.:
[base: template] <- [compare: master])
- The PR remains open and absorbs future commits as usual
- 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, just use the PR for a discussion and not an actual pull
I’m still experimenting with it but it seems to work well enough.
This makes a lot of sense, thank you! I will experiment with this next year when I have actual students (unless a comparable feature becomes baked into GC of course). Seems like your workflow would be quite scriptable by GC when an assignment is made; just make the branch and the PR as the assignment copies then add a link to the PR next to the repository link.
I tried to pull down the classroom code and see if I could add a feature like this, just to test the idea, but ran into ruby development issues on my VM. I’ll try again another time.
@mozzadrella is there an official spot for feature requests like this one, or is the Issues section of the classroom github the best bet?
The original post seems to be from 2017-18 so maybe it is just that GitHub Classroom has just evolved since then but my workflow is slightly different. I leave feedback for the students as Issues in their repository.