[development] Rating module quality

[Jeff Eaton]

> This usually turns into a popularity contest, which 
> eventually reflects the same information as #downloads. imho, 
> absolute numbers have little meaning: importance of a module 
> is a factor of it's
> 
> 1) usefulness
> 2) code quality (lack of bugs, buggy modules = bad reputation 
> for drupal)
> 3) maintenance quality (support in future drupal versions?)
>
> while (1) can be gauged from #downloads / popularity, the latter 2 can
> (possibly) be estimated from project.module stats.
> 
> Actually, I wouldn't mind having a small paragraph giving 
> devel statistics for each module, like
> 
> #open confirmed bugs
> #critical bugs in the past month (open / solved)
> #feature requests handled
> #commits in the last 4 months


I disagree that rating and download numbers will result in similar
values. There are large number of modules I've downloaded that I would
rate poorly in several of those categories -- the fact that I've
*investigated* something should not be taken as an indication of my
*conclusion* about it.

While extrapolaying from project.module could be useful, I'm not sure
that it would result in any more accuracy. It also opens up a lot of
arguments about what 'the right metric' is, when we could simply open up
some basic voting/rating capabilities and depend on the community to do
the work. It could easily penalize popular modules that churn through a
lot of bugs and fixes while making little-used modules appear more
stable even though they aren't.

Again, I don't want to press for using *my* solution to this, I just
think that pure download stats and issue tracker/commit stats won't
result in the information that Joe User wants to see when he's skimming
over the module list.

--Jeff