12

This is more or less a version of https://meta.stackexchange.com/a/157383/178438

Even though the review audit system and manual banning has been put into place, there are still many bad reviews that go through. Starting with this bad review, it took me just a few seconds to find this one and a few more to find this one. I probably could dig deeper or switch to another queue.

Anyway, I had some ideas for how to make the audit system more efficient.

The main idea is the following:

By some arcane magic (based on review stats, not audit stats), determine users who are likely to be robo reviewers. Increase the likelihood of them receiving audits, so as to catch them faster. Basically, instead of receiving one audit every 10 normal reviews, it will be more like one audit for every 2-3 normal posts. If they manage to pass these audits, put the likelihood back to its normal value.

Now, there are a few ways to have the "arcane magic" (mix and match):

  • Obvious robot-ness: If a user is repeating the same action in a queue or not taking much time on it, they probably need more scrutiny.
  • Sticky posts: When there are controversial posts with opposing reviews (upvotes/no-action-needed + flags/downvotes ; Accept + Reject ; Close + DNC ; etc), keep them in the queue for a while longer. Check involved parties for suspicious reviewing (especially the ones who upvoted), and put them under scrutiny.
  • Propagation: If a possible bad reviewer has been identified, go through their reviews and look for reviews where there were both people who agreed with the bad reviewer and those who disagreed. Put the ones who agreed under scrutiny (if their history seems suspicious). This trick is what I used to find the posts I linked to above.
  • Failed audits: If a user fails an audit, put them under scrutiny.

Note that all this is just a way of making the audit system more efficient -- increasing scrutiny on bad reviewers while not annoying good ones too much (compared with just bluntly increasing the likelihood of audits). None of this will directly lead to a review ban (which is why the ways to look for users to scrutinize aren't foolproof) -- the only way to get a review ban is via audits or manually by a moderator.

What do you think?

|improve this question
  • 1
    At first read, all this sounds too complicated and I wasn't sure we really need it. And then I clicked the links to check exactly how bad the approvals where, and realized that even after the audits and the review bans, the robo-reviewers problem isn't solved. Nothing more annoying than a few jokers that spoil the fun for everyone, I guess we've reached a point where byzantine solutions like this are necessary. <sigh> – yannis Apr 4 '13 at 16:04
  • 2
    Not sure why you think the 2nd example is bad. It uses more backticks than I would like, but I wouldn't call it a fail. – Lance Roberts Apr 4 '13 at 16:05
  • 5
    The third isn't that bad either, though I definitely would have improved it. – Lance Roberts Apr 4 '13 at 16:06
  • 1
    @LanceRoberts It's extremely minor, no reason to bug three reviewers just to add backticks. – yannis Apr 4 '13 at 16:07
  • @Yannis Per most of the answers on this recent question, the community thinks that is OK for users who can edit without a review, so why should the system be any different for users that have to go through a review? It doesn't seem right to have two completely opposite standards based on how much rep you have. – Rachel Apr 4 '13 at 16:07
  • 3
    @Yannis, I don't consider minor edits to be "bad", even if I wouldn't do them myself. I think of "bad" as something incorrect or vandalism. – Lance Roberts Apr 4 '13 at 16:08
  • I agree that the examples aren't that perfect regarding the minor edit thing, but there probably are many more good examples out there. – Manishearth Apr 4 '13 at 16:09
  • Anyway, the whole "minor edits" discussion is irrelevant here :) – Manishearth Apr 4 '13 at 16:14
  • 1
    @Rachel Rep is irrelevant, the different standards are because when you can only suggest edits, at least three people (on SO) need to spend some time reviewing your suggestions. Their time is as valuable as anyone else's and we certainly don't want to encourage people wasting other people's time to add a couple of backticks. – yannis Apr 4 '13 at 16:17
  • 2
    @LanceRoberts The edits aren't "bad", but the approvals are. Higher rep users should be encouraging newer members of the community to do more substantial edits, and one way to do that is to reject extremely minor edits. Blindly approving extremely minor edits sets a very bad example, and from personal experience I did quite a few minor edits as a new user until someone finally ping me in chat and explained to me how edits bump the whole thread, etc. I had no idea, and as long as my edits were getting approved, how could I? – yannis Apr 4 '13 at 16:23
  • Personally I think we should focus on providing better education for reviewers before we start trying to identify bad ones and kick them out of the system. I can think of many cases where reviewers simply didn't know what they were doing was wrong. For example, there is no link going to detailed guidelines about how to review, so all users know is what the short blurb says for each queue. (Feature Request: Add a link to the more detailed “How-to-review” meta posts in Review pages?). Or implement a review-the-reviewers queue to help them learn. – Rachel Apr 4 '13 at 16:34
  • @Rachel: review-the-reviewers is a bit much. Yes, we need more education, but if we can't catch them we can't educate them either. Which means that both feature requests are IMO good, and will work even better when put together (when a user fails an audit, link them to the meta post and freeze reviewing for 30 seconds for them to read it or something) – Manishearth Apr 4 '13 at 16:39
  • Shog9 seemed to indicate in this comment Ridiculously fast reviews have become something of a red flag... Unfortunately, we don't have audits running on all the queues yet that they will eventually do this – Some Helpful Commenter Apr 4 '13 at 17:35
  • @SomeHelpfulCommenter: Hm. That's another thing we should have, but I don't think it nullifies this one. (I'll look for and add examples of bad FP reviews if I get the time) – Manishearth Apr 4 '13 at 17:38
  • @Manishearth I didn't mean to say that it nullifies it. Just that it's an acknowledged problem. Also if you're looking for evidence of fast reviews see this – Some Helpful Commenter Apr 4 '13 at 17:44
6

Personally I think we should focus on providing better education for reviewers before we start trying to identify "bad" reviewers and kick them out of the system.

I can think of many cases where reviewers simply didn't know what they were doing was wrong, including some users that have since gone on to become moderators.

For example, the Suggested Edit queue only says:

Approve, reject, or improve edits suggested by users. (less)

  • Approve edits you know are correct
  • Reject those you know are wrong
  • Improve to improve this suggested edit
  • Skip if you are not sure and want to go to the next suggested edit

That's it. Nowhere does this say anything about trivial edits being unwelcome, or providing a definition of what counts as a "trivial" edit. There's not even a link for if you want more information about what edits are "correct" and which ones are "wrong".

If you want reviewers to stop approving trivial edits, tell them that. Don't just let them find out by blocking them from the review system.

I actually have a MSO proposal here to create some detailed Meta-FAQ pages about each review type, and link to them from the Review Queues, however its been sitting around for a few months gathering dust.

I see lots of MSO posts complaining about bad reviews or "robo reviewers", or wanting SE to wave some magic wand to ban "bad" reviewers from the system, however if you really want to improve the system, go help write some detailed Meta-FAQ community-wiki posts about the individual Review Queues.

Someone has even started one already

Edit:

It's been brought to my attention that I didn't address the feature-request suggested, so let me try to be clear about my answer to it:

I don't think we should attempt this until after we improve our way of educating reviewers.

The proposal is to create a bunch of algorithms to flag users for additional scrutiny, many of whom probably don't even know that what they're doing is wrong.

I think with the current system, it would result in far too many false positives, and would be much too human-resource intensive to be worth the effort of implementing it, especially when there are other easier alternatives that could provide a much better improvement to the review system.

To go into more detail:

  • Obvious robot-ness: If a user is repeating the same action in a queue or not taking much time on it, they probably need more scrutiny.

    I'm a fast reader and often have reached a decision before the buttons get enabled. I expect there are others like me, so I think flagging users based on the time will return a lot of false positives.

    Also, if users are truly trying to circumvent the system by approving everything for extra rep or badges, they can just wait an extra few seconds between clicking "Approve" or "Reject" button.

  • Sticky posts: When there are controversial posts with opposing reviews (upvotes/no-action-needed + flags/downvotes ; Accept + Reject ; Close + DNC ; etc), keep them in the queue for a while longer. Check involved parties for suspicious reviewing (especially the ones who upvoted), and put them under scrutiny.

    There are many times when the community disagrees on something (such as your 2nd and 3rd examples being too-minor), so this will at best result in queues that are 50% good users and 50% questionable users, or at worst result in 100% good users being placed under scrutiny.

  • Propagation: If a possible bad reviewer has been identified, go through their reviews and look for reviews where there were both people who agreed with the bad reviewer and those who disagreed. Put the ones who agreed under scrutiny (if their history seems suspicious). This trick is what I used to find the posts I linked to above.

    This assumes you know who a "bad" reviewer is. You can't accurately base it on review audits because those are picked by an algorithm that are sometimes incorrect, and you can't base it on the majority-vote because the problem we're attempting to solve is Approved reviews that should have been Rejected, so that means the majority was wrong.

  • Failed audits: If a user fails an audit, put them under scrutiny.

    Audits are based on an algorithm, not a hand-picked list of posts, and they are sometimes incorrect. I've seen multiple MSO posts asking about why they "failed" an audit when they actually took the correct action. In addition, it's fairly trivial to open the question in a new tab and figure out if it's an audit or not.

So ultimately, I disagree with the proposal right now. There would be too many false-positives at this time, and all you're really proposing is to flag users based on some unreliable algorithm, and put them in yet another queue for review.

Perhaps after we've improved the documentation and education for our review system this can be revisited, but right now I think we should be focused on the task of educating our reviewers, not try to identify the uneducated ones and punishing them.

|improve this answer
  • Well, a good place to start when you want to know what should be approved/rejected, from a reviewer's perspective, is to just look at the rejection reasons. Just reading through all of them should make it blatantly obvious that minor edits should be rejected as "too minor". – Servy Apr 4 '13 at 17:02
  • 1
    @Servy Sure, but typically you don't think to click "Reject" when you see someone changing the word "teh" to "the" – Rachel Apr 4 '13 at 17:03
  • 1
    True, but hopefully when someone decided, "I'm going to start reviewing posts for the first time" they'll end up hitting "reject" sooner rather than later and seeing what all of the reject reasons are. Once they've seen it once they'll know that, from then on, if they need a reminder of what the reject reasons are (or want to see the detailed text) they can click reject to see them. Even now I hit reject on posts frequently just to read the text, even if I'm not yet sure what I want to do. – Servy Apr 4 '13 at 17:08
  • 2
    Again, this is irrelevant to this feature request -- we should be doing both in parallel :) And note that while my examples are slightly ambiguous, there are tons of blatant roboreviews in the other queues that aren't. I just didn't look for any. – Manishearth Apr 4 '13 at 17:09
  • @Servy You get the same review screen when you click the edit(1) link on a post you're viewing, and the queue usually doesn't have more than a few items in it at a time so I wouldn't expect every reviewer to have had a reason to click Reject in the past. – Rachel Apr 4 '13 at 17:55
  • 1
    @Rachel Maybe not every single time, no, but if the person has reviewed more than say 5 items I'd expect them to have come across a post that should have been rejected. Maybe 10 on the high end. The idea that someone will have reviewed several dozen posts and never come across something they even considered rejecting is absurd in my mind; if they're reviewing in good faith. (Remember, after 10 or so reviewed they'll have hit an audit, and those are all obvious vandalism.) – Servy Apr 4 '13 at 17:58
  • @Manishearth My response to your Feature-Request is that I don't think we should attempt it until after we improve our way of educating reviewers. Your proposal is to create a bunch of algorithms to flag users for additional scrutiny, many of whom probably don't even know that what they're doing is wrong. I think with the current system, it would result in far too many false positives, and would be too human-resource intensive to be worth the effort of implementing it when other easier alternatives to improve the review system are available. – Rachel Apr 4 '13 at 18:14
  • @Rachel: How? Again, the audits so far are quite unambiguous and not leading to false positives. Yes, we need education. But light review banning (2 days on first offence iirc -- that's pretty much nothing, especially if you remember that the number of posts a user can review in a day is capped). A ban wakes them up, the ones who actually care will ask why they were banned on meta. Education ought to ensue. – Manishearth Apr 4 '13 at 18:18
  • @Manishearth Sorry, I've updated my answer to clarify as this is too long for a comment. – Rachel Apr 4 '13 at 18:45
-4

I think good or bad reviewing is very subjective, and it is hard to automate reviewing the reviewers. I certainly wouldn't want time to be a factor, since many times I get pulled away from a review by real life work, or on the short side, after you do a lot of audits you can get pretty quick at it.

I think on the suggested edits queue (and only that one) that we could have some kind of algorithm that would let mods know when someone has voted contrary to the majority A LOT. We would need to be careful on this, and always keep any consequences ultimately under manual control, since there is so much subjectivity to editing. As a natural contrarian, I would certainly be worried about too much automation in this process; in fact, I've already complained about some of it.

If they do implement a higher rate of audits, I hope they tie it to rep or history. The audits already take a lot of precious time.

|improve this answer
  • 2
    The audits are pretty blatant, it's rather hard to get false positives out of them. Like I said, this feature request only adjusts how many audits you receive, it doesn't directly lead to a ban. So... the subjectivity thing doesn't really apply to audits in the first place, and is completely irrelevant here. I don't exactly see what you mean by "time shouldn't be a factor here" :/ – Manishearth Apr 4 '13 at 16:18
  • @Manishearth, I really think they should just get better audits that aren't so obvious. – Lance Roberts Apr 4 '13 at 16:19
  • @Manishearth, On "time" I'm referring to your first bullet point. – Lance Roberts Apr 4 '13 at 16:19
  • 8
    I don't think that flagging a user that has "voted contrary to the majority" would work, because the problem we're attempting to solve is Approved reviews that should have been Rejected, so that means the majority was wrong. – Rachel Apr 4 '13 at 16:24
  • @LanceRoberts: (re:audits) Yep, but either way there shouldn't be subjective audits. (re:time) No, if you don't have time then you should abandon the audit. Regarding "getting pretty quick at it" -- you should be reading through the post -- it's easy to tell a bad post/edit, but hard to tell a good one (and robo reviewers generally mark stuff as "good"). There are a few exceptions to this, but that doesn't make a big diff since the "not taking much time" will be only if they take a few seconds (whatever the minimum time is) on almost all their reviews. – Manishearth Apr 4 '13 at 16:24
  • Also, note that we need not worry much about false positives here. This system just increases the rate of audits, which will just be a minor annoyance to the false positives, nothing more. False positives only are a problem if they are in the audits themselves. – Manishearth Apr 4 '13 at 16:26
  • @Rachel, good point. Also realize I meant a big pattern of voting against the majority, not just one instance. – Lance Roberts Apr 4 '13 at 16:26
  • @Rachel I've seen wrongly rejected edits too... With reject reason that didn't apply at all. – Hugo Dozois Apr 4 '13 at 17:01
  • @HugoDozois So have I, but it's very rare, and usually on posts that are very debatable and difficult to determine a correct decision for. It happens so infrequently that, at least for now, I see no need to change the system to try to address that problem. If, as a result of changes making it harder to robo-approve, we see people robo-rejecting, or just being overly trigger happy with reject (which I doubt we'll see much of, but if we do) we can address it at that time. – Servy Apr 4 '13 at 17:05

You must log in to answer this question.

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