Re: [Haskell-cafe] Package documentation complaints -- and a suggestion

On Tue, Oct 25, 2011 at 2:17 AM, Ketil Malde wrote:

Ivan Lazar Miljenovic writes:

...

Right, but first we need to define what all those terms _mean_... and it's no good saying your package is "stable" if you change the API in a large-scale fashion every release.

I think there are better criteria to use, like:

- do exported definition have Haddock comments? - does the package have an automated test suite? - is the package used by other packages? - ...by different authors?

These signals might not apply if the package is primarily a binary.

- has the package been recently updated?

This one is also tricky. A stable package is a good thing! On the other hand, a package that is broken by a new version of ghc and then takes months to be updated is not so great. What matters is maintainer responsiveness and that's not so easily measurable. I feel like use-derived signals are safer. E.g. number of downloads, user ratings, user reviews, depending packages. But that stuff obviously goes in a separate section, not a .cabal field. With ratings or reviews it's tricky because you want to make sure they apply to specific versions, so obsolete complaints about a fixed bug don't hang around forever.