On 8 November 2014 20:31, Nkansah Rexford nkansahrexford@gmail.com wrote:
One session I really looked forward to at the Wikimania was the one on Visual Editor and the talk on RealTime Editing (the one presented by Erik). Of course, I enjoyed, seeing some of the nice future goals of how realtime editing could be possible, however with very strong huddles to overcome.
One slide pointed out the number of edit conflicts that happened in the month of July only: https://plus.google.com/107174506890941499078/posts/NCPzu4G5cbP
There were *120k edit conflicts of about 23k registered user accounts* (anonymous conflicts might be higher or around this same value, or even less)
The proposals and design concepts of how the concurrent editing could be on Wikimedia projects were/are nice to see, and very hi-tech. However, I considered these proposals and design concepts to be far fetched, at least, at least, looking at how pressing the issue of edit conflicts are.
I think that that's a fair assessment. Doing real-time collaborative editing is a quite hard engineering challenge, but it's a much bigger issue for how our users would be affected, and working out some pretty fundamental ways in which MediaWiki would need to change. See https://lists.wikimedia.org/pipermail/wiki-research-l/2014-September/003828.... which I wrote a couple of months ago which outlines some of these issues.
I might be the only person that suffers from that problem, thus I ask
about. The simple solution to edit conflict in my own opinion isn't that complex, as at least, there's a living example of how it could be.
The WordPress* way of resolving edit conflicts, for me, at this point in time, will look more promising and do much better than the highly advanced concepts that were presented, which are not even near to realization, at least for the next 5 years.
Until those concepts presented are completed, how many more edit conflicts should be suffered? Losing lots (or even a line of edit) of edits because of editing conflict isn't something to take easily, at least when one has limited time and resources, but voluntarily decided to add content to an article.
It's a superficially attractive option that goes completely against the Wikimedia ethos, though. Allowing users to lock pages so that only they can edit them is anti-wiki. It works for WordPress because that's a totally different product; altering this model would massively change the way that people interact with wikis, and I'm not sure it's a reasonable change to make.
There are some useful points we're going to reach along the path to proper real-time collaboration, however, which might be better things on which to focus – flagging pages currently being edited, DOM diff-based edit merges and so on.
J.