On 23.05.2013 10:13, Shachaf Ben-Kiki wrote:

On Thu, May 23, 2013 at 3:48 AM, Simon Peyton-Jones 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_maintain... (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@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

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

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@gmail.com [mailto:amindfv@gmail.com] | Sent: 23 May 2013 14:06 | To: Simon Peyton-Jones | Cc: libraries@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 | 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@haskell.org | > http://www.haskell.org/mailman/listinfo/libraries

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

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

-- Sent from Gmail Mobile

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 :

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

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

-- Sent from Gmail Mobile

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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.

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@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata