I'm dreaming of a Perl::Critic policy (or a super test) that would make test descriptions mandatory.
]]>We're trying to follow a strict two-line format in the perl code, which makes the tests really easy to skim through.
ok my $thing = Classname->new( %args ), "Can create a Classname"; is $thing->accessor, $expected_value, "... and attribute was set ok"; ok my $result = $thing->method_call, "... and can method_call"; is $result, $expected_value, "... and method_call returned thing_we_wanted";
/me is enjoying not creating tmpvars on their own lines all the time and having oodles of space to write test descriptions :-)
]]>
Hopefully the next iteration will be a more accurate / useful indicator. XML-Twig will be a useful test-case for me!
]]>If the goal is identifying modules which need adoption then there should be a qualifying criteria.
I suggest that module which has been released within the last year should not qualify even if its overall score is very high.
As it stands, a module which was released yesterday with a lot of bugs and dependencies could score quite highly.
I think there could be modules most recently released 10 months ago, with very recent bugs, and they should probably be included. At the moment I'm thinking 6 months as a cut-off, but with other factors included.
If my needs change in the future, they are likely to get another round of attention; ditto if somebody reports a serious bug. But if everything seems to be working fine, then there's no point gratuitously updating them just so they seem more active.
I imagine there are plenty of other authors in similar situations.
Hash-Util-FieldHash-Compat (which is not mine, but seems a good example) has been sat on version 0.03 for over 5 years; and the changes since 0.01 have been fairly minor. Yet it works well; OX uses it; KiokuDB uses it. If something went wrong with it, I'd be fairly confident of that it would be fixed quickly; not least because its current maintainer is also a maintainer of KiokuDB so has a vested interest in doing so.
]]>@stevenh: good point about CPAN Testers — I've added that to the list. Might not make it into the next iteration, as I need to find an easy way to get the data.
]]>But if the list just highlighted modules that could use some live, that could lead top adoption. I for one regularly ask bug reporters for some of my modules to adopt them because I no longer use them (I've not had a great deal of success there though ;)
]]>@leont: your dist with two wishlist tickets only no longer appears. You have other dists which do appear though ...
@rkinyon: if you give HANDOFF or ADOPTME permissions on your modules, that will give your unloved dists a +1. They're scoring low though, so with my new version they still wouldn't make the cut. I'm thinking about another column for "adoptability", and also including modules that score high on that, even if the current score doesn't pass the threshold.