develooper Front page | perl.qa | Postings from June 2008

Re: CPAN Ratings and the problem of choice (was Re: About tidyingup Kwalitee metrics)

Thread Previous | Thread Next
From:
Salve J Nilsen
Date:
June 30, 2008 04:01
Subject:
Re: CPAN Ratings and the problem of choice (was Re: About tidyingup Kwalitee metrics)
Message ID:
Pine.LNX.4.62.0806301129300.22645@decibel.pvv.ntnu.no
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@,$'.#     <sjn@foo.no>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About