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:

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 Ignore	Phabricator: Page updated, click to reload

(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.)

Note: as I gather more information en route to requirements, I've added this ticket as a blocker to T296645 in order to hold us accountable to explicitly deciding whether we will address this issue before or after the en.wiki opt-out deployment.

Update: Draft requirements posted
Today, @Esanders and I started sketching out the user experience for what this could look like and I've now updated the task description to reflect what Ed and I talked about.

You'll notice the experience in the newly-created ===Requirements section hews closely to Approach #2: Introduce a new, more targeted, edit conflict detection mechanism and incorporates the ideas @DLynch, @ValeJappo, @Tacsipacsi, @Whatamidoing-WMF, and @matmarex have shared.

Next, the Editing Team will discuss the feasibility of implementing what's currently described in the ===Requirements section. In the meantime, we would value knowing what – if any – thoughts/questions/concerns the user experience, as it's currently described, brings to mind.

The "polling every X seconds for new changes" approach, if it's not too resource-greedy, appeals, since the sooner I know someone else has commented, the sooner I can start adapting mine to whatever they said. It'd be even better if there's an easy way to load their comment without feeling like the software is going to discard mine.

Most-expansively, to detect it, we could merge in something like this API patch (which exposes our parsed comment tree) and diff the tree between what's on-page and on-server. It'd be a minimal diff process that only cares about the subset of the current thread: find the currently replied-to comment and check whether it has the same replies; if the replied-to comment doesn't exist that's a major conflict; if the replies differ that's something we can prompt to display with the data from the API; special-case a check for "the current user has added a reply that doesn't exist on the local page" to catch double-posts after an error, maybe. We'd need to immediately check it when the reply widget is opened, and then we could fairly-infrequently poll while the reply is being written.

Advantage of this approach is that we can easily avoid being confused by revisions affecting other sections, and it's robust against minor changes to surrounding content. Disadvantage is that we'd be requesting the fully parsed discussion from the server pretty frequently, and so we might want to invest in optimizing/caching that.

In T250295#7389015, @ValeJappo wrote:

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.

@ValeJappo, I'm not asking about the future. I want to know how often automatic conflict resolution has already caused a problem.

I believe that the automatic conflict resolution has been running for more than one year. During that time, I think I have regretted the resolution about 5 times – definitely less than 10 times. I have been happy about it many times.

Is your experience very different from mine?

@DLynch, someone else replying to the comment would be something I'd want to know, but so would someone else replying at the same level as the comment I'm replying to. In other words, sometimes replies happen by indenting a level further, but sometimes they happen by just making another comment at the same indentation level.

In T250295#7651176, @ppelberg wrote:

Update: Draft requirements posted
Next, the Editing Team will discuss the feasibility of implementing what's currently described in the ===Requirements section. In the meantime, we would value knowing what – if any – thoughts/questions/concerns the user experience, as it's currently described, brings to mind.

Today, the Editing Team met to discuss the above and converged on the following plan...

1. We are going to split up this feature into two iterations:
   • First iteration (T250295): introduce functionality that alerts people, in real-time, when a new comment is posted within the same discussion read (== H2 ==) they are drafting a comment within.
     • This functionality is described in Steps 1, 2, 3, and 4 within the description's === Requirements section.
   • Second iteration (T300215): introduce functionality that makes it easier for people locate the specific comment(s) that have been changed.
     • This functionality is described in Steps 5 and 6 within the description's === Requirements section.
2. To start, we are going to surface alerts within the Reply Tool when a new comment is posted within the same discussion read (== H2 ==) people are drafting a comment within.
   • Thinking: while we consider alerting people when *any change/edit* is made to content within the *discussion* or *thread* they are commenting within, this level of precision will require more effort to implement. As such, we decided to start with offering "new comment" detection as a way of incrementally offering people more awareness of changes to the discussion they are participating in. If/when this level of precision proves to be insufficient, we'll prioritize work on: T300216.

Before beginning implementation, we'll share a version of the above on-wiki in order to learn whether we ought to reconsider any of the assumptions in the above.

In the meantime, I've updated the task description to reflect the above.

In T250295#7654982, @ppelberg wrote:

Before beginning implementation, we'll share a version of the above on-wiki in order to learn whether we ought to reconsider any of the assumptions in the above.

See: mw:Topic:Wov6fz5lqmm3nl3p.

The tricky part for notifying and how many details to show is that someone might have opened the page yesterday and then decided to click reply today, and so they'll suddenly get told about all 150 comments on a very busy page at once. (Of course, most discussions won't be that busy.)

I, of course, would *never* leave tabs open for weeks at a time to remind myself that I should maybe respond to something eventually...

In T250295#7647391, @ppelberg wrote:

Note: as I gather more information en route to requirements, I've added this ticket as a blocker to T296645 in order to hold us accountable to explicitly deciding whether we will address this issue before or after the en.wiki opt-out deployment.

Update: while the Editing Team is actively working on this task, we do not currently consider this as blocking the deployment of the Reply Tool at en.wiki

Blocked on design review. See T300560#7684642.

After discussion today, this feature is will initially be disabled on mobile due to our inability to safely refresh content in MobileFrontend. An alternative approach would be to refresh the whole page on mobile, with the small risk that sessionStorage fails for some unknown reason.

In T250295#7715695, @Esanders wrote:

After discussion today, this feature is will initially be disabled on mobile due to our inability to safely refresh content in MobileFrontend.

Here is a ticket for implementing this functionality on mobile: T301929.

An alternative approach would be to refresh the whole page on mobile, with the small risk that sessionStorage fails for some unknown reason.

In the meantime, @Esanders are you able to describe scenarios in which sessionStorage could fail? And, if possible, what you think the probability of those failures occurring to be? I ask this is an effort to decide whether blocking T301929 on T219420 is worthwhile.

sessionStorage could fail if it's disabled (generally lumped into cookie-blocking, I think), or if the storage is full (the size limit on the storage is 5mb-per-origin-per-session).

Disabled is probably more likely... but someone who's disabling all cookies on wikipedia is probably used to having an inconsistent experience.

The storage being full is possible, but I think very unlikely. Absent a mediawiki (or extension) bug filling the storage up with junk, you'd have to edit a lot of very large comments to even get close. (The storage includes the transaction history, so you could deliberately trigger this by e.g. repeatedly pasting in and deleting a large article.)

sessionStorage could fail if it's disabled (generally lumped into cookie-blocking, I think), or if the storage is full (the size limit on the storage is 5mb-per-origin-per-session).

Note that the current patch does not rely on sessionStorage as we created a wrapper that duplicates the contents of sessionStorage into memory, so even if sessionStorage is disabled we will always recover your comment when doing a dynamic update.

We've merged the patches implementing this (see subtasks), and the feature will be included in this week's release. T301582 and T300560 are not done yet, but they are not really blockers.

In the discussion at https://www.mediawiki.org/wiki/Topic:Wq2ekwwt65nu3mp2 Valereee has suggested making the warnings about edit conflicts be opt-in, and specifically that they be turned off for new editors. The benefit to new editors (<100 edits, so 99% of accounts?) is likely to be much lower, and the anxiety about what's going on (did I break something? Am I doing this wrong?) is likely to be higher.

The requirement for people being able to dismiss the alert has not been implemented and also there are some issues with highlight being persistent when someone clicks on those alerts to show the new comments. Awaiting @ppelberg's response on Slack.