ratings

Random Ideas in no particular order, simply for consumption.

---

Recognised Users

Being able to log in and associate actions easily to discrete users makes many diagnostic features possible. Any feature that needs unique user identification ideally needs to lower the boundary to entry as low as possible.

• OpenID based login
  Seems to be a popular way to do this.

• Speedy Registration Some service that allows you to create a user account really fast, few questions asked, and no need to verify your email account or anything to start using the registered user features.

• Delayed Association Users can associate account with an OpenID account or an Email address at a later date, however, no 2 users can exist with the same association data, and your actions don't bear weight until you confirm the association. Association can be changed at a later date, and at such a time, your actions are retroactively de-weighted until you re-confirm your account ( Or in the case of open-id, authorise the account with the vendor )

---

Review Request Process

Provide a link on all modules that produce a request for review.

This associates the Module at its current version with 1 user.

Then graphs of user interest and review requests can be created, and modules with demand for review can be easily located.

---

Review Time Correlation

To me, the when of the review is as important as the number or reviews and their value.

Something may look good initially to people, and they give it a good recommendation, but later, people may discover long term flaws with the module and the reputation can scale likewise.

Then instead of simply having a "4.5 stars average" produced by an aggregate of 10 past reviews and 1 current review, you can get a trend signifying that recently, the module has fallen into disrepute, or superseded by something better.

---

Review Components

A Simple 5 star analysis with a short comment is only so helpful, people have their own standards by which they rate things, and 5 stars can mean "I laughed, great name" or "This module is very good at what it does and the syntax is optimal for it".

Hence, its more advantageous to divide the review into smaller parts, not all parts need to be filled, they are of course optional, but more parts are more helpful.

• Module Code Style :
  • Is the code well indented
  • Is the code logical and well readable
  • Is the code utilising modern development practices.
  • Is the code reusing other modules where possible and not reinventing wheels.
• Documentation :
  • Is the documentation suffice that it accurately explains all of the modules functions
  • Is the documentation clear and easy to understand
  • Could there be additions to make documentation better
• Module Performance:
  • Does the module do everything it says on the box
  • Are there things that are logically in the scope of what this module should do that it doesn't yet do
  • Are there strange edge cases and weird things you need to do to use this module
• Module Use:
  • Is the module straight forward and easy to use
  • Are the error conditions well handled and well diagnosed
• Module Effectiveness:
  • Is this module effective in memory / cpu utilisation for the tasks it does
  • Are there other existing things on CPAN which do everything this module does, but better.