Re: Measuring water quality of the CPAN river

> I think we could be considering a number of dimensions.  Brainstorming:
> 
> * fails tests now – i.e. blocking automated dep installations – this is your existing metric
> * possibly an OS-specific variation of the above
> * stability over time – possibly your existing metric, but taking last "N" stable releases or all stable releases in last "N” years

Related to this: stability of interface over time. We don’t really have metadata that can be used to track this automatically though.

> * something looking at bug queues – possibly open tickets proportional to number of downriver dependents; possibly looking at open vs close ratios

One of the (rare) reasons I like RT over github is that bugs can be classified in a standard way. The downside is that not many people do. If we could be sure that an issue were a bug and not a wishlist item, typo in the doc, etc, then this would be a good thing to factor in.

Prompted by Kent’s response: could also factor in test coverage. It would be great if we had cpancover.com <http://cpancover.com/> evolved to a CPAN Testers type service, so we could have coverage smokers giving us coverage data on the mainstream operating systems and “supported” versions of Perl.

A couple of your points could be combined: only require a developer release if (enough) code was changed to warrant it.

Neil