Paul Fenwick said:
Jonathan Rockway wrote:
The same could be said for CPAN Ratings also. Why should my module
have 1 star next to it because any goof with a web browser can write a
review? Why is the opinion of someone with no ties to the community
considered relevant enough to show in the search.cpan search results?
I'm a big supporter of CPAN Ratings, because I view them as solving one
of the biggest problems facing the CPAN today. Choice overload.
CPAN is suffering from its own success. One of the most common
questions I get asked is "Which CPAN module should I use? There's like
300 that cover my problem". The worst thing is, faced with too many
choices, typical humans are more likely to choose *none* of them,
compared with if they were only offered one or two[1].
Thank you for making this point. I've had this problem too, many times,
and I'd love to see something that helps me manage it.
Let's assume I'm in hurry to buy a present to someone I don't know (or any
other situation where I'm forced to make a low-info, low-context
decision.) I have to make the best out of the situation with the
information that I have. Sometimes the only solution is just to ask the
clerk "what toy would you give as a birthday present to a 5 year-old
friend of your nephew?". The clerk would at least be able to give _some_
useful info, like "this is popular amongst the pre-schoolers" or "this toy
got a prize for being the most educational in 2007" or "we are getting
lots of these toys in return, so don't buy it until the problems are fixed
upstream"...
The criteria for choosing software are of course a bit different. I'd
argue the major one is that WE can also choose to improve the software we
select (at least when it comes to OSS.)
So when we're discussing Kwalitee metrics or the CPANTS game, we're in
fact discussing new datapoints for people to use when they choose. We make
information available. We're "communicating".
But as with all other kinds of communication, we have both transmitters of
information (the CPANTS website, metrics, explanations, reviews etc.) and
a receiver (the individual end users, the distro authors), and as with all
other kinds of communication, there's always a danger for the recipient to
interpret the info wrong.
There's a tradition in the marketing and sales professions that if a
message doesn't "land" well, then one should assume something is wrong
with the message, and not the recipient. This may be well and true in most
cases, but it doesn't take much to imagine situations where this
assumption is wrong - or at least not precise enough.
But for our purposes I think this tradition would apply well. If people
are actually annoyed about getting in the "hall of shame", we shouldn't
remove the hall, but instead give them useful info on how to get out of
it. If authors add useless "workarounds" just to get on the top of the
CPANTS game, we shouldn't remove the game, but instead find ways to make
this tactic useless.
It's extremely telling when one of the most popular parts of Perl
Training Australia's courses is showing students the Phalanx 100 as a
short-list. Even though the list is quite some years old, there's almost
palpable relief when the students realise they can just pick XML::Parser
from the Phalanx top 10, rather than having to examine the multitude of
choices on the CPAN.
So, why do ratings make a difference here?
Well, ratings provide at least a partial way for the community to solve
the choice overload problem. If a search reveals a 4.5 star module with
eight reviews, one doesn't feel compelled to look at the other options;
the choice becomes clear.
Let's look at one assumption I think we're making... Who are actually the
information "recipients" in this matter? Here's my take on it:
* End users of CPAN modules
* CPAN module authors
x People who are in a "learning" mode
x People who are in a "getting things done" mode
So, who should we tailor the messages for? Here's how I would rank the
message recipients:
1. End users of CPAN modules who are in a "getting things done" mode
(help users choose, because this makes CPAN into Perl's killer app)
2. CPAN module authors who are in a "learning" mode
(help authors make better modules, because we want less than 90% crap)
3. End users of CPAN modules who are in a "learning" mode
(help users become authors, because this is how the community grows)
4. CPAN module authors who are in a "getting things done" mode.
(help authors work efficiently/without "annoyances")
If we can agree on this, I think it'll be a lot easier to decide of ways
and means to move CPAN forward, and even make some good decisions.
- Salve
--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}"; __END__ is near! :)
