Early results
In my opinion, the top bar indicator works best when it:
- Minimizes the time it takes for review tasks to be handled and
- Minimizes the cognitive impact (to borrow a phrase from this answer).
Unix was the site with the most reviews in the experiment. It's clear that tasks did get done more quickly:
epoch reviews max minutes pending avg minutes pending
------ ------- ------------------- -------------------
before 2165 7931 168
after 2553 1690 56
I won't go through all the sites, but each one saw similarly positive decreases in review time. But meta feedback noted:
As in inveterate queue clearer, the behavioural impact is negligible. The cognitive impact, however, is unwelcome. The red dot immediately signals dread: "Oh, there are a heap of these things to deal with now..."
Save the red for when you really need it (ie., when the queue really is backed up: 10 or more, or whatever the old threshold was). Bring back the grey so the site feels less like it is on fire all the time.
Meanwhile on RPG:
I'm appreciative of the change: if I see no indicator, I now know there's no reviews.
It used to be there could be 1-2 sitting there and I'd just have nothing telling me.
It's a bit over-tuned in that it shows me everything I can't even work on, as mentioned in the question, but over-tuned is a nice departure from under-tuned, and I appreciate there's further work to tune it just the right way.
Reviews on that site also got a lot faster:
epoch reviews max minutes pending avg minutes pending
------ ------- ------------------- -------------------
before 465 1058 112
after 437 1012 58
But notice there are a lot fewer reviews. In the last 9 days, they've had about 2 review tasks per hour compared to Unix's ~15. (If you are doing the math with me, note that RPG started the experiment on the 13th and Unix started on the 15th.) Presumably Unix has more reviewers too, but since the average review hangs around for an hour, it's quite likely the indicator will come back each time the hour-long grace period expires after clicking on it. That's clearly too much and a long way from our (somewhat arbitrary) warn 10% of the time criteria.
So I think it's probably reasonable to turn on the new logic for sites with only one or two reviews in an hour. It's not at all reasonable for sites that get double digit review tasks an hour.
False negatives
Several people have noticed that sometimes the indicator doesn't light up even when there are tasks in one or more queue. After you click on the review queue icon, you get an hour-long grace period from being notified about new items. But the reports generally take that behavior into account. It looks like there's another reason for the occasional false negative: caching. So there's a potential delay of a few minutes between when a task enters review and when the indicator might first light up. When someone clicks the review icon, the number of pending tasks for each queue is recalculated and the grace period starts for that user.
Given that reviews are getting handled more quickly, this doesn't seem like a critical problem. The indicator does come on eventually, so it avoids the main criticism of the danger threshold version on small sites. Obviously, it would be nice to have a consistent mental model. On the other hand, it does reduce the potential for overwarning.
False positives
We did get one report of a false positive. In this particular case, it seems the user addressed all the review tasks but they didn't get cleared from the queue within the hour. We are addressing another potential problem: being warned of review tasks when you don't have enough privileges to see the queue. (The work has been completed, but it's probably not a good idea to deploy just before vacations.) False positives are certainly discouraging, so we'll want to eliminate as many as possible, if not all.