Page MenuHomePhabricator

Should we display a note about automatically resolving an edit conflict?
Open, Needs TriagePublic

Description

This question is inspired by @Encycloon at https://nl.wikipedia.org/w/index.php?title=Overleg_Wikipedia:Arbitragecommissie/Zaken/Obama_Nick_Gur&diff=56008041&oldid=56008026

When the handling of edit conflicts on busy pages is good, editors can Reply without even noticing that someone else had just replied to the same comment. Should we notify them when this happens? Would it be possible to differentiate between a relevant edit conflict (same conversation) and edit conflicts elsewhere on the page?

Requirements

@ppelberg to document once gathered.

Approaches

This section contains an in-progress list of potential approaches to addressing the need(s) this ticket is "asking" to be met.

  1. Re-use MediaWiki's existing edit conflict detection mechanism
    • Volunteer Experience
      • i. Someone clicks/taps the Reply button within the Reply Tool
      • ii. Edit conflict detection mechanism checks whether the page's state has changed in the time between this moment and when the person opened the Reply Tool in "i."
      • iii. If the edit conflict mechanism detects a change, a warning will appear within the Reply Tool informing people that an edit conflict could result from proceeding to publish the comment they drafted
    • Considerations
      • There are likely to be many false positives with this approach considering the existing edit conflict detection mechanism does not consider what part of the page might've changed.
    • Complexity
      • Relatively straightforward considering we'd be re-using and integrating existing functionality
  1. Introduce a new, more targeted, edit conflict detection mechanism
    • Volunteer Experience
      • i. Someone clicks/taps the Reply button within the Reply Tool
      • ii. The "new, more targeted" edit conflict detection mechanism begins checking for changes in the state of the section in which the person is drafting a comment within
      • iii. If the "new, more targeted" edit conflict mechanism detects a change, a warning will appear within the Reply Tool informing people that proceeding to publish the comment they are drafting will result in an edit conflict
    • Considerations
      • What happens if/when the comment to which you are directly replying to in "i." gets deleted?
      • How confident can the software be that an edit conflict will result from the person proceeding to publish they are drafting?
    • Complexity
      • More complex considering we'd be introducing a new mechanism that "bounds" detection to the specific section someone is posting a comment to/within

Open questions

  • 1. What requirements will guide the approach/user experience we end up deploying?
    • @ppelberg to propose and then discuss with team.

Event Timeline

Two options seem to exist:

  1. Display a warning pre-submit that changes have been made, in case they want to check what was said before posting their own.
  2. Display a notice post-submit that other edits were made.

In either case, we're sort of limited in that it'd be nice if we could show people the actual edits made... but there could be an arbitrary number of revisions involved, and highlighting new-comments isn't a thing we've worked out yet.

I'm using this tool for a while, and I find very annoying noticing edit conflicts just after when the edit has been published.

I don't get why differentiating between relevant edit conflicts and not relevant ones: if someone replied before I did, I'd like to be notified before the edit is published.

Alright, some users could find those edit conflicts' warnings annoying too, then you could just add a way to disable them in the preferences

I also said several times the same that someone else has also said in the meanwhile. The automatic edit conflict resolution is one of the most annoying features of the reply tool. So I think

  • Do it. Make it opt-in initially if you’re not confident enough, but eventually turn it on for everyone. Opt-out is not needed, everyone should know that there’s a new comment that potentially effects what they want to say.
  • Do it pre-submit. This is about letting people know there’s something new that potentially effects what they want to say; it makes no sense after the comment has been published.
  • Warning about the whole page can be annoying, so limit it to sections. If it’s not possible or takes long to implement, falling back to MediaWiki’s edit conflict detection (i.e. warning about cases where the full-page editing experience would show an edit conflict) covers most of the cases, namely when two people reply to the very same comment.

I was about to report the same issue. The automatic edit conflict resolution is quite annoying indeed. This needs to be worked on.

To summarize the ideal situation:

If there is an edit conflict, then:

  • You don't want automatic resolution if your comment will seem redundant to people who read the conversation later. For example, imagine that I ask where a page is. Two people both write "Here's the link". You want the second person to be told that another editor has already replied, so the second person can cancel the redundant comment.
  • You want automatic resolution in every other case, including:
    • The edit conflict is due to someone editing the comment you're replying to
    • Any sort of vote or poll (because saying the same thing is not redundant)
    • Your comment has different content (e.g., two editors who recommend different links, two editors replying to different parts of the conversation)

I don't know whether detecting these situations would be practical, but is that a reasonable description of the ideal?

Also, how often do you wish that an edit conflict hadn't been automatically resolved? Once a week? Once a month? Once a year?

@Whatamidoing-WMF

You don't want automatic resolution if your comment will seem redundant to people who read the conversation later.

I totally agree.

The edit conflict is due to someone editing the comment you're replying to

Actually, I wouldn't like the automatic resolution in those cases. Sometimes the initial comment changes a lot, moreover changes are hard to detect.

I agree on the other cases you pointed out.

Also, how often do you wish that an edit conflict hadn't been automatically resolved? Once a week? Once a month? Once a year?

Every time there is a conflict that needs my attention. There's no problem, even if it happens every day.

(Added the ===Approaches section to the task description based on the ideas @DLynch + @matmarex entered during the team's 29-Sep team meeting)

  • Considerations
    • There are likely to be many false positives with this approach considering the existing edit conflict detection mechanism does not consider what part of the page might've changed.

As far as I know, it does consider what parts of the page changed: MediaWiki core tries to merge parallel edits, an edit conflict occurs only when it fails. This means that comments in different topics are likely not to result in an edit conflict; even parallelly written comments in the same topic might not cause an edit conflict if the comments are sufficiently far from each other.

By the way, both solutions mention only edits made after the reply tool has been opened. However, conflicts can occur also between the page load and the time the reply tool is opened. (They’re possible, especially if the browser tab has been open for some time by the time one clicks the reply link.) What about them?

As I understand it, MediaWiki's built-in edit conflict behavior will display the conflict if you've added/removed/changes any lines of text within 3 lines of someone else's addition/removal/change, and automatically resolve the conflict otherwise (roughly… diffs are hard, I'd have to learn more to describe it precisely). Our current edit conflict behavior will always automatically resolve the conflict.

The question now is, when should we display the conflict instead?

  • We definitely want to display it if someone else replied to the same comment as you (I think this is uncontroversial, but please let me know if it's not)
  • We definitely don't want to display it if someone else commented in a different top-level section than you (see above)
  • We may or may not want to display it if they reply to a different comment in the same section, or if one of the users is replying in a subsection

I don't know what we should do in the last case (or maybe there are other interesting cases), I'd love to hear some thoughts about it.


I've started working on this, but mostly just thinking and experimenting for now, maybe I'll have some functional demo next week. I'd like it to look basically like this mockup:

image.png (2×3 px, 738 KB)

(mockup of a real example conflict that annoyed me this evening, and it's the second one this month despite my rare usage of talk pages… subscribing to notifications for sure seems to increase my chances of running into this problem)


I also want to integrate this interface with our behavior on old revisions (T269388, basically adding a way to show all recent comments without leaving the page) and "double-posting protection", a.k.a. edit conflicts with yourself (T286409). Not sure yet how, but it seems closely related.

Similar features exist in Phabricator and Gmail (where there is only ever one thread per page). I agree that the best approach would be a non-modal warning that new comments have been published in the same section with the option to non-destructively reload the page, preserving your unpublished comment.

Phab and Gmail are probably using push notifications, which we don't have the infrastructure for. Instead we would have to choose between

  • checking before submit
    • this requires us to stop the submit when changes are present which could be annoying on very active pages
  • polling every X seconds for new changes
    • we would probably want to detect inactive tabs to avoid wasting bandwidth
Gmail: new message from USER Show IgnorePhabricator: Page updated, click to reload
image.png (436×687 px, 79 KB)
image.png (273×431 px, 17 KB)

(I pushed some experimental code in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/732000, but this is nowhere near done and I won't have time to work on it soon, sorry.)