Copy of Etherpad notes:

• Birgit + Lea do an introduction:
  • We are talking about the top 1 wish from the German edition of the Technical Wishlist.
  • The team tried to understand what "please improve the edit conflict situation" means. Decided to focus on UI (first).
  • Current situation: 2 text fields, a diff with 2 sides. Lots of duplicate information!
  • Suggestion A.1: Drop the lower text field. Make the +/- signs not copyable. …?
  • Suggestion A.2: Two column screen, unified diff left, text box right.
  • Suggestion B: Similar to merge tools. Pick sections via checkboxes. Possibly edit such a section.
  • Key learning: Users just do not use the current UI.

Key learnings:

• Users just do not use the current UI. Workarounds, mostly copy-pasting stuff around.
• Programmers prefer what they know from diff tools.

New suggestion 1: Popup telling "somebody else just saved, may cause a conflict".

Discussion starts at this point:

• Popup may scare users for no good reason, because 80% of conflicts are automatically resolved.
• Multiple concerns about performance, because of all the backend checks necesarry.
• Suggestion: Only show the popup if the other edit is on the same section.
• Problem (raised multiple times): Adding something to the end of a section/article is always a conflict. This may need a special solution, limited to this special "append" case. Problem is that users will not merge the added paragraphs any more.
• Suggestion: Do not make it an "error" message, make it an invitation to talk to the other person.
• Suggestion: Offer to reload as long as no edit was made; possibly skip the warning when something was changed.
• Question: Do you have numbers for the actual situations that cause conflicts?

New suggestion 2:

• Two columns. Editor with current version left, your version right (read-only text field, not a diff).
• Your changes are highlighted on the right. Can copy-paste to the left.

Discussion:

• Concern (raised multiple times): Wrong direction. My text should be left, copy to the right.
• Typical situation is explained: User A creates new article. User B watches recent changes. Fixes mistakes and gows away. User A is then a bit lost.
• Concern: Small screens. All multi-column designs (possibly) have issues.
• Question: What/how exactly is text highlighted in your (read-only) version? Removeals (crossed out)? Also untouched stuff the other person touched, in an other color?
• Depending on which user changed more stuff, conflict resolution should be based on the version with more edits. The few edits from the other version need to be merged manually. This may need a button that allows switching the merge-direction (or an algorithm that can detect which merge-direction is easier?).
• James: Storing structured data not in wikitext (like on Wikidata) will not cause so many conflicts any more.
• Actual collaborative editing (in Visual Editor) will allow many new possibilities (e.g. hop into such a session when you are editing a paragraph somebody else edits).
• Patroling new edits is again raised. Possible solution: Profile user behavior, e.g. people doing many small edits in a row are patrolled different, which also causes less conflicts.
• James: Better automatic resolution. Actually understand what an edit does makes it possible to understand that it is independent from an other edit.
• Suggestion: Do it like Git, branch and actually save branches. Merge later, done by an other, experienced editor.
• Don't forget that many "conflicts" are not technical, but logical. E.g. two people editing two paragraphs, but the contents conflict. Worst case: Re-using a reference the other user removed.
• Suggestion: Don't focus on conflicts, make this a general "compare two revisions" tool. E.g. user works on a copy of an article and want's to copy it back.
• Wish: Allow me to save my edit somewhere (as a draft). I want to resolve this conflict later.
• More general discussion about forks (drafts) and merging forks back into the original article. Concern that to many drafts nobody is looking at may polute the wiki/recent changes. Hiding it makes it more pointless to have it in the first place.
• Critical to not show draft articles in categories. Current practice is to use HTML comments around categories in drafts.

Topics for discussion:

• Edit conflicts

General notes

• "warning notice" - concerns about false positives, and suggestions to change the message to a more positive "you're collaborating!" message, and different messages for different types of conflict
• get edit conflict stats per namespaces (Flow avoids edit confilcts on Talk pages!); do we want/need the same fixes for two editors writing the same article vs. RFC shouting matches?
• we have edit conflict stats per user level (bottom graphs at https://edit-analysis.wmflabs.org/compare/, adjust for the wiki/timescale you care about)
• Get edit conflict stats by type - if the cases of "prepending/appending content" are most common, e.g. adding categories, adding cleanup banners, and conflicting talkpage comments, then that might be solvable at a software level.
• Longterm investigations ongoing into (1) edit review improvements, (2) moving structured data out of within the articles (inc. categories, deletion tags, etc.), and (3) clustering edits / staging saves, hence making it easier to reduce the quantity of diffs with a conflict
• Edit review tool research, to potentially reduce the quantity of high-speed tagging of good-faith editors, might reduce edit conflicts
• Mobile suggestion, save draft to a subpage, for easier merging when back at a desktop
• <gwicke> example of visual diffing on localwiki: https://localwiki.org/davis/International_Relations_Student_Association/_history/2016-06-22%2020:40:50.228942...

Mentioned use cases:
One main use case of edit conflicts is new people making good faith edits that are immediately reverted / articles deleted by admins, before the newbie had the chance to improve them.

Outcome of the session:

The position of the group towards the two suggestions was:

Warning notice:

• There is more research needed to find out how many false positives this message would generate and if it would encourage more people to stop editing than the current edit conflict resolution screen (especially looking at new users)
• The warning should not be phrased in a negative, but more in a positive way („Hey! there is two of you helping out on this page, great“…:“)

Edit conflict resolution page:

• There is also lots of things that could be done to improve the edit conflict resolution algorithm
• The suggested solution is better than the current one („by far“)
• The new text needs to be on the right, the old on the left, to be consistent with other views