A Better Way to Build a EdTech Support Wiki (or, Doctor, Heal Thyself)

This post is going to be a bit geeky, and a tad technical. So there’s your warning.

I’ve been thinking a lot about the forkable Domain of One’s Own wiki, with its GitHub underpinning. And I’ve been watching a lot of Ward Cunningham’s videos on the concept of federated wikis.

And the thing I’ve come to realize is the institutional educational technology unit support site is a perfect microcosm of our more general OER challenges. What do I mean? Here’s my support wiki:


And here’s Keene State’s site:


And here’s Thompson Rivers:


Here’s some UMW documentation on using digital audio:


Just as with class materials, the reusability paradox rears its ugly head. There are bits mixed into these sites that are very institution specific. The players site above links to some UMW-specific stuff. The Keene site mixes in announcements about local presentations with more generic pieces on using screencasting as a tool. These are small things, but the feeling of local integration is important to the faculty hitting these resources. You really do want the faculty reading the material on screencasting to finish the article with a link to someone on campus they can contact, and as silly as it is, you’d like the faculty to feel locally supported, so the prospect of everything being a link to other university’s websites is unappealing.

But the way we accomplish this is a bit ridiculous, really. We reinvent the wheel a dozen times a month so that we can get that 10% difference that preserves the impact we want.

Is there another way to get that balance? It’s possible that a federated approach could provide the impact of local integration with the efficiency (and culture) of syndication. Playing around with Cunningham’s radical version of federation has convinced me it’s a bit much for people to swallow at this point. But the basic principle — that instead of every page on a site have an edit button, there is a “clone” or “fork” button is compelling. In such a world, if I saw a useful article on screencasting from Judy Brophy at Keene State, I’d hit the “Clone This” button on it (or perhaps hit a scriptlet button in my browser), and pull it over to my own support site. There I’d edit it to make it fit my faculty needs better.

Here’s the important thing — cloned articles would retain their history and relation. So the pieces of this that were Judy’s would still be attributed on the back end to Judy automagically, and the edits that were mine would be attributed to me. Better yet, since my page is seen by the version control repository as a fork, when Judy updates her article to cover new versions of Jing (complete with updated screenshots) those edits are pushed to me to accept or reject. And when I link to things on my site from the cloned page, Judy can check if she would like to clone some of those pages into her own site.

I don’t quite know how to build this, but it seems to me that the work that UMW is doing with dokuwiki could be a step towards this sort of world. And it could form the basis of a solution to some persistent problems in ed-tech around balancing distributed production and local autonomy. Best of all, unlike the classroom, how we build our support wikis is completely within our control.

Does anyone want to look at this idea with me, head down the path with it a quarter-mile or so, and see if it’s worthwhile or completely cracked? In short, what we’re looking at is collaboration in a world where open-licensing and version-control software make forks much, much less painful to manage…

(Note: In addition to Ryan Brazzel and Tim Owens and Jim Groom, I am indebted to both Alan Levine and Brian Lamb who have talked before about embedded content which is the *syndicated* way of doing this, this is really just taking that a step further towards *federation*.)

9 thoughts on “A Better Way to Build a EdTech Support Wiki (or, Doctor, Heal Thyself)

  1. I think this is the idea of dedtech, distributed education technology. Helping folks get up and running with various resources quickly so they can actually focus on cultural change, We are totally into this. Reclaim Hosting, the soon to-be real Reclaim Your Domain, all our docs, etc. are just this. The key would be simply getting schools to put what they have in a systme they contol and mainatain, but can be available for any other group or individual to brose and fork.

    I’m down with it, I’m not sure I can push too much more than I am already because I am teaching and that kills all other projects in terms of time. But I think this would be a very interesting problem to struggle with for a bit.

  2. Hi Mike – glad that wordpress picked up on the link to my post. Tried a comment from my mobile but seems to have been lost in the ether. Thanks so much for this – it prompted me to write up my ideas – and I would be interested in working on something like you’re proposing. I’m really loving the ideas around federated & distributed content and am getting the sense that the technology is catching up to allow these models to actually be built and implemented, in a ways that can actually be managed to ensure attribution & fair use. I think the solutions are there now – some of the things Jim’s being doing has been pretty eye opening – but perhaps the thinking & the models just haven’t been applied to an education context – which is the perfect place to be cutting edge in my opinion. I’d be up for discussing idea further and seeing where we could take this!

  3. I also see a real benefit of this for Reclaim Hosting. It’s ironic that Jim and I have built a system completely modeled on the Domain of One’s Own project, and yet the documentation for DoOO is much richer at this point than the weak knowledgebase we have at Reclaim. Every time I think “we need to be doing a better job” I get jaded by the idea that it would essentially amount to me copy/pasting and rewriting what I’ve already written for UMW. The Dokuwiki/Github approach is a bit of a bandaid but I do think it could work in the short term towards something even more approachable long term. I’d love to experiment (and I hate that I missed the convo today around it). It’s a great time for us since, as I mentioned, I’m starting to rethink Reclaim documentation in light of all the new developments. I sure don’t want to reinvent the wheel again as you so rightly put it.

  4. I’ve helped some academics get a personal research wiki running. The federated wiki idea seems excellent there. I got started in dokuwiki as well (via http://reganmian.net/wiki/researchr:start) but have been playing with other static file solutions such as Jekyll. Would be eager to discuss further and put in some development time!

    • So cool, Ryan, I love the idea of a community growing up aroudn this, and working well beyond edtech documentation to suggest the value for academia at large. Also, I’m interested in the Jekyll stuff as well, so share widely 🙂

  5. Yes — Ryan and Tim, I’m working on some stuff right now, and would love to collab in the future. I’m also going to write up a thing about why wikis fail soon that I hope you’ll comment on and critique.

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Connecting to %s