3

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.

    enter image description here

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.

  • @TomWijsman Just off the top of my head: Significant improvements to formatting and highlighting / Significant grammar and spelling corrections (making the post actually readable) / Made post easier to find (e.g. tags, adding keywords) / Removed unnecessary or repeated content (Hi all! So I was out taking a walk through the park on Sunday and thought about... Thanks!) / Added new information (e.g. when content was added in a comment only, or original content by the editor) / Content corrections (if the user actually got parts of his post wrong). – Daniel Beck Dec 6 '11 at 20:58
  • 5
    @Tom FYI users are allowed (and encouraged) to post network-wide feature requests for changes to the functionality of the Stack Exchange engine to their individual site metas. If Daniel wants this migrated to MSO we can do that, but it's perfectly fine here. – nhinkle Dec 6 '11 at 21:06
  • @TomWijsman it doesn't have to go to MSO, these discussions can be held on any Meta. If they team agrees they'll let us know regardless on what Meta we are. – Ivo Flipse Dec 6 '11 at 21:07
  • 3
    @Tom please discuss this in a separate topic on the meta site of your choice. – Daniel Beck Dec 6 '11 at 21:39
  • I would also like an optional/voluntary free-text accept comment, like after investigating if an edit is legit, to pass thoughts to the next reviewer on sites where two approvals are required. – Arjan Dec 6 '11 at 22:12
  • 1
    @TomWijsman I'm unaware of a specific reference but moderators have been specifically instructed by the community team to inform users that feature requests for network-wide things are allowed on per-site metas. – nhinkle Dec 6 '11 at 22:16
  • 1
    @TomWijsman here is the official post: "Which meta should I post on?" Specifically, Rebecca Chernoff says: "I can't stand it when I see a post on a child meta and the first comment is 'You should have posted this on MSO'. ARGGGGGGGGG" – nhinkle Dec 6 '11 at 22:22
  • 1
    Naturally, any user of any site is welcome to post on MSO if they so desire. But badgering users to do so - or closing their requests if they don't - is discouraged. – Shog9 Dec 6 '11 at 22:24
  • 2
    To the persons down voting and/or voting to close: This is supposed to be a discussion. Please participate, and if it's just to tell me how I am wrong and why you think so. Thanks! – Daniel Beck Dec 7 '11 at 19:26
4

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.

  • I agree (with Richard). The suggestion sounds like feature creep. Soon, people will just game that system. And any you put up. I suggest just banning people who game the current system. That kills the motive at the source. Or just warn them of a ban. – surfasb Dec 10 '11 at 1:05
  • 1
    @surfasb How do you determine whether someone games the system? At the moment, if you'd confront a user, they could still try to figure out a reason why the edit was somewhat useful. Additionally, we're talking about the most active high-rep users here (on pretty much all sites except SO, and even more so on all the smaller sites). I don't think it's a useful to the site to hit them with the banhammer unless there's outright vandalism, which I just don't expect to see. – Daniel Beck Dec 11 '11 at 8:55
  • Do you know how accepted/rejected review actions are displayed to a low-rep editor? – Daniel Beck Dec 11 '11 at 10:27
  • @DanielBeck: The current problem is with certain problem editors, but you are asking for a feature that is systematic. It's akin to punching your display to kill a fly on it. Then look at the cost/benefits. The manpower involved to code, test, test *2, test * 10, then deploy a feature like this versus the benefits is, IMO, low for what amounts to style and syntax. It is a situation that just requires a case by case review, a process which is unfit for a computer. The ban hammer is perfect for situations like this, because it is an extreme solution, thus cannot be applied without due diligence. – surfasb Dec 11 '11 at 14:05
  • A better solution would be to use case studies to educate your active users. – surfasb Dec 11 '11 at 14:08
2

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

  • 3
    Figuring out whether substantial, content-oriented edits are actually true is already tons of work. Not sure how significant one radio button is. – Daniel Beck Feb 3 '12 at 17:24
  • @DanielBeck Starts off with one radio button, then goes to options, then to customized etc etc – Sathyajith Bhat Feb 3 '12 at 18:05
  • 1
    @Sathya What are you talking about? I suggest it should mirror the rejection selection. There's no options and customization either. – Daniel Beck Feb 3 '12 at 18:28
  • @DanielBeck what choices do you get when opting to reject a suggested edit? Please post a screenshot. – Sathyajith Bhat Feb 3 '12 at 18:33
  • @Sathya See OP. – Daniel Beck Feb 3 '12 at 18:36
  • @DanielBeck I don't see the point. – Sathyajith Bhat Feb 3 '12 at 18:46
  • 1
    @Sathya studiohack argues that having to select similar options when approving makes approval "too much work". But verifying suggested edits, especially when content is concerned, for correctness, is already much more effort than then selecting an option or typing three words why it's a good edit. That's what my comment was about. I still don't get what you were referring to in your first comment. – Daniel Beck Feb 3 '12 at 18:51
  • @DanielBeck I don't mess around much with suggested edits for two reasons. 1) All 2K+ can approve and 10K+ can see the queue. 2) it is just too much of a pain with many of the edits out there. I think it's too much work rejecting for that matter. Too many reject reasons. – studiohack Feb 3 '12 at 18:55
  • @studiohack And that's exactly why we need the balance of required effort between approval and rejection. Otherwise people going for the reviewer badges are just going to approve all edits without looking closely, because it's quicker. – Daniel Beck Feb 3 '12 at 18:57
  • @DanielBeck you're essentially asking to replicate this: i.imgur.com/uhh6P.png ? – Sathyajith Bhat Feb 3 '12 at 18:59
  • @Sathya For approval of suggested edits, yes, by having users select why they think an edit is good. It's too easy to approve edits compared to rejecting them, and that has been voiced in chat, with crap edits being approved. There's a badge for it, and users choose the way of least resistance. – Daniel Beck Feb 3 '12 at 19:00
1

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?"

  • 1
    Well, for a few ideas, see the bottom of my question. And if today I wan tho reject a bad edit, and none of the reasons fit, I explain why it's not a useful edit, and press the button. Done. Don't see why it'd be a bad thing for accepting edits to work the same way. – Daniel Beck Dec 11 '11 at 8:51
  • 3
    (I realize both that there's a lot of mold growing on this, and that the suggestion was already declined, but since I wound up here and found this point un-made, I thought I'd add it.) Basically, I agree with @soandos. The missing consideration here is the reason for the reject explanations, which is to educate the submitter, not to create work for the reviewer. Nobody needs it explained to them why their good edit is accepted, but most people appreciate the courtesy of an explanation when they're refused. "Balancing" the reviewer tasks is focusing on the wrong aspect of the process. – FeRD Jun 12 '13 at 8:21

You must log in to answer this question.

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