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