Kwalitee

ethan on 2005-03-31T11:51:27

Lately I poked around a bit at CPANTS. I should maybe say that I am not really believing in this kwalitee thing and am mostly d'accord with what Schwern wrote about it on cpanratings.

Nonetheless I couldn't resist of looking up the scores of my modules. They weren't quite as high as possible because so far I haven't done any pod-coverage in my tests. This can be easily rectified. Then I noticed an annoying thing about Test::Pod and Test::Pod::Coverage: They claim to rely on Test::More. This is bad for some of my modules which are supposed to run on older perls, too, so I only use the plain Test module for their tests. Yet, CPANTS somehow tickled my vanity so I came up with test suites that use Test::Pod and Test::Pod::Coverage respectively without any need for Test::More:

eval "use Test::Pod";
if ($@) {
    print "1..0 # Skip Test::Pod not installed\n";
    exit;
} 

my @PODS = qw#../blib#;

all_pod_files_ok( all_pod_files(@PODS) );


and in a similar fashion for Test::Pod::Coverage.

Of course, this exposes my modules to other potential problems, such as when the Test::Harness protocol changes, and thus makes it more flakey. However, the kwalitee score is now higher which already says something about the value of the kwalitee measurement.

Also, I think this test from CPANTS:

is_prereq
    Shortcoming: This distribution is only required by 2 or less other distributions.
    Defined in: Module::CPANTS::Generator::Prereq


is plain wrong and worthless. Why should it be a good thing that a module is used as a prerequisite by other modules? There's a whole class of modules on the CPAN that provide very high-level functionality and will therefore never be a prerequisite (think of modules such as Mail::Box or MPEG::MP3Play). This applies to all modules that are used to write applications instead of other modules.


prereq

cog on 2005-03-31T12:06:22

is plain wrong and worthless. [...] This applies to all modules that are used to write applications instead of other modules.

Email domm :-)

is_prereq

Smylers on 2005-03-31T13:11:00

is_prereq is not worthless. While what you say is obviously true (some good modules may not be used by any other), the reverse does not necessarily apply: if a module is being used by other modules, written by different authors, then that's a sign that there are other people who respect it, and therefore it's got a chance of being of higher quality than other, similar modules that have no such dependencies.

If I'm trying to pick between several app-oriented modules then none of them will have is_prereq, so it's a level playing field, and the existence of is_prereq isn't doing any harm.

Or, rather, the only harm it's doing is to people who treat kwalitee numbers like they mean something in absolute terms. And such people deserve what they get (a high XP score on PerlMonks, probably).

Smylers

Re:is_prereq

ethan on 2005-03-31T16:14:01

if a module is being used by other modules, written by different authors, then that's a sign that there are other people who respect it, and therefore it's got a chance of being of higher quality than other, similar modules that have no such dependencies.

Ah, but you say "quality". kwalitee != quality.

If I chose to add a module as dependency, do I care whether this module has a README? Or whether it has POD coverage tests? Or uses strict everywhere? No, no and no. I include it because it turned out to be useful for me, the module author. I require users of my module to install this other module. He doesn't need to read this module's README or its documentation. I already did this work for him.

My point is that is_prereq doesn't fit into what kwalitee is supposed to mean. Also, it's the only test whose outcome can't directly be influenced by a module author. Hence it's wrong.

Re:is_prereq

Smylers on 2005-03-31T19:02:10

if a module is being used by other modules, written by different authors, then that's a sign that there are other people who respect it, and therefore it's got a chance of being of higher quality than other, similar modules that have no such dependencies.

Ah, but you say "quality". kwalitee != quality.

Actually I said "a chance of ... quality", the point being that it doesn't necessarily mean that the module is of higher quality, but in general there's likely to be a correlation between quality of modules and other people choosing to use them.

But quality isn't measurable; kwalitee is. Indeed that's the purpose of kwalitee: since quality can't be measured, the idea is to compute things which can be measured and which often are indicators of quality, with the hope that those modules with a high kwalitee will be those that also are of high quality.

If I chose to add a module as dependency, do I care ... README ... POD coverage ... strict?

No, but that isn't the point of is_prereq, since those are technical matters which can be determined automatically and are already taken into account elsewhere in the kwalitee calculation.

I include it because it turned out to be useful for me, the module author.

Exactly! You found the module useful, and surely usefulness is a sign of quality? Presumably you wouldn't've used this module if there was an alternative available of higher quality, so your vote of confidence is an indication of the module's quality, and therefore used in the kwalitee calculation.

My point is that is_prereq doesn't fit into what kwalitee is supposed to mean.

I understand kwalitee is "supposed" to be a measurable quantity of factors that often have a correlation with quality, and as such it sees to fit. What do you think kwalitee is supposed to be?

Also, it's the only test whose outcome can't directly be influenced by a module author. Hence it's wrong.

Why does that follow? Kwalitee (and quality) is an attribute of modules, not of authors. If something is indicative of quality then it's useful to include it in the kwalitee calculation. Authors can indirectly influence a module's usage by producing something that is useful. Doing so is much harder than following a checklist of things like including a README file, but that's no reason not to take note of those who succeed.

Smylers