Page MenuHomePhabricator

Reduce edit conflicts by treating different parts of the page as separate
Closed, InvalidPublic

Description

We all get edit conflicts, those of us who have stayed on wikipedia are largely those who have learned to resolve them, or to do lots of little edits in order to minimise the time lost when we get an edit conflict. There have been many proposals on bugzilla and elsewhere to reduce edit conflicts, but they haven't had resource as keeping new editors didn't use to be a priority. But this is one of the things that new editors find most bitey about wikipedia, and usually it is the newbie who loses the edit conflict because they are taking minutes on their edit and the categoriser or templater only seconds.

Edit conflicts are exactly the same in both the visual and wikitext editors, because the parser has resolved changes per LINE (e.g., a paragraph or a template on its own line), not per ==Section==, since approximately 2004. Editors who are not editing the same or adjacent lines will not get an edit conflict, regardless of whether they are editing the whole page or a single section, no matter which editing environment they use.

Currently we don't even have public statistics on number of editors lost through edit conflicts. Simply measuring them and the number of times they predict an editor leaves would either confirm this was one of the biggest causes of good new editors leaving, but actually fixing some of the things that cause edit conflicts would likely take as little resource.

Getting rid of all edit conflicts would require a revolutionary change in the user interface, but halving edit conflicts would take a fairly minor investment.

Specific ways to reduce edit conflicts include:

  • Treat the addition of a template at the top of an article or a category at the end as not conflicting with the alteration of the contents in between.
  • Pre populate all newly created articles with sections such as ==References== and ==See also== or equivalents in other languages
  • Treat # the same as a section heading so two replies in two different threads of the same section would not be treated as a conflict.

WereSpielChequers (talk) 20:54, 10 November 2015 (UTC)

This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey

This proposal received 41 support votes, and was ranked #21 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Editing#Halve_edit_conflicts

See also

Event Timeline

DannyH created this task.Dec 4 2015, 10:36 PM
DannyH raised the priority of this task from to Needs Triage.
DannyH updated the task description. (Show Details)
DannyH moved this task to Wishlist 51-on on the Community-Wishlist-Survey-2015 board.
DannyH added a subscriber: DannyH.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptDec 4 2015, 10:36 PM
IMPORTANT: If you are a community developer interested in working on this task: The Wikimedia Hackathon 2016 (Jerusalem, March 31 - April 3) focuses on #Community-Wishlist-Survey projects. There is some budget for sponsoring volunteer developers. THE DEADLINE TO REQUEST TRAVEL SPONSORSHIP IS TODAY, JANUARY 21. Exceptions can be made for developers focusing on Community Wishlist projects until the end of Sunday 24, but not beyond. If you or someone you know is interested, please REGISTER NOW.
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptJan 21 2016, 2:52 PM
Restricted Application added a subscriber: Luke081515. · View Herald TranscriptJan 22 2016, 1:59 PM

Change 266760 had a related patch set uploaded (by Addshore):
Count the number of EditPage edit conflicts

https://gerrit.wikimedia.org/r/266760

Change 266760 merged by jenkins-bot:
Count the number of EditPage edit conflicts

https://gerrit.wikimedia.org/r/266760

DannyH updated the task description. (Show Details)Feb 5 2016, 11:53 PM
DannyH set Security to None.

Does anyone know where the stats for edit.failures.conflict is actually collected?

DannyH renamed this task from Halve edit conflicts to Reduce edit conflicts by treating different parts of the page as separate.Feb 10 2016, 6:23 PM

Thanks @Addshore! From that graph it looks like there are currently about 2000-3000 edit conflicts per day.

I don't think this will cover conflicts using the API!

01tonythomas added a subscriber: 01tonythomas.
NOTE: This task is a proposed project for Google-Summer-of-Code (2016) and Outreachy-Round-12 : GSoC 2016 and Outreachy round 12 is around the corner, and this task is listed as a Possible-Tech-Projects for the same. Projects listed for the internship programs should have a well-defined scope within the timeline of the event, minimum of two mentors, and should take about 2 weeks for a senior developer to complete. Interested in mentoring? Please add your details to the task description. Prospective interns should go through Life of a successful project doc to find out how to come up with a strong proposal for the same.
Samtar updated the task description. (Show Details)Mar 3 2016, 7:10 AM

Hello is anyone willing to mentor this project for GSoc-2016?

Hello is anyone willing to mentor this project for GSoc-2016?

In case no one turns up, you can even look for one among https://www.mediawiki.org/wiki/Outreach_programs/Possible_mentors -- who might be interested in mentoring. Thank you!

In case no one turns up, you can even look for one among https://www.mediawiki.org/wiki/Outreach_programs/Possible_mentors -- who might be interested in mentoring. Thank you!

If I have found one, should I just email them directly or is there a different formal process to contact them?

If I have found one, should I just email them directly or is there a different formal process to contact them?

No formal process I'm aware of... See also the "Find two mentors" section on https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project#Coming_up_with_a_proposal (which might welcome some clarification).

Qgil added a subscriber: Qgil.Mar 31 2016, 9:31 AM

The Wikimedia-Hackathon-2016 starts tomorrow and this task is featured at T119703. We want to use T130776: Wikimedia Hackathon 2016 Opening Session to promote these projects and help recruiting volunteers to work for them.

If this task is ripe for hackathon work, please follow these instructions. If it is not ready, remove it from T119703 in order to avoid volunteers' frustration. Thank you!

kaldari updated the task description. (Show Details)Mar 31 2016, 10:32 PM

Am I right thinking that... the last edit the the task description by @Whatamidoing-WMF ("the parser has resolved changes per LINE (e.g., a paragraph or a template on its own line), not per ==Section==", which I assume it's true) puts in question the solutions proposed in the same description?

I wonder whether this task is getting complicated, and actually not a good fit for Possible-Tech-Projects.

Quiddity added a subscriber: Quiddity.

@Qgil Correct.
The parser already does, what the task-description previously requested.
Anyone can test this, using 2 accounts, editing different sections/paragraphs on the same page. E.g. https://www.mediawiki.org/w/index.php?title=User:Quiddity_%28WMF%29/Sandbox-editconflict&action=history - those pairs of edits were done at the same time as each other, with various conditions. This works with any mix of VE and Wikitext editors, and any mix of section-edit and full-page-edit.

As long as the diffs themselves don't overlap, and the diff-engine isn't confused by which block was actually changed, and they aren't saved in the same second, we don't get edit conflicts. (IIUC)

The vastly more complex work, is resolving edit conflicts within the same paragraph. This is being investigated by the Parsing team, ArchComm, and other teams, in tasks such as T112984: Real Time Collaborative Editing, and the tasks mentioned in T113004: Make it easy to fork, branch, and merge pages (or more).

There is also work related to some of the other issues, being done by the Performance team (e.g. T58849: Edit conflict detection by timestamp should be deprecated).

At the end of the comments in the wishlist, it is noted that T108664: Provide an interactive edit conflict resolution tool might be a good target for attention. I'm not sure if it's simple enough for a possible-tech-project, though - it needs a more detailed plan and design.

I suggest marking this task as "invalid", and metaphorically (or literally) migrating the community-wishlist emphasis onto one or more of the other ongoing tasks.

Qgil updated the task description. (Show Details)Apr 26 2016, 5:25 AM

I suggest marking this task as "invalid", and metaphorically (or literally) migrating the community-wishlist emphasis onto one or more of the other ongoing tasks.

I'm also proposing to close as INVALID: The request in the task summary ("Reduce edit conflicts by treating different parts of the page as separate") has already been in place when this task was created.

@DannyH: What to do with row #21 in https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results ?
Cross out and say "technically already in place since 2004"? Link that row to T108664 instead?

DannyH closed this task as Invalid.May 2 2016, 5:40 PM

Okay, thanks for the information. Closing as invalid.