Chris Dolan wrote:
is_prereq is usually a proxy metric for software maturity: if someone
thinks your module is good enough that he would rather depend on it than
reinvent it, then it's probably a better-than-average module on CPAN.
is_prereq is usually a vote of confidence, so it is likely a good proxy
for quality. In fact I believe that because the author (usually) can't
control it directly, is_prereq is one of the best proxies for quality
among the current kwalitee metrics.
I'd go so far to argue that is_prereq is perhaps a more significant
metric than Kwalitee itself as it is really a measure of *utility*. I'd
be very interested to see it explored fully, not just as a binary --
e.g. how many different authors used a module in at least one of their
distributions.
That said, it doesn't mean much for quality -- people may well use a
poor quality distribution if it is sufficiently useful.
As an example, consider pod_coverage. It's a rather annoying metric,
most of us agree. Test::Pod::Coverage really only needs to be run on
the author's machine, not on every user's machine. However, by adding
pod_coverage to kwalitee we got LOTS of authors to improve their POD
with the cost of wasting cycles on users' machines. I think that's a
price worth paying -- at least until we rewrite the metric to actually
test POD coverage (which is a decent proxy for POD quality) instead of
just checking for the presence of a t/pod_coverage.t file (which is a
weak proxy for POD quality, but dramatically easier to measure).
It doesn't check for the existence of a t/pod_coverage.t file. It
checks that a string like "use Test::Pod::Coverage" appears properly
formatted. E.g. I believe this is sufficient to get the Kwalitee point:
# t/pod_coverage.t
__END__
use Test::Pod::Coverage;
And, unfortunately, it also misses actual perl that doesn't meet its
regex expectations. (E.g. see the bug I recently filed for
Module::ExtractUse.)
Regards,
David
