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 <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED] 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.
