I’m fine with agreeing a process.
I do think we should consult the community (via a poll) about which extensions to include, and Hackage about which extensions are used. But still make decisions ourselves (informed by the community input).
Simon
From: ghc-steering-committee
* This counter-counter-proposal is meant to combine what I see are the best qualities of both proposals: the structure in Alejandro's (Joachim's suggests just debating about extensions over email, which causes me to shudder in horror, even if the discussion is just among committee members), with the committee-seeding from Joachim's.
My proposal is mis-phrased: I suggest _not_ debating. I want GHC2021 to contain only uncontroversial extensions. If debating flares up about a specific extension, that’s already a clear sign that the extension should not make it _this round_, which settles that very discussion. If at any point a committee member feels like strongly arguing in favor of an extension that does not already have a majority with more emphasis than just “here are some good points you might have missed”, then such an extension is not uncontroversial, and would simply be voted out. I expect us from refraining from strongly and verbosely arguing for an individual extension, and thus no discussion ensues. If at any point a committee member feels like strongly arguing against an extension that does already have a majority, then I expect that at least three other members will take that as “clearly not uncontroversial”, remove it from their vote, and make any further discussion not needed. I think it is wrong to think the decision “Should Foo be part of GHC20201” needs the same level of rigor as “should Foo exist”. In the latter case, if we say no, somebody is unhappy because they can’t use a feature they care about. So we really need the detailed discussion, and refinement etc. So yay for PRs. In the former case, if we say no, it’s no big deal, people will have to continue saying {-# LANGUAGE Foo #-} for a few more years. This does not hurt anyone! And therefore, I strongly advise against any heavy per-extension discussion process.
We'll all edit the meta-proposal as need-be, with the expectation that we friends do not clobber each other's work. Seems simpler than having the conversation spread among multiple PRs.
That’s a good point; we can have options in one PR and still do ranked voting. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ccc54e3a12f5843a64e5908d874649b76%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387322741398332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ll3x7YCeK9WX9vRXhPpx1Y9MXXv9saxPOs%2F347joONM%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccc54e3a12f5843a64e5908d874649b76%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387322741398332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yTvhE7jxAPBkmNSfXdF6KXAD8%2BQiRMDp%2B7ip9WTCTNU%3D&reserved=0