I’m hardly the first person to ponder ways to use the software collaboration site GitHub in a context outside of software development. There’s been a series of Chronicle of Higher Education pieces on “forking the syllabus”. There is Gitbook as a front end for using the approach for writing books.

While I have used GitHub a few years to hang out my software projects, managed to get one service running rather elegantly in GitHub Pages, I have to say, even as someone who is supposed to be a technologist, rather baffled on how it works, especially in a collaborative environment.

Recently fellow tinkerer John Johnston wrote a similar piece on his own Git head scratching — The Git Zone. It triggered a serious of responses of various agreement / disagreement from Ben Wedmüller, from Greg McVerry, from Adam Croom, and more.

The best outcome is that, as he does so well, John did not sit on a mushroom and pontificate– he went out and made something- see the puppies, oh the puppies. (by the way, his experiment does goats very well, you are welcome).

I have to say, that as a general statement, GitHub is a terrible “tool for education”. By that I mean that just applying or throwing GitHub into an educational process, like tossing of magic solutionist fairy dust, is kind of worthless, unless you are teaching software development, or you have a teaching environment where you desire confusion, mayhem, and WTFness.

But… I am trying to use it in a new project.

The problem is that, with tools, we often do not need the whole shebang. It’s less important to Git on some kind of GitWagon, and a better approach is to find and tap into the specific capabilities/affordances of a tool, and seeing how you can ease the entry point into it.

When Paul Stacey outlined the idea of the Creative Commons Certification project I am working on (we are working on getting a web site up, see his post on the CC blog for a general overview), parts of it spoke to me as partly something the GitHub (or more generally the git) process had an appeal. We are creating a Core or Master Creative Commons Certification, which will then be modified (think “forked”) for specialize versions for sectors like higher education, libraries, and government. We also envision what is created to be publicly available, more in a source code sense than a “download a PDF” sense, and could also be customized even farther, e.g. other sectors, for other locations in the world, (more and more forkage) by anyone else.

Keep in mind, this is a year and a half project, and it is highly conceptual.

And I am not announcing YES THIS PROJECT WILL BE HOISTED ON GITHUB. But there are attributes of the environment that appeal, beyond forking, beyond being open, there is the way that every change is tracked, revertable, that each individual’s contribution is built in (different from anonymous wiki editing), that there is an ecosystem of other tools to add to the mix (e.g. Gitter, Waffle, ZenBoard).

But GitHub, to most mortals, is anywhere from baffling to terrifying as an experience. How can the barrier of participation be made lower? I ran a call for people to try some simple silly forking. End result, a bunch of retweets, and the only people who actually forked something already have participated via GitHub on my other projects.

No white flags hoisted yet. Mainly because digging in deeper leads me to enough understanding to be able to frame it in a way people can grasp, or wake up and smell the goat poop to give it up.

GitHub is not my destination.

And this may be the longest introduction to what I intended to write about. If you are the Skip the Narrative and Explore ilk, off you go http://cogdog.github.io/ccc-map/.

If you prefer a video walk through…

And if you like my long winded written explanations, scroll on. In the project planning process, before I came on board, Paul and a few others had a brainstorming session to develop a Draft set of Creative Commons Certification specifications for what is now called the “Master Certificate” (I have to admit, I loathe the “master” language, I have been calling it myself “core”).

It’s in a giant spreadsheet that Paul reports is 8 feet wide when printed, and includes a set of seven core topical modules, in each is a set of seven to fifteen Performance Objectives, and in each of those are 0-10 “Enabling Objectives”.

A next step requires a 3 dimensional spreadsheet, to allow for a place in each of the granular Enabling Objectives to be filled out with examples of OER material that could be used to teach/learn the objective, and ideas for assemble activities that would satisfy some means of credentialing (how that is done is ahead of us).

In my bids to understand publishing GitHib Pages, I had an idea that could use some jQuery widget things to make the modules “tabs” that would open a series of “accordions” to reveal more information. Or I have collapsed (and expanded) that spreadsheet into this:

The "core" map- modules are tabs that open from left, each tab opens a series of accordions for objectives, themselves each opening more for sub-objectives

The “core” map- modules are tabs that open from left, each tab opens a series of accordions for objectives, themselves each opening more for sub-objectives

This is made possible by the Zozo Tabs and Zozo Accordions jQuery plugins (there is another tricky issue since those are licensed plugins, and should only be used if you licensed them yourself) (to be figured out).

At the part where we want people to edit/contribute is a stub of HTML, with the idea that anyone interested in adding would do so in GitHub:


This is where the Zozo plugin came in handy. I originally thought this would be a mega single HTML file, full of comments to show where to edit. But I discovered by randomly reading the documentation, that the contents of an accordion could be loaded via ajax. This means I am breaking it up into tiny, potentially editable pieces.

Breaking the content into little pieces

Breaking the content into little pieces

And I figured out a way to dynamically construct the link to edit the source in GitHub. The content for Module 2, Performance Objective 2.3, Enabling Objective 2.3.3 or “Give examples of digital commons” has some code at the bottom to identify it:

[sourcecode lang=”javascript”]


A more clever programmer might have parsed it from just the objective_item value, or better, the file name 2.3.3.html. But this is not quite the clever coding stage (like I have ever been there).

But I have a library function setSectionNumbers() that when the content loads, it fills in with jQuery some page elemnts, like the edit link:


So my first effort linked each small part we wanted input on to go to a link that opened the content in GitHub:

edit in github

But there we have some barriers. First is you need a GitHub account. That’s easy to deal with. But next, if you click the edit, you are prompted to fork the site, make edits, and submit a pull request. My thought was then, for people who might do more than a few edits, I add them as a collaborator to the project, then they can just edit, and their changes go into the project.

Yet still, there is the hurdle of editing HTML.

So then I back pedaled. We just want people to be able to submit ideas, and resources, not necessarily edit HTML. So I changed the link, so rather than going to edit the content, it loads the Github issues editor. A little more jQuery poking around made it so I could load the objective number and it’s title automatically as the topic.

But them even more goodness- I can create a GitHub Issues Template so there is some structure to what we ask people to write:


And I could add to the interface a link to some guidelines (it’s a draft for now, but will be improved).

So now, all someone has to do is type in a box, no more difficult than writing a blog comment. And on the GitHub project site, I can respond to the suggestion with a comment, I can assign it to someone to edit, I can categorize it, etc:


And because some people will still be okay with Githubbing, I left the link to the source edit in the site (the grayer gear icon on the right).

At this point, I am not sure I have made collecting input more complex than it needs be. I could have done a web form. Or just an open Google Doc (which always end up messy). Part of this is for me to dig in more to the GitHub environment, publishing, but more so, to speculate if I can make use of its affordances without forcing people to figure out forks, branches, repos and such.

It’s an experiment. I might just have to call in some goats.

Top / Featured Image: Screenshot of a google image search (filtered for licensed for reuse) on the broad word “get”. Strangely enough, many of the results feature goats. Is this a language thing? Anyhow, the lead on this result fit well Gratis foto: Get, Getter, Kid, Söt - Gra....

The large goat image itself is licensed public domain from Pixabay. And it’s cute.

Originally posted at CogDogBlog http://cogdogblog.com/2016/04/getting-gitting-or-goating/

Profile Picture for Alan Levine
Technologist, open web advocate, attributes nearly everything, wordpresser, photographer, dog lover, blogging since 2003 at cogdogblog.com. My role on this project is technology development, outward communications, and occasional silly video.