Hi all, I though I'd write a wrap up for the Rating discussion we started 2 weeks ago. Please post correction if I missinterpreted something.
CPAN Rating: - Most were positive to the changes I and other proposed. only two people wrote that it wouldn't get done before even discussing it (a world breaking record) - We all agreed that the Rating system we have today was good enough (with some people suggesting ameliorations) but that it was not used or visible enough.If the current system was to be more widely used, most would feel satisfied. Eric would have like to see a "Told me to (TM) rate the modules" - We have troubles finding out who is holding onto the code, were it is and how to change it. Some suggested starting another site to try but it was not taken as a very good idea (though still an idea) - The quality of the documentation for CPAN modules was either find to be lacking or people just didn't care. It seems to me that all would gladely have more/better documentation anyhow. - An alternative "Selected" CPAN was named. Something in the same spirit as a moderated mailing list. Other subjects we talked about: -Module dependencies; should be listed or automatically generated. -Auto-generated Readme: we questioned the fact of having a completely useless auto generated Readme or a competely useless 0 bytes Readme. -"PerlForge" was named and some ideas germinated from it, ex: the possibility to discuss a module without having to subscribe, providing a web page for the module, etc.. Some thought that there was too much dependency on SourceForge. I hope this wraps it up. I still don't know where/how/when to help to get some changes in place. Cheers, Nadim. "Khemir Nadim" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi all, > > I can live with buggy modules (I write some of them). > > I can live with non existant maintainers. > > I can almost live with idiots that think releasing open source code means > that they take no responsibility over it or that they are GOD. > > I can live with 13 years old module authors with whom it's impossible to > have an adult conversation. > > I can live with pedantic worthless modules that get big coverage while > having very little use (IMHO). > > But I can't live anymore with the low quality and release process that CPAN > has!!! > > Modules are born, grow, die but not all are born equal! > > How many CPAN modules are properly documented? how many are not documented > or have documentation that doesn't give a bloody clue about what it is for? > > I won't talk about tests, maintenance, etc ... because I suck too and I'd > very much like someone to enlight me by telling me that it's wrong and maybe > how to do it right. > > I look at new modules almost everyday, I mirror CPAN just to have it close > in case of network failure. I sometimes rate modules but most often when I > think they are good (I won't talk about the modules having a single rating, > 5 stars, written by the author ;-) > > What I propose is: > > - Introduce negative rating, ex: the documentation sucks, minus five start. > - Rating should be show by search.cpan.org, anywhere a module name > (including "recent") is show as well as how many have rated > > I would of course prefer not letting badly documented or tested modules get > into CPAN at all but that would certainly eliminate 99,99% of the modules > (including mine) and hurt joe hacker little ego (which is hugely bigger than > his module documentation). > > Now, I'm asking for someone else to do the job (I don't even know who he is) > but I'd gladely help if I can, I'd definitively rate more. > > I may just need to become as blazé as CPAN users and just accept the sate of > things but I'd rather not. > > > I like very much the perl advant calender (a system very popular with my > kids) and I wouldn't like to cut grass under their feet but couldn't we test > a module a week and rate it. That would make 50 "seriously" rated modules a > year. it's more than the total amount of modules I use and it might help > people getting started with perl (or the modules) > > Cheers, Nadim. > > PS: I know this kind of discussion comes back again and again. If you don't > have an input about what I propose we do, please don't bother answering > about why I want to do it or do it privately. > > >