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

[Evan Laforge]

On Tue, Oct 25, 2011 at 2:17 AM, Ketil Malde <ketil at malde.org> wrote:
> Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> 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.