43

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:

suggested edit review

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!

  • 2
    I had seen that question, and was wondering about how someone spotted a missing space. I should have checked the edit trail... – Charles Green Feb 1 '18 at 22:57
  • 1
    I saw the problem just after I approved. :/ – muru Feb 1 '18 at 23:39
  • @CharlesGreen Yeah, I saw it in the close votes queue as unclear what you're asking, which it was after the edit... without that comment I wouldn't have thought of digging – Zanna Feb 2 '18 at 6:32
  • 3
    @muru ugh I hate how you then can't edit until the review is finished – Zanna Feb 2 '18 at 6:34
  • 3
    Unfortunately, comments are not shown while reviewing suggested edits, unlike in other review types. I probably should have chosen Improve edit to make it clear promptly but I was simply unsure whether it’s the actual reason… – Melebius Feb 2 '18 at 6:53
  • 7
    @Zanna You can, by editing from the revision history. – Eliah Kagan Feb 2 '18 at 13:44
  • 1
    @EliahKagan that is extremely good to know! – Zanna Feb 2 '18 at 14:14
  • 2
    Related for the same reason on SO Meta meta.stackoverflow.com/q/260245/4532996 – cat Feb 3 '18 at 22:54
  • 1
    Couple of questions: 1) Is this something that occurs a lot lately ? 2) Why is that question put on hold as off-topic (nano and apt files and the fact that OP is using 14.04 and 16.04 definitelly make the question on-topic ) rather than as "unclear what you're asking" (because OP didn't respond to Melebius's comment or didn't provide full copy of what command-line error said). 3) Um...do we know for a fact this is the issue and not that OP simply typed out command by hand in the question or something ? – Sergiy Kolodyazhnyy Feb 4 '18 at 2:34
  • @SergiyKolodyazhnyy 1) not especially afaik, but when I saw it I thought I would mention it. 2) That comment belongs on the question; I didn't vote to close the question and it wasn't closed when I wrote this post and I will vote to reopen it. On Unix & Linux problems caused by a trivial syntax error are closed as no repro (unix.stackexchange.com/questions/342828/… - closed as dupe of Q closed as no repro Lol) which I disagree with, but this isn't that site. 3) try reproducing the error any other way. Do you think the question is unclear? – Zanna Feb 4 '18 at 6:37
  • @Zanna Yeah, it's a good idea to mention. Maintaining integrity of OP's code and error messages helps solving questions. This post (yours I mean) being very highly voted slightly made me concerned that this might be something that occurs a lot. What bothers me is that OP didn't respond to comments, karel jumped in with answer starting "It seems..." so it's not definitive answer; error message lacks shell and command portions, as in bash: nano/etc/passwd: No such file or directory. Maybe I read too much into it, but it's being written off too easily. – Sergiy Kolodyazhnyy Feb 4 '18 at 7:28
  • 1
    @SergiyKolodyazhnyy yeah the hint of the error came from the vague title. But even if OP doesn't come back to confirm, the error without the space is reproducible (despite the current close reason message) so it's a valid question. If they do come back and say that wasn't the issue at all, I guess we'll be dealing with that... – Zanna Feb 4 '18 at 7:50
  • 1
    @cat great reference, thanks! Maybe I should add that to the post – Zanna Feb 5 '18 at 17:37
  • When I apply code blocks I simply apply code blocks. I don't edit in between the code blocks and insert spaces like the editor did. I don't think the reviewers can be blamed for not noticing the editor changed the text embedded within the code block to make it a totally different command with parameter. Is our software flawed for only using two colours red and green when a third colour such as white foreground on black background should have been used for the space? – WinEunuuchs2Unix Feb 10 '18 at 1:40
2

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.

You must log in to answer this question.

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