We are all Perl's ambassadors...
I wonder how many newbies in the whole history of Perl had their "llama" arrive from Amazon and shortly thereafter—in a fever pitch of excitement—managed to create a distribution they thought was the best thing since sliced bread and upload it to CPAN only to have their debut into our wonderful, loving community met by a CPAN rater. After which, naturally, they slowly backed out of the room, closed the door behind them, picked up their (PHP|Ruby|Python|Javascript) book and never coded a line of perl again...
Surely, no one can say but maybe—just maybe—we'd be better off with a system similar to Stack Overflow where a user has to have a certain number of points or special kind of badge (e.g. the Teacher, Ambassador, the "Empathy Lieutenant", the "brian d foy", etc) in order to leave a rating on someone's first distribution.
I dunno. It's worth a thought, because this whole thing just made me cringe...
I don't think enough rating happen period, let alone enough that it would be a good idea to limit any being left. 8 out of 8 people found that review helpful. I don't want inconsistent ratings where I have to figure out if the rating is due to a person's first distro before weighing in on the worth of the rating itself.
Not that I encourage leaving scathing ratings, but those ratings are there for people who use the modules, not for module authors to pat themselves on the back (thats just a bonus).
What I hate most about the system is that it doesn't offer me a way to get back into contact with the rater. Maybe they are mistaken about something essential, maybe I fixed a legitimate issue they reported. Maybe I'd like some clarification on an issue. It's all impossible.
The other thing I hate is that there is no way to look up all my ratings. I have to check for each of my distributions, and I have quite a few of them. That is rather unpractical. How am I supposed to know I've gotten a new rating?
I really like the ++ on Metacpan. It enforces the old adage "if you can't say anything nice, don't say anything at all". Might not be as useful for long-form reviews, but I know that if I see a module with a lot of ++ then I should look into it. A module without doesn't mean that its crap, it just means that I might look at it harder before choosing it.
This is a good thing. Newbies (and not so newbies) looking for modules see the cream rise to the top. New authors don't have to live down the scenario you mention. Long live ++
My guess is few. Every single one of these cases is lamentable, so the fact that there are relatively few is no great solace, but I do not see signs of an epidemic of chasing novices away in this manner. (There are other ways in which the Perl community seems a lot more hostile to novices, at least intermittently.)
However, when I think about it, I can’t claim to feel that CPAN Ratings ever became a really valuable resource. Most reviews are worthless, hostile or not. If CPAN Ratings were to get thrown away tomorrow, very little of the content would merit salvaging – even when I look at my own reviews, even when I look at the ones I put some effort into.
One obvious way to improve the situation is by letting CPANratings "time out", so old (and presumably fixed) comments get a reduced visibility.
I think cpanratings.perl.org can be made into a much better resource than it is today, but this would require some coding.
Having said that, who's managing/developing that site, and is the code public?
The site info page is missing, and it looks very much to be part of Perl NOC's services, although it's not published with the other perl.org sites found on https://github.com/perlorg .
Ooh, correction to myself; CPANRatings is on github!
https://github.com/perlorg/perlweb/tree/master/lib/CPANRatings
:D
Unfortunately I think this may simply be a very small example of how the Perl community is generally sometimes unfriendly to new developers. Before I get pounced on I'll give a shout out to all of of the great work done by people who are trying to change that (Gabor Szabo for one). It was also nice to see the Zero to Perl workshop last weekend at the Pittsburgh Perl Workshop (Dan Wright)!
The snobbish attitude though is not reserved just for new developers. I'm not defending poorly written and possibly ill conceived modules that folks might naively upload to CPAN. I believe there need to be gatekeepers that keep the quality of the repository high. But can't reviews like that (however correct it might be) be done in a less public way?
Maybe create some phase gates for new contributors? or create some kind of bar to get over before you can upload and even get rated in the first place? I know that flies in the face of a free and open environment that promotes a rich marketplace of ideas, but the alternative creates a repo that will look like my garage. Who has time to sift through that junk? Ask my wife...
How about different CPAN tiers from free and open to highly restrictive where only the best tasting tuna gets to be Starkist? Or is that what the ratings are supposed to do and my suggestion is dumb?
It's really nice to have those in the community who are learned and experienced, and Perl has a lot of really smart people that happen to be programmers, but my experience has been that Perl's luminaries are at times either odd, obnoxious or both odd and obnoxious. People with a high degree of technical skill and acumen in this community would be well served in taking a few Dale Carnegie courses and understanding as the title of this post suggests, "we are all Perl ambassadors".
Bottom line I think the reputation of Perl developers as (sometimes) being old, out of touch and eccentric is not completely unfair and it is reflected sometimes in public ways that makes us all cringe. I'm encouraged at posts that point it out try to create a better experience for all Perl developers.
prepan.org exists as a place where authors can upload code for critique, but it doesn't get used often enough. I wouldn't mind the requirement for a new author to make at least one submission to prepan.org first (and get some positive feedback) before their first PAUSE upload, but this is difficult to enforce without a lot of code that no one would want to write.