On Sun, Feb 15, 2004 at 03:56:39PM +1300, Sam Vilain wrote: > ___ > / _ \ > | | | |_ _ ____ ____ > | |_| ||\ | | |___ > \___/ | \| |___ |___ upon a time, the Perl 5 modules list was an > excellent resource for those seeking to do anything non-core with > Perl. However, it has not kept pace adequately with the needs of the > community.
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 propose, what we do about this situation is : > > - expand the modules list into a new section of the www.cpan.org > site, by; > > - deciding if the current categories are good enough 'in this day > and age'; using the current list as a starting point, go through > each category and decide whether it is a useful grouping any more. > > This will ideally also involve individuals with experience with > other languages trawling over the appropriate CPAN equivalents, ie > PEAR, RAA, etc, and providing nice, *brief*, informative reports > on their structure. > > We will then hopefully have a half-decent list of categories. > This process should be quick, perhaps reporting back its progress > to the list every few days until there is a general consensus. Okay. > - encourage curators to step forward, or groups of curators, for > each category; possibly even create mailing lists for people with > a general interest in the technology in that category; to field > questions about naming for new modules to fit into each category. > These curators must have the power to update the contents of the > relevant portions of the www.cpan.org site. > > The idea would be to have each category something like the > http://poop.sourceforge.net/ site - but on a standard template to > lend it more credibility. Ideally with space for user feedback. > > I would hesitate to seed the listing of actual modules on the current > long Perl 5 modules list. Factors such as the usage that the module > has seen, whether long standing bugs were ever fixed, whether a better > module has come along since and gained widespread acceptance, etc need > to be taken into consideration. I disagree. You're mixing different goals that ought to be kept separate. 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. You could argue that Goal 1 is now largely addressed by searching search.cpan.org (although that's certainly not without problems). However the limited integration with the Module List's hierarchical categories and other metadata is unfortunate. I think that's partly due to Graham Barr's view (as I remember it, I might be wrong here) that the Module List was too incomplete relative to the whole of CPAN to be useful and he's right. So let's fix that - see below. Goal 2 is still important - as you can see from archives of [EMAIL PROTECTED] when there have been discussions leading to a better choice of module name. But [EMAIL PROTECTED] has it's own set of problems (that I hope will be addressed when it's integrated with RT so requests don't fall between the cracks). > Many popular modules are missing from the list altogether. The text file is out of date. The underlying database isn't: http://www.cpan.org/modules/03modlist.data.gz (Though it is incomplete because not enough authors take the steps to get listed, but that's a different set of issues.) 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). Here's what I'd suggest: 0. Don't underestimate how difficult and subtle naming issues can be. 1. Split and extend the list of categories aiming for about 2 to 3 times the number to keep it managable, perhaps grouping the categories into a two-level hierarchy (but the top level is just for human use, the 2nd level names should be self-descriptive without the 2st level names). 2. Map modules from the old categories to the new ones This needs to end up as a sequence of SQL statements that can be run on the PAUSE mysql db to update the category number for each module that has one. 3. Write a script to generate http://www.cpan.org/modules/00modlist.long.html from http://www.cpan.org/modules/03modlist.data.gz or ideally from the underlying mysql database (with simpler formatting and focussing on just the modules) and give it to Andreas for PAUSE to use automatically. 4. http://www.cpan.org/modules/03modlist.data.gz is actually a perl module called CPAN::Modulelist but it's nor downloadable as a module. I think it would be good if it was. Give it a YYYYMMDD version. That's for Andreas to do, I guess. 5. This is a key one... For those modules that are not on the Module List, (i.e., not in http://www.cpan.org/modules/03modlist.data.gz) and which have a 'significant' existing user base, develop a "Fast Track" process to get them added to the Module List. The key point here is that modules with a significant existing user base can't easily be renamed so we might as well live with the names they have. Tim.
