Hi,

All article development in Wikipedia follows the strict linear versioning system - each version builds on the one before it. The software enforces this model and potential conflicts are dealt with in such a manner as to avoid any branching or multiple concurrent versions of an article. I work for a company developing a tool designed to support having multiple versions of text, and thought that I could write an interesting blog posting about how one could use our software to enhance a site like Wikipedia.

However, after spending a whole day just going through Wikipedia entries I couldn't find a good example that would support this. I'm sure there must have been some situations in Wikipedia history where important changes to an article have been lost because of the nature of linear editing, or just a generally allowing editors to work in parallel on an article would have helped. Or is Wikipedia inherently a linear tool? What is cause and effect here?

Ok, I'm not sure if I'm making much sense Have a look at what we ended up blogging on : http://www.textflow.com/blog/?p=92
and if anyone knows of problematic Wikipedia entries that might match what we are talking about in the blog, I'd love to hear about it.

Regards,

Mark.

Wikipedia does have a system to mostly try to handle cases where one editor is working on one section of the article and another is working on another section at 'the same time' (i.e. the second editor starts editing before the first one has saved) - and when that doesn't work it presents as screen showing what happened and allowing them to redo their changes.

It's not clear what exactly you're expecting a system to do differently if two people are editing the same paragraph - automatically create a jumbled-up mess of random words?

Welcome Mark.

I have trouble imagining what a non-linear wiki collaboration might look like. Might this mean multiple alternative articles? Perhaps several threads of "versions" with one being selected as the accepted article but fundamentally differing approaches developing independently and periodically being permitted to contend for "the top spot?" The Blog cited seems to say something like this but perhaps the sorting out being a level of "chunks" of the article and not complete articles. Given the nature of an encyclopedia it would seem to be a problem to offer multiple versions all on equal footing.

Maybe I completely miss your approach. Could you elaborate?

Welcome

It sounds like what you're describing is something along the lines of Google Knol, with alternative versions of articles. I can't envision a non-linear wiki (while many people have problems with Wikipedia's content, I don't think anyone has any major problems with the software itself); if you mean the ability to view former versions of the article, that already exists via the "history" tab. I'd imagine a Wikipedia-size project that allowed multiple live versions would be unworkable. (The scale of Wikipedia – about to hit 3 million articles – dwarfs every similar project).

Sometimes they goes very sensetive about the aricle is set up if you change it, even if you change it from hard to read to nice to read.

Here's a stab at a serious answer. First, there is an issue of definition -- "concurrent" meaning what we might term "micro-concurrent", i.e. two people editing a page truly simultaneously, and getting an "edit conflict" from the Wiki software. Another view of "concurrent" editing, and the one your software seems to support, which we might call "macro-concurrent", is akin to Version Control Systems, where separate versions are maintained and edited over long periods of time, with the goal of re-integration at some juncture in the future.

The first is dealt with, inelegantly but sufficiently, by the Wiki software. It gives you an edit conflict notification, determines whether the edit is in conflict, and potentially allows you to re-submit the edit. It doesn't work well, but it's not an overly common occurrence in article space, and crops up mostly when the yammering classes on WP are arguing with each other on talk pages.

The second case -- the "macro-concurrency" -- is specifically disallowed in the Wiki culture. See WP:POVFORK (T-H-L-K-D). If Wikipedia allowed "POV forking" -- essentially concurrent copies of contentious articles representing different points of view -- it would cease to function in even the minimal way it does now. Unlike (e.g.) software source code, legal documents, or whatever, there is no incentive for a re-merging of the forked article. The partisans or fringe nutcases who split the article to begin with will keep it alive, and the partisans on the other side will keep it out of the "main" article. Therein lies the rub -- there is no way in Wikipedia's namespace to denominate the "main" article. They all get googled, mirrored, and branded with WP's dubious stamp of authority. So the article Evolution (T-H-L-K-D) that talks about Darwin, etc, would be on an equal footing with another article of the same or similar name that argues evolution is all a hoax. Perhaps more instructively, the article on (e.g.) Palestine (T-H-L-K-D) written by the two sides in that conflict would bear little resemblance to one another, and (even moreso than now) neither would much resemble the objective, academic, generally-accepted position.

Every vested interest in WP is against this, and here's why: if Wikipedia enfranchised these alternative (fringe, partisan, call them whatever) articles, then the administrative power structure would cease to have a powerful weapon with which to ban people (there would be no edit-warring, just creation of alternate articles), and the utter unreliability of Wikipedia would leap to the forefront. Who would continue using WP as a reference work once you had to read two or six or twenty-seven versions of the article on God (T-H-L-K-D) before finding something reasonable? Right now WP manifests what you might call "the aura of authority" by presenting a single article on, say, Israel (T-H-L-K-D), and the ill-informed might read such an article, together with WP's self-generated hype, and enter the Wikipedia Reality Distortion Field™, and assume that article represents some accepted, widely-held views. Little do they know (c.f. the current ArbCom case) that articles like that are hotbeds of partisan chicanery and spin-doctoring by zealots in favor and against various positions, some backed up by powerful WikiWarLords.

So the bottom line is that your version of concurrent versions would destroy Wikipedia as we know it --- so I'm all for it!

In cases where the community is hopelessly split (i.e., pretty much any non-trivial topic and most of the trivial ones), allowing more than one version to exist concurrently might be something to consider.

A different approach is to have one central article with a number of (less neutral) essays.

Hi Everyone,

Thank you for your feedback - Google Knol is interesting, but isn't quite the direction I had in mind though not far from it. I see now that I should have been a bit clearer in my initial posting, but I didn't want to make it too long-winded either!

The original idea came to us in the form of a comment by one of our users that a tool for merging multiple (e.g. 4 or 5) versions of a text into a single version might be a useful solution to the current proposal in Wikipedialand for having flagged revisions -- but now that I'm looking into it I can see that, while it might be useful, it probably isn't in any way necessary or even desirable for them.

Current proposals to solving flagged revisions all circulate around the dilemma of having two versions that are somehow relevant: the "flagged" version that people see by default when looking at the article, and then the actual "latest" version that you get if you try to edit the article. Here I see a minor problem, which is that you would go to the article, read it, decide you want to make some changes, click edit and suddenly the version you are editing is not the version you just saw. This is the approach taken to maintain a linear version tree. If it takes Wikipedia editors a week or two to get around to approving a new version, then in theory there could be a number of newer versions that get built up during this time, each one building on the last.

What TextFlow could, in theory, offer here is that everyone would be allowed to edit directly from the flagged version (as opposed to the latest version), thus creating a number of new versions that all directly derive from the flagged version, and that the act of flagging a new version would be the act of comparing all of these new versions and selecting which parts of each get to go into the new article. This would be non-linear in that there would exist multiple versions that split off from the flagged version -- but these versions would then be merged back into a single version. So this would lead to a constant pattern of: split, merge, split, merge, where each merge was effectively an editor doing the control check for flagging a new version.

So, as I said, I understand that this solution might not be the best (or even a solution) - but we wanted to look into it and try to find an article in Wikipedia where this kind of branching and merging would have been beneficial. and put together a demonstration based around that. I'm still looking, but I am starting to understand that I'm probably not going to fine one, and even if I did, that it probably wouldn't be appreciated by the Wikipedia people.

Many thanks,

Mark.