Making decisions

[Ian Lynagh]

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/