Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 153 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

While reviewing edits, I sometimes come across edits of the form:

The code above works fine in most situations but has a bug when xxxx. Here is a corrected version: (code follows, rather different i.e. not just a typo)

How are we supposed to deal with those edits (assuming they are correct of course)?

  • On the one hand they could probably be flagged as "invalid edit" (it should be a separate answer) or "radical change" (as it does change the original answer significantly)
  • On the one hand they add interesting and useful information and rejecting them seems counterproductive as the user might not take the time to create a separate answer after the rejection (or the user is anonymous in which case I would have thought s/he doesn't even get notified)
share|improve this question
up vote 6 down vote accepted

Edits that make substantive changes to other people's code (rather in questions or answers) should be rejected. If they're doing something more than fixing an obvious typo or reformatting code blocks that are difficult to read, they probably aren't a valid edit.

Even if you know the language and agree that their proposed "fix" is a "better" way of doing things, you still shouldn't approve the edit. That is an abuse of the editing system. You don't need to be a domain expert to judge an edit that is useful or inappropriate. Suggestions on how to improve someone's code should be posted as a comment to the post, or perhaps as an entirely separate answer (depending on the nature and scope of the corrections). We don't want to use edits to put words into people's mouths, especially when it comes to code.

I generally reject these types of edits as an "invalid edit", implying that they should have been posted as a comment instead. If you feel more comfortable rejecting them as a "radical change", that's fine, too. It really doesn't matter which rejection reason you pick, the point is that we shouldn't be allowing these through.

On the one hand they add interesting and useful information and rejecting them seems counterproductive as the user might not take the time to create a separate answer after the rejection (or the user is anonymous in which case I would have thought s/he doesn't even get notified)

This is a potential concern, but I don't think it overrides the cardinal rule not to make significant modifications to other people's code.

If you want to educate these users (which is, of course, the point of a suggested edit system, as "training wheels" for future editors), then you could reject their edit with a custom reason. Something like:

Making substantive changes to other people's code via edits is discouraged. Please either leave a comment with your suggestions, or post a separate answer to the question.

If and when the team finally decides that making the rejection reasons for users' suggested edits more visible is a good idea, information like this will be very helpful.

If you feel particularly moved by a particular suggestion, and you don't think the person who suggested the edit will follow through after you reject it, you can add it as a comment or answer yourself. Nothing wrong with that, so long as you give proper attribution to the original user.

I've even done this occasionally when someone tries to leave an obvious comment to someone's answer using the suggested edit system. I will leave a courtesy comment to the poster, linking to the suggested edit, and summarizing their point.

share|improve this answer
@MrLister Yeah, it's a gut call. It's rather difficult to write a rule for this, which is why we haven't automated the handling of the suggested edit queue yet. But that's not really what this question is about. He's talking about edits that fix a bug, and even says that they consist of more than fixing a simple typo. As far as your specific example, I'd have to see it in context. Is the extent of the function return 42;, or is 452 appearing somewhere else? Anyway, when in doubt, reject. This kind of thing is what comments were made for. – Cody Gray May 22 '12 at 9:56

Another option, which I've tried a couple of times recently, is to add a comment to the question/answer saying "Someone just suggested [this] edit, I'm going to reject it as too radical, but you may what to check it out".

On the two (I think) occasions that I've had any reaction, it has been positive.

share|improve this answer
I really wish that this could be a feature, new Button "Refer to Author" – örs May 22 '12 at 11:30

This looks like the case when I would use "Custom" reject reason for an edit, with appropriate explanation.

share|improve this answer

I think the option that would be most ideal in this situation is a third one:

  • Reject the edit as "This edit is best suited as a comment on the post, rather than editing it directly."

However, most of the times I've seen this, it's by new/ anonymous users who don't have comment privileges yet.

Firstly, if the edit is fixing code mistakes more obvious than this (typo, basic logic) etc, then I'll accept the edit. If it's something more finikity like what you propose on a language I'm familiar with and I agree with the edit, I'll accept it.

If I'm not familiar with the language, I'll leave it for someone else to judge (although they usually end up getting rejected as "Radical Change").

share|improve this answer

You must log in to answer this question.

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