
Honestly the first step is making it easier (and efficient) to look at reverse dependency information plus download count. Those numbers are both manipulable, but can still yield some informative basic info. On Monday, November 4, 2013, Ben Gamari wrote:
Charlie Paul
javascript:;> writes: This has been proposed many times before, and each time everyone agrees that something like this is a good idea. However, like many good proposals, no one has put up code.
I also think that many Hackage improvements like this one were blocked on Hackage 2. Now since this is finally in the wild it should be a bit easier for people to pick up this sort of project.
Also in this particular case, the devil is in the details. How do ratings transfer between versions? How do you account for the effects of bitrot?
Certainly there are tricky details to work out but I think a lot of the work will be simply getting to the point where we can collect ratings and stuff them into a database. After this there would need to be some experimentation to work out the finer points you mention.
In my mind a rating would consist of some numeric rating (1-5, for instance, perhaps along multiple dimensions, e.g.: quality of documentation, type-safety of interface, performance) for a particular package. The user, date, and current version number should also be recorded.
A zeroth-order approach for accounting for bit-rot might be to use a simple temporally-weighted average. This would be simple to implement and might even produce marginally useful results. Even if not, it's a place to start.
Cheers,
- Ben