> 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
