I really just wanted to mark down the modules we all generally agree are above suspicion and put them some place fairly easy to link to. That way the next time some one asks why we all trust CGI you can send em to a page that lists 8 of us that have dug through it and asked Lincoln questions about it in person.

The last thing I want to do is present these bozos with a list of excuses why not to use modules when they want my help rewriting ReadParse to handle multiple selects.

In the end, any form of certification just consists of a bunch of people who say that a module is worthwhile. You then must consider on what grounds you trust these people.
Exactly correct. Now that they have come to us for advice, they are extending SOME trust to us so we offer them a list of the modules we trust.

I see presenting a list of the best that the perl community has to offer as a positive step. I see building a list of the bad ones as divisive and mean-spirited. In no way did I wish to be associated with that. I'd rather we stay at no lists at all than have an official "icky" list floating around.

--
$you = new YOU;
honk() if $you->love(perl)

From what I've noticed about such posts, the authors usually don't want to take our advice. Those who won't be swayed by a list of reasons to use a given module are probably unlikely to be swayed by the fact that monks J, K and L have given it the quality seal of approval. I, on the other hand, might well be swayed if I've developed some respect for those monks. For that reason I viewed this more as a resource for those who have already used the site to some degree and established feelings about how trustworthy the reviewer is.

What type of list is more useful depends on the prospective user's starting point. The person you described does need to be approached with reasons to use a particular module; I think there are certainly far worse things you could do with your time than to compile a list of reasons from all the replies on previous instances of the subject, which would give a convient place for us to point to the next time the topic came up.

If, on the other hand, your desired audience is people who already frequent the site and who are inclined not to re-invent wheels (without good reason), then a list of poorly-written modules is more valuable than a list of good ones. When I have to do something I've never attempted to do before, I tend to look to see if there are any modules which might help me. If I find them, I am inclined to assume they work and initially believe that any problems I have are caused by my own lack of understanding. I expect the module to work as advertised, so I am unhappy to discover when one does not.

To me it is not mean-spirited but helpful to be warned about potential problems. If we lack the ability to say anything bad about something that truely is bad, then we appear either blind or corrupt, and either way we do users a disservice by keeping knowledge from them.

After further thought, I suppose the idea I want to question is the list itself more than the good or bad list. Unless the list is a summary of a discussion of the module, I think its use is limited. If lots of people are saying a module is bad, I want to know why. Likewise, I imagine the person who has just hand-rolled some code wants reasons why the standard module is better, not a list of 8 people (whom s/he doesn't know) who say so. The question you mention ('...how do you know that module is any good') is perhaps better answered with 'this is why' than 'this is who says so'.

I don't mean to discourage some sort of rating system. I think the idea of maintaining some standard evaluation is very important. I just think that only a list, just like only a mention of benefits, shortchanges those who would benefit from the review.

Maybe you could add links from each module you list to the appropriate module review where approving or disapproving monks could state their feelings in more detail?

Maybe you could add links from each module you list to the appropriate module review where approving or disapproving monks could state their feelings in more detail?
Schblam! Now that is a good idea. It'll take time but I'll start looking for the best threads about using/not using a module. Hooking to reviews was already planned, as well as trying to review a few myself. /me lobs yet another ++ on kudra.

--
$you = new YOU;
honk() if $you->love(perl)

Occasionally, it is useful to re-invent the wheel, so you can understand how wheels work. However, if you take someone else's money to create solutions for that person, it is only fair and ethical to create those solutions in the least expensive way to that person.