When the Phalanx 100 first came, it's no secret that I was unimpressed at the result (although appreciative of the effort)
The spirit of the exercise seemed quite reasonable. Identify the things that we care the most about, as targets for greater testing attention and as candidates for volunteers to help with.
What I really couldn't get past, despite the good intentions, was the lack of completeness. Even though it was derived from download numbers, it was still hand-compiled and didn't factor in dependencies.
This lack of a feedback loop meant that it was always going to be stale. Moose does not appear on the Phalanx 100, yet it has roared up the Volatile 100 list even in the last few weeks from 97th place to 69th place. The Volatile 100 list is pretty much what I always imagined the Phalanx 100 should be, although even now has the problem of not factoring in end-user download numbers (I'll get to that later in the year hopefully).
The second problem I had with the Phalanx 100 was in it's role as a menu for Perl modules that monger groups might want to adopt and help out with. I think this also suffered from some big flaws in that it didn't control for whether or not the module NEEDED any help, or whether the author might be agreeable. It also kind of implied a monger group might look after something over a period of time, whereas I much prefer getting people involved on a single specific task they can start and complete in one chunk.
Two weeks into the FAIL 100 we've seen a lot of positive changes. A host of modules with double figure FAIL counts near the core that haven't released in quite a while have all landed bug fix releases.
In particular, Graham has dropped new Scalar-List-Util and IO releases that repair long-standing Windows failures. We've also seen a Storable update, and three or four other top 20 modules doing incremental releases to flush out minor packaging or testing problems (including a few of mine that I wasn't aware were a problem).
For a heavy module like Padre, this combined bug fix work has meant that the CPAN Dependencies "Chance to install" number has climbed from around 25% to 35% (even if this is a fairly artificial number).
Now that initial release flurry is over, you can see a particular pattern emerging in the top 10 or so failing releases. The authors list reads like a who's who of the chronically overworked. People that used to be more active in the past than they are now, but haven't had as much time more recently to maintain the movements they founded.
There's also a few special cases like the C-related toolchain modules that you'd expect to be inherently hard to keep bug free and that will remain near the top for some time.
The best thing about this list is that the modules complete, working, and heavily used. They all make great candidates for Perl Monger hackathons or for an ambitious individual that would like to do a little Perl programming and contribute something to Perl. Just about all the modules in the top 20 could benefit greatly from someone picking up even one of the CPAN Testers fail reports and doing the legwork to chase down and fix that one specific bug.
Even though some of the bugs may be obscure, and involve something of an adventure to find and fix, you can do so with the knowledge that you are making a difference to a huge number of people.
In a few cases, the authors may even be amenable to someone else taking over maintainership of the module. (if you're interested in that kind of thing).
I encourage you to take the initiative.
Look for a module in the Top 100 you care about (the higher the better) and contact the author to see if they'd like your help fixing it. Or even better, find or file an RT bug report for the failure in CPAN Testers, fix it, and attach the patch to the RT queue.
