All of these are reasonable, though there can be two reasons for not releasing -- either it can be unmaintained, and left to fester, or it can be complete, and have no bug reports against it.At the moment the focus seems very much on packaging. That's fine, but it does mean that "correctly" packaged junk looks pretty good. In time, some more metrics would be good. Some suggestions:
- How do the CPAN testers reports look? - What does cpanratings think? - Some analysis of the RT action. - Number of releases, perhaps in relation to the size of the code. More releases expected for larger code.
These are difficult to do without running code, which puts it outside the scope of what the OP was willing to do.- Static analysis. - Test coverage.
OTOH, testing if it has any tests is easy, as is testing the size of the tests in relation to the size of the actual code.
- Having a signature
- Having a valid signature
(Unsigned distros should have a higher kwalitee then distros with broken signatures.)
- Having dependencies given
(An empty arrayref of dependencies shows that they're providing the metadata, but it doesn't depend on anything. Not having it is not providing the metadata, meaning we have no way of telling.)
- Having POD - Not having the POD that h2xs puts in - Having a README - Not having a README that's the same as the POD.
BTW, I tend to think that modules that require lots of other things deserve lower kwalitee... and that perhaps in addition to kwalitee we should attempt to track importance.
You can get importance for: - being listed as a (prereq|recommendation|build_prereq) for something else (in relation to the importance of that thing) - having lots of CPAN testers reports - having lots of RT activity - having lots of rating votes - having good rating votes (The two above can probably be simplified by taking the sum of all rating votes.) - Being the most recent version of the dist in question - Not being a devel (IE with-underscore) version.
BTW, all modules should probably be considered to depend on perl itself, no matter what the metadata we have says -- otherwise perl gets an unfairly low importance.
Kwalitee/Importance ratio probably dictates what we should be most worried about -- those that have high importance, and low kwalitee are probably problems waiting to happen, or holes in our testing methods. (There needs to be a cutoff in the lowest importance we're interested in looking at, of course -- otherwise a module with zero Kwalitee, and one importance (hm, needs an approximation to go with Kwalitee... too bad it's so easy to spell -- impurtnce?) has a very low ratio -- but nobody cares if it lives or dies.)
BTW, what's $report->{files}{ninja}?A standalone tester would be very nice -- so authors can test their kwalitee before they upload, rather then after.
There's a couple of misspelled fields in the kwalitee report.
-=- James Mastros
