CommunityWiki: Branching Wiki

Related to the quest for a ViewPoint like system, it might be interesting to keep in mind the possibility of a wiki in which pages could be forked (or branched) into multiple concurrent versions.

Problems this helps to solve:

Edit conflicts (and high traffic)
Cluttered pages;
- Perhaps it would be easier to refactor a page if you literally split it temporarily into separate factors and then simplified each of those, with each factor represented in a different branch.
- This way multiple people could refactor a cluttered page in a few different ways, and then the community can decide later which way of doing it was best (or, more likely, create a composite).
Moderation schemes
- For instance, if you wanted some changes to be checked over somehow before becoming live, those changes would sit in a branch until being accepted into the main trunk.

Disadvantages:

Some way must be found to merge the pages. In my view, branches of a single page should never become permanent (unless one of the branches is renamed and so becomes a new page). (in the case in which there are different ways to look at the same issue, a system of “facets” is more appropriate than “branches”).
Even if merging is made efficient, there will be the temptation to leave separate branches open rather than to bother to merge.
Confusingness.
It might work against the wiki principle of gradual improvement – it’s easy to just make your own version instead of working together on the common text. Mergng is always possible, but usually involves a conscious decision and often quite a lot work.

How to do it?

Software

A CVS or similar backend
- Known wikis which support a CVS or Arch backend (which may be a good starting place for a BranchingWiki):
  - AtisWiki (see Wiki:AtisWiki)
  - CVWiki (see Wiki:CVWiki)
  - DevWiki (see Wiki:DevWiki)
  - JSPWiki (partial)
  - ServletBasedWiki (in development; see Wiki:ServletBasedWiki)
  - PyleWiki
  - TinyWiki
  - MoinMoin? (http://c2.com/cgi/wiki?WikiMoinMoinReviewZeroFive indicates that it can work with CVS)
  - IkiWiki (http://ikiwiki.info/) - more a wiki compiler (converting wiki pages into HTML pages) but supporting git and subversion
  - By extension, any wiki which stores the pages as simple text files and which can deal with the files being changed from the outside, or any wiki with a sufficiently pluggable backend such that a CVS extension would be trivial.
- Known wikis supporting branching in a nice way
  - Gazest (http://ygingras.net/gazest) “Gazest tries to be better by not flattening the history of changes. This storage model is heavily inspired by distributed revision control systems like Git and Mercurial”

Merging

See also MergingAutomatically?. See also the Arch revision control system and its fancy merge schemes.

Other

I should note that although I am moderately interested in this for normal wikis as an EditConflict resolution method for high traffic sites (such as a wiki news site on the order of slashdot), I’m also interested in it for CommunityProgrammableWiki.

– BayleShanks

Note that a CVS based wiki would also allow branches whose origin is past versions of a page. I can’t see what good this does, though (outside of the CommunityProgrammableWiki context); I guess this emergent “feature” wouldn’t be used much.

Also, according to my understanding of CVS, you can’t easily “forget” old VersionHistory, right? So the forgetting part of KeptPages would have to be added as an extra feature (and in the case of CommunityProgrammableWiki, could be subverted). But the WaybackMachine at InternetArchive allows subversion of ForgiveAndForget anyway if you really care, so that doesn’t bother me.

– BayleShanks

"alternatives"

I had a similar idea, “alternatives”, where you could make an alternative paragraph or section or page. You could use this for language tranlations for instance. Or with different terminology or something. Or just a competing version (useful for something like wikipedia?). This could also let you set up a possible merge or change but not finalize it quite yet. Alternatives would be identified with some attributes that you could select, e.g. in a cookie, so each page request selects the alternatives you want. But there would still be a main or original version. This lets the UI be a bit less confusing perhaps.

– ReedHedges

The point is that branching is easier: less likely to step on someone’s toes, less work, and you are still contributing – so you get the good feeling of doing something for the community. I think that refactoring is the most essential thing in the wiki – the point is to be forced to do it in order to speak. This way you not only have to try and understand the text of others, but you also need to actually think about what is good and bad in it and how to improve it. It’s a different way of thinking than the one needed for conversation or essay writing. Of course, not all wikis are like that and branching may be exactly the thing they need. At the same time at other wikis branching might just provide an easy way out of conflict – way that doesn’t lead to mutual understanding and even agreement.

SamRose

RefactoringVsBranching

That does make sense, Radomir. If you make both available, it is probably likely that most people will take the PathOfLeastResistance.

I wonder, though, if there may be applications where branching is preferable? I can think of some examples, such as a psychology experiment, where you might ask people to write conceptualizations. But, then again, I guess you really don’t need wiki in particular for those applications. So, “branching” could be accomplished via an application like Drupal’s “book” module, which lets users create “child” pages off of a main page, for instance, and creates a built in navigable hierarchy. The only process that might come close could be a like a “branch merging” process. But this would be limited, I think. And refactoring in wiki would actually be quicker.

So, I agree with you Radomir, that wiki is better used in a refactoring pattern, than a “branching” pattern. I also agree with you about the way that refactoring forces you to think about the content.

Found wikiri a simple wiki engine written in Python using git as backend for history. That could be used for testing BranchingWiki using the nifty branching from git.

CategoryWikiTechnology CategoryUnimplementedWikiFeature? CategoryRevisionControlBasedWiki