Making decisions

Manuel M T Chakravarty chak at cse.unsw.edu.au
Tue May 28 02:46:51 CEST 2013


I agree with Ian. Voting has no meaning if the constituency is not properly defined.

A process in which a maintainer is in charge and makes the decision of whether a proposal has meaningful widespread support and is technically sound has served us well in the past. As Ian wrote,

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


I don't care whether we call the person in charge maintainer, tsar, secretary, or something else. The point is that there is one person who makes the final decision, but who listens to and is held responsible by the community as a whole. (Instead of one person, it may be a small closely cooperating group of people for a large artefact.)

Manuel


Ian Lynagh <ian at well-typed.com>:
> On Sat, May 25, 2013 at 10:19:42AM -0400, Ryan Newton wrote:
>> What was the sample size on the 85% vote?
> 
> I don't know, but who is it sampling?
> 
> [begin over-exaggerated strawmen - don't take the below personally!]
> 
> Are we getting votes mostly from people who have been programming
> Haskell in their sleep for a decade, and who therefore are very involved
> with the language (so are subscribed to libraries@), but have forgotten
> how steep the slope to learning it is and are unaware that the
> generalisations they want may be raising the barrier to entry to an
> infeasibly high level?
> 
> Or have all the long-timers gotten bored of the libraries list, and the
> votes are coming from an influx of new users who only started learning
> Haskell last month, who just joined the list, don't really know what
> mapM does but thinks a generalisation sounds cool so are voting for it?
> 
> Or have I been campaigning my friends to vote for the option I think
> best? Or signing up for Yahoo accounts to cut out the middle man?
> 
> [end strawmen]
> 
> As a maintainer, a plain +1 or -1 from someone I don't know really
> doesn't tell me much. If the majority agree with my opinion, then it's
> fairly easy to take it as support, but if they disagree with my opinion
> then I don't know why (Have they misunderstood the implications? Has the
> selection bias meant that they weighted the different factors
> differently to the majority? Are they voting for what would be best for
> them, or what they think would be best for the whole community? Or could
> it be that I'm actually wrong!?). By contrast, Ivan's mail here:
>    http://www.haskell.org/pipermail/libraries/2013-May/019988.html
> gives me a lot more insight.
> 
> Unfortunately I'm struggling to think of changes to the proces that are
> strict improvments. The problem is that we have a mixture of simple
> proposals, where someone proposes we do something and most people agree
> that we should or shouldn't, and complex proposals, where different
> people think we should do different things and there are various
> arguments and counter arguments to consider. This wouldn't be so bad,
> except that it's not always clear at the outset whether a given proposal
> will turn out to be simple or complex (if we knew in advance, we could
> require justification for "votes" on complex proposals, but not for
> simple "should we add this obvious missing combinator" proposals).
> 
>> Is there a website for keeping
>> track of these persistently?
> 
> If a ticket is filed then it should summarise the opinions, but not all
> proposals have tickets filed.
> 
> 
> Thanks
> Ian
> -- 
> Ian Lynagh, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries




More information about the Libraries mailing list