Why is the close review queue lagging behind the other queues on certain sites?

Question

There are numerous meta posts about the huge close review queue on Stack Overflow.

But SO is not the only site which is struggling with its close review queue. Several other sites have a lot of items (on their own scale) at any given time in their close review queue while the other queues are pretty much empty. Here are the number of items in the close review queue and the total for the other queues right now on the highest-traffic sites plus a few (I cut off when I got tired and added CS which I'm personally familiar with and Chemistry and Scicomp for comparison):

site        2014-Jan-02
  queue   close  others
SO        100970      1
Gaming         2      6
SU           384      8
Ubuntu       178     11
Apple          0      6
English        6      4
Cooking        5      9
SF            59      4
Android        1      3
Webapps        9      2
Unix           2      0
Math           0      4
SF&F           1      4
Programmers   51      6
TeX            0      0
Bitcoin β     40     24
DIY            2     11
EE             2      0
DBA            2      0
Security       0      0
Movies β       0      2
RPi β         21     29
Wordpress      1      4
CS β          33      5
Chemistry β    0      0
Scicomp β      6      5

So among SO, SU, SF, AU, Programmers and CS seem to have a difficulty with the close review queue. The other sites don't. For the sites I frequent (SO, AU, CS), I can confirm that this situation is habitual.

Is there a common factor that makes close reviews more difficult or less attractive on certain sites? Do items linger for a long time or is the high queue size due to a lot of items lingering there?

And of course the habitual question — what can be done to improve things, that hasn't already been suggested (or that has and is specifically relevant cross-site)?

Answer 1

I suspect that part of the equation might be whether the site is likely to attract low-quality questions: e.g., "plz give me the codez", "solve my homework problem for me", product recommendations, "why does my computer crash?", etc.

As we all know, Stack Overflow attracts many of those questions every day, which is why the close vote queue is so essential to Stack Overflow. I don't have personal experience with most of the other sites, but CS.SE does attract a fair number of what I would classify as low-quality "solve my homework for me" questions (it's a tempting target for CS students). I wouldn't be surprised if AskUbuntu and SuperUser got many lower-quality questions (e.g., from users who are new to StackExchange and might not have as much experience with technology).

In general, if you have a high ratio of low-quality questions to users who frequent the close vote queue, I'd expect to see higher close vote queue sizes.

I doubt this is the whole answer; far from it. But it might be one factor.

Answer 2

Close Review Queue is one of the most demanding in terms of time and energy required.

• If it's a duplicate we need to read both the questions - the one we are closing and the one we are targeting - to ensure that we select a proper duplicate target.

• If it's an off-topic question that we are closing - we also need to ensure that the question doesn't get closed improperly. We also need to take into account if the question can be salvaged with editing.

• If it's unclear, most of the times we need to comment to let the question-asker know what it is that is unclear; or what he/she should do and further edit the question.

• Broad and opinion-based are subjective and requires similar amount of time and energy to come at a conclusive opinion about them.

Another reason that this review queue lags behind is because it needs five people to close the question. This plays a small part in ensuring that Close Review queue often has the maximum number of items for review.

What I would like to get implemented specifically for this queue

A REVIEW LATER button which would allow me to skip the particular review item for the time being and come back lateron to that question. At present if I press the Skip button, I can't review that item again unless I save the link for it somewhere.

I have recently acquired the privilege to review this queue on one of the network sites and I often find myself closing the tab for the particular item and once again entering the queue to hope that I find a new item to review. I generally don't want to press the Skip button in this queue. However, I easily press the Skip button in other queues. I don't know what it is but Skipping items in this queue is what I do not want.

So, in effect I review smaller number of items in this queue because part of my time goes in leaving and re-entering the queue.

Answer 3

Having items in the review queue isn't necessarily a bad thing.

I would say that a modest number of items indicates that a site is healthy, and it shows active community involvement.

If I'm reviewing Programmers, and I find what I think is a bad question then I throw a CV on it and move on. But a close vote requires four more community votes in order to support the close. On a lower volume site (like anything other than SO… ) there ought to be some sort of backlog to indicate work needs to be done.

By way of reference, Programmers has been adding more close vote reviewers in the past few months and our average backlog number in the queue has been trending down. That's excellent as it demonstrates more community involvement.

Other review queues don't require as many supporting votes, so they'll clear out faster.

Also remember that there needs to be something in the queue to invite in new reviewers. It can be really hard to pick up suggested edit, late answer, and VLQ reviews on Programmers as those queues are generally pretty quiet.

---

The trick (and this is where my conjecture comes apart a little bit) is to figure out how to define "modest number of items." Too many items in the queue is a sign of needing more community involvement with reviewing. As many posts have lamented, a perceived insurmountable backlog detracts new participants. But you didn't ask how to define modest in this case, and I'm not willing to venture into that minefield this morning. So I'm going to whistle tunelessly while carefully backing away from this corner…

And for the record, I'll happily take more close votes and delete votes on Programmers. Just had to throw that out there.