This is a nice set of reflections on the potential value of GitHub to teachers. The title is broader, referring to the Git source code version control system, an open standard with hundreds of implementations, but most of the article is about GitHub, a closed commercial system that packages up Git with a deeply social workflow and friendly interface, making the bulk of its money from those that want support for closed projects and teams rather than open source goodness. Ben rightly points out that a source control system is great for text but less great for binary files and that, despite the quite friendly interface, there is quite a learning curve needed to use it effectively, especially if you are not used to the complexities of writing MarkDown code. Essentially, though it is a soft tool that can be repurposed and reassembled in many different ways, it is built for programmers, and structured in ways that support application development, not other things.
Ben’s suggestions are (typically) thought-provoking and good…
- An open source, freely-available content control tool designed for people working with non-code. It’s okay for it to not know about fancy file formats like Word, but it should be able to handle more than line-by-line changes. Perhaps call it scribe.
- A proprietary, beautiful city ecosystem built around it. A ScribeHub.
Nice idea and, as he observes, one that some people have already tried and failed to do, providing some good examples of tools that go part of the way. There’s a good discussion of some of the issues of doing so in the follow-up comments to a post by David Wiley a while back. That said, the big advantage of GitHub is that it does already exist (and is thriving) and does get used for much more than just coding. I really like some of the innovative uses of GitHub for things like journal production: https://github.com/ReScience/ for instance, uses it to make articles and research into living documents, updated as reviews and replications come in. But, as Ben says, it is not optimal for anything other than coding and text documentation and, though there are some great exemplars, it is not likely to hit the mainstream as an alternative means of production outside the coding and documentation community for some time, if ever. Also, much as I love GitHub for its innovative and smooth community integration, it is a commercial monolith. Such things should be distributed and open.
What makes GitHub so cool
Perhaps the biggest differentiating feature in GitHub that makes it stand out from other similar tools is the combination of (for the unpaid variant) required openness, and the ability for anyone at all to make a ‘pull request’. Anyone can make a copy (a ‘fork’) of an existing GitHub project and (and here is the good bit), if they make changes that would be useful in the upstream project, submit a pull request to the author(s) so that their changes can be reincorporated (merged) back into the main branch of the code. Github provides tools that, at least for text, make such merging relatively pain-free. Through this mechanism, the work of many loosely coupled people can cooperatively work on complex projects without the need for further mechanisms of collaboration, teams, collaboration, or complex project management. GitHub does, of course, have rich communication tools for discussing such changes and passing them back and forth, so it can be used very effectively for closed teams as well as in a more open, networked community, but its central social motif is the network, not the group.
An idea
I have been thinking for some time about building a programming course that uses GitHub or, perhaps better, an open variant such as GitLab, or a related coding support tool with similar intent like Phabricator. The basic idea would be that the course itself would evolve through pull requests – if students or others have ideas for improvements, they would simply implement them and submit a pull request which the course owner could choose to merge or reject. Others could, of course, build their own versions of the course at will. I don’t think this is particularly original in itself – many have built OERs this way – but it makes sense to me as both a way of actually hosting a course, and as a way of building in student participation in the development and evolution of a course. Amongst other things, it opens up the potential for students to customize courses for their particular needs: if the basic model contains stuff that is irrelevant or already known, they could adapt it to the way they want it and, of course, share that with others. This in turn opens up some interesting options for scalability and personalization (the good sort). Rather than providing a single, monolithic MOOC, courses could branch off into many related versions, each with its own communities and interests. Someone might, for example, adapt the structure for a different language, focus down on a particular element, restructure it for different pedagogical designs, or extend it for more or less advanced learners. As the ‘course’ itself would be hosted on GitHub (or whatever) there would be no need for additional tools, and the course communities/cohorts could relatively easily blend with one another, or overlap. There would be evolutionary competition between the various branches, perhaps, leading to ever better (or, more accurately, better adapted) versions of the courses.
At least a part of the assessment of the course would be based around taking an existing codebase (in some possible variants, perhaps the code used for the system employed to host the course?) and making improvements to it. Credit would be awarded to those whose pull requests were accepted. One particularly nice thing about that is that all work would, by its very nature, be original. There would be no value at all in simply copying what someone else had done, and success would be measured according to real-world metrics: it would have to be good enough to enter production. It might get a bit complicated as the course matured and there were fewer obvious things to be improved, but I have yet to come across any perfect software beyond very trivial and, with a plugin/service-based architecture the potential for improvements could be virtually limitless. There’s scope for most skill levels, apart from absolute beginners, here. And even relative newbies could contribute to things like documentation.
The idea appeals to me though, as others have found when trying to do something similar with OERs, the complexities mount up pretty quickly. One of the issues is that, unlike in the case of most programming code, one size does not fit all: it is not about producing one useful course or toolset. We are not talking about building an open textbook here, but a course that is suitable for many people in many different contexts. It is therefore more likely that forks would be more useful than merges for most people. In the coding community, this can be a problem – you wind up with many similar forks of code, each of which goes its own (increasingly incompatible) way, diluting the value and community around the original and making it difficult to choose between them (for instance, the many forks of MySQL or the two major branches of Open/LibreOffice). Big products can spawn so many forks and pull-requests that the original authors can be overwhelmed. For courses, forking would allow for the kind of repurposing – contextualization around individuals and communities – that makes OERs worthwhile in the first place. More than with open source applications, though, there would also be issues with diluting the learning community: this might be a benefit for something like a MOOC, where numbers are too large to be managed in the first place, but not so good for smaller courses. There’s a balance to be sought. Having recently tried (and I am still trying) to incorporate changes from a main branch into a modified version of an OER course, I can verify that it can be fiendishly complex. I want to maintain our own localizations but the updates are great and, in some cases, necessary. Merging is really difficult, because there is a great deal more involved than simple text, hierarchical directories and a few dependencies to deal with.
A system that would do as Ben suggests for complex media would be a great help in such things. Among those rich media I would love it if it could cope with, say, an exported Moodle course, where it is not just content but process and structure that needs to be tracked, and where changes to structure could greatly impact the meaning and value of the content. The complex, soft dependencies and need for narrative flow make such things structurally very different from the relatively proscribed ways that programs can change, so I don’t have a clear idea of how that could be done right now. It would certainly be possible to use an XML interchange format to track such things but those are made for machines, not people, to read. In fact, the only human-friendly way that I can think of for dealing with it would be to build it into the authoring environment itself – to have a Git-like thing at the backend of (say) Moodle. At Athabasca we do kind-of the same sort of thing using Alfresco to track changes, but the process is clunky, discontinuous, lacks the elegant cooperation of GitHub, is very document-centric (no fine-grained merging at all), and is very much a group, not a network environment, with teams and roles that are anything but open and that exist in very rigid organizational hierarchies, with roles that limit what they can do, and only a single, unforked course as the outcome.
Perhaps such a project – to build that friendlier front end – might be what course takers might use as raw material. Early, and more advanced, takers of the course would be building the infrastructure for later students. I rather like the idea.
Address of the bookmark: https://medium.com/@benwerd/git-for-teachers-e993d2ca423d#.nqby85xqs
