[development] Rating module quality

[Darrel O'Pry]

On Fri, 2006-01-27 at 08:03 -0600, Jeff Eaton wrote:
> > My problem with the  
> > VotingAPI module is this: it addresses an _extremely_ _trivial_  
> > problem.  It saves us 10 lines of code and 20 minutes of  
> > implementation work at the cost of an extra layer of code  
> > (performance cost), an additional module to monitor/track/audit  
> > before upgrades (extra dependencies, time overhead) and install  
> > (usability).  Maybe the added value becomes clear after I spent some  
> > more time looking at it but right now, I prefer to go with a single,  
> > dedicated module.
> 
> I can definitely understand those objections. I think 10 lines/20
> minutes is a bit of an understatement considering the more complex
> voting scenerios it's capable of handling, but the real benefit of it is
> the potential for cross-module consistency and sharing of voting data.
> 
> Dedicated voting modules have a strong tendency to do the same thing in
> a dozen different ways. Some in contrib have a great UI, others
> calculate the statistics a given user needs, others are capable of
> working with the moderation queue. None work together. If I want to
> moderate nodes and comments, track the most popular pictures, and allow
> users to rate downloads on my site, I have to install four separate
> modules with four wildly different UIs and four completely different
> silos of data.
> 
> The same objections could be raised about taxonomy: why use a complex,
> topheavy API when all we need to do is assign a 'category' to a node?
> I'll be the first to say that my skills are not equal to those who
> crafted Taxonomy.module, and the VotingAPI is a lot less mature. I do
> think that the need for a consistent way of storing and accessing voting
> data across modules will enable a broader range of tools for working
> with it, in the same way that we have loads of taxonomy-related helper
> modules. Frustration with those silos of voting data is what prompted me
> to dive into the project in the first place.
> 
> Of course, whether drupal.org and project.module is the correct place to
> champion this is another question entirely. If folks feel it would be a
> bad use of resources or would add unecessary complexity to the site,
> that's that.
> 
> --Jeff


Further use cases could be found in machine learning and data mining
where a consistent method for accessing data regarding nodes and how
users have rated them, them cms has rated them, or any other simple
metrics stored with the voting api, can be beneficial.

being able to get a list of data silos and define a set of rules for
gleaning information from them could be very useful in a machine
learning or datamining ui...  

just one place it could be useful.