Following are some related philosophical musings which I originally wrote in a private email in May on the subject "Conflict-free Replicated Data Types", copied here for wider dissemination.

The problems we're trying to solve are to produce an edit history with reviewable diffs that reflect each user's intention, and to produce a final text which reflects a synthesis of the thoughts of the participants.

As an example of the first problem: we wish to distinguish a revert on principle (an edit war) from a revert arbitrarily generated by the software.

On the second problem, consider that we have various kinds of edit conflicts which vary by how tractable they are to automatic analysis:

• Editing different sections
• Adding items to the end of an unordered list
• Adding items to the end of a list with some specific order, for example paragraphs in a history article in chronological order.
• Most intractably, two authors simultaneously presenting views on a subject where each has incomplete information and thus an incomplete model of the subject.

By communicating through the edit interface, the authors fill in the gaps in each other's knowledge and thereby produce a document which reflects the sum of the knowledge of both. Consider Hegel's idea of the development of human ideas by thesis, antithesis and synthesis. Even if it were possible for the server to produce a synthesis of views, that would not solve the problem of author education.

A conflict of views, requiring synthesis, can even be non-local, e.g. a fact stated in the lead of the article can contradict a fact stated in a later section. With the current edit conflict merge system, this would be discovered later during review. With arbitrarily strong AI, such conflicts could be discovered prior to save and presented to the user for resolution.

So I think we should look at edit conflicts as a user-to-user communication system, and we should aim to facilitate that communication by clearly explaining the nature of the conflict to the user, using natural language and visual layout, and by presenting options for suggested resolution.

@tstarling: You nailed it.

I'm looking at a problem in ORES (revision scoring), which I believe overlaps with the interface you're describing, and until we solve it we'll be stunting the growth of our young AI. We're training on a set of already noisy, human-produced precedents that we hope will predict whether or not an edit is going to be reverted. Jumbling edit wars together with vandalism is... just pure static. Simply learning that a person decided to "undo" an edit is not enough information, it's like trying to learn the alphabet from a camera that can report "there is black ink on the page".

That said, it is possible to train a machine to do *something* with a blurry signal like this. But its tragicomic AI destiny would be to get really good at perpetuating whatever crazy prejudices the editors it learns from are afflicted by. I wonder if showing a blurry historical picture to other humans has a similar effect... An even scarier thought is that an AI trained to revert edits in a highly prejudicial way might actually become an inspiration for real people to do the same. Imagine seeing a score on each edit like, "96% No, do not assimilate (confidence of 2σ),"--this would have a strong influence over us poor, impressionable humans. We might stop doing human learning!

Both humans and machines would probably benefit enormously if editor communities agreed to an interface like you sketched out, where the software allows editors to more easily express the nuanced relationships between people and the things they write. In the revision scoring case, this would also allow us to develop some cool diagnostics, "This edit is not vandalism, but you should take a look soon cos it has a 75% chance of causing a week of drama among the subject matter experts". Also, the AI would get better at fighting vandalism by learning from a cleaner signal.

The second, philosophical half of your proposal sounds even more futuristic. Like, far far into the future ;) To facilitate the meta-discussion about conflicting ideas, and ideas about ideas, what do you think about T89575, allowing talk page content to optionally appear inline with article text, as marginalia for example?

If talk is surfaced and linked to the article, we could also directly address the revision history. Discussion is about content (article or talk), and about the changes to content (edits). I'd like to bring this back to edit conflicts, and suggest that we should offer another option for conflict resolution: save as a draft and don't resolve at this time. Editing and conflict resolution require different mindsets, maybe different skillsets, and I'd expect that different people enjoy one or the other. Yes, imagine if an unresolved, conflicted edit could become a point for discussion and be collaboratively improved (T103081, T91137)!

For example, say if two users try to insert a paragraph into the same point of an article at the same time.

I think this example is too simplistic to deal with the main pain point. Those edit conflicts are relatively easy to solve, since they require a single copy-and-paste action. In fact, they are so simple that they could be resolved by clicking a button.

The more irritating problem looks like this: I open the page and start changing "the great Prof. I.M. Portant wrote" to plain "Portant wrote" in every single paragraph in a very long page. While I'm doing that, you open the page and fix a single typo – one that just happens to be in one of the paragraphs where I removed "Prof." The result is an edit conflict for the entire page, rather than for the one line where an actual conflict exists. A button to "Automatically resolve all the lines without a direct conflict" would save 95% of my work and make it much easier to see where the actual conflict is.

If you could combine this with your "click a button" process, or with phrase-by-phrase resolution, then it might be even more powerful. Imagine that I could keep 95% of my work by clicking a button to "Automatically resolve all the lines without a direct conflict", and the rest of it by choosing from a menu with options like "Keep mine, not his" or a "Merge those lines, because your change was in the first half of the paragraph and mine was in the last half" button, and I could save all my work and yours, too, by clicking two buttons.

I've re-titled this to hopefully make it clearer. It's a nice idea. I've tallked in the past about a three-column merge tool (such as Eclipse provides) which probably wouldn't have a hope of scaling for mobile users, but could be an option for desktop users at least.

Dupe of T2980: Automatical merge of conflicting non-section edits to unintersecting sets of sections?

Replies to three people below.

In T108664#1526671, @awight wrote:

@tstarling: You nailed it.

I'm looking at a problem in ORES (revision scoring), which I believe overlaps with the interface you're describing, and until we solve it we'll be stunting the growth of our young AI. We're training on a set of already noisy, human-produced precedents that we hope will predict whether or not an edit is going to be reverted.

That's an interesting approach to the problem.

To facilitate the meta-discussion about conflicting ideas, and ideas about ideas, what do you think about T89575, allowing talk page content to optionally appear inline with article text, as marginalia for example?

Yes, I think that would be a good feature.

I'd like to bring this back to edit conflicts, and suggest that we should offer another option for conflict resolution: save as a draft and don't resolve at this time. Editing and conflict resolution require different mindsets, maybe different skillsets, and I'd expect that different people enjoy one or the other. Yes, imagine if an unresolved, conflicted edit could become a point for discussion and be collaboratively improved (T103081, T91137)!

Yeah, that could work, as long as somebody finds conflict resolution fun or rewarding. We just have to be careful not to redirect contributions into an infinitely long queue of non-fun review work, like what happened on some wikis when FlaggedRevs was enabled.

In T108664#1528086, @Whatamidoing-WMF wrote:

For example, say if two users try to insert a paragraph into the same point of an article at the same time.

I think this example is too simplistic to deal with the main pain point. Those edit conflicts are relatively easy to solve, since they require a single copy-and-paste action. In fact, they are so simple that they could be resolved by clicking a button.

That's the proposal: provide the button. Edit conflict screens have too much information and so it's not easy for the user to work out what to do. It's simple but it's not obvious. Very motivated editors will figure out an edit conflict screen, we probably lose a lot of content submitted by users who are not that motivated.

The more irritating problem looks like this: I open the page and start changing "the great Prof. I.M. Portant wrote" to plain "Portant wrote" in every single paragraph in a very long page. While I'm doing that, you open the page and fix a single typo – one that just happens to be in one of the paragraphs where I removed "Prof." The result is an edit conflict for the entire page, rather than for the one line where an actual conflict exists. A button to "Automatically resolve all the lines without a direct conflict" would save 95% of my work and make it much easier to see where the actual conflict is.

Sure, this is like what I said about word-level merging, except that I gather you would have the user accept the merges unseen, whereas I would show minimal fragments of merged text for review before the merge is accepted. Sometimes there's no easy way to detect a "direct conflict", for example a change at the start of the sentence may require a different noun case in the middle.

"Merge those lines, because your change was in the first half of the paragraph and mine was in the last half"

Changes to different sentences could perhaps be merged with less review. Some people already put a line break at the end of each sentence, which allows merges of changes to different sentences of the same paragraph.

In T108664#1530542, @MZMcBride wrote:

Dupe of T2980: Automatical merge of conflicting non-section edits to unintersecting sets of sections?

Perhaps VCS-style conflict markers would be tolerable with VE. I said in my description "the last option would return to the editor with with the both the added texts retained and highlighted", and conflict markers could provide a way to implement that highlighting. If so, T2980 could be a blocker. It's not a dupe.

FYI

In T122234#2238136, @Qgil wrote:

This investigation should take into consideration T108664: Provide an interactive edit conflict resolution tool. In fact, even if the title of that task refers to a "tool", the description explains what that task is really about: "redesigning the edit conflict merge screen". It looks like there is overlap, or maybe these tasks should be merged?

At the very least it would be useful to get @tstarling's ideas into this investigation, and to the Community Wishlist task T121469: Improve diff compare screen.

... where "@tstarling's ideas" actually means the ideas of everybody contributing to this task. :)

FYI: The WMDE's WMDE-TechWish is currently working on improving the edit conflict merge screen, since this was the #1 wish of the German-speaking community wishlist 2015. Right now we have a prototype up of how we want to change the interface, and we are happy about feedback! This is not an interactive tool, yet, but it should help improve the situation already.

Things we have learned on the way that might be interesting to you, too:

• where edit conflicts appear: https://grafana.wikimedia.org/dashboard/db/mediawiki-edit-conflicts (see also T139019 )
• When testing other ideas earlier, we received positive feedback to ideas similar to three-way-merge-tools - but there seemed to be a split between developers (who were excited about this direction) and non-developers (who found it not very helpful and were concerned that such a tool would take more time solving the edit conflict. However, speed seemed to be crucial to them, since especially in heated discussions more time = more trouble)
• Some solutions make it easier to "just pick your own edits" and not really look at the other person's work. When designing a solution, we should make sure that it does not encourage lazy merging as in ignoring the other person's changes.

I could imagine a tool that integrates with VisualEditor (similar to the Find and Replace panel) allowing you to navigate through the conflicting paragraphs, providing you information about each conflict (only you edited this paragraph, only the other user edited this paragraph, both of you edited, showing the diff), and tools to replace the other user's version of a paragraph with yours.

I propose that we make conflict resolution deferrable and optional, in other words we provide a "Resolve later" button that puts the conflict resolution up for grabs. This lets power users clean up immediately, but doesn't block one skillset (editing) on another (curation).

Mostly done in Two-Column-Edit-Conflict-Merge, I think?

In T108664#8495701, @Tgr wrote:

Mostly done in Two-Column-Edit-Conflict-Merge, I think?

This tool achieved ambiguous results, so please consider the problem still open. Here's an overview of what we did: https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Edit_Conflicts

The impact on editors was that anonymous user conflict resolution was somewhat improved, but many common conflicts became much more difficult to resolve. This feature will probably never become a default.