# Peer review rejects bugfix edit on ground of it being aimed at the author

I proposed an edit to this answer to one of my questions.

The edit consisted of replacing two single quotes with two double quotes. The sample code in the original answer failed to compile; the edited version compiled and ran as advertised.

Peer review of the edit rejected the edit with the apparent stock-phrase:

This edit was intended to address the author of the post and makes no sense as an edit. It should have been written as a comment or an answer

Subsequently I pointed out the bug in a comment, whereupon the code's author promptly performed exactly the same edit that had I proposed.

Surely a simple bugfix to posted code is aimed at everyone reading the code, not just the author. Rejecting the edit merely delayed a necessary bugfix and increased the amount of effort required to get it done and the number of people involved.

Was this a reasonable rejection of the edit?

The correction of the compilation alone, without the junk comment would have been a great edit, appropriate and encouraged. The rejection message is a stock message, and doesn't reflect the real reason your edit was rejected.

As @Vogel612 already said, the rejection is reasonable and correct, simply because the commentary is practically just junk. We understand your good intentions and that you simply didn't know a better way, but that doesn't make it a good edit, so rejection is appropriate.

That being said, a better way to handle the suggested edit would have been the Improve Edit option, and either remove the junk, or if that's not possible due to the 6 character limit (for users without the powa), then replace the junk with something meaningful (which of course can be very hard).

• Am I correct to think that the peer reviewers have sufficient privileges to be absloved of the 6 char limit? If so, they should have improved the edit by simply removing the junk, rather than rejecting it. While I completely agree with the edit being rejected (because of the junk) I completely disagree with the stated reason for rejection. If we forget about the junk (which I was forced to put in) is this edit really more appropriate as a comment? – jacg Jun 29 '16 at 9:12
• If we forget about the junk, it's a great edit! The stated reason is canned (not editable), so don't read too much into it. I'm not 100% sure that the reviewers would have been absolved of the 6 char limit, as this is such a rare situation that I don't recall another example. (Vogel says yes, but I just don't know.) Maybe they didn't go the extra mile to improve the edit, maybe they couldn't, in any case we're all human, and the rejection is technically correct – janos Jun 29 '16 at 9:31
• The point of this question wasn't to bicker about the rejection, but to understand whether simple bugfixes to code posted in answers, should be offered as edits or comments. It seems that we agree that they should be edits, and that the peer review message was misleading in this case. (And the 6 character edit limit is the cause of all the trouble.) – jacg Jun 29 '16 at 9:41
• Good point, I added a paragraph at the top to clarify – janos Jun 29 '16 at 10:08

Leaving the reasonability of rejection as a "reply-to-author edit" aside, I noticed something in your edit:

-- SE disallows edits shorter than 6 chars! Grr!


This is unnecessary meta-commentary, if not borderline "vandalism" (note the quotation marks). As such it's not helpful to be in a post (and by extension in an edit).

The Character-Restriction does not apply to instant edits, such as people with edit privileges, the post owner and moderators. The edit should've been rejected, because that doesn't belong into an SE post.
For future reference: if you need to make an edit that has too little characters, you can always add syntax-highlighting to a codeblock like so:

<!-- language: lang-[languagecode] -->


This is enough to top the character limit.

So much and happy editing :)

• I address the 6 character limit in a separate question. So your answer here answers that other question. Thanks. I agree with your 'borderline "vandalism"' comment: it was never my intent to leave it there, but to remove it immediately in a subsequent edit; the peer-review process (of which I was unaware) threw a spanner in the works. Your proposed hack seems better than my workaround, but it's still a hack around what appears to me to be a poinless and counterproductive limit. – jacg Jun 29 '16 at 8:31
• @jacg There's a good reason for that limit, but that would go beyond the scope of this question. Feel free to find us in The 2nd Monitor if you want to discuss it further. – Mast Jul 6 '16 at 13:05