Simon Peyton-Jones | 23 May 09:48 2013
Picon

Making decisions

This "burning bridges" thread has really got us going!  

I'm a bit concerned, though, that we don't have an effective mechanism for resolving such debates.  If
everyone feels that they have a vote, perhaps, but only one among many, then one feels either mandated or
indeed willing to invest the extra cycles to summarise pros and cons based on feedback, crisply
articulate alternatives, and so on.   And, worse still, no one feels mandated to actually decide anything.  
That's fine when there's a clear consensus; not so fine when there isn't, as here.  Several people on the
"Burning bridges" thread have commented on the interminable nature of the debate.

Our general procedures for library changes are described here:
http://www.haskell.org/haskellwiki/Library_submissions.  For specialised libraries (eg MD5
checksum, or even containers) the situation is clear: the author or current maintainer decides.

But for the basic core libraries, whose influence is pervasive, matters are murkier.  Looking at
http://www.haskell.org/haskellwiki/Library_submissions#The_Core_Libraries we see that many are
maintained by "GHC HQ".  But the plain fact is that GHC HQ is not up to the task, especially now that Simon M has
moved on to Facebook.   To be absolutely explicit, I'm worried that decision making may get stuck because I
don't have the capacity to participate, lead, drive, propose, and ultimately make a decision.  So there's
a decision-making vacuum for the "GHC HQ" libraries.  If that's the case, then the best thing is for GHC HQ to
get out of the way!

Is that what others feel, or are you all happy?   My proposal would be to form a Library Tsars committee, that
* Takes ownership of the "GHC HQ" libraries
* Also owns any global library issues; ones that can't be resolved
    by a single maintainer

Like any maintainer the Library Tsars would be expected to follow the guidance on the wiki
http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_maintainers
(responsiveness, consultation, etc).  But they could actually decide things. 

(Continue reading)

Edward Kmett | 23 May 09:58 2013
Picon

Re: Making decisions

I for one strongly support the creation of such a committee.


On Thu, May 23, 2013 at 3:48 AM, Simon Peyton-Jones <simonpj <at> microsoft.com> wrote:
This "burning bridges" thread has really got us going!

I'm a bit concerned, though, that we don't have an effective mechanism for resolving such debates.  If everyone feels that they have a vote, perhaps, but only one among many, then one feels either mandated or indeed willing to invest the extra cycles to summarise pros and cons based on feedback, crisply articulate alternatives, and so on.   And, worse still, no one feels mandated to actually decide anything.   That's fine when there's a clear consensus; not so fine when there isn't, as here.  Several people on the "Burning bridges" thread have commented on the interminable nature of the debate.

Our general procedures for library changes are described here: http://www.haskell.org/haskellwiki/Library_submissions.  For specialised libraries (eg MD5 checksum, or even containers) the situation is clear: the author or current maintainer decides.

But for the basic core libraries, whose influence is pervasive, matters are murkier.  Looking at http://www.haskell.org/haskellwiki/Library_submissions#The_Core_Libraries we see that many are maintained by "GHC HQ".  But the plain fact is that GHC HQ is not up to the task, especially now that Simon M has moved on to Facebook.   To be absolutely explicit, I'm worried that decision making may get stuck because I don't have the capacity to participate, lead, drive, propose, and ultimately make a decision.  So there's a decision-making vacuum for the "GHC HQ" libraries.  If that's the case, then the best thing is for GHC HQ to get out of the way!

Is that what others feel, or are you all happy?   My proposal would be to form a Library Tsars committee, that
* Takes ownership of the "GHC HQ" libraries
* Also owns any global library issues; ones that can't be resolved
    by a single maintainer

Like any maintainer the Library Tsars would be expected to follow the guidance on the wiki http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_maintainers (responsiveness, consultation, etc).  But they could actually decide things.

One other thing.  I'd certainly consider well-argued proposals for changing GHC to better support backward compatibility in the face of library change.  One such proposal was the "class alias" story, but that was a big, complex general mechanism (and arguably big benefits).  Because of its complexity it is currently stalled.  But there may be other much more modest things we could do to help; the question about ad-hoc deprecation of Monad without Functor is a  small, highly-specific, ad-hoc idea.

Simon
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Shachaf Ben-Kiki | 23 May 10:13 2013
Picon

Re: Making decisions

On Thu, May 23, 2013 at 3:48 AM, Simon Peyton-Jones
<simonpj <at> microsoft.com> wrote:
> Is that what others feel, or are you all happy?   My proposal would be to form a Library Tsars committee, that
> * Takes ownership of the "GHC HQ" libraries
> * Also owns any global library issues; ones that can't be resolved
>     by a single maintainer
>
> Like any maintainer the Library Tsars would be expected to follow the guidance on the wiki
http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_maintainers
(responsiveness, consultation, etc).  But they could actually decide things.

+1
Andreas Abel | 23 May 13:39 2013
Picon

Re: Making decisions

On 23.05.2013 10:13, Shachaf Ben-Kiki wrote:
> On Thu, May 23, 2013 at 3:48 AM, Simon Peyton-Jones
> <simonpj <at> microsoft.com> wrote:
>> Is that what others feel, or are you all happy?   My proposal would be to form a Library Tsars committee, that
>> * Takes ownership of the "GHC HQ" libraries
>> * Also owns any global library issues; ones that can't be resolved
>>      by a single maintainer
>>
>> Like any maintainer the Library Tsars would be expected to follow the guidance on the wiki
http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_maintainers
(responsiveness, consultation, etc).  But they could actually decide things.
>
> +1

+1

The library Tsars should have some 'executive' capabilities, i.e., some 
resources to actually implement small to medium changes which they 
approve.  Of course, implementation can be delegated, but the Tsars 
should be a driving force.

--

-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel <at> ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
Henning Thielemann | 23 May 10:19 2013
Picon

Re: Making decisions


On Thu, 23 May 2013, Simon Peyton-Jones wrote:

>  So there's a decision-making vacuum for the "GHC HQ" libraries.  If 
> that's the case, then the best thing is for GHC HQ to get out of the 
> way!

In the special case of adding Traversable and Foldable to Prelude, it 
worries me that it is about changing Prelude. I am more relaxed about 
changes to 'base'. However, since Prelude is part of the Haskell 98 and 
Haskell 2010 specification, I thought that changing Prelude could also be 
decided by the Haskell Prime committee.
Edward Kmett | 23 May 10:23 2013
Picon

Re: Making decisions

Note, the haskell98 and haskell2010 packages would be unaffected by this proposal as it stands.

The (repeatedly raised in this thread) Applicative as a superclass of Monad situation on the other hand, sadly does impact them.

-Edward


On Thu, May 23, 2013 at 4:19 AM, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:

On Thu, 23 May 2013, Simon Peyton-Jones wrote:

 So there's a decision-making vacuum for the "GHC HQ" libraries.  If that's the case, then the best thing is for GHC HQ to get out of the way!

In the special case of adding Traversable and Foldable to Prelude, it worries me that it is about changing Prelude. I am more relaxed about changes to 'base'. However, since Prelude is part of the Haskell 98 and Haskell 2010 specification, I thought that changing Prelude could also be decided by the Haskell Prime committee.


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ian Lynagh | 23 May 14:14 2013

Re: Making decisions

On Thu, May 23, 2013 at 07:48:22AM +0000, Simon Peyton-Jones wrote:
> This "burning bridges" thread has really got us going!  
> 
> I'm a bit concerned, though, that we don't have an effective mechanism for resolving such debates.  If
everyone feels that they have a vote, perhaps, but only one among many, then one feels either mandated or
indeed willing to invest the extra cycles to summarise pros and cons based on feedback, crisply
articulate alternatives, and so on.   And, worse still, no one feels mandated to actually decide anything.

FWIW, the current library process
    http://www.haskell.org/haskellwiki/Library_submissions
actually requires that the proposer evaluates the result:
    At the end of the discussion period, summarise your understanding of
    the consensus (or lack thereof), including a link to the thread in
    the mailing list archives, and send the summary to the maintainer
    for decision.
    [...]
    If the decision is positive, create a ticket on the GHC trac.

If someone does that, then I generally do a quick skim of the list
archives and then apply the change. I don't think I've ever rejected a
proposal that got as far as a ticket, but many don't get that far.

I have no objections to a committee doing the evaluation (or the
execution, for that matter) instead, though.

Thanks
Ian
--

-- 
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
amindfv | 23 May 15:05 2013
Picon

Re: Making decisions

I enjoy a good Tsar as much as the next man, but I think I'm actually against this proposal, at least for
deciding the Foldable/Traversable issue.

From my perspective, it hasn't been an endless amount of discussion with no end in sight. At least on the
libraries list, there's been healthy discussion, some minds have been changed, votes were cast, and
generalizing the prelude won by a landslide.

These changes (which I'm for, by the way) have implications for every Haskell programmer, and everyone
teaching Haskell. They also put lots of information in RWH and LYAH out-of-date. We should expect and
embrace constructive discussion.

I'm not saying we shouldn't have library Tsars, but in the case of Foldable/Traversable, I think democracy
has served us well so far.

Tom

El May 23, 2013, a las 3:48 AM, Simon Peyton-Jones <simonpj <at> microsoft.com> escribió:

> This "burning bridges" thread has really got us going!  
> 
> I'm a bit concerned, though, that we don't have an effective mechanism for resolving such debates.  If
everyone feels that they have a vote, perhaps, but only one among many, then one feels either mandated or
indeed willing to invest the extra cycles to summarise pros and cons based on feedback, crisply
articulate alternatives, and so on.   And, worse still, no one feels mandated to actually decide anything.  
That's fine when there's a clear consensus; not so fine when there isn't, as here.  Several people on the
"Burning bridges" thread have commented on the interminable nature of the debate.
> 
> Our general procedures for library changes are described here:
http://www.haskell.org/haskellwiki/Library_submissions.  For specialised libraries (eg MD5
checksum, or even containers) the situation is clear: the author or current maintainer decides.
> 
> But for the basic core libraries, whose influence is pervasive, matters are murkier.  Looking at
http://www.haskell.org/haskellwiki/Library_submissions#The_Core_Libraries we see that many are
maintained by "GHC HQ".  But the plain fact is that GHC HQ is not up to the task, especially now that Simon M has
moved on to Facebook.   To be absolutely explicit, I'm worried that decision making may get stuck because I
don't have the capacity to participate, lead, drive, propose, and ultimately make a decision.  So there's
a decision-making vacuum for the "GHC HQ" libraries.  If that's the case, then the best thing is for GHC HQ to
get out of the way!
> 
> Is that what others feel, or are you all happy?   My proposal would be to form a Library Tsars committee, that
> * Takes ownership of the "GHC HQ" libraries
> * Also owns any global library issues; ones that can't be resolved
>    by a single maintainer
> 
> Like any maintainer the Library Tsars would be expected to follow the guidance on the wiki
http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_maintainers
(responsiveness, consultation, etc).  But they could actually decide things. 
> 
> One other thing.  I'd certainly consider well-argued proposals for changing GHC to better support
backward compatibility in the face of library change.  One such proposal was the "class alias" story, but
that was a big, complex general mechanism (and arguably big benefits).  Because of its complexity it is
currently stalled.  But there may be other much more modest things we could do to help; the question about
ad-hoc deprecation of Monad without Functor is a  small, highly-specific, ad-hoc idea.
> 
> Simon
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Simon Peyton-Jones | 23 May 15:14 2013
Picon

RE: Making decisions

I wasn't suggesting arbitrary decisions ignoring opinions.  On reflection "Tsar" carries the wrong
connotations.  How about "Core libraries facilitating group"?   Or something less dull-sounding, but
with the same sense.   I like democracy as much as the next person.  But someone has to drive the process or it
wanders into the long grass.

Simon

| -----Original Message-----
| From: amindfv <at> gmail.com [mailto:amindfv <at> gmail.com]
| Sent: 23 May 2013 14:06
| To: Simon Peyton-Jones
| Cc: libraries <at> haskell.org; Simon Peyton-Jones
| Subject: Re: Making decisions
| 
| I enjoy a good Tsar as much as the next man, but I think I'm actually against
| this proposal, at least for deciding the Foldable/Traversable issue.
| 
| From my perspective, it hasn't been an endless amount of discussion with no
| end in sight. At least on the libraries list, there's been healthy discussion, some
| minds have been changed, votes were cast, and generalizing the prelude won
| by a landslide.
| 
| These changes (which I'm for, by the way) have implications for every Haskell
| programmer, and everyone teaching Haskell. They also put lots of information
| in RWH and LYAH out-of-date. We should expect and embrace constructive
| discussion.
| 
| I'm not saying we shouldn't have library Tsars, but in the case of
| Foldable/Traversable, I think democracy has served us well so far.
| 
| Tom
| 
| 
| El May 23, 2013, a las 3:48 AM, Simon Peyton-Jones <simonpj <at> microsoft.com>
| escribió:
| 
| > This "burning bridges" thread has really got us going!
| >
| > I'm a bit concerned, though, that we don't have an effective mechanism for
| resolving such debates.  If everyone feels that they have a vote, perhaps, but
| only one among many, then one feels either mandated or indeed willing to
| invest the extra cycles to summarise pros and cons based on feedback, crisply
| articulate alternatives, and so on.   And, worse still, no one feels mandated to
| actually decide anything.   That's fine when there's a clear consensus; not so
| fine when there isn't, as here.  Several people on the "Burning bridges" thread
| have commented on the interminable nature of the debate.
| >
| > Our general procedures for library changes are described here:
| http://www.haskell.org/haskellwiki/Library_submissions.  For specialised
| libraries (eg MD5 checksum, or even containers) the situation is clear: the
| author or current maintainer decides.
| >
| > But for the basic core libraries, whose influence is pervasive, matters are
| murkier.  Looking at
| http://www.haskell.org/haskellwiki/Library_submissions#The_Core_Libraries

| we see that many are maintained by "GHC HQ".  But the plain fact is that GHC
| HQ is not up to the task, especially now that Simon M has moved on to
| Facebook.   To be absolutely explicit, I'm worried that decision making may get
| stuck because I don't have the capacity to participate, lead, drive, propose, and
| ultimately make a decision.  So there's a decision-making vacuum for the "GHC
| HQ" libraries.  If that's the case, then the best thing is for GHC HQ to get out of
| the way!
| >
| > Is that what others feel, or are you all happy?   My proposal would be to form
| a Library Tsars committee, that
| > * Takes ownership of the "GHC HQ" libraries
| > * Also owns any global library issues; ones that can't be resolved
| >    by a single maintainer
| >
| > Like any maintainer the Library Tsars would be expected to follow the
| guidance on the wiki
| http://www.haskell.org/haskellwiki/Library_submissions#Guidance_for_maintai

| ners (responsiveness, consultation, etc).  But they could actually decide things.
| >
| > One other thing.  I'd certainly consider well-argued proposals for changing
| GHC to better support backward compatibility in the face of library change.
| One such proposal was the "class alias" story, but that was a big, complex
| general mechanism (and arguably big benefits).  Because of its complexity it is
| currently stalled.  But there may be other much more modest things we could
| do to help; the question about ad-hoc deprecation of Monad without Functor is
| a  small, highly-specific, ad-hoc idea.
| >
| > Simon
| > _______________________________________________
| > Libraries mailing list
| > Libraries <at> haskell.org
| > http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
David Luposchainsky | 23 May 15:20 2013

Re: Making decisions

On 2013-05-23 15:14, Simon Peyton-Jones wrote:
> I wasn't suggesting arbitrary decisions ignoring opinions.  On
> reflection "Tsar" carries the wrong connotations.  How about "Core
> libraries facilitating group"?   Or something less dull-sounding, but
> with the same sense.   I like democracy as much as the next person.
> But someone has to drive the process or it wanders into the long
> grass.

The Trac wiki uses the phrase "first among equals" [1] for what we're
calling Tsar here. It's less tongue-in-cheek, but does a way better job
at avoiding confusion. :-)

David

[1]: http://hackage.haskell.org/trac/ghc/wiki/Contributors
Heinrich Apfelmus | 25 May 15:36 2013
Picon

Re: Making decisions

Simon Peyton-Jones wrote:
> I wasn't suggesting arbitrary decisions ignoring opinions.  On
> reflection "Tsar" carries the wrong connotations.  How about "Core
> libraries facilitating group"?   Or something less dull-sounding, but
> with the same sense.   I like democracy as much as the next person.
> But someone has to drive the process or it wanders into the long
> grass.

How about the name "Secretary of Libraries"?

In many countries, the Secretary of State is a head of civil servants 
and appointed by a minister. It serves as a bridge between political 
positions and civil servants. (Not in the UK, though, where the position 
is equivalent to minister.)

This name would capture the idea that a "Secretary of Libraries" is 
responsible for maintenance, can make decisions, but is still bound by 
the votes on library proposals.

Best regards,
Heinrich Apfelmus

PS: This is beginning to sound like a constitution of Haskellland. But 
hey, we have to organize some bits.

--
http://apfelmus.nfshost.com
Ian Lynagh | 25 May 15:54 2013

Re: Making decisions

> 
> 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/
Ryan Newton | 25 May 16:19 2013
Picon

Re: Making decisions

What was the sample size on the 85% vote?  Is there a website for keeping track of these persistently?  


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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


--
Sent from Gmail Mobile
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ian Lynagh | 25 May 17:09 2013

Re: Making decisions

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 <at> ), 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/
Manuel M T Chakravarty | 28 May 02:46 2013
Picon
Picon

Re: Making decisions

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 <at> ), 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
Heinrich Apfelmus | 31 May 10:45 2013
Picon

Re: Making decisions

Manuel M T Chakravarty wrote:
> 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,
>
> [..]
>
> 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.)

Completely agree. When I wrote "vote" I didn't mean a literal vote, but 
the various opinions in the community. It is at the secretary/tsar/...'s 
discretion to weigh the different arguments and turn them into a decision.

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com
Edward Kmett | 25 May 18:36 2013
Picon

Re: Making decisions

There were something like 12 respondents initially, followed by 15-20 respondents after we broke the format out into multiple responses here on the mailing list (with some overlap) and 115 in the straw poll with biased wording that was sent out by some folks on #haskell (with more overlap), but the results correlated pretty tightly.

-Edward


On Sat, May 25, 2013 at 10:19 AM, Ryan Newton <rrnewton <at> gmail.com> wrote:
What was the sample size on the 85% vote?  Is there a website for keeping track of these persistently?  

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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


--
Sent from Gmail Mobile

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Joachim Breitner | 26 May 17:40 2013
Picon

Who may vote

Hi,

Am Samstag, den 25.05.2013, 14:54 +0100 schrieb Ian Lynagh:
> 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.

more structure in the decision making would be helpful. Also, the +1/-1
mailing list voting is everything but efficient, and I have pity for
those who manually track and count the votes.

I assume that everyone involved here has a hackage account, or would not
mind getting one. How about a small web app on hackage.org that allows
everyone (with an account) to start a poll, or to extend a poll with
additional options, and to vote on the poll.

Then the tallying would be much easier (i.e. automatic). Also, just to
put a bit more meriocracy into the process, the tally could have several
columns: One just the number of votes for each option, then one with the
votes weighted by number of packages uploaded by the voter on hackage,
and then one with the votes weighted by number of packages × reverse
dependencies.

I’d deliberately put in several metics at once to stress that this is
_not_ a binding vote with clear majority requirements, but it would
allow the final evaluation to have a much clearer picture of the level
of consensus. Also we do not put too much emphasis on these numbers, to
avoid people uploading packages just for the stats.¹

Greetings,
Joachim

¹ like I once did a mostly trivial upload during a Hackathon just to get
into the raffle for a signed copy of RWH, which actually worked :-)

--

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata <at> debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata <at> joachim-breitner.de | http://people.debian.org/~nomeata

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 26 May 18:05 2013
Picon

Re: Who may vote

Am 26.05.2013 17:40, schrieb Joachim Breitner:

> I’d deliberately put in several metics at once to stress that this is
> _not_ a binding vote with clear majority requirements, but it would
> allow the final evaluation to have a much clearer picture of the level
> of consensus. Also we do not put too much emphasis on these numbers, to
> avoid people uploading packages just for the stats.¹

You cannot fool Goodhart's law:
    http://en.wikipedia.org/wiki/Goodhart's_law

"You get what you measure."

In your metrics, beginners would have a low weight. Might be intended or 
not.
Ben Millwood | 26 May 18:12 2013
Picon

Re: Who may vote

On Sun, May 26, 2013 at 05:40:35PM +0200, Joachim Breitner wrote:
>more structure in the decision making would be helpful. Also, the +1/-1
>mailing list voting is everything but efficient, and I have pity for
>those who manually track and count the votes.
>
>I assume that everyone involved here has a hackage account, or would not
>mind getting one. How about a small web app on hackage.org that allows
>everyone (with an account) to start a poll, or to extend a poll with
>additional options, and to vote on the poll.

At the risk of repeating myself, what's wrong with using the wiki for 
this?
Joachim Breitner | 26 May 18:54 2013
Picon

Re: Who may vote

Hi,

Am Sonntag, den 26.05.2013, 17:12 +0100 schrieb Ben Millwood:
> On Sun, May 26, 2013 at 05:40:35PM +0200, Joachim Breitner wrote:
> >more structure in the decision making would be helpful. Also, the +1/-1
> >mailing list voting is everything but efficient, and I have pity for
> >those who manually track and count the votes.
> >
> >I assume that everyone involved here has a hackage account, or would not
> >mind getting one. How about a small web app on hackage.org that allows
> >everyone (with an account) to start a poll, or to extend a poll with
> >additional options, and to vote on the poll.
> 
> At the risk of repeating myself, what's wrong with using the wiki for 
> this?

hmm, good idea too, and sorry for not having read it before.

A wiki page that keeps a running summary of the discussion is generally
a good idea to make mailing list discussions more efficient. But they
need someone who maintains the page.

Greetings,
Joachim

--

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata <at> debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata <at> joachim-breitner.de | http://people.debian.org/~nomeata

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
wren ng thornton | 29 May 07:46 2013

Re: Who may vote

On 5/26/13 11:40 AM, Joachim Breitner wrote:
> I assume that everyone involved here has a hackage account, or would not
> mind getting one. How about a small web app on hackage.org that allows
> everyone (with an account) to start a poll, or to extend a poll with
> additional options, and to vote on the poll.

I'm all for making polls, even if just to simplify the bookkeeping rather
than to be anything more official. However, adding options to a poll in
progress is treacherous; how should pre-change responses be tallied?

--

-- 
Live well,
~wren
Edward Kmett | 29 May 19:06 2013
Picon

Re: Who may vote

Polls are ultimately about taking the temperature of the room. As Ian pointed out the process isn't majority rule. Ultimately the polling is to inform the maintainer of the library of popular opinion. As it is ultimately about judging over all opinion assessing the relevance of pre-change responses is something that seems well within the capabilities of a maintainer.

-Edward


On Wed, May 29, 2013 at 1:46 AM, wren ng thornton <wren <at> freegeek.org> wrote:
On 5/26/13 11:40 AM, Joachim Breitner wrote:
> I assume that everyone involved here has a hackage account, or would not
> mind getting one. How about a small web app on hackage.org that allows
> everyone (with an account) to start a poll, or to extend a poll with
> additional options, and to vote on the poll.

I'm all for making polls, even if just to simplify the bookkeeping rather
than to be anything more official. However, adding options to a poll in
progress is treacherous; how should pre-change responses be tallied?

--
Live well,
~wren


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Casey McCann | 23 May 16:39 2013
Picon

Re: Making decisions

Regarding the matter of consensus, do note that the general opinion
was something like an 85% supermajority in favor, which is far beyond
what most democratic governing bodies require even for drastic
actions--I really don't think that starting World War III should
require less of a group consensus than modifying the Prelude. Any
non-trivial change to core libraries is sure to provoke some amount of
opposition, so in practice this is about as clear a consensus as can
be expected.

However, as was pointed out on IRC, this is not a democratic process
and the decision lies ultimately with the maintainer. While the
maintainer may certainly take community feedback into account, in a
largely unstructured format such as a mailing list it's easy for
extended debate to create the appearance of significant disagreement
where none really exists.

With ideas like the current Foldable/Traversable suggestion there is a
great deal of work that would need to be done before reaching the
point of having a complete, clear, and fully-detailed proposal:
Exactly which combinators are to be generalized, whether any
monomorphic versions should exist outside of Prelude, what situations
(if any) may cause ambiguious types that break existing code, whether
any functions are unavoiably less efficient when generalized, if there
need to be rewrite rules to improve performance, how this impacts list
foldr/build fusion, and probably a variety of other implementation
details on top of that. While this change doesn't intrinsically
require breaking anything, in practice it surely won't be that easy.

Ideally someone would write up a better overview of these concerns--a
task which Shachaf has selflessly volunteered to delegate to me, and
I'll do so if necessary--but the process of working out the answers to
those questions should have broader community involvement, which is
difficult to accomplish in the presence of infinitely persistent
arguments about whether the change should happen at all.

To make headway on larger changes while retaining community
involvement, what I think is necessary is an authority capable of
listening to the community, making a *clear decision on whether to
proceed or not*, and then organizing the process of investigating and
resolving any implementation details.

So that's what I'd like to see from a Core Library Bikeshed Decoration
Committee or whatever it ends up being called: Find out whether a
change is desired by the community, if so determine whether that
change is feasible, and if so drive the process to implement it.

And anyhow, GHC itself is certainly no less critical than the core
libraries. Anything that reduces the amount of non-GHC burdens for GHC
HQ to deal with is a win for everyone, I would expect.

- C.
Petr Pudlák | 23 May 17:05 2013
Picon

class aliases (was: Making decisions)

Dne 05/23/2013 09:48 AM, Simon Peyton-Jones napsal(a):
> One other thing.  I'd certainly consider well-argued proposals for changing GHC to better support
backward compatibility in the face of library change.  One such proposal was the "class alias" story, but
that was a big, complex general mechanism (and arguably big benefits).  Because of its complexity it is
currently stalled.  But there may be other much more modest things we could do to help; the question about
ad-hoc deprecation of Monad without Functor is a  small, highly-specific, ad-hoc idea.
Is it this proposal? http://repetae.net/recent/out/classalias.html
Looks very interesting! How does it compare to Default superclass 
instances 
<http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances>? 
 From the first glance it seems to me that class aliases are strictly 
stronger. Are there some know design problems with this extension, which 
make it complex and which need to be solved first, or is it just a lot 
of work to implement?

(I'd be willing to do some work on it, although I'd probably spend a lot 
of time just figuring out how GHC intenals works.)

   Best regards,
   Petr
Simon Peyton-Jones | 24 May 09:33 2013
Picon

RE: class aliases (was: Making decisions)

Petr

It's a complex design space. I can't even readily answer your question "are class aliases strictly
stronger".  Neither feature is fully specified yet.  Each has variations. I'm also worried about
implementing a complex feature that ultimately turns out not to solve the library-evolution problem.

So although I can see the benefits (to library evolution in particular) I have consciously punted on this,
hoping that someone will evolve a design that everyone says "aha, that's it".

So by all means have at it; I'm sure we'd learn from the process.  I just don't want to promise up-front to adopt
the result.

Simon

| -----Original Message-----
| From: Petr Pudlák [mailto:petr.mvd <at> gmail.com]
| Sent: 23 May 2013 16:05
| To: Simon Peyton-Jones; libraries <at> haskell.org
| Subject: class aliases (was: Making decisions)
| 
| Dne 05/23/2013 09:48 AM, Simon Peyton-Jones napsal(a):
| > One other thing.  I'd certainly consider well-argued proposals for changing
| GHC to better support backward compatibility in the face of library change.
| One such proposal was the "class alias" story, but that was a big, complex
| general mechanism (and arguably big benefits).  Because of its complexity it is
| currently stalled.  But there may be other much more modest things we could
| do to help; the question about ad-hoc deprecation of Monad without Functor is
| a  small, highly-specific, ad-hoc idea.
| Is it this proposal? http://repetae.net/recent/out/classalias.html
| Looks very interesting! How does it compare to Default superclass
| instances
| <http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances>?
|  From the first glance it seems to me that class aliases are strictly
| stronger. Are there some know design problems with this extension, which
| make it complex and which need to be solved first, or is it just a lot
| of work to implement?
| 
| (I'd be willing to do some work on it, although I'd probably spend a lot
| of time just figuring out how GHC intenals works.)
| 
|    Best regards,
|    Petr
wren ng thornton | 29 May 07:42 2013

Re: Making decisions

On 5/25/13 10:19 AM, Ryan Newton wrote:
> 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).

I'm not a Schemer, but I definitely sympathize. FWIW, I've always
considered the +1/-1 posts to be more along the lines of reddit; i.e., I
dis-/like this proposal but don't have anything substantial to add.
However, more recently, the +1/-1 posts have tended to come across as
something more like "voting" ...which, as others have mentioned, is
problematic at best.

I've worked with a few consensus-based nonprofits and co-ops, so I have
some feel for the complexities involved in establishing official decision
mechanisms, whether they be voting-based or consensus-based. So far, we've
gotten by pretty well with the benevolent dictator model of just feeling
the community out and then doing stuff. But I wonder if the community has
gotten too large for this to continue, which may be why the feeling behind
+1/-1 posts has been shifting towards this terminology of "voting". That
could also explain why (IMHO) some of the discussions on this list have
been getting more contentious--- in voting models people tend to feel like
they need to shout louder in order to be heard, while simultaneously
feeling like they have less and less of a say in the outcome (which leads
to shouting of another sort).

This is all just vague musing at the moment. I've always enjoyed the
friendliness and conscientiousness of the Haskell community, and it'd be
nice to keep that. But maybe it is time to move to a more official
mechanism of decision making; if so, then what sort of mechanism do we
want? Simon has suggested an extension of the benevolent dictator model,
with a small committee making the final call. I've always been a fan of
consensus methods since they do a good job of airing different
perspectives and coming to decisions that don't fracture the community or
encourage partisanship. Most of us are familiar with voting models of
various sorts. Each of these models has its ups and downs; regardless,
it's something to think about before just picking one.

--

-- 
Live well,
~wren
Tyson Whitehead | 29 May 16:40 2013
Picon

Re: Making decisions

On May 29, 2013 01:42:43 wren ng thornton wrote:
> On 5/25/13 10:19 AM, Ryan Newton wrote:
> > 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).
> 
> I'm not a Schemer, but I definitely sympathize. FWIW, I've always
> considered the +1/-1 posts to be more along the lines of reddit; i.e., I
> dis-/like this proposal but don't have anything substantial to add.
> However, more recently, the +1/-1 posts have tended to come across as
> something more like "voting" ...which, as others have mentioned, is
> problematic at best.

Maybe you need more of reddit, where individual comments can accumulate +/-.  
This way the important points won't get lost in the noise, and at the end of 
the day you have a bit of a summary of the major points.

Cheers!  -Tyson

Gmane