Mike Caulfield has been writing up a storm on federated wikis, a tool where users maintain their own site , then copy/fork individual pages they want to keep or edit from other sites in their federation. Today Mike, Tony Hirst, and Boll Fitzgerald had an energetic discussion about when to fork and when not to fork in a federated wiki (particularly in Ward Cunningham’s Smallest Federated Wiki , henceforth referred to as SFW, the federated wiki sandbox of the moment)
I think there’s a semantic issue here. In a software context, you fork because you want to take the project a different direction, as opposed to submitting patches to the existing codebase. In a SFW context, a given wiki belongs to a particular individual, and only that individual can edit pages within that wiki. Clicking the fork button does two things
- Makes a copy of the page with the same name that you can edit as part of your wiki instance
- Starts tracking changes on the original
Even if you don’t intend to make changes, you may fork a page in order to have a local copy. As Mike points out, this is in and of itself a good thing.
Some of this concern about forking and changes stems from conceptualizing SFW as a publishing platform. Maybe this isn’t the right concept. Instead, I imagine a sort of public notebook that it’s very easy to copy from. Since it’s mine, I can keep any page in the state I want it, but anyone else can grab what they want while maintining at least some sourcing/changelog. In the discussion this morning, Mike mentioned that versioning a single document pushes a group of authors towards consensus, presumably since the system requires that one ends up with one document. Federated wikis show what can happen when that constraint is removed and people can create together individually. We’ve never really had that kind of tool. before. what might you do with it?
Mike’s demo SFW project, The Hidden History of Online Learning has been a fascinating introduction to the platform. The federation allows users to create and organize in whatever way makes the most sense to them and fork from others only what interests them. What if you took it another step.
Your wiki is your central learning repository. It allows access controls so you have public (your portfolio), restricted access (group collaboration) and private (your thesis first draft) pages, Into these pages you can drag all sorts of content . For that matter, you might be able to set permissions on each JSON object for very granular access control. You might then export content to a publication platform like a blog when it’s in a final form.