Add info to the help center stating what not to edit

Question

The Help Center has a nice section titled "When should I edit posts?". It comes with a couple of helpful editing suggestions.

What is not made clear in there however is when/what you shouldn't edit. I would propose a small addition to the help center, primarily motivated by some of the comments made here:

Is there anything I shouldn't edit?

When it comes to questions, don't change the code. Minor code formatting and indentation corrections are often acceptable, but for indentation sensitive languages such as Python, even such edits are best not made. Correcting what you think are typos or irrelevant mistakes might well change the entire question or confuse the author.

Editing code in answers follows roughly similar guidelines, though the correction of an obvious typo is often acceptable. If your edit is substantial however, it is often wise to leave a comment for the author explaining the flaw and requesting the correction.

Of course the wording is merely a proposal and I would be open to other suggestions and improvements.

I think such a clarification would be good information to have for suggested edits, and it would perhaps prevent some of the "Why was my edit rejected?" questions we see here on Meta. (One can only hope). Particularly so when the information tells you to "correct minor mistakes".

Answer 1

In general, enumerating badness is a bad idea... Particularly when it comes to something that like editing that depends heavily on context. If you're going try and warn against certain behaviors, you want a few specific, easy-to-recognize examples that the reader can extrapolate from, not a complicated set of prohibitions that must be carefully parsed before it can ever be applied.

The guidance you've written appears to disallow a vast swath of useful edits in favor of those that can be reviewed without any knowledge of the subject. But such edits are already a source of frustration - I see no reason to go any further to encourage more context-insensitive rejections... or more timid, superficial edits.

Should you be extra-careful when editing code? Yes, absolutely. In particular, if you don't have a solid understanding of the language you're working with in general and the specific code being edited in particular, tread lightly.

But presuming that all or even most editors on a site for programmers won't have a clue how to edit code seems... Unreasonably pessimistic. Particularly when it's so easy to correct mistakes.

Worse yet, this guidance directly conflicts with the guidance already on the page, which suggests editing...

• To include additional information only found in comments, so all of the information relevant to the post is contained in one place
• To correct minor mistakes or add updates as the post ages

Shall we abandon all hope of moving useful information from transient comments into permanent, searchable posts out of fear that someone will screw it up? Shall we relegate updates to old posts, their authors long ago moved on, to comments pleading futily for permission to edit?

The problem you're identifying is largely limited to suggested edits - so let's focus on that. We already have an official set of guidelines for rejecting these:

Not only are these displayed to every reviewer, they become attached to the suggested edit itself, providing an edit-specific explanation for the rejection. They haven't been updated in quite a while either, and could almost certainly use some work...

With some form of editor notification implemented, this would likely go a lot further toward your goal of reducing support request here on Meta than a couple of paragraphs buried in the help center.

Answer 2

Because the guidelines for editing and suggested editing are different and because what is considered acceptable to one community may not be acceptable to another, I think an expanded version of this idea would work better as a post under the faq tag. There is a post on reviewer guidelines (although not a faq yet), but doesn't quite answer the question for the editors completely enough.

Given the fact we get a lot of "why was this edit rejected" and similar posts on MSO (I can't speak for site specific metas as I don't frequent them as much), it would probably quality as a "frequently asked question" anyway. It would also give a good canonical post to link duplicates.

Placing it in the help center gives this an official rule feel, which I don't think it is. The guidelines for editing are decided more on community consensus instead, so a MSO post that would be more easily edited and allow it to grow and change organically as the rules evolve in time.

It would also allow for more detail as to what is consider acceptable and actually explain why, which I think it needed, rather than just 2 paragraphs that say "Don't do this". And a Shog points out, it does run contrary to other bullets on the same page.

As Bart points out though, a meta post will not get nearly the visibility as a help center entry, so I think the help center idea could be refined to link to a faq post. It would also help with transparency to Bart's other point of the Stonecutters Ancient Mystic Society of No Homers MSOer's trying to host it's own secret rules.

An addition to this page under the When should I edit posts? section could be the solution (emphasis is mine to highlight the addition):

When should I edit posts?

Any time you see a post that needs improvement and are inclined to suggest an edit, you are welcome to do so. The original author of a question or answer may always edit their own post, regardless of reputation level.

Edits are expected to be substantial and to leave the post better than you found it. Common reasons for edits include:

• To fix grammar and spelling mistakes
• To clarify the meaning of the post (without changing that meaning)
• To include additional information only found in comments, so all of the information relevant to the post is contained in one place
• To correct minor mistakes or add updates as the post ages
• To add related resources or hyperlinks

For more information on how editing works and suggestions on how to make good edits, please visit <some meta link>

In fact this idea could be expanded into a complete editing FAQ (probably best as a series of posts) which goes into details on all of the editing policies and guidelines.

Answer 3

This is a bad idea for two reasons.

First and foremost, this adds some detailed rules about an uncommon case. The current guidelines for “When should I edit posts?” are 122 words long. You're proposing to add a whooping 100 more words, so the size of the rules would almost double. You need to keep these guidelines short and to the point, otherwise nobody will read them (as opposed to almost nobody).

The rule you propose for questions is a refinement of one of the already existing guidelines: “to clarify the meaning of the post (without changing that meaning)”. If a question is about a piece of code, this code shouldn't be changed in any way that changes the meaning of the question, which rules out most non-whitespace edits.

In my experience as a reviewer, edits that change the code in ways they shouldn't are exceedingly rare. It's not a case worth mentioning in generic guidelines. Among the vast number of bad edits, there are far, far, far more edits that scramble the formatting. If I could add one sentence to these guidelines, it would be “backticks are for code, not for emphasis or for proper names”.

In addition, the help section is the same on all sites; your proposed addition would have to be present only on Stack Overflow. While this is technically possible, it's likely that users who participate on multiple Stack Exchange sites would read that section only on one site, so they may never see this SO-specific content, or see it and be confused because it doesn't apply to other sites they edit on.

A second problem with your proposal is that the part about answers is not good advice. There is a major difference between editing code in questions and editing code in answers. In questions, when you go beyond indentation, there's a real chance that you'll inadvertently fix the problem that the poster was asking about. In answers, there is no such risk, and you should encourage editing answers to fix minor mistakes. Correcting the name of a method, adding a missing parameter, adding a missing validation condition, adding proper escaping to avoid code injection vulnerabilities, … Those are all good edits and should be encouraged. Stack Overflow already has a problem that many of these edits are wrongly rejected; we don't want to add anything that discourages such edits.

Answer 4

I totally disagree with the idea that correcting indentation in the code of a Python question shouldn't be allowed, and more generally I don't think it's true that you shouldn't correct mistakes in code in a question.

I think there are two points you kind of wanted to make when you said that, but you've been too aggressive and come up with an overly sweeping rule that discourages too much. I think you wanted to express the following points:

• Obviously, if someone posts code saying "My code is throwing Exception XYZ - why, and how do I fix it?" then you shouldn't 'correct' the code to a version that doesn't throw Exception XYZ. More generally, you shouldn't fix the problems that are actually being discussed in the question.
• You also shouldn't fix bugs or instances bad practice in question code that don't prevent the code from running or being understood, and which don't prevent the problem being asked about from being exhibited, although pointing such issues out in comments may be appropriate. (E.g. pointing out an SQL injection vulnerability in code posted for a question about something completely different is a good use of a comment, but you shouldn't edit the vulnerability out - that's just confusing and pointless.)

The trouble is, your rule also explicitly and strongly recommends against plainly useful edits in the following situations:

• The OP has posted Python code, asking "Why do I get a ValueError on line 7 here?", and the indentation of the Python is broken such that trying to run the code just throws an IndendationError, line 7 is never reached, and it's obvious that the indentation has been broken in the process of copying and pasting the code because the broken indentation is the only thing preventing the code from exhibiting the behavior described by the asker. (This isn't a hypothetical situation, it's fairly common in the Python tag. Since joining SO I've probably seen 10+ questions by new users who broke their indentation when copying and pasting the code, but I've never seen a question where indentation errors were a relevant part of the question.)
• More generally, someone posts code saying "This code exhibits unexpected behavior X - why?", but there's a trivial error earlier in the code that crashes the code before you even reach the part that would cause the unexpected behavior. It's easily fixable, and it looks like the mistake was probably introduced by the author either when anonymizing their original code or creating a minimal demo case without testing it as thoroughly as they should've.

In both the above cases, I think that you should edit the code in the question to fix the incidental bugs that are preventing the code from exhibiting the problem that the author is actually asking about. Doing so makes the question more useful and not only preserves but clarifies the author's original intent. Discouraging such edits seems like a bad idea.

The spirit of the guidance, I feel, ought to be

Correcting what you think are typos or irrelevant mistakes might well change the entire question or confuse the author...

... so bear that in mind be very careful not to do either of those things!

Instead, you've effectively said

Correcting what you think are typos or irrelevant mistakes might well change the entire question or confuse the author...

... so just don't do it! Trust us, you're not clever enough to figure out the difference between a helpful edit that clarifies the author's intent and one that changes the entire question.