Current Design of the Federated Classroom Wiki as of Today

I’m realizing some of the design description of the Federated Classroom Wiki on Hapgood is out of date. So here is how it is currently working (or soon to work based on some scheduled coding). This is the process you would use as a user.


  1. Install! Your institution installs Dokuwiki on a server, on a PaaS, or other vehicle. Wherever you want with whoever you want. (You can do any step here as an individual as well, just dealing with institutional case here).
  2. Extend! Your institution installs the two custom plugins I’ve written (federation and clone) and the freely available gitbacked plugin
  3. Federate! You go to the federation GitHub site (e.g., though you can make others). You fork it, add your self-named folder to it (ex. UofUT, UVU, NIU, UMW, whatever), then issue a pull request to accept that change. You point this new folder to your dokuwiki pages folder (via gitbacked). There’s some finessing here that Tim will show in a screencast soon, but what you’ll end up with after Tim’s magic is done is a system where your changes to your wiki will flow into the subfolder. Then all pages from all federated wikis will flow into a special subfolder/namespace of your wiki called alternate. This will be searchable by people with editing permissions (although you can set permissions up any way you want, really).


  1. Search! Now you are about to write a syllabus, or assign your students to write an article. You think — wouldn’t it be nice to just tweak a syllabus, or give my students an article to *extend*? You go and search the :alternate: namespace for federation content you can use. You find some great articles your students can improve, and a syllabus that is a good starting point.
  2. Clone! You clone the articles and the syllabus to your public wiki/course namespace. The revision record follows the documents so that attribution is taken care of.
  3. Edit! You tweak the documents to your own needs. You write additional documents.
  4. Feed Forward! Here’s the neat part — because you are federated, feed forward isn’t actually a step. All the changes you make feed back into the federation as alternate versions of the documents you cloned. The person whose docs you cloned gets a message in their revisions history that you cloned it, and is automatically pointed to your revisions to see if they are useful. Your other original docs you made also flow back to the federation. The next person who searches will see your alt-versions and new documents, and maybe end up cloning those. Lather, Rinse, Repeat.

There are possibly classroom systems which already do similar things, though I’ve never seen them do this well. The fundamental difference here is the structure that makes it possible. This is not a service that everyone has to agree on to be a part of. It’s a federation — you have absolute control over who is in your community and what they can do and where your instance lives and how it’s branded. You are self-governing, an island. But on the back-end the architecture creates a system of sharing by default that gives you the benefits of working with a community without having to make institutional or individual compromises. The contract is simple– all this stuff will flow to you if you let your stuff flow back. Think of it sort of like torrenting — you get your download speed by letting others download from you.

There’s lots of reasons I’ve come to feel that this point is crucial for the expansion of higher ed collaboration, but that’s another post.

6 thoughts on “Current Design of the Federated Classroom Wiki as of Today

  1. This is pretty cool. One simple addition that could make a big difference is to add an optional field where the person editing their page can make notes about the reasons for their changes. Most people won’t use it, but it creates at least the opportunity for a discussion to develop around the changes. Longer term, what I think would be cool is a version of the “discuss” pages for Wikipedia articles that is appropriate for this distributed model. I don’t know Github, but I bet there is infrastructure in place for commenting on forks.

  2. Great idea! Can absolutely add a note field for the change — you get it on every other edit, just a matter of exposing that functionality at the clone point.

    The discussion page piece is an issue with the forking –We have discussion pages for individual pages, but not across clones. And I’m not sure we want them across clones — if I fork your GEOG 239 (Cultural Geography) for my ANTH 421 (The Anthropology of Place) I probably want out of the discussions. I’d thought of linking people back to the original pages for discussion, but one of the fundamental principles is that they don’t have comment rights on other systems besides the gardened wiki.

    What we’re thinking right now is that the “gardened” wiki is the place for discussion. So if you’ve got a great version of GEOG 239, you go and add your edits to the gardened wiki. Anyone interested in those updates can set a watch on the page and discuss them. Since this is not a cheerocracy, the wiki gardener can be the final arbiter, but even the discussion will alert others that they can adopt those changes on the local instance regardless of the way the gardened wiki goes.

    Actually this just gave me another idea for far future — cloning a previous revision. But much later, got to get cloning to subdirectories working first…;)

  3. It is the best time to make some plans for the future and it’s time to
    be happy. I’ve read this post and if I could I wish to suggest
    you some interesting things or tips. Perhaps you can
    write next articles referring to this article.
    I wish to read even more things about it!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s