Personally I think a persistent, open poll has a higher chance of capturing a wide participation. Short fuse votes will exacerbate sampling bias.
I'm a refugee from Scheme-istan. Most important to me are not the specific technical outcomes, but that a sense of community cohesiveness survives, avoiding, for example the post-R6RS affair (divergent R7Rs, Racket split).
Not that that could happen easily with Haskell.
Thank goodness for a single dominant implementation ;). To you, GHC!
On Saturday, May 25, 2013, Ian Lynagh wrote:
>
> responsible for maintenance, can make decisions, but is still bound
> by the votes on library proposals.
Just to clarify the current libraries process:
A few people have used the word "vote", but we don't vote on library
proposals. If we wanted to change that then we would first need to
answer the question of who was elligible to vote.
There is some clarification on this in
http://www.haskell.org/haskellwiki/Library_submissions
For example:
Proposals that have widespread support, and are accompanied by
patches (preferably with tests and documentation), should normally
be accepted by the maintainer.
It is up to the maintainer to decide what "widespread" means; in
particular, it does not always mean "a majority of those who
responded". The majority-responder story is vulnerable to selection
bias; e.g. 7 people (out of a client base of hundreds) say "add this
function" but the maintainer thinks it will make the interface
incrementally more complicated without sufficient benefit.
and:
The maintainer still has ultimate say in what changes are made, but
the community should have the opportunity to comment on changes.
However, unanimity (or even a majority) is not required.
Thanks
Ian
--
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries