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:
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.
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.
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.
Keeping involved with user communities helps, but many
professional Perl programmers are not in a position to join
general language discussion groups, hang out in IRC channels and
attend conferences where this information is widely discussed.
use.perl.org and perlmonks.org are great, but in my experience,
they still involve a large time sink to get the simple reviews of
the community.
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)
> 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 ;)
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 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.
Goals will provide editors with guidance, and I suggest some goals
below.
How the CVS accounts, and auto-publishing is implemented and
administered is a non-trivial detail, but I do not think that it is
yet the correct time to thrash that out. Let's just let the concept
stew.
I would personally like to see goals like;
a) the content should be *helpful* for programmers, that are:
- new to programming
- or just new to Perl
- or just trying to pick up that field/category of Perl as
quickly as possible.
b) the content is *concise*; refer to and summarise the gist of
reviews, don't duplicate them. Reading content should *save
time*.
c) Each module was written with particular goals in mind; therefore,
the editorial content should attempt to identify what
*distinguishes* modules. In this way, a prospecting author can
decide which is best suited for their particular purpose.
In particular, conflicts of opinion about modules are largely
down to differing views on which goals of the module are most
important. Don't argue, try to understand your fellow
programmer's viewpoint.
d) The "cargo cult" effect is both glorified as a way of helping the
community gather steam and establish common practice, and
humourously regarded as sometimes meaning that much of the
community misses the simpler approach.
So, content should be written that pays attention and refers the
programmer to communities that have chosen to thrash out a
particular path, as well as noting the upstarts that are trying
something new.
e) No personal attacks,
f) Try to distinguish between commenting on APIs and
implementations; but please, do compare both where useful :)
g) Keep as much bibiolgraphy information as possible. Link to as
many relevant articles, and opinion articles as you can, within
reason. Especially take note of large OSS projects or other
modules on CPAN that use the works as a base, for "prime
examples".
> 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.
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
The most incomprehensible thing about the world is that it is
comprehensible.
ALBERT EINSTEIN
