Hehe, you're right, your tickets would drop to 35 or less and your rank would be beyond 100. Unfortunately it's quite a bit more tricky to provide stats that eliminate tickets to self because many tickets reach Status=resolved without ever getting an Owner. So I'll refrain posting revised stats.
During the last year I took over the lead in the top posters of RT tickets both for the year and for all time. I'd like to take the opportunity to apologize to all recipients for my being such a pain in the neck but also to thank the hundreds of you who fixed their code quite often on the same day I posted my report.
Is this a rhetorical question? Human judgement of course, on a case by case basis. When you send the automatically generated emails all to yourself and read them and do the best of all possible efforts to judge the situation and only then forward those manually that have passed all possible filters. I mean permanently adjusting filters according to gained insights during the review process. Then you will still find people who disagree with you but that's just fair because you have done your very best effort. And that's the only thing that counts.
I'm with chromatic here because I'm probably 10000 times more annoyed by spam than you are. My tolerance against self appointed importance sheriffs is quite limited. Why can't you just publish your wonderful statistics and let people subscribe who care enough? You should rather deny the right to email authors on the basis of being on the list. Prevent spam instead of asking for the right to spam.
Other readers may wonder what I'm talking about: I looked at the list twice and both times the number one hit was obvious nonsense. I mean the formula is really pretty weak. It gives a good guidance when you have plenty of tuits and don't know where to invest them. That's what I recommend these lists for. The hope that the false positives will vanish has not much reason.
FAIL100 is a really nice tool to indicate that something might be important but it's not suited to prove that something is important.
The bug in IO-Zlib is identified in https://rt.cpan.org/Ticket/Display.html?id=47793
The result is more boring than you'd hope but at least we know what we have to do. Thank you, Adam.
The problem with your metric is that you also measure the time how long a distro is sitting on CPAN because the number of fails will tireless increase even if the fails are irrelevant. Maybe divide by number of received reports?
Releasing a developer release comes close. You cannot log into the machines but you can write your tests such that they spit out enough diagnostics. Some testers have a modern setup that delivers the tests within minutes after the upload. So while it's not as relaxed as sitting in front of a shell prompt it's an alternative.
1: SREZIC 681 2: ANDK 643 3: MSCHWERN 491 4: guest 486 5: ADAMK 350 6: MARKSTOS 335 7: CHORNY 304
