Hi Rexford, This is one of many places where feature requests can be made. Thanks for your interest. The last I heard is that tools are in development that will make it easier to edit content simultaneously. I am asking Quim to provide us an update. Pine On Mon, Aug 4, 2014 at 10:02 AM, rupert THURNER <rupert.thurner(a)gmail.com> wrote:

Thanks for the update Quim. I hope it gets done as soon as possible, as it'll go a long way to help multiple concurrent edits. I think it's been lacking for a long time now, and can't wait to see it in action. +Rexford <https://plus.google.com/+Nkansahrexford> | +CG Central <https://plus.google.com/b/103109918657638322478/103109918657638322478/posts> | +233 266 811 165 l BFCT <http://www.blendernetwork.org/member/nkansah-rexford-nyarko/> On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil &lt;qgil(a)wikimedia.org&gt; wrote:

On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil &lt;qgil(a)wikimedia.org&gt; wrote: i'd have strong doubts here, from a technical standpoint :) i can only 100% agree, quim, and i am glad you help clarifying the feature request in this direction. the suggestion is "notify" or "show", not "block". if a user presses edit, the page shows other persons who pressed edit in the last, say 15 minutes, and did not save yet. it sounds simple to implement, but big benefit, especially with many users. an additional goodie could be to show it on the edit window of other user as well, so she can quickly save. if a user ignores the notification and is quicker in saving, we have the current situation. additionally these "in work" templates would be made superfluous in many cases. rupert

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 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. rexford **I'm no wordpress dev, neither have I ever even done coding in php. I mention the wordpress here because, as someone who uses wordpress a lot, and have seen how its editing conflict has been, in a typical way, resolved, I find it impressive, and think Wikipedia of all websites, should have implement that approach long time ago, if not just after wordpress did it.* On Aug 9, 2014 11:58 AM, "Pine W" &lt;wiki.pine(a)gmail.com <javascript:_e(%7B%7D,'cvml','wiki.pine@gmail.com');>> wrote: -- +Rexford <https://plus.google.com/+Nkansahrexford> | +CG Central <https://plus.google.com/b/103109918657638322478/103109918657638322478/posts> | +233 266 811 165 l BFCT <http://www.blendernetwork.org/member/nkansah-rexford-nyarko/>

Looked for it and found this doc on it: http://codex.wordpress.org/Post_Locking Your points are also valid, at least far better than the current diff system which isn't that easy to understand what is actually going on or whatnot. On Nov 8, 2014 10:01 PM, "Brian Wolff" &lt;bawolff(a)gmail.com&gt; wrote:

It might be worth asking the Editing team if improving the handling of edit conflicts is something that they have on their agenda or if they can add it next to their agenda for the next FY, or if this project would be a good GSOC/OPW project. James, can you comment? I know you're busy with VE and I'm not sure what your capacity and priorities are outside of VE. Thanks! Pine

On 9 November 2014 01:10, Pine W &lt;wiki.pine(a)gmail.com&gt; wrote: ​I've mostly answered this in subsequent e-mails, but for clarity, yes, I'm responsible for all editing tools, including the edit conflict resolution process​, but we don't have any particular roadmap of improvements in this area. In general, areas with lots of problems and no solutions or guidance are very poor places to push GSoC/OPW projects, and this is definitely one of those IMO. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

On 13 November 2014 06:40, Federico Leva (Nemo) &lt;nemowiki(a)gmail.com&gt; wrote: ​Hey Nemo, Unfortunately you've accidentally cropped off all the context of whoever's e-mails to which you were responding​. What were you trying to say? J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

Please endure. That's the way forward now. For now, technically, there's no known or brought-forth solution, I'll recommend you endure. I'm sorry, but that's the reality many people face. On Nov 16, 2014 10:07 PM, "Pine W" &lt;wiki.pine(a)gmail.com&gt; wrote:

Svetlana: having accidentally tested this "feature" again, yes. I was looking in the wrong place for my text, and I copied the wrong portion of text in my haste to save it. The text is now permanently gone. Judging by the number of times that I hear about edit conflicts, I have plenty of company with encountering this scenario. James: would it be possible to automatically save the text of a page to a user's sandbox when they encounter an edit conflict? This would overwrite the content of the sandbox, but that could be reverted using the normal history page for the sandbox. Pine *This is an Encyclopedia* <https://www.wikipedia.org/> *One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.* *—Catherine Munro* On Sun, Nov 16, 2014 at 2:10 PM, svetlana &lt;svetlana(a)fastmail.com.au&gt; wrote:

It sounds like the data loss here was purely due to user error, David. Also, Pine, users do not have a 'sandbox' as far as the software is aware. Maybe we could allow saving things to a given subpage of their user page though. I wonder if there would be issues with this idea due to missing history/attribution/etc.... On 16 November 2014 22:41, David Gerard &lt;dgerard(a)gmail.com&gt; wrote:

On 16 November 2014 22:58, Zack Weinberg &lt;zackw(a)cmu.edu&gt; wrote: +1. This is precisely the dataloss that needs to be averted. Something like that. - d.

On Thu, 20 Nov 2014, at 10:22, Bjoern Hoehrmann wrote: +1 for that. Unfortunately local storage in modern web browsers behaves unreliably. Yet instead of acknowledging that improvement and standardizing of the local storage is long overdue, people develop "native" mobile apps. In my view your post shows where this approach hits a ceiling (as most desktop users don't have a "easily install an app" culture or even a package manager, such as the popular windows platform). -- Svetlana

On 16 November 2014 22:36, Pine W &lt;wiki.pine(a)gmail.com&gt; wrote: On 16 November 2014 22:58, Zack Weinberg &lt;zackw(a)cmu.edu&gt; wrote: What is this nonsense? It was clearly user error, not the fault of the software. On 16 November 2014 23:03, Pine W &lt;wiki.pine(a)gmail.com&gt; wrote: of your time and had all your work disappear that it was your fault? Well to be honest I'd think of myself as pretty stupid for leaving two hours worth of work without saving it anywhere safe, but at least I would be able to see that it was my own fault and that the software had returned everything that was needed, making it just a user experience issue rather than a data-loss-major-high-priority bug.

On the second edit conflict, I read the message at the page top. It says: Someone else has changed this page since you started editing it. The upper text area contains the page text as it currently exists. **Your changes are shown in the lower text area.** You will have to merge your changes into the existing text. Only the text in the upper text area will be saved when you press "Save page". Emphasis added by me. We all know that people fail to read though. If we can come up with a more colorful error message or a more intuitive edit conflict page layout, I'm all ears. As to (semi-automatic) conflict resolution, our diff viewer probably has to be fixed first - any conflict resolution starts with identifying the differences, and our diff viewer fucks up at smallest possible edits or problems as soon as an extra line break is involved, i.e. https://test.wikipedia.org/w/index.php?title=User%3AGryllida&action=his… (Were the first sentence edit and second sentence edits made separately, and with a conflict, the logic would die (esp. with an extra line break change involved inbetween)). On Mon, 17 Nov 2014, at 09:36, Pine W wrote:

On 16 November 2014 16:27, svetlana &lt;svetlana(a)fastmail.com.au&gt; wrote: ​However, any "colourful" message will likely get ignored more, not seen more – a problem which is exacerbated by wikis modifying many of the most common messages to be colourful. See https://en.wikipedia.org/wiki/Banner_blindness for more. ​Moving to character-level rather than paragraph-level diffing might help here, potentially. I vaguely​ remember that we attempted that and abandoned it because it caused more issues than it solved back in ?2004, though. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

On Mon, Nov 17, 2014 at 11:03 AM, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: here, potentially. I vaguely​ remember that we attempted that and abandoned A paragraph-level diff means that you only get an edit conflict if two people change the same paragraph. A character-level diff would mean, then, that you only get a conflict if they change the same character? That sounds a bit excessive. (Stupid example: if I change "sixty-three" to "sixty-five" and someone else changes it to "seventy-three", that should probably be a conflict, but a character-level diff would happily merge them into "seventy-five".) A sentence-level diff would make much more sentence, except breaking text to sentences is a less trivial task than breaking it to paragraphs (lines). It is a very fundamental step in natural language processing though, so I am sure mature algorithms and tools exist for it, we just would have to research them. Another low-hanging fruit would be to special-case the situation when editor A adds text to the end of a section but does not start a new section, while editor B adds a new section to the same place. This is currently a conflict as they both try to insert to the same "slot" between paragraphs, so a generic merge tool cannot figure out whether those additions conflict and what would be the right order if they don't; however, knowing the semantics of wikitext, inserting the text from A first and the one from B after that seems a pretty safe bet. This kind of conflict is very typical on talk pages where people almost always edit the end of a section, and the few "hot topic" sections get the majority of the edits. (Of course, using unstructured wikitext for talk pages is a bad thing in general, but that's a long-term problem, and this kind of edit conflict could be prevented quickly.)

On Thu, Nov 20, 2014 at 10:59 AM, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: I don't think this is particularly unique to wikitext, but sure, a character-level (or even word-level) diff would often bring better results than the current algorithm. My point is that paragraph-based (and maybe even sentence-based) diffing makes unwanted results rare enough that it can just be applied without any oversight from the user, while the same definitely would not be true of the finer-grained algorithms. They could be applied with some sort of user review, or 3-way merge interface, and those would be cool features in general, but more complex than just tweaking the diff algorithm, I would think. ...which made me wonder: are we logging enough information of edit conflicts that we could just replay them with an alternative algorithm and see how well it performs? None of the EventLogging schemas which look relevant (Edit [1], EditConflict [2], EditDebugging [3]) seem to store the text which could not be saved, and while EditDebugging saves the ids for both old revisions for a successful automatic merge, I'm not sure if those can be connected with id of the new revision. [1] https://meta.wikimedia.org/wiki/Schema:Edit [2] https://meta.wikimedia.org/wiki/Schema:EditConflict [3] https://meta.wikimedia.org/wiki/Schema:EditDebugging

On Mon, 17 Nov 2014 19:56:04 +0100, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: I've always thought that the reason for the current ordering is so that people don't blindly press "Save" again and undo others' changes. -- Bartosz Dziewoński

On 20 November 2014 09:33, Gergo Tisza &lt;gtisza(a)wikimedia.org&gt; wrote: ​No. The Drafts extension (and any feature that puts hidden content on the servers) was veto'ed years ago by Legal. We need to stop beating this dead horse. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

On Thu, Nov 20, 2014 at 11:00 AM, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: If that is the case, it should be expressed more clearly at T39992 <https://phabricator.wikimedia.org/T39992> which right now has some legal arguments (not very convincing ones, in my opinion, but I'll expand on that there), but no mention of any authoritative legal evaluation, and on the whole the discussion is centered on usability. Anyway, this doesn't really answer the question - whether drafts are stored locally or on the server is an implementation detail (a major one, but still). Is a localstorage-based draft feature on the roadmap, then?

James Forrester wrote: I seem to remember you making a number of claims about the use of drafts by terrorists and child pornographers and other evildoers, but I don't know what veto you're referring to. Do you have a link to a mailing list post or a blog post or another source to verify the claim you're making? MZMcBride

On Wed Nov 19 2014 at 3:50:02 PM Nathan &lt;nawrich(a)gmail.com&gt; wrote: Except since rev_id auto-increments you'd end up with an out-of-place rev_id in the history. In your example you'd end up with something like: [[Page]] history: - Latest rev by Joe (rev_id 2) - Previous rev by Jane (rev_id 3) <- This was the edit conflict, inserted after the fact - First rev by Jim (rev_id 1) <- This one was the one Jane and Joe both began editing from -Chad

On 8 November 2014 22:01, Brian Wolff &lt;bawolff(a)gmail.com&gt; wrote: ​Yes, though this is normally triggered because the section isn't called what it used to be; if you're appending a new section to the end of the page I think it works fine.​ ​The normal way to solve this UX problem is "three column diff"​, but that (a) isn't remotely good for mobile interfaces, and (b) adds Yet Another Interface which may confuse as much as it assists. We'd need a lot of painful UX research and a huge amount of developer time here, I feel. ​This doesn't work for languages without word/sentence/paragraph separators​, of course, but has some promise. ​There are probably some other improvements we should think about, but this is a good start. ​ Note that the behaviour ​ for IP editors is probably worse, given the special code paths used for logged-in editors (the "you can't conflict with yourself" branch) that aren't open to IPs. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

On 12 November 2014 14:46, Brian Wolff &lt;bawolff(a)gmail.com&gt; wrote: ​Oh, sure. I'm not totally convinced that we'll be able to help with HTML/DOM diffing, but that's planned at some point in the future and should at least provide a much better experience for non-wikitext users in navigating changes to documents. It's possible that it will provide a "simple" UX for edit conflicts as well, I suppose. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

Indeed Forester, your answer on the wiki research list is outstanding and shines light on what collaborative editing entails. I really appreciate pointing those issues out, and I fully agree. You ended by saying My question is, is there currently a proposal to handle the issue of Edit Conflicts for the mean time, before the holy grail wikipedia collaborative editing concept presented at wikimania is realized? Or, we all, new editors and old editors alike, continue to endure, most times, the annoyance that comes with editing conflicts? Has that actual proposal started? I fully agree its a daunting challenge with the realtime editing thing, but before that is achieved (perhaps maybe next 10 years time), I believe there should be a quick 'hack' to that. Can't wait to learn what the proposal finally is. As you explained, I don't think the locking articles like wordpress does will be much sensible in this wikipedia context. thanks for your explanations On Wednesday, November 12, 2014, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: