in reply to Re: Social CPAN : Finding the best and most popular modules
in thread Social CPAN : Finding the best and most popular modules

On several occasions I've been motivated to post a review or to vote on a review. In every case, my motivation was unable to survive the roadblocks of the "mechanism". I don't recall what the specific road blocks were. I just recall more than one way that the implementation showed me an interface to invite me to do something and then changed its mind and denied me. Having tried more than once to jump through the hoops to satisfy its login (and perhaps other) requirements, I have yet to succeed.

I don't even recall what the requirements were, but had they actually been "minimal", I'm sure I would have met them (having met registration requirements before). I won't dispute that the requirements are likely "small", but they have certainly been enough to stop me despite multiple attempts.

Perhaps I'm just an abnormally lazy or picky person, or something. Or perhaps the implementation has some room for improvement. I find requiring registration to add a review for a module to be a rather disappointing statement on the implementors' view of their fellow humans. *shrug*

- tye        

  • Comment on Re^2: Social CPAN : Finding the best and most popular modules (thwart)

Replies are listed 'Best First'.
Re^3: Social CPAN : Finding the best and most popular modules (thwart)
by GrandFather (Saint) on Jan 20, 2009 at 03:21 UTC

    We are Perl programmers - we are supposed to be lazy.

    I've had exactly the same experience and remember just as much about the roadblocks. *sigh*


    Perl's payment curve coincides with its learning curve.
      This would then argue that the current system should be amended. That still doesn't argue for an entirely new system. Have you made the suggestions to the appropriate people?

        I disagree, the current system is just too inflexible and static. To give an idea, lets look at Module::Build. The rating system gives a 3 star. However, the ratings apply to the module over the course of 3+ years which has had many changes.

        If someone complains about a bug from 3 years ago is that rating properly reflective of the utility of the current module? I don't think so.

        On the other hand, should we reset the ratings for a particular module everytime they release a new version? I don't that either.

        I would rather see a way of inventorying of modules that get used in scripts or modules that using cpan modules, but they, themselves are not on cpan. It would give an idea of which modules are actually being used by developers. It would not be perfect, but seeing what people are actually using would be incredibly useful.