XP for modules

One of the most time consuming thing when facing a perl task is to find a module and decide whether it's the right thing. Actually it's already pretty hard to decide whether a module is stable enough(there are many modules staying at version 0.24.) There have been some discussions here about how to rate modules (e.g., Rating System for Modules). I think it's more useful to know what modules people are actually using, instead of their opinion on something they've never used. I'd suggest we use the same XP idea, that is, every registered user can enter the modules they're using (say, just a text box for entering: CGI, DBI, Data::Dumper, etc.), PM makes sure no duplicates from the same user. We can then make a page listing the usage stats, rather than the download stats from some other sites. When the time comes for me to pick a module, say for xml processing, I can see which one other people are using, indicating not only preference but also stability.

We can probably add some XP related ideas: give more weights for people with more XP, even restricting how many modules one can enter depending on XP (sounds bad, but actually it forces people to pick their best).

Comment on XP for modules

Replies are listed 'Best First'.
Re: XP for modules by eserte (Deacon) on Aug 16, 2004 at 17:57 UTC
Are you aware of cpanratings.perl.org?	[reply]
Re^2: XP for modules by johnnywang (Priest) on Aug 16, 2004 at 18:04 UTC
no, I wasn't aware of that, thanks for the pointer. Does one need to write a review to be counted? I'd say a simple declaration "I'm using XXX" is very good indication, and it's easy for the user to enter. And also there can be huge differences between modules that are both rated as 5 stars, a usage number is probably a better indication.	[reply]
Re^3: XP for modules by stvn (Monsignor) on Aug 16, 2004 at 18:14 UTC
I'd say a simple declaration "I'm using XXX" is very good indication, and it's easy for the user to enter But not very informative. What are you using it for? On what platform? etc etc etc. Take the time, and tell them why you like it, and whats so good about it. And also there can be huge differences between modules that are both rated as 5 stars, a usage number is probably a better indication. Another reason why you should be more descriptive in your rating. Why did you rate it five stars? Personally, I would rather hear specifics, than see numbers. -stvn	[reply]
Re^4: XP for modules by Joost (Canon) on Aug 16, 2004 at 19:32 UTC
Re: XP for modules by stvn (Monsignor) on Aug 16, 2004 at 18:09 UTC
I am not sure what is wrong with http://cpanratings.perl.org/? Sure its a little rough around the edges and could use some nice report-ish screens to make it easier to browse, but its already integrated into http://www.search.cpan.org which is a major step. It has a pretty decent amount of reviews on it, and they are growing every day. I check in regularly and there is at least 1-5 new reviews a day. Actually it's already pretty hard to decide whether a module is stable enough(there are many modules staying at version 0.24.) Since when does a version number have anything to do with stability? It is a falsehood perpetrated by proprietary software, that 1.0 == stable, we all know that is not true. Stability can also is somewhat conditional on platform as well, what runs great on my Mac OS X 10.3.5 machine, may run really badly on the WinXP machine next to me (for some odd obscure deep-perl reason the developer doesnt know about). Stability should be proven in the test suite, and demostrated by running `make test` during the intsall process. Even then, there is no way to be sure, but hey thats software :-) I think it's more useful to know what modules people are actually using, instead of their opinion on something they've never used. Why do you say that? I may have done a thorough analysis on a module (code and all) and decided it was not for me for various reasons. Are my reasons not valid because I didnt actually use it? I could have determined a particular module would not work in mod_perl, while others happily use it for vanilla CGI. IMO, that is valuable information. I'd suggest we use the same XP idea, that is, every registered user can enter the modules they're using (say, just a text box for entering: CGI, DBI, Data::Dumper, etc.), PM makes sure no duplicates from the same user. This is an idea, but whats to stop me from XP-whoring and creating fake users who think my module is gods gift to perl? We can probably add some XP related ideas: give more weights for people with more XP, even restricting how many modules one can enter depending on XP (sounds bad, but actually it forces people to pick their best). I think this is a really bad idea. I think the U.S. presidential elections of 2000 have shown us that bad things can happen when some peoples vote count more than others. It does not work that way on nodes, so I don't see any reason why it should work that way for this. Seriously though, I think if you really feel strongly about this, you should get involved over at http://cpanratings.perl.org/. They have a to-do list on their about page, and I am sure they would appreciate the help. -stvn	[reply] [d/l]
Re: XP for modules by tachyon (Chancellor) on Aug 16, 2004 at 22:39 UTC
Read the changelog first, tests next, code/docs last. Many hackers are modest and start numbering at 0.01 once they are happy it is good enough to release. IMHO a first release at 1.00 is almost certainly a bad sign. cheers tachyon	[reply]
Re^2: XP for modules by eserte (Deacon) on Aug 17, 2004 at 08:19 UTC
On occasion I start with 1.01, mostly if using RCS for versioning and using the `$VERSION = sprintf("%d.%02d", q$Revision: 1.1 $ =~ /(\d+)\.(\d+)/);` style of setting the version. I know, I could somewhere add a "-1" :-)	[reply] [d/l]
Re^3: XP for modules by kappa (Chaplain) on Aug 22, 2004 at 08:26 UTC
Offtopic, achtung. I think it is a bad practice to base software versions on file revisions. This is a question of «granularity» — whether you really want to have a 1.108 version in two months of hard work or hesitate to commit a small whitespace-only code style fix to your source because it's just too little a change to justify for a new version. This is Bad Thing(TM) to say nothing of having multiple (for large values of «multiple») equally important files with totally different revision histories inside one software package with one version number.	[reply]