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