Today I wanted to share a methodology that I use to track and review the homework assignments for the students in my cohort. I’m a big fan of Github; I use it every day for work. Aside from being a terrific piece of software, my favorite social network, and the best reference implementation of a ReSTful API, I always find the people there pretty awesome.
Take Elizabeth Narramore, for example. She’s pretty awesome. She gives a talk called Github for More Than Just Code that resonates with me. I use Github repos for lots of things besides code. When I started teaching at Valencia College, I setup a Github Organization for my PHP class, another for my JS class and distributed the syllabus via Github Pages.
Students were required to create a free Github account in order to receive and turn in assignments. In the 2 and a half years that I ran the two classes, I experimented with forked repos, Pull Requests, and made a lot of train wrecks. I eventually settled on the process that I started using for my first cohort of 14 at The Iron Yard, and I’m still improving it, based on the ideas of others and continuing experiments.
#1 Start with a blank canvas…
I started by creating a Github Organization for the campus instead of just the JS class or just my specific cohort. I found that creating new Github Orgs every semester that I ran a class was just a Bad Idea and sharing an org with Future Me forced me to pick more specific names for the repositories. I also found that maintaining a single
Assignments repository in the Org was confusing to former students and a pain.
Part of the “pre-work” the incoming students are assigned before the class is to create a Github account, visit the class Org, and star the Repo for the class. As they come in, I take the “Stargazers” for the Repo and add them to a read-only Team within the Org. This allows me to @-mention the Team within an issue or commit message to push notifications to the whole group, like a mailing list.
#2 Throw in some assignments…
For every assignment, I added a new Markdown file to the
Assignments folder within the repo. I started with very detailed assignments that included bulleted lists and checkboxes, and the students just copied those verbatim into an Issue, which displays a progress bar for the individual Issue. I could see their progress at a glance, and they got used to using a ticket-based project management system. As the class progressed, I slowly backed off the detail and had them add their own checkboxes.
Most assignments involved producing some kind of code, which the students added to their own
TIY-Assignments repositories (not a fork of mine) in a unique branch. They create a Pull Request (PR) within their own Repo and use Github Flavored Markdown to link the PR to their issue in the class repo, giving me another visual cue of progress and completion.
I used Labels on the Issues to indicate grading status, and I established three grades: Acceptable (green), Unacceptable (red), and Please Try Again (orange). The latter indicated that the student had some time to incorporate my suggestions and recommendations before I issued a final grade, which might still be green or red.
Pt. 2 to follow on Thursday!