On Mon, Feb 16, 2004 at 10:37:12AM +1300, Sam Vilain wrote:
> On Mon, 16 Feb 2004 01:32, Tim Bunce wrote;
>
> > I'd like to see a summary of what those "needs of the community"
> > are. (Maybe I missed it as I've not been following as closely as
> > I'd have liked. In which case a link to an archived summary would
> > be great.)
> > It's very important to be clear about what the problems actually
> > are.
>
> I don't really want to argue this side of things, I think that the
> problems pretty much speak for themselves. But I hate unspoken
> consensus, so let me suggest a few from my perspective; this applies
> to the combined Perl 5 modules list / using search.cpan.org:
I'll play devils advocate here and point out some alternative remedies
for the problems. By doing so I'm _not_ trying to detract for your
suggestion, which I like, I'm just trying to show how existing mechanisms
could be improved incrementally.
> a) searching for modules for a particular task takes a long time and
> unless you get your key words right, you might not find it at
> all. Refer the recent Mail::SendEasy thread.
Calls for a richer set of categories and cross-links of some kind.
(Editorial content alone is basically just more words to a search engine.)
> b) it is very difficult to find good reviews weighing the pros and
> cons of similar modules; they exist, but are scattered.
>
> CPAN ratings was a nice idea, but has too many "First Post!"
> style reviews to be useful in its current form IMHO.
Argues for moderation of reviews and a minimum review length.
A "was this review helpful" mechanism would also help to bring
better reviews to teh top. Also the search.cpan.org should not
just show the overall rating, it should show the underlying three
individual ratings (docs, interface, ease of use).
> c) it is nearly impossible to tell which modules are the wisest
> choices from a community size point of view; using modules that
> are more likely to fall out of maintenance is easy to do.
Argues for more stats. I think useful *relative* download stats
could be extracted from a sample of CPAN sites. Also search.cpan.org
could provide relative page-*view* stats for modules.
> d) some great modules are not registered (I am referring of course
> to such masterpieces as Pixie, Heritable::Types, Maptastic :),
> Spiffy, Autodia, Want ... and those are just the ones missing
> in my bag of tricks)
Argues for fixing the registration process.
> > Originally the Module List had two goals:
> > 1: to help people find perl modules for a particular task.
> > 2: to provide a second-tier of modules above the 'anarchy' of
> > people uploading half-baked ideas with half-baked names.
>
> Honourable goals, which it solved adequately for a period of time, and
> full credit where it is due.
>
> But now let's look at where we are. We've got masses of modules,
> truckloads of categories and thousands of contributors. This task
> cannot be left in the hands of a handful of hackers, no matter how
> much awe they inspire, they probably still have lives and day jobs ;)
The registration process can, and should, be automatic for any modules
for which no one objects. You'd apply and RT would automatically
register if no one commented on the application.
> I will maintain that the current format, or even simply adding some
> more fields to the database is *not* enough information to give
> uninformed people looking for a module the information to make an
> informed decision.
>
> It is my gut feeling that only editorial content, managed by people
> who are experts in the field, will truly perform this task - and that
> to gain maximum support, that it should be included in the content
> mirrored along with the rest of cpan.org.
I agree that comparative editorial reviews would be very valuable
for Goal 1 above. I wouldn't address Goal 2 effecively at all.
> I think we're mature enough as a community to be able to produce this
> content without it disolving into flamewars or being too one-sided.
>
> In particular, I really think that as little red tape should be
> applied to this system as possible. Let's just set up a few CVS /
> subversion accounts, to edit content that is autopublishing to the
> www.cpan.org site, with a few disclaimers chucked on the bottom.
> LARTing the naive and troublesome as appropriate.
I agree. This all seems very similar to the DMOZ.org project that
maintains reviews of millions of web sites:
"6,095,104 sites - 61,277 editors - 551,043 categories"
That's a mature and very sucessful model (used by google directory etc)
that's well worth learning from.
> > The text file is out of date. The underlying database isn't:
> [...]
> > Please work with the PAUSE system, and Andreas and myself, to
> > enhance what already exists (which includes a UI for module
> > authors to pick which category they want the module in).
>
> I'd be honoured to. I think that the plan you propose would be an
> excellent step forward, and whether or not the editorial plan gains
> acceptance then it has merit.
>
> Unfortunately right now I have to move house :-) but I should be able
> to dedicate at some time this week to research and kick-start this
> recategorisation effort.
Ultimely countless good ideas fail for lack of time.
Tim.
