Editing: add a "require author approval" checkbox

Question

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:

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:

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?

Answer 1

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.

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?