Edit conflict handling suggestion

From Meta, a Wikimedia project coordination wiki

This is a suggestion. Not a vote or poll or anything. -- Timwi 20:39, 3 Sep 2004 (UTC)


Currently, when a person A brings up the edit screen, makes some edits, and in the meantime another person B submits an edit to the same article, then person A will receive an "Edit Conflict" screen when saving the page. There is a mechanism in place that merges A's and B's edits if they are to different parts of the article, but if they are not, person A still gets an "Edit Conflict" screen.

This "Edit Conflict" screen is rather confusing, and very intimidating to newbies. It is well conceivable (but not measurable) that a number of valuable contributions have been made by newbies, but have been rejected due to an edit conflict and have got lost because they did not know how to resolve the conflict.

The suggestion[edit]

My suggestion is to remove the "Edit Conflict" screen entirely. Instead, the article itself should reflect the edit conflict. I am envisioning something similar to what happens when there is a conflict in CVS; however, the visual appearance is not important and can be debated separately.


Suppose the article text is:

A Banana is a fruit.

Suppose person A corrects the spelling:

A banana is a fruit.

Suppose person B adds bold markup:

A '''Banana''' is a fruit.

The resulting article might look something like:

(EDIT CONFLICT) Banana (1) banana (2) '''Banana''' (END EDIT CONFLICT)
is a fruit.

This essentially means that the "Banana" portion of the text has been changed by one person to "banana", and by some other person to "'''Banana'''". Again, please remember that the visual appearance of the edit conflict is not important. This is about the general idea of moving edit conflicts to the article text.


  • As mentioned above, the "Edit Conflict" screen is intimidating to newbies. There is no real way of making it any less intimidating, but at least we don't need to expect of the newbie to resolve the conflict. By moving the warning that an edit conflict has occurred to the article itself, the resolution of the edit conflict can be left to anyone, most notably to more experienced users who understand the phenomenon.


(EDIT CONFLICT) Banana (1) banana (2) '''Banana''' (END EDIT CONFLICT) will look absolutely awful in an article. Displaying such a mess to readers of the page is not a solution. Angela 21:05, 3 Sep 2004 (UTC)

Thanks for reading the proposal before commenting on it, Angela. — Timwi 23:56, 4 Sep 2004 (UTC)
I did read it. I assume you are referring to the fact it says "the visual appearance of the edit conflict is not important"? I strongly disagree. You can not ignore something which is going to have a huge effect on the article like this. Until you do have an alternative to the format you proposed above, then I still hold the view that your proposal is not a solution. Angela 03:17, 5 Sep 2004 (UTC)
Thanks for reading and understanding the proposal before commenting on it, Angela. — Nowhere was I suggesting that anyone should implement this change without giving consideration to the format. But for as long as we don't even know if people generally want this change at all, thinking about the format is a waste of time. If you disagree, then I strongly suggest you provide more constructive criticism, perhaps your idea of a better format, rather than destructively and discouragingly shooting down an idea based on a concern that isn't even under consideration yet. — Timwi 10:44, 9 Sep 2004 (UTC)
I have to agree. The edit conflict as of now is not bad. Everything has a learning curve. The edit conflict page is one of the easier things to learn. Frecklefoot 21:20, 3 Sep 2004 (UTC)
Hence why Timwi stressed that the visual appearance was not what he was asking for comments on, only the principle. It may be that there is no visual appearance that would be acceptable, but it is probably too early to decide that just yet. - IMSoP 21:19, 3 Sep 2004 (UTC)

Well, my initial reaction to this is that it would be technically difficult. By that, I don't mean just "how do you expect to code this" (a challenge, but probably not an insurmountable one) but that your claim that "the visual appearance of the edit conflict is not important" may be over-stated. For such a system to work, there would need to be some way of presenting it that allowed:

  1. a casual reader to still understand the article
  2. an editor, preferably even one with little experience, to understand the existence and nature of the edit conflict
  3. an editor, again preferably even an inexperienced one, to see how to correct the conflict

The first point is in some ways both the most important and the most challenging: if an edit conflict is left behind by two inexperienced (or rushed/lazy) editors, a visitor must be able to read the entire article without being distracted by the existence of the conflict. It could be hidden away on a seperate page ("This page has conflicting versions") but what version would then be presented to a visitor, and what would the user be given to edit? And how would we prevent edit conflicts proliferating as naive users edited on top of a version which was in a state of quantum indeterminacy?

The second and third points are important if the new system is to have value over the current one: it must be less confusing for new users, not more; and result in more definitive changes, not more TODO items in the 'pedia. I suspect that in answering the first point, answers would more or less emerge for the second and third ones: a usable presentation and editing system would entail an interface for describing and resolving the conflict.

Note that this is all just initial reactions, and spurs for further discussion, not a permanent position or judgement of the idea. While my gut feeling is just "make the current interface and explanation nicer", it is always useful to look at alternative approaches to things, and evaluate them on their own merits. It puts me somewhat in mind of an idea that's drifted around my head for a while of a kind of pre-moderation mode wiki, where prospective changes could be stored, awaiting official approval, and further changes would build up on top of these prospective versions - perhaps it is this similarity that worries me, since it would seem to block the natural flow of the raw wiki process.

I'll shut up now, and let others join the discussion. (Oh, tee hee, I got an edit conflict while discussing edit conflicts; I notice the resolution screen is still not by-section when both edits are within a section - there's one improvement to be made to the current approach, anyway!) -- IMSoP 21:19, 3 Sep 2004 (UTC)

I honestly see no problem with the Edit conflict screen. Until the developers program the software to heuristically merge edits or something, this task will have to be done manually. Letting conflicts get into the page with inevitably cause problems, as Angela has pointed out. --Slowking Man 22:43, Sep 3, 2004 (UTC)

It does merge conflicts automatically, just like CVS. You usually get conflicts when two people try to add something to the same location. This happens quite regularly when they are both replying to the same comment on a talk page. -- Tim Starling 04:22, 4 Sep 2004 (UTC)
Well yes, I know that. I was referring to the problem you just described, and I was speaking somewhat facetiously, as I doubt you can figure out a way to choose a "right" version when, say, two people edit the same sentence in different ways at the same time. --Slowking Man 07:10, Sep 4, 2004 (UTC)

I think it's a decent idea, but it will take a lot of work to work well / look good, and IMHO there are more important things for developers to be working on. ··gracefool 22:15, 4 Sep 2004 (UTC)

How about this... If you get an edit conflict, why not just accept the first edit as part of the page, but with a discreet line of text that links to the alternative "unaccepted" edit, your banana article may look something like:

Edit conflict
A banana is a fruit.

Any Wikipedian could then come along to the page and merge the conflicting edits. The Edit conflict text could then be removed from the page.
SimonMayer 05:27, 4 Sep 2004 (UTC)

How about the system warning the second user on the edit page that the article has been retrieved in edit mode x minutes ago and not been saved yet. Only show the warning when unsaved previous edit was less than x minutes ago. The first user may never save any changes, but at least the second user is prepared an edit conflict may occur. Erik Zachte 12:17, Sep 4, 2004 (UTC)

I think that might scare newbies.
SimonMayer 17:24, 4 Sep 2004 (UTC)
I would expect that an advance warning, if phrased properly, will be less scaring than the current edit conflict page. Erik Zachte 22:50, Sep 4, 2004 (UTC)

Reading all the comments above, it seems that most of you are afraid that an edit conflict would stay around for too long. I have to admit, I was working under the naïve assumption that just about every edit conflict would be resolved by someone within a reasonable time-frame. — To help achieve this, one might have the system automatically add [[Category:Articles with edit conflicts]] to the article. Enthusiastic cleaner-uppers could then regularly check that category and resolve any edit conflicts that may have occurred. How does that sound? — The lower the average time taken to resolve a conflict, the less important the actual appearance of a conflict in an article becomes. Timwi 23:56, 4 Sep 2004 (UTC)

Actually, what I find annoying about the edit conflict screen is that it doesn't go line by line of your changes with the recent document. I rather have the edit conflict screen to be revised such that it's much like the display of revision differences. I want to see the edit conflict window to be handled more like a spell checker. Or at least some kind of merged version where you can select which changes of yours to add to the document.

Something like, if "passage A" was added, there's a specific form box for you to edit the new passage of text. Then for anything that you wanted to add but could not due to the conflict will appear if the section was untouched. Any areas that were modified which you also wanted to modify would take the current approach to the edit conflict: Current revision is displayed then below it your revision is displayed. This may be messy, due to all the form boxes, but I would think breaking it up would be far more effective if anyone happens to write a lot... only to discover that they have to make further revisions due to edit conflicts.

Since you submitted the document, it is likely you don't really to intend to change the parts of the document you didn't edit, thus those portions which have not been touched from the previous revision and the current revision (which you had an edit conflict with), should not be displayed.

--AllyUnion 09:08, 5 Sep 2004 (UTC)

In as much as I understand what you're proposing here, I think it sounds like quite a good idea. I certainly think breaking down the page would make it much less like hard work merging edits - I've long thought that if the conflicting edits are contained within a section, only that section should be presented in the conflict window. And taking that further, you could have an algorithm that would auto-merge some sections and present conflicts for others - of course, highlighting what changes had happened, in case they made a difference to whether you wanted to change something somewhere else. One of the most frustrating things about the current screen is that if you make a few minor copyedits while you've got the edit window open (a bit of a habit of mine) the chances are you won't bother finding and making them again.
I suspect I'm just repeating what you've already said, so I guess the short version is: yes, that sounds like a sensible direction for improvement. - IMSoP 17:50, 5 Sep 2004 (UTC)


Show the diffs[edit]

I think the edit conflict page should show the diff between the revision you just submitted and the conflicting revision (as well as the two edit boxes we currently have containing the full source). This would make merging edits a lot easier. In a long article I often have no idea what the other person has done. I'd hazard a guess that this would be relatively easy to implement too, since it's a mixture of the diff pages and the existing edit conflict page. Lupin 01:20, 8 Sep 2004 (UTC)

Highly seconded. I would really like to see this. If there's a bugzilla bug, let me know, I'll vote for it. w:User:JesseW 09:04, 25 Oct 2004 (UTC)

Inefficient system[edit]

While I appreciate this proposal, I think the edit conflict page is perfectly fine. While the disadvantage is that we may lose contributions, the disadvantages of the proposed system are far greater... we would create a Wikipedia where a lot more monitoring is needed. I think it's better to have less contributions (by 0.00001% - most new users aren't involved in edit conflicts) and more integral content, even if it's harder for new contributors, rather than 0.00001% more contributions and pages that look ugly and are a lot harder for readers. Ronline 10:59, 25 Oct 2004 (UTC)