​Hey.

[This is a bit off-topic for wiki-research-l, but I've been asked to answer.]

First things first: There aren't any plans right now to try to roll this out any time soon.

Collaborative real-time editing is an interesting task in terms of engineering, but an exceptional challenge in terms of product. I think that it's reasonable to talk about it as a possible solution to issues, but the number of problems it raises is so great that people should be careful to not talk of it as some magic pixie dust. :-)

For a couple of brief examples:

If the objective is to prevent all edit conflicts by making parallel edits them impossible, this means either:

* everyone has to use the collaborative editor;

* people who can't use the collaborative editor (e.g. old computer, slow network, no JavaScript, etc.) can't edit at all;

* people who don't like the collaborative editor are unable to edit ever again; and

* bots can't edit at all (because they can't react to prompts from other users)

… or:

* you have to choose to use the collaborative editor for each edit (how do newbies know, or is it opt-out somehow?)

* as soon as someone wants to edit an article collaboratively, everyone else's edits die and they're told so (or they all have to wait for the collaborative edit session to end and then manually resolve the edit conflict);

* for people who can't or don't want to use the collaborative editor, and all bots, the article is essentially locked from their editing until the collaborative edit is finished.

Neither of these are great options.

​If instead ​we're happy to keep having edit conflicts, we can allow parallel edits, but then the benefit for newbies (and, frankly, the rest of us) goes away the second your collaborative edit conflicts with a non-collaborative edit. Whoops.

​Say that we've decided on a course of action for the above, maybe by biting the bullet and denying people with older computers etc. the ability to edit (which I think would be sad and a dereliction of our values); what do you do when there are too many parallel editors of an article?

When you're editing in a real-time collaborative editor, that means you see the edits of each of the participants, alongside their cursors/selections and comments in the chat system if there is one (which there normally is). When there's two or three of these, it's relatively easy to see what's happening. But what if there are 1,000 people trying to edit the article at once (e.g. the article of a very famous individual just after they've died unexpectedly; think Michael Jackson or Robin Williams). Showing 1,000 cursors at once isn't just unhelpful – the level of traffic would probably kill most users' browsers. Consequently, there needs to be a limit somehow on the number of participants; maybe call it 10.

So, what happens when you click edit on an article where 10 people are already editing?

* Do you just get told "tough"?

* Does the least-recently active editor get kicked out so you can join?

* Does this mean that all I need is 11 bots requesting to edit an article to DoS it?

If you're a "special" user (e.g. a sysop), can you get into a collaborative edit even if it's at the limit?

* If yes, doesn't this go against our values to place some editors above others?

* If yes, do we just let the system "actually" cope with 11 not 10 editors, or do we kick someone out?

* If no, how do we resolve the issues with too many editors locking an article?

Then there are some really deep issues (more germane to this list) about how article histories and revisions work, about the atomicity of edits and the semantic concepts of saving, about blame maps vs. personal contribution histories, about the concept of flagged revisions and suppressed edits, about reversions and protected pages, and about legal matters such as around multi-licensing and deleted edits.

The short answer is that it's a really interesting area of possibilities, but we're going to want to work through a lot of these issues and come up with an actual proposal about what this would mean.

Yours,