Hi Omer, There is such content in the haskell wiki. For example there is something here http://www.haskell.org/haskellwiki/Alternatives_and_extensions_for_libraries or http://www.haskell.org/haskellwiki/Applications_and_libraries/Mathematics. Perhaps there is (or should be) category in the haskell wiki similar to http://cran.r-project.org/web/views/ -- Adam On Mon, Nov 4, 2013 at 2:34 PM, Charlie Paul wrote:

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.

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?

On Monday, November 4, 2013, Ömer Sinan Ağacan wrote:

...

Hi all,

The following is happening to me very often:

- I decide to do some work in Haskell and decide to do it using a library. - I go to hackage and search for some keywords, find 10 different packages that does similar things. - In that moment, I need to apply some heuristics to decide which package to use. When my heuristics don't end up with only one package, I go to Haskell IRC channel and ask people there to which library to use.

My heuristic is something like:

- Look if author/maintainer is well-known people in Haskell community that are already produced very high-quality libraries. - Make sure it's currently maintained(updated at least in past few months) - Make sure it has Github repository. - some other stuff like that.

These heuristics are not working great, most of the time I'm ending up with IRC channel. So my proposal is this:

Why not have a rating/comment system for packages in hackage, so that when I need to find a library for something I can just look to comments or ratings to see how complete/well-implemented or what does it good for etc. (for example, we have several high quality xml parsers, some of them are for performance while some of them aiming for being easy to use)

Any comments would be appreciated.

--- Ömer Sinan Ağacan http://osa1.net _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

indeed! Now having those latter tabulations on hackage-server (or a hint for new haskellers about where to look) would be dandy i'm happilly over the "who does/likes what" hump myself, but it is valuable breadcrumbs for folks getting started. That said, asking via cafe / reddit / irc is also valuable because you can get peoples *opinions* about when two libraries are better in what use case. Not all problems can have a "canonically best tool" (as much as we'd like to strive for such tools) On Mon, Nov 4, 2013 at 5:04 PM, Dan Burton wrote:

And these steps are done!

* Download count is already there on Hackage, though it's relatively new so it may take some more time for these numbers to have real weight. * Revdeps are calculated and provided here: http://packdeps.haskellers.com/reverse

-- Dan Burton

On Mon, Nov 4, 2013 at 1:39 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

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 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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Integrating with github stars was what I imagined. I was thinking of maybe forking http://www.clojuresphere.com/ and trying to get it to work with haskell projects. It looks pretty viable since hackage appears to have downloads and haskellers.com looks like it has the dependency graph stuff already done. On Mon, Nov 4, 2013 at 2:45 PM, Simon Hengel wrote:

...

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.

I think a simple like/star mechanism is better than 5-star rating. Otherwise I, as a package author, feel tempted to make every user happy in fear of bad reviews (which may not necessarily lead to the most consistent or future proof API). Writing high-quality packages is not a popularity contest!

Or maybe just integrating GitHub stars is the way to go? If this leads to more stars for Haskell projects on GitHub, this would also help to promote Haskell in the large open source community!

Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi all, I must admit that I didn't read all responses in detail, but what I figured is that we just can't make everyone happy. I think what's need to be done is someone create a webpage that uses hackage pages, but adds ratings/comments/whatever to the same page so that we can at least discuss and rate packages and then wait for users to contribute. Of course the obvious question is why not do it myself? This is because I'm currently very busy and I can't spare my time for this. (also, I'm not very experienced in web stuff so it costs me more time than it costs someone more experienced in this stuff) --- Ömer Sinan Ağacan http://osa1.net 2013/11/5 Ben Gamari :

Curtis Gagliardi writes:

...

Integrating with github stars was what I imagined. I was thinking of maybe forking http://www.clojuresphere.com/ and trying to get it to work with haskell projects. It looks pretty viable since hackage appears to have downloads and haskellers.com looks like it has the dependency graph stuff already done.

I'm not sure about this. It seems like a rather indirect metric. I, for one, often use Github's star feature as more of a bookmark facility than anything else; a reminder to have a look at a project when there are free cycles. In my experience stars are rarely removed so there is really no way to account for stagnation. Instead, the metric turns into more of an indicator of project age than quality.

I'll admit that I may have been overcomplicating things in suggesting a multidimensional rating space, however.

Cheers,

- Ben

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

* Simon Hengel [2013-11-04 23:45:36+0100]

Or maybe just integrating GitHub stars is the way to go? If this leads to more stars for Haskell projects on GitHub, this would also help to promote Haskell in the large open source community!

That's a great idea! The github url can be derived by checking the homepage url and the source repository location for the right pattern. (At least one of these should point to github.) Then we just need to send a GET request at http://api.github.com/repos/:owner/:repo/stargazers and parse the JSON response. To avoid the delay while loading the page, I guess it's better to do this asynchronously on the client side. Anyone cares to write this piece of javascript? Roman

If we go with the star-based option, I don't see a serious reason not to add other sites as well. Though, if our goal is to get a rating of sorts from it, we would need to have factors for each hosting site, to account for varying user bases. On Mon, Nov 4, 2013 at 9:49 PM, Carter Schonwald

wrote:

would we also want to integrate bitbucket and darcsden analogues as well?

On Tue, Nov 5, 2013 at 12:35 AM, Roman Cheplyaka wrote:

...

* Simon Hengel [2013-11-04 23:45:36+0100]

...

Or maybe just integrating GitHub stars is the way to go? If this leads to more stars for Haskell projects on GitHub, this would also help to promote Haskell in the large open source community!

That's a great idea!

The github url can be derived by checking the homepage url and the source repository location for the right pattern. (At least one of these should point to github.)

Then we just need to send a GET request at

http://api.github.com/repos/:owner/:repo/stargazers

and parse the JSON response.

To avoid the delay while loading the page, I guess it's better to do this asynchronously on the client side.

Anyone cares to write this piece of javascript?

Roman

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, Nov 5, 2013 at 2:00 AM, Carter Schonwald

wrote:

honestly this is getting a bit over complex and silly! Should we also have google +1s and fb likes? What about # of blog posts? number of upvotes on on reddit? These are all great marketing metrics, but they dont help an end user understand which libs are *used*.

github stars are not a measure of quality, but more of wow/coolness factor.

lets try to stick to metrics that correspond to library usage and volume of developer activity

+1 -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1) comments have spam 2) the new process for getting the ACLs to a package where you're taking over is to email the libraries list and have the prior maintainer say "yes, Ketil is now maintainer" and/or you tell the libraries list "i couldn't reach the maintainer and its been X time period" and they'll giveyou push powers. email the libraries list and someone can help. or go on #hackage on IRC and ask On Wed, Nov 6, 2013 at 3:34 AM, Ketil Malde wrote:

...

lets try to stick to metrics that correspond to library usage and volume of developer activity

How about comments? Using e.g. disqus, it's a minimal administrative overhead, and provide user-contributed information without any artificial limitations or ambiguity.

For instance, I recently updated a library to work with newer compilers, and sent the patches to the previous maintainer. He suggested I just upload it to Hackage, but this is not allowed anymore, and I haven't heard from him since. If I could add a comment, I could at least point to my repository with an updated library version until this can be resolved.

-k -- If I haven't seen further, it is by standing in the footprints of giants

Carter Schonwald writes:

1) comments have spam 2) the new process for getting the ACLs to a package where you're

On the face of it, this looks like two entirely different things. But in a sense, I think they're not. As hackage is tightening up its administrative aspects, there are new protocols and due process to accomplish various things. However, one must be acutely aware of the cost of even small hurdles. I read somewhere (but couldn't find it again) that for every extra action required in a process, you lose a certain - fairly large - percentage of people. So when I fixed a few things in Data.Judy, I emailed the patch to Don S (the maintainer), who suggested I just take it over. I actually took the trouble of figuring out the process for transferring maintainership (which wasn't terribly obvious), and mailed him back. And haven't heard anything. And I don't blame him, he's likely busy with real work, and doesn't have any particular interest in an old orphaned library. Now, sure, I can find the correct subscription process for libraries@, subscribe, wait for confirmation, send a message applying for maintainership, wait for approval (or rejection, and appeal?), then upload the new version to hackage. Or I can install an IRC client, find out which IRC server I should use, go to #hackage, send a message, resend it at intervals, until somebody responds, wait for maintainership to be transferred, upload a new package. Well, guess what, this has little to no benefit to myself - and chances are, I'll postpone it to some lazy day in the future - probably never. After all, my version works for me. Anyway, I'm not saying the processes and protocols are wrong, perhaps the net benefit outweighs the costs. I have previously uploaded new versions to hackage after not getting a response from the maintainer for a few days - this was much to the annoyance of said maintainer, so there are clearly downsides to having a process that is too open. I think the important thing is that: a) we keep in mind that any hurdle, any restriction has a real and tangible cost, and thus the necessity of any restrictive feature should be very carefully considered b) if a restriction cannot be avoided, its impact should be made as small as possible (for instance, requests could be directed to a list that isn't subscribers only) So in the case of comments, yes, there is a risk of spam (although I do think disqus is doing a pretty good job of avoiding it). But it is also a very low-barrier way for users of sending feedback. Must we really sacrifice that? -k PS: I'd love user comments on anything I maintain, I wonder if I could sneak in some code in the .cabal file that will render a disqus comment field on hackage regardless? :-) -- If I haven't seen further, it is by standing in the footprints of giants

Hi. On 6 November 2013 08:34, Ketil Malde wrote:

...

lets try to stick to metrics that correspond to library usage and volume of developer activity

How about comments? Using e.g. disqus, it's a minimal administrative overhead, and provide user-contributed information without any artificial limitations or ambiguity.

Does anyone remember thishttp://www.reddit.com/r/haskell/comments/v8gvc/hackage_comments_a_simple_use... ? I had enabled the user script back then, and I still see disqus comments on hackage. The comments are not useful at all though, because they practically do not exist. (Very few people used the user script anyway.) -- Ozgur Akgun