###TL;DR I don't think there is a detailed site policy and I don't want there to be one, because it would be too complex to codify*. No policy, however sensitively and scrupulously defined and flexibly applied, can replace learning through experience. I much prefer the SE way of respecting experienced users and having an initial learning process (suggesting edits which are checked by the community) and checks and balances in place. ---------- Anyway, FWIW, here is my take (I guess I am a pretty prolific editor) in more detail, subjective as it must remain. There is a rather generic list of guidelines that pops up at the side of the screen when, as an unprivileged user, you set out to suggest an edit. I can't remember what that looks like on Ask Ubuntu but I'm going to assume it's similar to what I see on U&L and Stack Overflow: > How to Edit > > ► fix grammatical or spelling errors > > ► clarify meaning without changing it > > ► correct minor mistakes > > ► add related resources or links > > ► *always* respect the original author There's no special mention of code here, so we can assume that the same guidelines apply to code: I should *correct minor mistakes*. There is no mention of formatting, which is probably in need of editing more often than anything else, but I assume you mean the actual code text, not the formatting. 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) **I err on the side of editing.** My bottom line is, **if I can improve the site by editing, I should do so.** Edits can always be rolled back or re-edits done. In practice "improving the site by editing" is a complex goal and there are multiple factors to consider (*this is why I think no policy could be codified) - in particular I always first ask myself: - 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 I go ahead and edit, here's what I do in situations where code is involved, not including formatting: - 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 should say that **I always eventually check back on my comments.** If a post still seems bad after I've given time for it to be fixed by the poster after leaving a comment, I will either (preferably) edit it or, if not done already, downvote it. Occasionally, I leave a comment for the sake of future visitors in cases where I have no intention of editing the post, but in general I will edit unless there is a compelling reason not to (generally that the post is an established one and the author is active). 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?)