Make reviewers explain why they accept a suggested edit

Question

A few times already I've seen users in chat complain about the willingness of reviewers to approve very minor edits whose usefulness is questionable. Sometimes the edits were even counterproductive, leading to questions that were actually off topic.

---

Looking at the current UI for reviewing suggested edits, the asymmetry of approval and rejection actions stands out:

• To approve an edit, click a single button.

• To reject an edit, click a button, select an explanation why the edit was rejected, or, if none are applicable, type an explanation.

  

It is much easier to approve edits — even in great numbers — than it is to reject one or a few edits. If you're going after the Proofreader badge, it's much more economical to just wave through all suggested edits.

---

Another problem is that it's not just easier, you don't even need to reflect about why you approve an edit at the moment: If you like the user suggesting the edit, that's good enough for the system. OTOH, when rejecting, you are forced to give a reason. You also open yourself to criticism, because your explanation for the rejection is recorded and publicly available. Others will be able to check your decisions and detect when you abuse the review system.

There is no such record of the decision-making process for approvals.

---

For these reason, I request that reviewers be required to select a reason for approving an edit, or type one of their own, similar to how rejection works.

This will balance the scale of approval and rejection of suggested edits. Users will be forced to think twice (as it requires two clicks) about their reasons for approval, and it will remind them what the community considers to be characteristics of good edits. Let's face it: Not every participant on this site cares that much about community consensus and Meta discussions of what is and isn't appropriate, so a gentle reminder at the time of action might be a good idea.

It will most likely not harm genuinely useful edits, and I expect that, overall, approval, being a positive action, will still be ahead anyway.

---

While we'd need to discuss what default categories for explaining an edit we should offer, as an initial example only, I could imagine the following:

• Significant improvements to formatting and highlighting

  The significant is, of course, important here. It suffices to monospace key combinations to get the point across. We don't need kbd unless as part of a more significant edit. This category is for those folks who post log output or code without indentation.

• Significant grammar and spelling corrections

  This is not British English vs. American English (unless that's actually considered an important edit?), but about those posts that can barely be identified as English (halp plx k thx!!!!). We value proper use of language on the site to make content more accessible.

• Made post easier to find

  Adding relevant tags, (also removing irrelevant tags, as they are noise), or adding specific key words, like adding the terms extended attributes to the umpteenth question asking about that @ in ls -l output.

• Removed unnecessary or repeated content

  Hi all! So I was out taking a walk through the park on Sunday and thought about how I want to disable these security dialogs in Windows. Has anybody here ever attempted that? I mean, someone must have been bothered enough by these stupid dialogs to have found a way to disable them? Thanks! Gotta go!

• Added new information

  For example, when the OP added relevant information in a comment to the question or an answer. This could also include original content by the editor. One example for the latter would be this edit, and for the former, I offer this.

• Content corrections

  Users sometimes get their posts wrong. Asking for the wrong thing by associating similar but independent concepts, users posting code while being distracted, etc. This is for posts that are otherwise complete, but just aren't correct.

To repeat, these are just examples I'd consider useful as a starting point. These categories, their wording and explanation are not what this topic is about.

Answer 1

Disagree.

Hence -1 vote.

(This is based on my experience of reviewing edits on SO.)

The resistance for rejection of edits (I've rejected plenty, both before the reason was added and since) is not much friction. There is more effort in making the choice of whether to accept or reject. If a reviewer isn't putting the effort in to the review then all their reviews are invalid, whatever the default result.

Therefore I see no need to "balance the paths".

Additional On further thought: the reason for the reject reasons is to tell the editor why it was rejected, so they can avoid such edits in the future. With an accepted edit the feedback is already there: accepted.

The reasons given in this question would make more sense for the editor to provide to the reviewers. But the reviewer would then need to additionally agree or disagree with the reason. Then we would need a mechanism to handle the case where the reviewer agrees with the edit but not with the reason for the edit. Finally with the edit privilege you don't have any of this (an edit roll-back doesn't give a reason), so it would be even more inconsistent.

Summary: the reject reason is to inform the edit of why it is was rejected. This is useful in helping that editor suggest better edits. An accept reason wouldn't.

Answer 2

This is status-declined because it creates too much work for users to approve edits. We want the process to be as streamlined and as efficient as possible.

Answer 3

I think this is a bad idea. What if the reason that the edit is accepted is that it is a "good edit?" The reason why I think that there are no options for why it is a good edit is because it is pretty straightforward most of the time. It improves the question's readability.

What other reasons are there for something to be a "good edit?"