What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 127 Stack Exchange communities.

When editing other users' posts, to reformat code or to clarify the meaning of a question, for example, I always return to the post, and refresh it, before submitting the changes to make sure that someone hasn't already made the same changes to the post whilst I have been editing it. I have found that this would be a particularly common scenario with the more popular questions, or questions that have unformatted code which several people may rush in to edit, for example, and it is unclear when editing the post whether changes have already been made by other users.

What I am proposing is that:

  • When editing a post, you are notified if there have been any other edits by other users on the post, whilst you have been editing it, similar to the notification displayed in the bar at the top of the page when answering a question and other users post answers.
  • If other users have edited the post, have the option to load the most recent version, whereby further edits can be made if need be.

This would reduce the time wasted by others making changes to a post that have already been put into effect without their knowing, and also reduces the number of revisions on a post that are similar or the same.

Edit: as dbr said, it wouldn't necessarily have to be a real-time notification.. Just some form of notification to help reduce duplicate edits.

share|improve this question
    
enhanced per my answer –  Jeff Atwood Apr 13 '11 at 11:40
add comment

4 Answers

up vote 15 down vote accepted

This is partially implemented. You'll get async notifications during editing, if someone else saves a revision during your editing. These notifications ping the server every 45 seconds to check.

Additionally, we now prevent edit collisions on save.

When you click "Save Edits", if the post changed while you were editing, we now return:

Warning! You're editing an old revision. If you save it, you will effectively roll back to this old version of the post.

And:

Oops! Your edit couldn't be submitted because:

  • {username} edited {tags / body / title} of this post; try refreshing this post and editing again.

It is specific to the area in question, so one user can edit body and you can edit tags without conflicting. (Or title, etc). It's only when you both edit the same field at the same time this error is returned on save.

share|improve this answer
    
Yay for collision-detection! –  Shog9 Mar 30 '11 at 0:55
    
Somehow, the new collision detection did not work when a suggested edit was made while/before/after I started editing and saved that... –  Arjan Apr 17 '11 at 10:51
    
(And as Community approved that suggested edit, it kind of looks like I used the improve button. Which I did not.) –  Arjan Apr 17 '11 at 11:54
    
@Arjan, I will look at improving this, but it is pending the rejection reason stuff being implemented. cause then I can have the system silently reject without implications. Can you log a bug on this. –  waffles Apr 26 '11 at 6:53
    
@waffles, the bug report is already there: Collision detection fails when saving while suggested edits are pending? My bad for not cleaning up the comments above! –  Arjan Apr 26 '11 at 7:21
    
Is this still used? Or is all inline editing now, which does not warn about all concurrent edits, according to @waffles and this example? –  Arjan Oct 1 '11 at 11:06
    
@arjan it's the same warning inline and full-page now, no difference –  Jeff Atwood Oct 1 '11 at 14:08
    
The above needs some editing, but I'm not 100% sure of all nifty details—nor if we want those to be duplicated anyhow. For future reference: collision detection in the inline editing, and rules about silently overriding. –  Arjan Oct 2 '11 at 10:29
add comment

I don't think I've ever encountered this problem, but overwriting someone elses work is pretty crappy, and should be prevented..

Perhaps you could steal the Wikipedia method of resolving edit conflicts - if a question is modified since the user started clicked edit, when they click save it shows both versions side-by-side, and allows the user to manually merge them.

Pretty simple to implement, all you need is a hidden form edit_start_time, which you compare to the questions last_modified_time when the user clicks save, and a page which shows the markdown from the other user and the WMD box with the current users edit. A diff would be nice, too (since the framework is obviously there for the edit-history)

Adding another polling-for-activity feature seems like it would a lot of unnecessary strain on the server - I definitely think it's justified for new answers, but for edits it seems overkill (as I said, I don't think I've encountered the problem before)

share|improve this answer
    
Ah yes, that's a better idea. –  Alex Rozanski Jul 2 '09 at 11:52
2  
Here's relevant question I asked about how wiki's merge concurrent edits: stackoverflow.com/questions/223040/… –  Sam Hasler Jul 2 '09 at 12:05
    
Here's my suggestion for this: meta.stackexchange.com/q/233719/183189 –  MDeSchaepmeester Jul 3 at 10:48
add comment

I don't think SO should let you submit your changes if someone else has edited the the post in the meantine, or at least not without acknowledging that yes, I'm overwriting the other person's changes.

Take a look at the history of this question. Two minutes after it was asked, 4 (!) people (of whom I was one) simultaneously made changes, attempting to fix the bad code formatting and various grammatical issues. We all stomped on each other toes as a result. It would have been much better if, after the first edit was made, further concurrent edits did not immediately succeed.

This is what Bugzilla does -- if you attempt to make changes to a bug, and someone else has edited the bug in the meantime, Bugzilla will give you an error page when you try to submit, and then you have to go back, refresh, and merge your changes back in. I think this works fairly well, since most of the time, all you're doing is adding a new comment and/or changing a few fields, which can easily be redone. I think this would also work well for SO.

share|improve this answer
add comment

First: don't get me wrong, I like having the notification. But it really doesn't help much.

I recently had it pop up for me. So I thought, "OK, I'll check and see what's changed." I middle-clicked the "back to question" link -- oh, wait, there isn't one! So I had to middle-click the main Stack Overflow banner at the top, look for the question in the list, open it, then click on the revisions link. At that point I could finally see the edits.

But once you see the other person's edits, what do you do? We'd both made large formatting changes, so I couldn't tell what was going to be different in my version. I ended up saving anyway because that's the only way to get a diff. And it knocked the question to CW.

So there are two things about this process that I think could be improved.

  • Re-add the back-to-question link. This suggestion has been beaten to death already (and everyone seems to favor it except the ones that count).
  • Add a merge-resolution interface before saving, basically like dbr already suggested. Could clicking on the notifier perhaps let you view the differences inside the same edit screen, without being obligated to save first? And Wikipedia might already do this, but I'd also suggest that it be a diff of the actual Markdown code; that would make it much easier to see formatting changes.
share|improve this answer
add comment

You must log in to answer this question.

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