Making decisions

[Simon Peyton-Jones]

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