Andreas König

And what is most amazing about it? That 186 or 46% are either resolved or patched. That's a wonderful success rate.

If you have a login on rt.cpan.org you can issue this query to see the actual 401 tickets.

Very nice graphics and ad-hoc statistics are then provided by RT when you look at the bottom of the page. I've never noticed that RT footer under the result of a query before.

For example I can create a bar chart by CreatedMonthly that shows me when the rally started: 65% of the tickets were created from August to December. That's because on the first days of August was the relaunch of http://analysis.cpantesters.org/ after a few months break due to the cpantesters 2.0 launch. Analysis is the real work horse that drives me in this game. It's kind of playing solitaire with bugs. Analysis provides the deck: cards of many different shapes and colors, my job is to read them and find the ones that can be resolved quickly.

A never ending deck it seems. In the last four years we had over 3400 uploads to CPAN that have both passing and failing tests. Enough material for more players. Feel yourself invited.

The total number of my posts to rt.cpan.org over the years approaches 1500 tickets. 840 of them are resolved. That's a lot and then again it's a lot that remains unresolved. The first thing you have to learn if you're about to follow my footsteps: don't expect too much and be patient. Today I can enjoy mails about resolved tickets I have opened years ago and hardly can remember. They are the final intrinsic reward for the hours spent in the RT ticket game.

Analysis has changed the game drastically though. In the old times it was a purely random process when I was hitting a distribution with a failing test. Only when some other channels brought my attention to a distro and a test of that distro failed then I had a case for a potential bug report. Analysis now brings the distros to my (and your;) attention nearly instantly. As soon as it has at least three PASS and three FAIL reports it gets listed in analysis. This may be on the same day as the release. I usually wait until three whole days have passed before I allow myself to report. I think this is a polite grace period that gives the authors a break.

If a bug report arrives as quickly as 72 hours after the release many authors are still familiar with the process of releasing and immediately make a new release. That's so fascinating. Getting 46% of the tickets resolved within a few months was not a goal you hoped to reach in the old days. The standard seems to be shifting. Thank you, all.

PS: if you know of other software QA projects using multivariate statistics to identify potential causal relations, please post them here. I'm eager to learn about other approaches.