Thanks for the background, Edward. I don't mean to question the composition of the committee, only to start a discussion about how the community might handle the selection process going forward. I apologize if I was not clear about that. As I said below, if a direct vote resulted in the same committee we would have had under the current system, I would consider that a success!
We may also see a larger nomination pool in the future :) Cheers, Geoff On 10/21/2015 03:54 PM, Edward Kmett wrote: > The committee was formed from a pool of suggestions supplied to SPJ > that represented a fairly wide cross-section of the community. > > Simon initially offered both myself and Johan Tibell the role of > co-chairs. Johan ultimately declined. > > In the end, putting perhaps too simple a spin on it, the initial > committee was selected: Michael Snoyman for commercial interest, Mark > Lentczner representing the needs of the Platform and implementation > concerns, Brent Yorgey on the theory side, Doug Beardsley representing > practitioners, Joachim Breitner had expressed interest in working on > split base, which at the time was a much more active concern, Dan Doel > represented a decent balance of theory and practice. > > Since then we had two slots open up on the committee, and precisely > two self-nominations to fill them, which rather simplified the > selection process. Brent and Doug rotated out and Eric Mertens and > Luite Stegeman rotated in. > > Technically, yes, we are self-selected going forward, based on the > precedent of the haskell.org <http://haskell.org> committee and > haskell-prime committees, but you'll note this hasn't actually been a > factor yet as there hasn't been any decision point reached where that > has affected a membership decision. > > -Edward > > On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland > <mainl...@apeiron.net <mailto:mainl...@apeiron.net>> wrote: > > On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland > wrote: > > [...] > > >> In effect, only those who actively follow the libraries list have > had a >> voice in these decisions. Maybe that is what the community > wants. I hope >> not. How then can people like me (and Henrik and > Graham) have a say >> without committing to actively following the > libraries list? >> >> We have a method to solve this: elected > representatives. Right now the >> Core Libraries Committee elects its > own members; perhaps it is time for >> that to change. > > [...] > >> > Proposal 1: Move to community election of the members of the Core >> > Libraries Committee. Yes, I know this would have its own issues. > > > How > exactly do public elections of representatives address the problem > > that some people feel left out? Have you considered nominating > yourself > > or somebody else you have confidence in for the core libraries > > committee? You'd still have to find somebody to represent your > > interests, regardless of whether the committee is self-elected or > > direct-elected. > > Here's some food for thought regarding language > design by voting or its > indirect form via a directly elected > language > committee: > > Back in February there was a large-scale survey which > resulted (see [2] > for more details) in a rather unequivocal 4:1 > majority *for* going > through with the otherwise controversial FTP > implementation. If the > community elections would result in a similar > spirit, you'd could easily > end up with a similarly 4:1 pro-change > biased committee. Would you > consider that a well balanced committee > formation? > > Thanks, all good points. > > It is quite possible that direct elections would produce the exact > same > committee. I wouldn't see that as a negative outcome at all! At least > that committee would have been put in place by direct election; I > would > see that as strengthening their mandate. > > I am very much aware of the February survey. I wonder if Proposal > 2, had > it been in place at the time, would have increased participation > in the > survey. > > The recent kerfuffle has caught the attention of many people who don't > normally follow the libraries list. Proposal 1 is an attempt to give > them a voice. Yes, they would still need to find a candidate to > represent their interests. If we moved to direct elections, I would > consider running. However, my preference is that Proposal 3 go through > in some form, in which case my main concern would be the Haskell Prime > committee, and unfortunately nominations for that committee have > already > closed. > > >> Proposal 2: After a suitable period of discussion on the > libraries list, >> the Core Libraries Committee will summarize the > arguments for and >> > against a proposal and post it, along with a (justified) > preliminary >> > decision, to a low-traffic, announce-only email list. After another >> > suitable period of discussion, they will issue a final decision. > What is > >> a suitable period of time? Perhaps that depends on the > properties of > the >> proposal, such as whether it breaks backwards > compatibility. > > > That generally sounds like a good compromise, if this actually helps > > reaching the otherwise unreachable parts of the community and have > their > > voices heard. > > My hope is that a low-volume mailing list would indeed reach a wider > audience. > > >> Proposal 3: A decision regarding any proposal that > significantly affects >> backwards compatibility is within the > purview of the Haskell Prime > >> Committee, not the Core Libraries Committee. > > I don't see > how that > would change much. The prior Haskell Prime > Committee has been > traditionally self-elected as well. So it's just the > label of the > committee you'd swap out. > > In the recent call of nominations[1] for > Haskell Prime, the stated area > of work for the new nominations > was to > take care of the *language* part, > because that's what we are lacking > the workforce for. > > Since its creation for the very purpose of > watching over the core > libraries, the core-libraries-committee has > been almost exclusively busy > with evaluating and deciding about > changes to the `base` library and > overseeing their implementation. > Transferring this huge workload to the > new Haskell Prime committee > members who have already their hands full > with revising the language > part would IMO just achieve to reduce the > effectiveness of the > upcoming Haskell Prime committee, and therefore > increase the risk of > failure in producing an adequate new Haskell Report > revision. > > My understanding is that much of the work of the core libraries > committee does not "significantly affect backwards compatibility," at > least not to the extent that MRP does. If this is the case, the > bulk of > their workload would not be transferred to the new Haskell Prime > committee. Is my understanding incorrect? > > The intent of Proposal 3 was to transfer only a small fraction of the > issues that come before the core libraries committee to the Haskell > Prime committee. In any case, we would certainly need to clarify what > "significantly affects backwards compatibility" means. > > Perhaps we should consider direct elections for the Haskell Prime > committee as well as changing their mandate to include some subset of > the changes proposed to libraries covered by the Haskell Report. My > understanding of the current state of affairs is that the Haskell > Prime > committee is charged with producing a new report, but the core > libraries > committee is in charge of the library part of that report. Is that > correct? > > Cheers, > Geoff > > > Regards, > H.V.Riedel > > [1]: > > https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > > [2]: > https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html > > _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime