Federated Wikis – A Use Case

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

  1. Makes a copy of the page with the same name that you can edit as part of your wiki instance
  2. 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.

3 thoughts on “Federated Wikis – A Use Case

  1. “Starts tracking changes on the original”

    Does it? Or in the SFW case does it track changes to other copies of the page too? I can imagine several sources of change to these loose entity we are calling “the page”:

    – copies/”forks” made of my page;
    – copies/”forks” made of the page I copied after I first copied/”forked” it;
    – copies/”forks” made of the page I copied before I first copied/”forked” it;
    – copies made of any of those copies, and copies of those copies, ad inf.

    • I think it shows you any changes within the federation (SFW calls it a neighborhood) made to pages with that name. Your page remains unaltered unless you click fork on a page with the same name. Caveat: Mike is the expert and could probably give a more authoritative answer.

      • So is that federation *all* pages with the same name (and cloning/forking etc keeps a page with the same name? Can you change a page name? What happens then, if so? Can you delete your copy of a page? Can you clone a copy of your own page?!)

Leave a Reply

Your email address will not be published. Required fields are marked *