[Haskell-cafe] The participation threshold (was Re: idea: ratings (or maybe comments) for packages in hackage)

[Ketil Malde]

Carter Schonwald <carter.schonwald at gmail.com> 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