Return to Answer

• Is the post author experienced and active on the site?
• If so, I will usually comment rather than editing unless there is some obvious typo or slip-up
• If not, I will usually go ahead and edit.

• If the poster has not included commands that I think should have been included, I include them (as a fairly extreme example, if a post says "pass intel_idle.max_cstate=1 as a boot parameter" I will generally edit into it an explanation of how to set boot parameters with commands. Less drastically, if a post mentions installing a package, I will often edit in the command to install the package).
• If there is something in the code that I am fairly sure is an error, I will correct it.
• I usually switch out any backticks used for command substitution and replace with $() because of the potential of the former to cause markdown-mixups
• If someone has written something similar to what I would write as an answer myself, and I can think of an additional related command suggestion, I will usually edit it into the answer rather than writing an answer of my own.
• If the code makes what I consider a bad minor decision (typically sudo gedit (or sudo <any graphical application>) I will "fix" it (sudo -H gedit and so on)
• If the code makes what I consider a bad major (ie the answer will need to take a significantly different approach to avoid it) decision or fails in a way I can't fix (when I test it), I will usually leave a comment (and downvote if warranted) instead of editing.
• If the code could be simplified or improved, I will usually comment instead of editing.

• Is the post author experienced and active on the site?
• If so, I will usually comment rather than editing unless there is some obvious typo or slip-up
• If not, I will usually go ahead and edit, with a couple of exceptions*

• If the poster has not included commands that I think should have been included, I include them (as a fairly extreme example, if a post says "pass intel_idle.max_cstate=1 as a boot parameter" I will generally edit into it an explanation of how to set boot parameters with commands. Less drastically, if a post mentions installing a package, I will often edit in the command to install the package).
• If there is something in the code that I am fairly sure is an error, I will correct it.
• I usually switch out any backticks used for command substitution and replace with $() because of the potential of the former to cause markdown-mixups
• If someone has written something similar to what I would write as an answer myself, and I can think of an additional related command suggestion, I will usually edit it into the answer rather than writing an answer of my own.
• If the code makes what I consider a bad minor decision (typically sudo gedit (or sudo <any graphical application>) I will "fix" it (sudo -H gedit and so on)

*situations when I don't usually edit:

• If the code makes what I consider a bad major (ie the answer will need to take a significantly different approach to avoid it) decision or fails in a way I can't fix (when I test it), I will usually leave a comment (and downvote if warranted) instead of editing.
• If I think the code could be simplified or improved, I will usually comment instead of editing.

• If the poster has not included commands that I think should have been included, I include them (as a fairly extreme example, if a post says "pass intel_idle.max_cstate=1 as a boot parameter" I will generally edit into it an explanation of how to set boot parameters with commands. Less drastically, if a post mentions installing a package, I will often edit in the command to install the package).
• If there is something in the code that I am fairly sure is an error, I will correct it.
• I usually switch out any backticks used for command substitution and replace with $() because of the potential of the former to cause markdown-mixups
• If someone has written something similar to what I would write as an answer myself, and I can think of an additional related command suggestion, I will usually edit it into the answer rather than writing an answer of my own.
• If the code makes what I consider a bad major (ie the answer will need to take a significantly different approach to avoid it) decision or fails in a way I can't fix (when I test it), I will usually leave a comment (and downvote if warranted) instead of editing.
• If the code could be simplified or improved, I will usually comment instead of editing.

• If the poster has not included commands that I think should have been included, I include them (as a fairly extreme example, if a post says "pass intel_idle.max_cstate=1 as a boot parameter" I will generally edit into it an explanation of how to set boot parameters with commands. Less drastically, if a post mentions installing a package, I will often edit in the command to install the package).
• If there is something in the code that I am fairly sure is an error, I will correct it.
• I usually switch out any backticks used for command substitution and replace with $() because of the potential of the former to cause markdown-mixups
• If someone has written something similar to what I would write as an answer myself, and I can think of an additional related command suggestion, I will usually edit it into the answer rather than writing an answer of my own.
• If the code makes what I consider a bad minor decision (typically sudo gedit (or sudo <any graphical application>) I will "fix" it (sudo -H gedit and so on)
• If the code makes what I consider a bad major (ie the answer will need to take a significantly different approach to avoid it) decision or fails in a way I can't fix (when I test it), I will usually leave a comment (and downvote if warranted) instead of editing.
• If the code could be simplified or improved, I will usually comment instead of editing.

I believe that "minor mistakes" is deliberately vague: as editors we are trusted to know when the mistake can be salvaged by editing, and when we should do something else instead. I don't mean that we are or should be expected to always know that, I mean, that if you set out to edit a post, you should have the appropriate knowledge gained from observation and experience to do so appropriately.

Context sometimes matters - what else is going on besides the code in this post? Is it one of numerous answers to a question? Is it an ambiguously phrased question with answers addressing different possible sides of it? Respecting the original poster might be quite a wide ranging consideration - I try to look around to see if I am treading on any other toes too when editing (for example, if I "clarify" a question, am I making one of the answers lose meaning and usefulness? How can I avoid that?)

I believe that "minor mistakes" is deliberately vague: as editors we are trusted to know when the mistake can be salvaged by editing, and when we should do something else instead. I don't mean that we are or should be expected to always know that, I mean, that if you set out to edit a post, you should have the knowledge gained from observation and experience to do so appropriately. (As mentioned by @edwinksl, In the context of review - if you are unsure, the skip button is your friend)

Context sometimes matters - what else is going on besides the code in this post? Is it one of numerous answers to a question? Is that question ambiguously phrased, with answers addressing different possible sides of it? Respecting the original poster might be quite a wide ranging consideration - I try to look around to see if I am treading on any other toes too when editing (for example, if I "clarify" a question, am I making one of the answers lose meaning and usefulness? How can I avoid that?)