Making decisions

[Simon Peyton-Jones]

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