develooper Front page | perl.module-authors | Postings from July 2004

Re: Future of the "Module List"

From:
Randy W. Sims
Date:
July 14, 2004 15:50
Subject:
Re: Future of the "Module List"
Message ID:
40F5B88F.603@thepierianspring.org
On 7/14/2004 5:51 PM, Tim Bunce wrote:

> On Wed, Jul 14, 2004 at 12:40:03PM -0500, Dave Rolsky wrote:
> 
>>On Wed, 14 Jul 2004, A. Pagaltzis wrote:
>>
>>
>>>* Dave Rolsky <autarch@urth.org> [2004-07-14 19:26]:
>>>
>>>>Some of them _are_ registered, but that document you're
>>>>referring to hasn't been regenerated since 2002/08/27!  I wish
>>>>the CPAN folks would just remove it if it won't be generated
>>>>regularly.
>>>
>>>Does anyone else here think that the list should probably just be
>>>done away with entirely?
> 
> 
> The _file_ should go, yes. The concept of registering modules is different.
> 
> 
>>Given the fact that most authors seem to not register their stuff, the
>>modules@perl.org list is slow as heck, and that the web pages never get
>>regenerated, yes.
> 
> 
> Those are all fixable. Volunteers?
> 
> The real issues are bigger and deeper. I've appended a couple of emails.
> 
> Tim.
> 
> 
> 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.)

Are we talking about the same thing: <perl.module-authors:2601> ?

>>  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 the 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).

This is definately a trouble area. Not long ago I was exploring the 
cpanratings site and discovered the unhelpful "rampage" by one 
particular reviewer <http://cpanratings.perl.org/a/181>. Maybe breaking 
the reviews into catagories would be helpful? Rate: installation, 
interface, robustness, overall, etc.

>>  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.

Narrow the interface for CPAN such that all viewing takes place on a 
single server where it can be monitored, and all download requests are 
distributed to mirror sites (ala sf.net).

As for the best of the best, I still believe there is a lot of merrit in 
the list built from dependencies idea.

>>  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.
> 
> 
>>This is why I am mailing you to ask: what's going on?  Why is such
>>an outdated module list being published in an authoritative location,
>>and where can I get an up-to-date list?
> 
> 
> Module List *document* was maintained by hand.  When managment of
> the Module List *data* was automated there was a desire to automate
> maintainance of the document but the document had a slightly richer
> structure than the data. That small hurdle meant automation never
> happened and the document was left unmaintained.
> 
> Around the same time search.cpan.org became functional so the
> document had less relevance and busy people had other things to do.
> 
> I'll happily conceed that the *document* isn't important these days.
> But I feel strongly that the *principle* (of moderated naming and
> categorization) is.
> 
> The main pieces currently missing are:
> 
> 1. Automated handling of module registration. [Where has that got to?]
> 
> 2. Better integration of registration data into search.cpan.org
>    So registration details are includes in search results, for example.
> 
> 3. A 'fast path' process to register many modules that are in
>    widespread use but are not registered. So then the majority of
>    modules are registered and 
> 
> The alternative is just to give up. Seriously. We could just stop
> banging our heads against authors uploading half baked ideas with
> half-baked names (which are "self explanatory" to them).
> 
> The hope would be that out of the anarchy would rise some new
> form of organization[*] (in the broadest sense) that would help
> hapless users find what their looking for.
> 
> Do we want to do that? [I'm asking this question in all seriousness.]
> 

We could accomplish required, automated, and reviewed registration by 
setting up a new list (the modules list is filled with so much automated 
chatter that I don't even look at it any more). Before an author could 
upload a module, a message would be auto posted to the list. If, after 
some arbitrary time period, no one responds, then registration is is 
approved. If there is a response, then it gets pushed on to a queue for 
moderator approval. Moderation is simply a select group of people who 
monitor the discussion and have authorization to act according to the 
consensus reached in the discussion. Moderators do not make the 
decision; they just execute it.

The list would accomplish the same thing that generally happens here 
(name discussion, reinvention, etc), but will be required.

Randy.

> Tim.
> 
> p.s. I think the term "Module List" should be deprecated in favor
> of talking about "Registered Modules" and "module registration" etc.
> 
> [*] Presumably based on metadata, rantings, editorial reviews, download
> stats and/or whatever else people can come up with.
> 





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