Right now people over-write each other, edit unknowingly when others are editing, etc. Could we improve the edit-feature maybe to lock the question while it's being edited, and show who is currently editing it? Perhaps give the edit 10 minutes before the lock is lifted, and the user cannot touch the question for another 10 minutes or so.

Potential Abuse:

While it is possible that some people would attempt to lock themselves "in" to prevent others from editing the question, they would first need sufficient reputation (unless they are the author), and their lock will expire after n-minutes. Furthermore, no 1 person is allowed two consecutive edits (within n-minutes?).

alt text

  • 4
    Lol! You had me with the image; I thought that was the actual edit bar; I was... "where'd that come from? huh?" – Marc Gravell Jul 17 '09 at 11:21
  • @Marc, confused myself too :) – Sampson Jul 17 '09 at 11:21
  • The "no two consecutive edits" presents a problem for editing your own posts... but then, I'm simply not a fan of locks in the first place ;-p – Marc Gravell Jul 17 '09 at 11:30
  • What about "no two consecutive edits within n-minutes"? – Sampson Jul 17 '09 at 11:39
  • It would be like not posting more than 1 comment within 30 seconds. A rule that currently exists on SO. – Sampson Jul 17 '09 at 11:40
  • Is this a dupe? - meta.stackexchange.com/questions/1577/… – ChrisF Jul 17 '09 at 12:57
  • It's similar, ChrisF. But I'm suggesting a lock during edit, as well as a few additional features. – Sampson Jul 17 '09 at 13:06
  • (-1) I've added a downvote, because I don't like the idea of locks of any kind for editing. – devinb Jul 17 '09 at 13:10

We now prevent this.

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

{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.

  • Do you save the edits in localstorage so all is not lost? Yes, I know, impossible dreams. – jcolebrand Mar 30 '11 at 0:57

I (along with Marc) believe that locks are not the way to go.

I like your idea of an "in edit" tag. Or perhaps when you attempt to 'check in' your edit, it could present a version control style 'merge screen'. Shouldn't be too difficult since they already run a diff in the backend for use the the history.

You should be able to 'merge' 'overwrite' or 'discard'.

With that solution, you would not need the tag, because the tag DOES have the downside of broadcasting that someone is MAKING an edit, which, in the case of RichB, means that there are people who would wait around until he's done and then just overwrite his edits.

If, instead you don't say "who" edited/editing, but just pop-up the 'edit merge' dialog that I'm claiming they should create, then you get a change to see if someone has made the same edits you have.

  • 1
    I'm worried what the 'merge,overwrite,discard' screen would look like if say 3 or 4 people were making simultaneous edits. – Sampson Jul 17 '09 at 12:46
  • @Jonathan, like source control, it doesn't care HOW MANY edits have been made since, it only cares about the edit you tried to make and the current server version. If four people are currently editing, then one checks in, no problem, a second checks in, and merges against the first 'check-in', a third checks in, and merges against the second check-in, etc. Source control would be terrible if only one person were ever allowed to edit the source code at a time. – devinb Jul 17 '09 at 13:09
  • 1
    @devinb - you've seen Visual SourceSafe, I take it? ;-p – Marc Gravell Jul 17 '09 at 13:20
  • @Marc, I've unfortunately never had the pleasure of working with Visual SourceSafe. I've been spoiled by TFS for my working career. I shudder to think of going back to the dark ages prior to it. Zip Files as source control. – devinb Jul 17 '09 at 13:24

I'm not sure it needs locks; but it is indeed a problem. Perhaps something as simple as including the revision number when editing, and not committing if there is a mismatch (but re-displaying the users edited textbox! it would be painful to re-type). Then the problem becomes the standard "merge" issue - you've got the original copy that you started editing, your revised copy, and the conflicting ("HEAD") copy. You'd probably need to be able to see at least "yours" and the "HEAD" copy to manually merge (or decide that actually the other edit has done the job adequately).

Although it is a problem, I'm not sure it is a very common problem. I have, however, seen a post get wiki'd in under 4 minutes by 8-odd people trying to fix the same question. Any 1 of the edits would have been fine, but instead all 8 got committed (over-stamping each other). Instant wiki, and arguably unfairly so.

Another problem with locks is that I can guarantee that this will be abused by people who don't want the post edited - i.e. post something inappropriate (spam, abuse, etc) then immediately "edit" to take a lock; normally, it would take the community about 2 minutes to spot this and remove it by editing - but the "flags" approach (spam/abuse/etc) takes longer to hit critical mass.

  • The reason for the locks is to prevent the 8 different people from touching it simultaneously. Seems like there's no way around that without implementing locks. – Sampson Jul 17 '09 at 11:18
  • Re: Locks, I suspected some would lock themselves inside. But 1) They need enough rep to do so, 2) the lock expires after n-minutes and they are effectively locked-out for n-minutes. – Sampson Jul 17 '09 at 11:19
  • Marc's suggestion is very similar to how Wikipedia handle the issue, and in my experience, it works well there – Rowland Shaw Jul 17 '09 at 13:05
  • Does any 1 article experience the same amount of edit-traffic as a single question on SO? (Not a rhetorical question) – Sampson Jul 17 '09 at 13:08

Slight twist: don't lock anything, merely prevent edit submissions from other users within the 5 minute timeframe already used to coalesce consecutive edits. This includes the initial revision, so 5 minutes from posting this answer, only I would be able to edit it, for example.

This requires no UI change when displaying the post (it's obvious that if the last edit is less than 5 minutes old, the last editor has it "locked"), and a user could still use the edit link to open the editor. The editor could display "X minutes until .." and should encourage users to merge their changes with those from previous editors.

The only potential for abuse is making a quick edit to "grab edit rights", then fixing everything you can within 5 mins. Social pressure should be enough to discourage that from people who do it badly. Additionally, this only forces what I see as good convention anyway: I will purposefully wait until the last edit is at least 5 minutes old.

A side benefit is you have a grace period to review your post and fix any typos or small errors, which is annoying when you're already doing that within the 5 minutes and you get "This post has been editedmurdered by someone else."

  • I'm ambivalent on extending this to 10-15 minutes while still keeping the 5 minute auto-merging (but the timer wouldn't reset on each 5 minute edit), but the timeframe needs to be at least 5 minutes. – Gnome Apr 9 '10 at 19:46

You must log in to answer this question.

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