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:
See also MergingAutomatically?. See also the Arch revision control system and its fancy merge schemes.
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.
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.
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.
See also Wiki:ChangeManagementAppliedToWiki.
See also HighTrafficWiki.
You may want to see also Wiki:VersionControlAppliedToWiki, although I don’t think there’s much on that page that’s needed here.
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.
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.