I ran across this paper via the Human Current interview with Cesar Hidalgo. In general they studied GitHub as a learning community and the social support of people’s friends on the platform as they worked on learning new programming languages.
I think there might be some interesting takeaways for people looking at collective learning and online pedagogies as well as for communities like the IndieWeb which are trying to not only build new technologies, but help to get them into others’ hands by teaching and disseminating some generally tough technical knowledge. (In this respect, the referenced Human Current podcast episode may be a worthwhile overview.)
I’ve seen the five R’s used many times in reference to the OER space (Open Educational Resources). They include the ability to allow others to: Retain, Reuse, Revise, Remix and/or Redistribute content with the appropriate use of licenses. These are all some incredibly powerful building blocks, but I feel like one particularly important building block is missing–that of the ability to allow easy accretion of knowledge over time.
Some in the educational community may not be aware of some of the more technical communities that use the idea of version control for their daily work. The concept of version control is relatively simple and there are a multitude of platforms and software to effectuate it including Git, GitHub, GitLab, BitBucket, SVN, etc. In the old days of file and document maintenance one might save different versions of the same general file with increasingly different and complex names to their computer hard drive: Syllabus.doc, Syllabus_revised.doc, Syllabus_revisedagain.doc, Syllabus_Final.doc, Syllabus_Final_Final.doc, etc. and by using either the names or date and timestamps on the file one might try to puzzle out which one was the correct version of the file that they were working on.
For the better part of a decade now there is what is known as version control software to allow people to more easily maintain a single version of their particular document but with a timestamped list of changes kept internally to allow users to create new updates or roll back to older versions of work they’ve done. While the programs themselves are internally complicated, the user interfaces are typically relatively easy to use and in less than a day one can master most of their functionality. Most importantly, these version control systems allow many people to work on the same file or resource at a time! This means that 10 or more people can be working on a textbook, for example, at the same. They create a fork or clone of the particular project to their personal work space where they work on it and periodically save their changes. Then they can push their changes back to the original or master where they can be merged back in to make a better overall project. If there are conflicts between changes, these can be relatively easily settled without much loss of time. (For those looking for additional details, I’ve previously written Git and Version Control for Novelists, Screenwriters, Academics, and the General Public, which contains a variety of detail and resources.) Version control should be a basic tool of every educators’ digital literacy toolbox.
For the OER community, version control can add an additional level of power and capability to their particular resources. While some resources may be highly customized or single use resources, many of them, including documents like textbooks can benefit from the work of many hands in an accretive manner. If these resources are maintained in version controllable repositories then individuals can use the original 5 R’s to create their particular content.
But what if a teacher were to add several new and useful chapters to an open textbook? While it may be directly useful to their specific class, perhaps it’s also incredibly useful to the broader range of teachers and students who might use the original source in the future? If the teacher who forks the original source has a means of pushing their similarly licensed content back to the original in an easy manner, then not only will their specific class benefit from the change(s), but all future classes that might use the original source will have the benefit as well!
If you’re not sold on the value of version control, I’ll mention briefly that Microsoft spent $7.5 Billion over the summer to acquire GitHub, which is one of the most popular version control and collaboration tools on the market. Given Microsofts’ push into the open space over the past several years, this certainly bodes well for both open as well as version control for years to come.
A Math Text
As a simple example, lets say that one professor writes the bulk of a mathematics text, but twenty colleagues all contribute handfuls of particular examples or exercises over time. Instead of individually hosting those exercises on their own sites or within their individual LMSes where they’re unlikely to be easy to find for other adopters of the text, why not submit the changes back to the original to allow more options and flexibility to future teachers? Massive banks of problems will allow more flexibility for both teachers and students. Even if the additional problems aren’t maintained in the original text source, they’ll be easily accessible as adjunct materials for future adopters.
One of the most powerful examples of the value of accretion in this manner is Wikipedia. While it’s somewhat different in form than some of the version control systems mentioned above, Wikipedia (and most wikis for that matter) have built in history views that allow users to see and track the trail of updates and changes over time. The Wikipedia in use today is vastly larger and more valuable today than it was on its first birthday because it allows ongoing edits to be not only improved over time, but those improvements are logged and view-able in a version controlled manner.
This is another example of an extensible OER platform that allows simple accretion. With the correct settings on a document, one can host an original and allow it to be available to others who can save it to their own Google Drive or other spaces. Leaving the ability for guests to suggest changes or to edit a document allows it to potentially become better over time without decreasing the value of the original 5 Rs.
Webmentions for Update Notifications
As many open educational resources are hosted online for easy retention, reuse, revision, remixing, and/or redistribution, keeping them updated with potential changes can potentially be a difficult proposition. It may not always be the case that resources are maintained on a single platform like GitHub or that users of these resources will necessarily know how to use these platforms or their functionality. As a potential “fix” I can easily see a means of leveraging the W3C recommended specification for Webmention as a means of keeping a tally of changes to resources online.
Let’s say Robin keeps a copy of her OER textbook on her WordPress website where students and other educators can easily download and utilize it. More often than not, those using it are quite likely to host changed versions of it online as well. If their CMS supports the Webmention spec like WordPress does via a simple plugin, then by providing a simple URL link as a means of crediting the original source, which they’re very likely to do as required by the Creative Commons license anyway, their site will send a notification of the copy’s existence to the original. The original can then display the webmentions as traditional comments and thus provide links to the chain of branches of copies which both the original creator as well as future users can follow to find individual changes. If nothing else, the use of Webmention will provide some direct feedback to the original author(s) to indicate their materials are being used. Commonly used education facing platforms like WordPress, Drupal, WithKnown, Grav, and many others either support the Webmention spec natively or do so with very simple plugins.
One of the issues some may see with pushing updates back to an original surrounds potential resource bloat or lack of editorial oversight. This is a common question or issue on open source version control repositories already, so there is a long and broad history of for how these things are maintained or managed in cases where there is community disagreement, an original source’s maintainer dies, disappears, loses interest, or simply no longer maintains the original. In the end, as a community of educators we owe it to ourselves and future colleagues to make an attempt at better maintaining, archiving, and allowing our work to accrete value over time.
The 6th R: Request Update
In summation, I’d like to request that we all start talking about the 6 R’s which include the current 5 along with the addition of a Request update (or maybe pull Request, Recompile, or Report to keep it in the R family?) ability as well. OER is an incredibly powerful concept already, but could be even more so with the ability to push new updates or at least notifications of them back to the original. Having the ability to do this will make it far easier to spread and grow the value of the OER concept as well as to disrupt the education spaces OER was evolved to improve.
This week, using the magic of open web standards, I was able to write an issue post on my own website, automatically syndicate a copy of it to GitHub, and later automatically receive a reply to the copy on GitHub back to my original post as a comment there. This gives my personal website a means of doing two way communication with GitHub.
This functionality is another in a long line of content types my website is able to support so that I’m able to own my own content, yet still be able to interact with people on other websites and social media services. Given the number of social sites I’ve seen disappear over the years (often taking my content with them), this functionality gives me a tremendously larger amount of control and ownership over my web presence and identity while still allowing me to easily communicate with others.
In this post I wanted to briefly sketch what I’ve done to enable this functionality, so others who are so inclined can follow along to do the same thing.
Setting up WordPress to syndicate to GitHub
I’ll presume as a first step that one has both a GitHub account and a self-hosted WordPress website, though the details will also broadly apply to just about any content management system out there that supports the web standards mentioned.
Register your GitHub account and your website with Bridgy
Ryan Barrett runs a fantastic free open sourced service called Bridgy. To use it you’ll need the microformat rel=“me” links on both your GitHub account and your website’s homepage that point at each other. GitHub will do most of the work on its side for you simply by adding the URL of your website to the URL field for your GitHub account at https://github.com/settings/profile. Next on your website’s homepage, you’ll want to add a corresponding rel=“me” link from your website to your GitHub account.
In my case, I have a simple widget on my homepage with roughly the following link: <a href="https://github.com/username">GitHub</a>
in which I’ve replaced ‘username’ with my own GitHub username. There are a variety of other ways to add a rel=“me” link to your webpage, some of which are documented on the IndieWeb wiki.
Now you can go to Brid.gy and under “Connect your accounts” click on the GitHub button. This will prompt you to sign into GitHub via oAuth if you’re not already logged into the site. If you are already signed in, Brid.gy will check that the rel=“me” links on both your site and your GitHub account reciprocally point at each other and allow you to begin using the service to pull replies to your posts on GitHub back to your website.
To allow Brid.gy to publish to GitHub on your behalf (via webmention, which we’ll set up shortly), click on the “Publish” button.
Install the Webmention Plugin
The underlying technology that allows the Bridgy service to both publish on one’s behalf as well as for the replies from GitHub to come back to one’s site is an open web standard known as Webmention. WordPress can quickly and easily support this standard with the simple Webmention plugin that can be downloaded and activated on one’s site without any additional configuration.
For replies coming back from GitHub to one’s site it’s also recommended that one also install and activate the Semantic Linkbacks Plugin which also doesn’t require any configuration. This plugin provides better integration and UI features in the comments section of one’s website.
Install Post Kinds Plugin
The Post Kinds Plugin is somewhat similar to WordPress’s Post Formats core functionality, it just goes the extra mile to support a broader array of post types with the appropriate meta data and semantic markup for interacting with Bridgy, other web parsers, and readers.
Download the plugin, activate it, and in the plugin’s settings page enable the “Issue” kind. For more details on using it, I’ve written about this plugin in relative detail in the past.
Install Bridgy Publish Plugin
One can just as easily install the Bridgy Publish Plugin for WordPress and activate it. This will add a meta box to one’s publishing dashboard that, after a quick configuration of which social media silos one wishes to support, will allow one to click a quick checkbox to automatically syndicate their posts.
Install the Syndication Links Plugin
The Syndication Links plugin is also a quick install and activate process. You can modify the settings to allow a variety of ways to display your syndication links (or not) on your website if you wish.
This plugin will provide the Bridgy Publish Plugin a place to indicate the permalink of where your syndicated content lives on GitHub. The Bridgy service will use this permalink to match up the original content on your website and the copy on GitHub so that when there are replies, it will know which post to send those replies to as comments which will then live on your own website.
You should now be ready to write your first issue on your website, cross post it to GitHub (a process known in IndieWeb parlance as POSSE), and receive any replies to your GitHub issue as comments back to your own website.
Create a new post.
In the “Kinds” meta box, choose the “Issue” option.
Type in a title for the issue in the “Title” field.
In the “Response Properties” meta box, put the permalink URL of the Github repopository for which you’re creating an issue. The plugin should automatically process the URL and import the repository name and details.
In the primary editor, type up any details for the issue as you would on GitHub in their comment box. You can include a relatively wide variety of custom symbols and raw html including
and with code samples which will cross-post and render properly.
In the GitHub meta box, select the GitHub option. You can optionally select other boxes if you’re also syndicating your content to other services as well. See the documentation for Bridgy and the plugin for how to do this.
Optionally set any additional metadata for your post (tags, categories, etc.) as necessary.
Publish your post.
On publication, your issue should be automatically filed to the issue queue of the appropriate GitHub repo and include a link back to your original (if selected). Your post should receive the syndicated permalink of the issue on GitHub and be displayed (depending on your settings) at the bottom of your post.
When Bridgy detects future interactions with the copy of your post on GitHub, it will copy them and send them to your original post as a webmention so that they can be displayed as comments there.
If you frequently create issues on GitHub like this you might want a slightly faster way of posting. Toward that end, I’ve previously sketched out how to create browser bookmarklets that will allow you one click post creation from a particular GitHub repo to speed things along. Be sure to change the base URL of your website and include the correct bookmarklet type of “issue” in the code.
The Post Kinds plugin will also conveniently provide you with an archive of all your past Issue posts at the URL http://example.com/kind/issue/, where you can replace example.com with your own website. Adding feed/ to the end of that URL provides an RSS feed link as well. Post Kinds will also let you choose the “Reply” option instead of “Issue” to create and own your own replies to GitHub issues while still syndicating them in a similar manner and receive replies back.
Given the general set up of the variety of IndieWeb-based tools, there are a multitude of other ways one can also accomplish this workflow (both on WordPress as well as with an infinity of other CMSes). The outline I’ve provided here is one of the quickest methods for beginners that will allow a relatively high level of automation and almost no manual work.
One doesn’t necessarily need to use the Post Kinds Plugin, but could manually insert all the requisite HTML into their post editor to accomplish the post side of things via webmention. (One also has the option to manually syndicate the content to GitHub by cutting and pasting it as well.) If doing things manually this way is desired, then one will need to also manually provide a link to the syndicated post on GitHub into their original so that Bridgy can match up the copy and the original to send the replies via webmention.
If you’ve followed many of these broad steps, you’ve given already given yourself an incredibly strong IndieWeb-based WordPress installation. With a minimal amount of small modifications you can also use it to dovetail your website with other social services like Twitter, Facebook, Flickr, Instagram, Google+ and many others. Why not take a quick look around on the IndieWeb wiki to see what other magic you can perform with your website!
I’ve documented many of my experiments, including this one, in a collection of posts for reference.
If you have questions or problems, feel free to comment below or via webmention using your own website. You can also find a broad array of help with these plugins, services, and many other pieces of IndieWeb technology in their online chat rooms.
This has to be the most awesome Indieweb pull request I’ve seen this year.
WithKnown is a fantastic, free, and opensource content management service that supports some of the most bleeding edge technology on the internet. I’ve been playing with it for over two years and love it!
And today, there’s another reason to love it even more…
This is also a great reminder that developers can have a lasting and useful impact on the world around them–even in the political arena.
Oddly, I had seen the VERY same post/repo a few weeks back and meant to add a readme too! (You’ll notice I got too wrapped up in reading through the code and creating some usability issues after installing the plugin instead.)
Given that you’ve got your own domain and website (and playing in ed/tech like many of us are), and you’re syndicating your blog posts out to Medium for additional reach, I feel compelled to mention some interesting web tech and philosophy in the #IndieWeb movement. You can find some great resources and tools at their website.
In particular, you might take a look at their WordPress pages which includes some plugins and resources you’ll be sure to appreciate. One of their sets of resources is allowing you to not only syndicate your WP posts (what they call POSSE), but by using the new W3C webmention spec, you can connect many of your social media resources to brid.gy and have services like twitter, facebook, G+, instagram and others send the comments and likes on your posts there back to your blog directly, thereby allowing you to own all of your data (as well as the commentary that occurs elsewhere). I can see a lot of use for education in some of the infrastructure they’re building and aggregating there. (If you’re familiar with Known, they bake a lot of Indieweb goodness into their system from the start, but there’s no reason you shouldn’t have it for your WordPress site as well.)
If you need any help/guidance in following/installing anything there, I’m happy to help.