Problem statement

Currently, the FAQ says:

When should I edit posts?

Any time you feel you can make the post better, and are inclined to do so. Editing is encouraged!

Some common reasons to edit are:

  • to fix grammatical or spelling mistakes
  • to clarify the meaning of a post without changing it
  • to correct minor mistakes or add addendums / updates as the post ages
  • to add related resources or hyperlinks

However, it seems that in practice, these common reasons are the only accepted reasons. For instance, edits such as code addition/modification seems systematically disapproved by the community, even if we "feel it makes the post better" (sometimes rightfully, but sometimes not of course).

The reason is that it is considered as changing the meaning of a post too much, or that it does not respect the author. Hence, the encouraged and respectful way to deal with this situation is to leave a comment, that may or may not be taken into account by the author.

While I agree with this recommended behaviour, I think it has the following drawbacks:

  • It creates noise in the comments (post improvements + explanation best lie in revision history)
  • The person suggesting the edit is not credited in the revision history
  • A comment may not leave enough space for the suggested contribution, and the reduced MarkDown may not make it convenient.
  • The original author still has to make the edit himself (either by copy-pasting, or creating the final content following the general idea of the suggestion) while the external contributor may have been enclined to do it himself.

Proposed solution

Adding a checkbox "require author approval" to the normal editing process, like this:

checkbox unchecked

This would allow more substantial edits such as:

  • writing a full new paragraph (when it does not make sense to post it as a separate answer)
  • code improvement
  • code creation (accurate implementation of author suggestion)

And this would still be respectful to the author, by voluntarily choosing that this edit is only a "suggestion" made to the original author, hence that is not imposed to the author. Checking the checkbox may display the following message:

checkbox checked

When the edit is saved, the author receives a notification of suggested edit, with for instance the following text:

UserABC has performed an edit to your post to improve it, but has voluntarily required your approval. This means he or she believes there is a possibility you may disapprove, and wants to give you the opportunity to perform one of the following action before it becomes public:

  • accept the edit
  • decline the edit, with an optional explanation to UserABC
  • modify the edit, with an optional explanation to UserABC

From which he can perform the desired action.

If the contributor has less than 2k reputation, this would override the traditional review queue, since in this case it does not make sense that external reviewers can refuse (resp. accept) the suggested edit that the original author would have accepted (resp. refused). This doesn't break the possibility to improve "bad question" from new users (that the new user may have refused), since in this case we would not check the checkbox, and the modification would be applied either instantly for >2k user, or go through the normal review process for <2k users.

This solution solves all the points discussed in the problem statement:

  • Remove noise from comments
  • Credit contributor in revision history
  • Make contribution easier by using full editing features
  • Leverage original author work

Any thoughts?

  • this looks almost the same suggestion I gave in this post. And yes, This will be useful...
    Jul 12 '13 at 5:24
  • 1
    I just realized this related post. Anyway, I'm more thinking here about improving answers, not questions. Jul 12 '13 at 5:25
  • 2
    @CRUSADER: No, your suggestion, while good, is very different. You propose a mechanism to alert the OP when an answer is updated, and what I propose is a mechanism to propose an edit to an existing answer (or question), so that the author of the post can decline it. Jul 12 '13 at 5:27
  • 4
    I would support this if it were overruled after a certain period of time; the only problem I see here is that you have the potential for a lot of content to be lost in the ether if the OP never returns to check this notification and approve. So if after a certain amount of time (a week? up for discussion) the OP had neither rejected nor approved the edit, it should be automatically approved (if you have edit privileges) or sent for peer review (if you don't have edit privileges).
    – WendiKidd
    Jul 13 '13 at 3:21
  • @WendiKidd Indeed, this is an interesting option to consider. But I would say at first thought it is probably not a good idea. The cases where you would use this feature are when the edit would normally not be considered "acceptable" (peer review would refuse it). It means something like: "Hey, I've proposed an edit that is out of the limits defined by SO, but I really think it improves your answer, do you agree and accept it?". Automatic acceptance (even after a delay) would defeat the purpose. With the current "workaround" through comments, content is also "lost" if author does not proceed. Jul 13 '13 at 4:41
  • @Boris Well the comments still exist, so I don't agree that the information is lost. Hmm, I don't know. I see your point but I don't think that possibly losing content to the ether fits with SE principles. I suppose we'll have to see what comes of further discussion!
    – WendiKidd
    Jul 13 '13 at 16:13
  • @WendiKidd Good point about the comments still being there. Maybe a solution would be, after some time, to be able to see the edit, but with a disclaimer at the top: "the last revision of this post contains significant changes by another author that may not reflect the views or opinions that the original poster". Jul 13 '13 at 20:26
  • 2
    Nice suggestion, this would probably also solve the Show the post's comments on the “Suggested Edits” review interface problem. As an addition, maybe reviewers could get this option as all, indicating that while they consider this too radical to be simply accepted they suspect that OP might agree with the edit and should really judge by themselves. Aug 22 '13 at 8:34
  • 4
    Note this function would require a cooldown, i.e. if the OP doesn't react within a sensible time (say 24h), the option would be ignored in order to avoid a) eternally pending edits and b) OPs overburderned by too many suggestions (could happen to users with many posts like Mr. Skeet) Aug 22 '13 at 8:37
  • I don't know. It would be rather easy, for the OP, to give the 2 points reputation to a friend, if the friend of the OP would always select the checkbox. I can also imagine somebody could avoid the other users' review, knowing the OP would accept his suggested edit, even if it was wrong. Does the OP always know when a suggested edit is correct? No.
    – apaderno
    Aug 31 '13 at 14:25

We already have plenty of mechanisms to improve posts:

  • comments when you see a post that is not perfect but you aren't sure how to improve it;
  • edits to make improvements that do not fundamentally change the post, such as clarifying, correcting minor mistakes, adding references, etc.;
  • downvoting and posting an alternate answer if an answer is fundamentally flawed; closing if a question is fundamentally flawed.

Edits requiring author approval would only cover a tiny use case. If you aren't sure of your improvement, a comment is perfectly appropriate. There are a very few cases where it is difficult to describe a proposed improvement in a comment due to the lack of formatting, but these are extremely rare in my experience: usually either an edit or an alternate answer is appropriate in such cases.

Improvements proposed through comments can certainly be reflected in the revision history: if someone proposes an improvement to one of my posts and I carry through with an edit, I always credit them in the edit summary (unless I forget, but usually I do). Improvements suggested in comments aren't noise: such unresolved issues are what comments are for. They only become noise if the edit has been done. As for the original author having to carry out the edit himself: it's worse with your proposal; at least with a comment anyone can go and do the edit.

Note that post authors are notified of all suggested edits on their post. So if you make a suggestion and it's rejected, the author can still find out about it. The notification is easy to miss among the mass though.

If you are sure that you have an improvement, go ahead and edit. On Stack Overflow, you may run into reviewers who reject good edits in contradiction with the official rules for editing — this is an old problem which unfortunately repeated threads on Meta Stack Overflow shows that we're nowhere near fixing. Nonetheless I don't think that adding a tool to work around that deficiency is the right way to go. It adds a whole new tool which counters a problem that needs solving regardless of the existence of that tool, and has inferior workflow to the existing tools.

Stack Overflow (but, I'm glad to report, in my experience, not the other Stack Exchange sites) has a problem with good suggested edits being rejected. In particular, there are many people who systematically reject edits that modify code, or other such nonsense. I think the way this came about is best explained by telling a story.

You might have seen this story before: researchers placed monkeys in an enclosure and put a banana on top of a ladder. Every time a monkey climbed the ladder to reach the banana, all the other monkeys were spread with water, which they disliked. So the monkeys started to attack any monkey who would climb the ladder. After a while, the monkeys no longer tried to climb the ladder. Over time, the scientists replaced the monkeys one by one. Newcomers quickly learned not to climb the ladders for fear of their fellows attacking them.

After a while, none of the original monkeys were around. But all the monkeys knew that you shouldn't climb the ladder. Why? They didn't know: none of the monkeys present had seen anyone being sprayed. But still they would attack any monkey who tried to climb. Ours is not to question why.

the monkeys and the bananas

How does that relate to Stack Overflow and suggested edits that improve code? Well, pretty much everyone agrees that you shouldn't edit code in questions beyond indentation and such. This is because the part that you edit may well be the one that caused the problem that the question is about. Over time, this has been quoted repeatedly to say that you shouldn't edit code in answers. Why? There's no good reason. Of course, since this happening with humans and not with monkeys, people have come up with plenty of bad reasons not to edit code in answers — that fixing a typo is “a radical change”, or “changes the meaning”. These reasons are in direct contradiction with the rules for editing, and indeed editing is a core value of Stack Overflow. But since there's a nice-looking rule (“thou shalt not edit code”), it's being bandied about whether it's appropriate or not, omitting the context and the reason for that rule in the first place (“… in a question”).

And to add to the meta-ness: the monkey story? It's a good one… but it's wrong. Yup, although its origin isn't known for sure, no trace of such an experiment can be found, and all signs point at this story having been made out of whole cloth (and perhaps different experiments in different contexts with different conclusions). But hey, it's a good story, so why think about why it's there when it's so easy to just take it for granted?

  • +1 for pointing out the real problem. However, I'm not sure a work-around shouldn't be added. You can always remove it once (if) the problem is solved. Aug 31 '13 at 14:33
  • +1 Thx a lot for this awesome answer. I Indeed suggested this feature after having a code addition rejected, that I still think was truly clarifying/improving the post without changing any of its meaning, hence following the FAQ guidelines. Then I learned that well, yes, adding/modifying code is not accepted by the SO community (even though it's not stated anywhere in the FAQ), for reasons I strongly disagree with, for the reasons you pointed out. Accepting this fact, I proposed this instead. But I am 100% for solving the true problem in the first place, if it can be. Sep 3 '13 at 2:26

You must log in to answer this question.

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