On a number of sites*, there's enough review flow to reliably keep certain queue backlogs in the dozens or even hundreds. This is discouraging to regular reviewers; some sites struggle recruiting more than a few reviewers, and a number of comments have cited large queue lengths as the demotivating factor limiting their own involvement. It also increases time to handle new items, making community moderation less effective and causing more work to clean up e.g. answers to questions that are not closed promptly.
The only feature that currently acts to actively restore the balance in most such cases is the raising of daily caps to 40 instead of 20. But because this takes effect only when the queue has a backlog of 1000 or more, and cuts out as soon the backlog drops below that (without waiting for any user to finish with their expanded allowance), it does nothing to actually bring the queue to 0. Clearly, though, the general approach is considered philosophically acceptable: if there's just too much in the queue, give each willing reviewer somewhat more opportunity to try to take care of it all, even at the expense of slightly reduced accuracy or higher per-reviewer load.
What should be changed, therefore, is the trigger. How about a graduated system? For any week** in which a given queue never reaches 0, the daily cap for all users for the next week** is raised by 10, up to a maximum of
50. Conversely, for any week** in which a queue never reaches
20 items backlogged, the cap is lowered by 10, to a minimum of
10. If neither condition is met, the cap remains the same as the previous week**, and caps are initialized to the result of the current calculations. Transitions can be very efficiently tracked by checking whether a given queue is at 0 or
20+ whenever the 10k-tools review count is updated, and setting a bit field if so.
Some queues are limited by votes, not just the review cap: Close, Reopen, and certain functions of Low-Quality. These should ideally allow additional queue-only votes; specifically, allow
5 review-queue-only close votes for every 10 reviews in the cap (including the baseline). So a queue operating at 50/day/user would allow the first 25 close votes to be cast for "free". (These would probably be shared between all eligible queues, including Triage on SO, since the alternative requires a much more complicated UI.) Delete votes for 20kers in LQP should be handled similarly, but the scaling would need to be rethought; that deserves a separate proposal.
The primary benefit of this proposal is twofold: queues that are not absolutely incorrigible could be brought reliably to heel by the community, removing the futile perception of fighting perpetually multi-hundred-item queues, and newly busy queues would be adjusted for much faster, reducing system lag in most cases of increased load. (Not counting events like the recent Late Answers surge, of course.) Fundamentally, this addresses the key problem of review queues, which is not current backlog, but capacity as a rate at the margin.
The general principle behind this idea has been recently tested at SO, and the results were officially promising enough to warrant some sort of scaling increase. I think this algorithm is one of the best choices for this: it's relatively simple but quite flexible anyway.
*SO's CV queue is of course legendary, and would not be materially affected by this, but the recent growth of LQP there seems to have no real end in sight (900 at time of writing, and still climbing fast). Other sites affected include SF and SU, ELU, Android, DIY, AU, and probably dozens of others I'm less aware of.
**Or day. I'm not sure which granularity is likely to be better.