[ghc-steering-committee] GHC 2020

[Simon Peyton Jones]

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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 19 October 2020 20:24
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] GHC 2020

It seems that people like the idea, 300 out of 400 respondents gave a "yes!", with around 100 saying it's a good idea or not caring.

If we did some meta-PR, I would prefer to simply discuss Joachim's and Richard's proposals. I've been convinced that discussing per-extension would result in endless pain, and I am in favour of making the Committee "seed" the process with the list of extensions. Any other source of information (polls, stats) should be considered, but I agree with Joachim that some extensions may not be used that much, but pose a very low barrier, and thus should be accepted. I don't think that would be a problem, I trust ourselves not making crazy decisions.

What do the rest of the Committee think?

Alejandro

El lun., 19 oct. 2020 a las 17:05, Joachim Breitner (<mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>) escribió:
Hi,

Am Montag, den 19.10.2020, 14:07 +0000 schrieb Richard Eisenberg:
> * 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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201020/c820258d/attachment-0001.html>