Page MenuHomePhabricator

Reduce edit conflicts by either telling users to edit a section only, or to have better logic to treat paragraphs, categories, templates independently
Closed, DeclinedPublic

Description

On EN wiki in particular edit conflicts are frequent, especially at new page patrol. http://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol#Aggressive_new_page_patrol_edit-conflicts is the latest example of this causing arguments in the community. Edit conflicts waste a lot of editor time and they make the editing experience suck.

The 25% of Newbies who start by creating a new article are particularly vulnerable to edit conflicts, as are the many editors who try to start editing on a major breaking new story.

It has been a while since we have seen a major change to the way that the interface treats edit conflicts. But in many cases it should be possible to reduce edit conflicts. Reducing edit conflicts would greatly improve site experience, immediately increase the number of edits that actually take place, and almost certainly improve newbie retention.

There is one easy way to reduce edit conflicts and one difficult way. The two are so different I should probably raise them as two different Bugzilla requests, but I'm feeling lazy.

The easy way is to disable the edit button for very busy articles. Experienced editors already know that if a page is going to be busy you edit a section and you don't try to edit the whole article. So to reduce edit conflicts on "trending articles" and Jimbo's talkpage, the system needs to automatically notice which articles are busy and when anyone clicks the big edit button at the top of a busy article render: "Sorry, but this article is currently very busy, so to reduce edit conflicts you can only edit one section at a time. Please pick the section you want to edit", then gave them a choice of sections.

The difficult thing is to reduce edit conflicts at newpage patrol and other random encounters when two people try to edit an otherwise rarely edited page. A typical conflict here is that the person who has just started a new article adds a sentence to it 2 minutes after creation, but a newpage patroller has already added a template or a category. Since most such articles start without any section headings this pretty much guarantees an edit conflict. Now the complicated way to reduce edit conflicts here would be to have some logic in the editor that treated paragraphs, categories and templates as independent entities much as it does sections, so if one page patroller adds a category, and another bolds the first two words of the article and wiki links a word in the second line, and the newbie who has started the article then adds a second sentence, the system should treat all three simultaneous edits as complementary and composite them together so that all three editors have successful edits. Some of this could of course be reduced by the simple expedient of starting all new articles with two lines "==References==" and "{{reflist}}" in the middle of the first screen. Then assuming that if two people are editing the whole article but only actually changing one section, then their edit can be treated as a section edit. This would avoid edit conflicts between categorisors and those who are adding or amending content, it might even prompt some editors to actually add a reference. Shifting more of the templates from the start of the article to the end would also reduce edit conflicts as they would be in the references section. ~~~~


Version: 1.21.x
Severity: enhancement

Details

Reference
bz41338

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:11 AM
bzimport set Reference to bz41338.
bzimport added a subscriber: Unknown Object (MLST).

Summarizing the two proposals here:

(In reply to comment #0)

The easy way is to disable the edit button for very busy articles.
when anyone clicks the big edit button at
the top of a busy article render: "Sorry, but this article is currently very
busy, so to reduce edit conflicts you can only edit one section at a time.
Please pick the section you want to edit", then gave them a choice of sections.
The difficult thing is to reduce edit conflicts at newpage patrol.
Now the
complicated way to reduce edit conflicts here would be to have some logic in
the editor that treated paragraphs, categories and templates as independent
entities much as it does sections

Just as a point of observation: As far as I can see, detection of edit conflicts is NOT based on sections, it's based on paragraphs (as far as I understand, either blank lines or paragraphs will work as deviders, but I could be wrong about the details.).

I've just had an edit conflict where someone had responded to a different post in the section, so I'm pretty sure it currently works at section level. If it differentiates by paragraph then it needs a blank line, and on talkpages those are rare. It would be good progress if it didn't cause an edit conflict for one person to reply to one !vote in an RFA whilst another !voted in the same section.

(In reply to comment #1)

Summarizing the two proposals here:
(In reply to comment #0)

The easy way is to disable the edit button for very busy articles.
when anyone clicks the big edit button at
the top of a busy article render: "Sorry, but this article is currently very
busy, so to reduce edit conflicts you can only edit one section at a time.
Please pick the section you want to edit", then gave them a choice of sections.
The difficult thing is to reduce edit conflicts at newpage patrol.
Now the
complicated way to reduce edit conflicts here would be to have some logic in
the editor that treated paragraphs, categories and templates as independent
entities much as it does sections

The problem with summarising complex proposals is that you lose some of the complexity. For example your summary omits "starting all
new articles with two lines "==References==" and "{{reflist}}" in the middle of
the first screen." This should be simple to code and would on its own be quite a big step forward.

(In reply to comment #3)

I've just had an edit conflict where someone had responded to a different post
in the section, so I'm pretty sure it currently works at section level. If it
differentiates by paragraph then it needs a blank line

Yes, it needs a blank line. A blank line is the markup for a paragraph in wiki syntax. And yes, it would be very nice if lines starting with "#", "*" or ":" (or space, or... ) would also be paragraphs.

That might actually be doable without too much pain, and would probably already greatly reduce the change of edit conflicts on talk pages. I propose to file that as a separate feature request - it's a concrete request and a self-contained change, so there's a good chance that it gets implemented swiftly.

(In reply to comment #1)

Summarizing the two proposals here:
(In reply to comment #0)

The easy way is to disable the edit button for very busy articles.
when anyone clicks the big edit button at
the top of a busy article render: "Sorry, but this article is currently very
busy, so to reduce edit conflicts you can only edit one section at a time.
Please pick the section you want to edit", then gave them a choice of sections.

Looks like an extremely bad idea. We must not add more clutter, we have to make things work. --> WONTFIX

The difficult thing is to reduce edit conflicts at newpage patrol.

Now the
complicated way to reduce edit conflicts here would be to have some logic in
the editor that treated paragraphs, categories and templates as independent
entities much as it does sections

This is solved by the PageTriage extension.

(In reply to comment #5)

(In reply to comment #3)

I've just had an edit conflict where someone had responded to a different post
in the section, so I'm pretty sure it currently works at section level. If it
differentiates by paragraph then it needs a blank line

Yes, it needs a blank line. A blank line is the markup for a paragraph in
wiki
syntax. And yes, it would be very nice if lines starting with "#", "*" or ":"
(or space, or... ) would also be paragraphs.
That might actually be doable without too much pain, and would probably
already
greatly reduce the change of edit conflicts on talk pages. I propose to file
that as a separate feature request - it's a concrete request and a
self-contained change, so there's a good chance that it gets implemented
swiftly.

I agree, someone please define the request exactly and keep bugs specific (defining the aim and not the proposed solution). We already have bug 13462 and bug 42053.