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