Please don't correct commands in questions unless you are sure the mistake is not the source of the problem

Question

_{This might well be a dupe. If so, y'all know what to do ;)}

When editing questions, make sure you don't eliminate all clues as to what was causing the problem by fixing incorrect commands, as this edit suggestion did:

Sometimes the OP has made a mistake only in the question, rather than when they were running commands in a shell, and those should be fixed. If it is at all unclear whether the mistake is only in the question, then comment and ask for clarification. In the case above, it's almost certain and fairly obvious that the lack of a space caused the error the question was about, and the edit made it mysterious.

One reviewer picked up the problem and rejected, but others approved, which is very understandable given that the edit made obvious improvements (and the suggested edits queue gives barely any context). I would probably have approved it myself. Reviewers: watch out for things like this!

Answer 1

In addition to what Zanna has said, I think there are two related cases that sometimes arise.

(This post expresses my views, and I am not claiming that it restates any policy that is already established. Readers may disagree or agree, and perhaps vote accordingly.)

1. An edit may be correct but there's no way for reviewers to know.

In the example given in this meta question, the edit was wrong but it was hard for reviewers to notice that it was wrong. However, it is also possible for an edit to look wrong--or for it to be unclear whether it is right or wrong--even though the editor does know enough to be sure of what command the OP really ran (or, more generally, whatever they really did).

In this case, the solution is for the editor to include enough information in the edit summary so that reviewers can be reasonably confident that the edit they are approving does not misrepresent what the OP did. Often this could consist of a link to or (less good) other mention of a comment where the OP clarifies that. There are limited scenarios where an editor may be able to infer what the OP really did using their technical knowledge of the subject. In these cases, they need to explain their edit fully in the edit summary, and should think hard before applying it--it should not be just a guess, even if it's a pretty good guess.

Although I think it's often reasonable to click Skip on edits that make a technical change outside one's own knowledge, I do not advocate this for edits to questions that appear to risk misrepresenting what the OP did. If an editor doesn't give enough information to make clear that such an edit is correct, and a cursory investigation cannot support the edit, then it should be rejected immediately.

Users with enough reputation that their edits are not subject to review should still write good edit summaries so it's clear to others why the edit is correct. I'm not saying that all edit summaries need to be detailed or to contain an argument for why an edit is correct--but edit summaries for edits that would otherwise appear to harm a post always should.

2. An "improvement" may be inappropriate even if it doesn't prevent a solution.

Sometimes people submit edits that seek to improve the style of a command or address mistakes in it. They know they are turning it into a command that the post's author did not run and were unlikely to have intended to write. On answers, this is sometimes appropriate, though editors should exercise caution to avoid mistakes where they think they're significantly improving an answer and are actually worsening it or not significantly changing its quality. On questions, however, this is almost never appropriate.

The purpose of commands shown in a question is only rarely to instruct the reader as to what the reader should do. The rare situations where that is their purpose fall mostly into two categories:

• Material that appears in the question should actually be in an answer, or
• it is a question along the lines of "Such and such will do useful thing X, but how do I make it do Y?" that contains an unrelated mistake, and there is actual risk that people may follow its advice about how to do X.

In the first situation, an edit is not really harmful, but it is important that the information be moved to an answer.

In the second situation, I think that people other than the OP (and sometimes not even them) should still usually not correct such a mistake in a question unless (a) there is broad agreement that the question is better without it and (b) no answers have addressed the mistake. Basically, this would apply to a "canonical question" intended to address a common case of interest, where an unrelated mistake in the question is distracting and embarrassing and does not help illuminate the intended topic. In rare cases, a mistake is so severe and dangerous that readers should be warned of the risk; in such cases, a warning banner edited into the post is still often better than attempting to excise the mistake.

This is not intended as an exhaustive description of when such an edit is reasonable or unreasonable. However, I've seen edits aiming to enhance commands in questions that are thoroughly unreasonable. Edits that remove a username from a prompt in a question are unreasonable unless the OP has indicated they don't want to show it. Edits that vandalize a question to conceal that a user is running a shell as root, on the grounds that bystanders might imitate this supposedly bad behavior (I have actually seen such edits!) are unreasonable. Edits that improve quoting in a command or replace the ` ` form of command substitution with $( ) are typically unreasonable (but see above).

Edits that improve a command so it doesn't teach bad technique can be appropriate on answers. It is extremely rare that they are reasonable in questions. Constantly we are asking people to describe exactly what they did so we can help them. Edits that deliberately seek to make it look like they did something they did not do should almost always be rejected. Answers and comments can address peripheral mistakes in a question. And sometimes they turn out not to be so peripheral after all.