I’ve gotten some shout-outs on ProfHacker regarding posting syllabi on GitHub. I wanted to take to my own blog to talk about my choices behind building Git repositories for each of my courses. I also want to offer a few different approaches instructors might take for using GitHub for sharing syllabi. I’ll also preview how I’m planning to use GitHub to run a course this fall (rather than just hosting the repository course materials there). I plan to detail that process in a future post, for those instructors looking to do the same.

In his questions about the practice of posting syllabi to GitHub, Mark Sample claimed that GitHub only understands plain text, and that it’s a laborious task to convert one’s syllabi into plain text form. That’s a somewhat incomplete description of GitHub, and Git itself. And because of that, putting syllabi under Git control may not be all that laborious.

It’s more accurate to say that Git/GitHub best understands any format that exists as plain text. That includes, of course, the vanilla plaintext file, .txt, but also other forms including Markdown, HTML, and so on. (Pretty much any markup and programming language is plain text; its file extension—.txt, .md, .html, etc.—only serves to cue software as to how to interpret the file. Making matters somewhat more complicated, Windows and Mac OS both hide file extensions for known file types in their respective file/folder views.) You can put Word documents and PDF files and other binary format files under Git control. But what you lose are diffs: changes represented by a particular commit from the previous commit, or between two arbitrary commits anywhere along a repository’s timeline of development. Those diffs help to confirm and illustrate the change as described in a commit message.

But I would argue that if your syllabi are not in some plaintext form, in a flat file (versus a database entry in WordPress or Blackboard or something), they really should be.

I can make that argument from my own experience. I came to rely on GitHub for my syllabi and course-website needs from frustration with the wikis I had been using to run course websites. Every semester, I would create a new instance of WikkaWiki (which is a really nice and relatively lightweight wiki, if you’re truly in need of a wiki). But then would come the inevitable copying and pasting of materials over from previous semesters. Not to mention also the problem of how to archive the old wiki (all of my past wiki-driven courses are currently inaccessible, for exactly that reason; and I’m too paranoid to just leave the things running in case an exploit should be discovered that compromises not just the wikis themselves, but my entire server that runs them).

So I considered what needs I had that wikis were filling, and whether there wasn’t some other way to address those needs while moving to something without the overhead and security issues of a full-on per-class wiki installation. I’m developing this list in retrospect, but basically:

• Fast editing. As an instructor, it was nice that I was able to jump in and change something on the calendar or a project description at a moment’s notice, without all of the overhead of an SFTP client or whatever.
• Open editing. It was equally great to have a system that students could edit themselves, minus things like the course policy statement (which I used access control locks in WikkaWiki to prevent).
• Versioning. I liked the version history of individual pages that WikkaWiki provided (although if my memory serves me correctly, the version history only went about ten revisions deep).

Git and GitHub meet all three of those needs (on top of my long-standing demand to never keep a course’s materials behind some private wall or Blackboard-like roach motel). Better still, I’d meet my needs without the overhead and risks of a database-driven system (anyone who’s installed a WordPress installation has probably experienced the phrama hack and other ills). And best of all, I needed some kind of external motivation to continue improving my own skills with Git, and to expand in what I thought were some imaginative ways for using Git and GitHub.

So, here’s how I’ve approached posting course materials on GitHub, and some new ways that I intend to try out this fall already:

Read on...