Wikipedia:Avoiding edit-conflicts

It's often a good idea to avoid edit conflicts, you never know what mistakes you might introduce in resolving them

This essay describes ways to reduce, or totally avoid, an edit-conflict that rejects saving a current edited revision. For background, see: Help:Edit conflict.

There are several techniques, or tricks, to avoid many types of edit-conflicts. The key issue is to keep changes separated by at least 1 unchanged line between them, but also keep away from areas where lines are being moved from or to. Some tactics include (each linked below): short lines, text-separators, reply-separators, or re-edits (copy/paste).

Using short linesEdit

For most article pages (but not talk-pages), an effective method of reducing edit-conflicts is to keep the text split into short lines, such as phrases of 5 or 10 words long, rather than entire paragraphs which wrap 130 words on a single line of text.

Example of short lines:
  • Troublesome: Long lines of text are likely to cause edit-conflicts if edited by users quickly.
  • Best practice:  Long lines of text
                  are likely to cause edit-conflicts
                  if edited by users

For extremely busy pages, modified by many people per hour, then phrases should be kept very short, with many section headers in the page.

Using reply-separatorsEdit

In a dialogue, such as for a talk-page or project-page discussion, the edit-conflicts can be reduced by separating various replies by a reply-separator line. Any text could be used, even a blank line, if other editors were aware why the replies were being separated. For example, an HTML-comment phrase "<!--reply here...-->" could be inserted, after a question, to avoid conflicts with later replies.

  • Should the article on France be split into subarticles?
    <!--reply here
       --or below-->

Any text placed before "reply here" would not conflict with text placed below the comment, to give editors two different places to respond to the same question without an edit-conflict.

Example with replies:
  • Should the article on France be split into subarticles?
    : The split already follows "Outline of France". -JDoe 08:02, 16 June 2013 (UTC)<!--reply here
       --or below-->
    : The sightseeing should be shortened, with links to Wikivoyage. -MSmith 08:02, 16 June 2013 (UTC)

In the example, the replies by users JDoe and MSmith can be added within the same few seconds, because the 2 replies are separated by another line (by the line "--or below-->"), which provides the unchanged line between two sets of changed lines. If two editors agree who will post a message at "reply here" versus "or below" then they could both answer numerous questions with almost no edit conflicts. Also note that either reply could be edited, such as for further clarification, whereas 2 adjacent replies would each trigger edit-conflict if the other line were also modified during the same time period. The concept, of reply-separators, could be extended to invite several editors to all reply quickly, such as:

Example for several quick replies:
  • Should the proposal be adopted?
    <!--reply below (at random)-->
    <!--reply below-->
    <!--reply below-->
    <!--reply below-->

If each person picked a spot to reply, at random, then many replies could all be combined, within a few seconds, rather than the typical guaranteed edit-conflict for most editors after the 1st reply was saved. If there were 100 lines of "reply below" then perhaps dozens of replies could all be saved within seconds, until 2 people chose the same line at random.

Using text-separatorsEdit

In general, if text is kept split into 5 or 10-word phrases, then multiple edits to a page, by a few editors, are less likely to trigger edit-conflicts. However, when numerous editors add text, such as into a busy article or list page, then the edit-conflicts can be reduced by separating various text areas with a text-separator line. Any text could be used, even a simple blank line, if other editors were aware why the text areas were being separated. For example, an HTML-comment phrase "<!--add sentence below-->" could be inserted, after a section paragraph, to avoid conflicts with later sentences.

Multiple separators could be used if large amounts of text were being added quickly, within the same few minutes.

Example for adding multiple sentences:
  • == Description of topic xx ==
    <!--add sentence below (at random)-->
    <!--add sentence below-->
    <!--add sentence below-->
    <!--add sentence below-->
    <!--add sentence below-->
    <!--add sentence below-->

As long as the various editors, each, inserted new sentences between the text-separators, then many new sentences could be added into existing paragraphs, within the same few minutes, with relatively few edit-conflicts. By comparison (without text-separators), if one editor adds a new sentence while another editor is changing the line above or below, then an edit-conflict is guaranteed to reject the new sentence.

One tactic could be to wait for a quiet period of a busy page, such as one hour overnight, and then split many long lines into phrases while making other changes, in preparation to continue modifying those lines during busier periods.

Depending on the stability of the page, then some text-separators could be removed after a while, or extra text-separators inserted when numerous editors began modifying the page. Again, for most general editing, then merely splitting long lines into 5 or 10-word phrases will provide enough separation to allow several editors to modify the same paragraphs with fewer edit-conflicts in a short time period.

Using re-editsEdit

The re-edit solution is for an experienced editor, who can copy/paste between 2 browser windows. First, edit the page and proofread changes separately (as a 2nd copied window), then re-edit in the first window, merge the new text (quickly), and save. It is just that simple, as if an editor could edit, write, and save all within 30 seconds. Now, an annoying exception was a bug (in October 2012) that caused a "ghost edit-conflict" when no other editors were actually there. However, remember this simple 4-step fix:

  • STEP 1: Edit a section to prepare/proofread the updated text for merge.
  • STEP 2: Re-edit the section in another window (if gone, review the whole page).
  • STEP 3: Merge the proofread text into the re-edit window (quickly).
  • STEP 4: Save as rapidly as safe, for your level of confidence.

It might be difficult to believe that years of endless edit-conflicts can be solved simply by re-edit & merge, but the reality is that a 15-second re-edit timeframe is often enough to avoid the conflict.

Compare the effort: The bother to re-edit and merge might seem excessive, but it is trivial, compared to walking away from a SAVE, only to return later to an edit-conflict mess, where other editors might have further altered the same text, now with a struggle to redo the botched edit-conflict, as more time passes. The re-edit/merge is much faster.

Extremely busy pagesEdit

For pages with intensely busy edits, it might be necessary to just insert a temporary break subsection, such as "=== Subtopic (continued 2) ===", with a short one-line entry, then re-edit that new subsection to add whole paragraphs of text (by re-edit/merge). Although the extra break subsections might seem like extra clutter in the page, remember they can be removed (or renamed), later, once the frantic editing has subsided. Never think of an edit-break subheader as long-term "clutter" or marring of a topic, because the "====" subheaders can always be removed later, to have a clean, organized page when the flurry of editing slows to a comfortable pace.

Editing only the leadEdit

If you want to only edit the lead, it is possible to turn an option to enable only opening the lead for editing: go to Special:Preferences#mw-prefsection-gadgets. In the Appearance section, select "Add an [edit] link for the lead section of a page". The new [edit] link will appear immediately to the right of the article title.

See alsoEdit