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?
=== Story
As someone who is drafting a comment using the Reply Tool, I want to know when someone publishes a comment in the same section I am drafting a comment within and what they have said, so that I can decide whether or not to make changes to the comment I'm drafting prior to publishing it.
=== Requirements
META
- Platforms: **Desktop** + **Mobile**
- Editing Interfaces: **Reply Tool**
-- //Note: any implementation should preserve us the option to extend this experience to other VE-based experiences (e.g. New Topic Tool, VE, 2017 WTE)//
USER EXPERIENCE
1. **Inform people the state of the page has changed**
-- The moment a qualifying change has been made, show an alert in/ around the Reply Tool informing people that the page has changed from the version they are looking at.
--- //Where "qualifying change" in this context means any *edit* to the *section (`== H2==`)* the person is drafting a comment within.//
2. **Offer people the opportunity to see what's changed or to explicitly forego this opportunity**
-- The "alert" mentioned above ought to contain affordances that enable people to:
--- Show the change(s) that have been made to the discussion in the time between you opened the Reply Tool and "this" moment
--- Forego the opportunity to see what changes have been to the discussion
3. **If people opt to see what's changed in the discussion, ensure whatever content they've drafted within the Reply Tool is retained/recovered/saved**
-- Don't reload the page, just update the contents via the API and keep the comment you've drafted in memory. //@Esanders can speak to this in detail.//
4. **If people forego the opportunity to see what's changed in the discussion, ensure they can return to what they were doing prior to the alert appearing**
-- Upon opting NOT to see how the discussion has changed, people should see the alert disappear and all other aspects of the page, the Reply Tool, and the content within the Reply Tool unchanged.
5. **Help people to easily locate what's changed within the discussion **
-- Upon opting to see how the discussion has changed, people should see the page update with the comment(s) that have been changed highlighted ephemerally
6. **Help people resume writing/editing the comment they started**
-- In updating the page to its latest state, people need to be able to immediately locate the Reply Tool with the comment they drafted prior to the discussion being updated in tact.
=== Open questions
- [ ] 1. How might we go about detecting **edits** to a specific **section**?
- [ ] 2. What do we do to visually communicate when content has been deleted?
---
=== References
- This ticket was filed in response to @Encycloon at https://nl.wikipedia.org/w/index.php?title=Overleg_Wikipedia:Arbitragecommissie/Zaken/Obama_Nick_Gur&diff=56008041&oldid=56008026
- @Sdkb and @MichaelMaggs also raised this issue at mediawiki.org: https://www.mediawiki.org/wiki/Topic:Woomtgg3secx6r2h
---
=== 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 {nav 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
2. **Introduce a new, more targeted, edit conflict detection mechanism**
-- //Volunteer Experience//
--- i. Someone clicks/taps the {nav 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