I was reviewing a suggested edit and decided that while the edit was incorrect, there were things to improve about the post. So I clicked “Improve” and set about my business.

When I tried to submit my edit, I got the following error message, telling me that the post had been edited in the meantime by the suggester:

User already edited the body of this post; your edit must be more substantive to override the current edit.

When I tried later on a tag wiki, I got the altogether unhelpful indication that “an error has occurred”, and again no way to do anything but cancel and lose my work.

But refreshing the page brought me to the suggested edit page, showing the suggested edit as approved, with no trace of my editing. (Fortunately I'd saved my text on the side!) With a later suggested edit on a tag wiki, I was marked as having reviewed the suggestion, with the indication “edit” — but there was otherwise no trace of my alleged edit.

So, if you improve a suggested edit and it gets approved in the meantime, you get into a situation where

  • there is no link to the post;
  • if you go back, you get to what you were doing before and lose your edit;
  • if you reload the page as instructed, you lose your edit.

The bug here is that unless you take extra precautions such as copy-pasting your edit into an external editor, you will lose your work.

Expected behavior

Unlike normal edit conflicts, an edit made to a suggested edit is guaranteed to be a derivative of the suggested edit - so if that edit was approved and then an "improved" version is submitted, that "improvement" edit should be applied to the post (the helpful status indicated by the checkbox shouldn't affect anything though).

When two different reviewers both opt to improve a suggested edit, a conflict is unavoidable - this should be resolved based on the size of the edit, as is the normal behavior.

  • 1
    I think the suggested edit improve should work the same way of normal editing: 1) it will check whether someone else improved the post and show a warning 2) and it will appear as a new edit over the suggested edit.
    – nhahtdh
    Commented Sep 3, 2012 at 16:19
  • 6
    This is why I always copy my text that I enter into anything. Too many, "Log in.. whoops, what did you say again?" Commented Sep 7, 2012 at 15:17
  • I asked a very similar question already (though not exactly the same)...
    – Gaffi
    Commented Sep 7, 2012 at 19:53
  • 1
    I can confirm that this is still broken. I've occasionally been able to override an approved edit with my improvement, but I often get stuck as described. Maybe a broken “more thorough” check? An improvement is by definition more thorough (bug #1), and in the case of concurrent improvements there should be a way to review (bug #2) and override (bug #3). Commented Sep 12, 2012 at 10:01
  • 6
    +1. I just got this myself. The warning User already edited the body of this post; your edit must be more substantive to override the current edit. was received when trying to submit my edit (note that the warning is quite misleading; it's the act of the original suggested edit being approved that prevents you from submitting the improvement, not another edit, or further edit to the post). The ideal workflow here is that an improve overrides any approval/ rejection that has happened in the time it's taken you to improve the post.
    – Matt
    Commented Sep 14, 2012 at 9:35
  • 1
    This happens to me also frequently, and it's the more frustrating when the reviewed edit should have been rather rejected, if not improved.
    – Adinia
    Commented Oct 9, 2012 at 7:47
  • 2
    There is an easy solution, stop reviewing posts. Let the site owners do all the moderation until they fix the review system. As it stands now, it is completely broken.
    – Lundin
    Commented Mar 25, 2013 at 7:36
  • 1
    @Lundin: What, as in moderators? Not possible.
    – Ry-
    Commented Mar 25, 2013 at 15:50
  • 4
    @GraceNote So, any news? It's been 6–8 months, and the bug is still there. Commented Jun 2, 2013 at 18:44
  • Related: Allow manual override for edits — but there are other issues when improving a suggested edit, in particular the lack of an easy way to open the post in a new tab, and the fact that improvements are systematically treated as less substantive than the suggestion. Commented Aug 8, 2013 at 12:59
  • @Shog9 6 to 8 months later, the bug is still there. Can you flip one bit please? Instead of treating improvements to suggested edits as always less substantive than the suggestion, treat them as always more substantive. Commented Jan 16, 2014 at 0:02

10 Answers 10


Improving a suggested edit is now considered more substantive than an approved suggested edit for the period of 10 minutes after the suggested edit has been approved. There can however still be a conflict if 2 reviewers submit an improvement after the suggested edit has been approved - in that case we fall back to the standard edit conflict resolution.

Implemented in build 2014.2.3.1913 on meta and 2014.2.3.1343 on sites.

Editor's Note: Since this request was filed, there is now a period of exclusivity of 3 minutes when users get a suggested edit review task. In other words, for the first three minutes after you load a review task, the same review task will not be shown to others, so this situation should occur much less often. There are still some edge cases (e.g. manual navigations, accessing the suggested edit from the post and not the review queue, from the notification on suggestions to one's own posts, etc.), but those are rare.


Normally when you're editing and someone else makes an edit to the same post, you get a nice orange box saying the post was already edited, and it makes you refresh the post to see the updated version (if your edit isn't "more substantial").

When reviewing, often crappy, suggested edits and opting to improve, you only seem to get a very, very small timeframe to complete your improvements before it gets approved by ignorant reviewers.

At this point in the process, when their edit gets approved, the post thinks it's now been edited and won't let me submit my improvements anymore (I don't lose my edit like you claim). This is just plain stupid, as I already know what improvements they made. Thanks for telling me that ignorant people just approved the edit that I was going to mark as not helpful, now why are you preventing my edit from being submitted?

My specific case I just encountered was on this post where the user only suggested an edit to the title. It wasn't a great edit and definitely deserved to be rejected as too minor, as clearly there was tons of other stuff to fix in that post. So I finish my improvements and attempt to submit, I'm still greeted with the orange box. How is my massive edit that changes almost everything in the body, plus more changes to the title not considered more substantial than this title-only edit that I've already reviewed and determined needed to be improved, hence I clicked the Improve button.


When I'm improving a post, it shouldn't forbid me from continuing to apply my edit anyways just because it got approved. As stated, I've already seen that edit. I know exactly what they changed, and I know I wanted to improve it. Please stop making it more inconvenient to improve crappy edits.

  • The edit isn't lost in the sense that it's still sitting there in the browser window. But it's lost in the sense that there's no way to submit it short of copy-paste. Commented Nov 20, 2012 at 8:08
  • 7
    My Current Workaround: <!--\nthis\nedit\nis\nmore\nsubstantiative\ndarn\nit!\n-->
    – Ry-
    Commented Mar 31, 2013 at 1:16

The main problem I see with the current implementation is that it discourages reviewers to improve posts. This is because it is very likely that other reviewers will accept or reject a post while you are spending time improving it, especially on sites like SO with many concurrent reviewers. The «punishment» in form of lost work or increased burden is conditioning reviewers to stop improving and instead directly accept or reject suggested edits. The pressure to not improve is further increased by the gamification, which rewards reviewers with badges based on the number of reviews they make. And finally, reviewer bias towards rejecting instead of improving may discourage the people who suggested the edits from editing in the first place. I don't think this is what we want.

A solution would make it as easy as possible to successfully resolve the «accept/reject while improving» conflict, as not to «punish» reviewers for improving. For most cases, the resolution could/should be automatic, as suggested by others.

  • 3
    This is the single most frustrating thing about reviewing suggested edits. I've just had it happen four consecutive times, since I opt to improve almost every valid edit.
    – mmyers
    Commented Dec 25, 2013 at 6:03

Stack Overflow should create an automatic merging feature when edits are made simultaneously. This means that if different lines are edited, it could merge them into a new revision. If the same lines are edited, the system could attempt to identify if different sentences in the same line is edited, and merge in these cases.

I mean, we expect changes to source code to merge cleanly usually, why not this?

In cases where a conflict occurs, a new screen should show what has been committed by a previous editor in a form (with parts which can be merged automatically merged), along with what you have proposed, along with a diff view of any conflict locations (similar to the reviewing suggested edits).

That would mean that most conflicts can be resolved automatically (perhaps with a notification that a merge has been made), and even for conflicts which cannot be resolved, no work is lost.

  • 16
    we expect changes to source code to merge cleanly usually hm I for one dropped that expectation about 10 years ago - and since then, once in a year or two I re-discover that automatic merge is not sufficiently reliable to let it run unattended
    – gnat
    Commented Sep 9, 2012 at 10:30
  • that is mainly talking about semantic merges - which is a problem quite specific to source code. I am proposing merges on text, for which conflicts due to renaming won't cause "bugs". Anyways, I also proposed that you are notified of automatic merges anyways, so I don't see what the problem is.
    – ronalchn
    Commented Sep 9, 2012 at 11:22
  • 3
    What’s a “line”? Do you mean a paragraph? Do you mean a sentence? What makes sense for linebased source-code diff/merge may not make sense for text paragraphs that run hundreds of characters before they encounter a newline character.
    – tchrist
    Commented Mar 16, 2013 at 18:02
  • At least for concurrent "Edit" reviews, there is such a feature: check this review and this resulting history. My edit included the exact same tag changes, and the system correctly merged my change with the concurrent edit.
    – oberlies
    Commented Jul 26, 2013 at 16:16
  • @tchrist, What’s a “line”? -> A word.
    – Vi.
    Commented Nov 30, 2014 at 3:03

I've encountered this issue many times (I was thinking of posting it here), and what's especially frustrating is that it seems to be caused by the post being approved rather then just edited, and quite often it probably should not have been approved at all.

Implementing a CheckIn/lock process for reviewing should resolve this issue as well as encourage more thorough reviews as opposed to fastest gun in the west style reviews.


The simple solution is that if a 2k+ editor has done an improve (and I was thinking you had to be 2k to get an improve option), then just have their edit go through, overwriting the approved suggested edit, just as if they had gone to the question and hit the edit button.

That dialog stopping the process should only appear if someone has edited the post after the suggested edit was approved (which might happen if the editor took a ton of time to do his edit).


Stack exchange should create locks on the posts. It should allow only one user to edit the same post at the same time.

Once a user is editing a post, then any other user that tries to edit the same post, should be notified that the post is already locked by another user and you could edit the post, when the current user is done with editing.

  • 1
    We basically do. The problem here is improvements replace the suggested edit, but if the suggested edit is approved in the meantime, the improved version (which otherwise immediately overrides it) replaces the improved version, completely erasing it.
    – Zelda
    Commented Oct 19, 2012 at 0:29

Personally, I think you should be allowed to edit your own questions no matter what (so it overrides any other edits). Your edit should take priority. If you feel that your question needs editing, surely it should be your responsibility. In your case, I think the other person should be notified of your editing, then have to wait until you've finished, then check your edit.

  • 4
    Yeah, sure, but that's a rare case, worth a separate feature request and irrelevant here. Commented Sep 9, 2012 at 17:53

Yes, I agree it is really frustrating after you make a lot of edits and you got the alert.

I would suggest whenever a person edits a question and the post got already updated, we can show a Modal-popup with the message.

This post has already edited and now its content is given below. If you still feels that your review is more helpful then submit your edit

In the popup we also show the current edit content and if user after reviewing the post submit own edit, then it should get priority.

We can solve the problem of losing edited content and save the steps of copy-paste by this.


I agree with animuson, so I propose the following:

  • Add a grace period of 5-10 minutes. People that have the review already open can vote, others can't.
  • Because we could get 4 rejects after the edit already has 3 accept, I suggest changing the rules for accepting/rejecting a post in the following way:
    • The minimum difference of the majority needs to be 2 (or maybe 3 on SO)
    • The review is removed from the review queque once it reaches the that thereshold.
      • Don't display the "edit (1)" button that leads to the review.
      • The grace period starts now.
      • If the outcome was accept, show it?
    • If the thereshold changes in the grace period, the suggested edit review is added back to the queue.
    • A vote from an moderator/the OP is binding. Don't use the grace period in that case.
    • An improvement let the Community user cast a vote (like before). I assume that only people that want to improve the post do that and that improving an edit is too much work for the robo-reviewers.
    • A moderator and the OP can also cast a binding vote on the review AFTER the grace period until an other edit has been done. An improvement count as an other edit.

The effect of this is:

  • You have at least 10 min time to review/improve the post
  • Controverse edits are reviewed by more people (the suggested edits queue is almost always empty, so it does not sound like a problem)
  • It allowes the OP (and ♦) to override the outcome of the suggested edit review.

But when to grant the +2 rep for the suggestor?

  • I suggest after reaching the thereshold with the outcome accept.
  • Revoke the reputation if the review does not longer hold the required thereshold.
  • 2
    I don't understand what you're driving at. What's the point of all these rules? This is a simple bug: now, when you finish an improvement, it's systematically rejected if the edit was approved in the meantime. The test should be reverted: systematically accept an improvement as being more thorough than the suggestion. Commented Dec 13, 2013 at 9:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .