[ghc-steering-committee] GHC 2020

Tue Sep 8 12:01:04 UTC 2020

I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design. 

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them. 

Eric

Sent from my iPhone

>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Personally I don’t think we should make the Steering Committee responsible for initiating or driving this.  We should
> establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),
> express open-ness to a proposal, and then
> review proposals when/if they materialise.
>  
> It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible. 
>  
> What do others think?
>  
> Simon
>  
> From: Alejandro Serrano Mena <trupill at gmail.com> 
> Sent: 08 September 2020 09:13
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>; ghc-steering-committee at haskell.org
> Subject: Re: [ghc-steering-committee] GHC 2020
>  
> Dear all,
> 
> I would really like to move this forward, and I would be happy to put some work on it.
> 
>  
> 
> What do you think of the following plan?
> 
> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.
> 
> - Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.
> 
>  
> 
> If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
> 
>  
> 
> Regards,
> 
> Alejandro
> 
>  
> 
> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
> 
> Just back from holiday. Some thoughts
> 
> * I don’t think this mailing list is the best place for the
>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>   a committee member, possibly not) should write a proposal,
>   and we should put it through the process.
> 
> * We should advertise the criteria, as Richard has done on the
>   wiki page.
> 
> * Any such proposal should be informed by data. Notably, extension usage
>   in Hackage, or perhaps Stackage (since it's a bit more curated).
> 
> * A proposer might also want to run a public poll, as an additional
>   source of data
> 
> * When it comes to the committee, we can (I guess) vote on individual
>   extensions, rather than just accept/reject the whole thing.
> 
> I am intrigued by the idea of using Kialo to coordinate discussion.
> Maybe it'd work better than GitHub?  Are there other alternatives?
> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-steering-committee <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
> |  Sent: 02 September 2020 14:57
> |  To: Eric Seidel <eric at seidel.io>
> |  Cc: ghc-steering-committee at haskell.org
> |  Subject: Re: [ghc-steering-committee] GHC 2020
> |  
> |  It seems clear that my wiki idea isn't winning the day -- I never
> |  really liked it either. I'd be fine with either Eric's or Joachim's
> |  approaches. Maybe start with Joachim's approach and then use Eric's
> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
> |  approach is that it seems hard to get good community involvement.
> |  
> |  Richard
> |  
> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
> |  >
> |  > Opening a regular discussion about whether and how we want to work on
> |  GHC 2020 sounds fine, that will also give the community a place to
> |  weigh in. I do think the eventual contents should be informed by the
> |  community though, it shouldn’t just be us working alone.
> |  >
> |  > Sent from my iPhone
> |  >
> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
> |  breitner.de> wrote:
> |  >>
> |  >> Hi,
> |  >>
> |  >> sounds plausible. It would also allow us to use tags to easily
> |  indicate
> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and
> |  >> then filter by issue to get the current list…
> |  >>
> |  >> But before we go there, shouldn’t we maybe have a discussion first
> |  on
> |  >>
> |  >> * do we even want that?
> |  >> * what are the abstract criteria (or guidelines)?
> |  >> * what is the process?
> |  >>
> |  >> I believe that discussion could be done like any other proposal.
> |  >>
> |  >>
> |  >> As for the process; when I brought up the idea, I was worried about
> |  us
> |  >> spending huge resources discussion individual extensions to death,
> |  and
> |  >> proposed, in the interest of efficiency and getting things done:
> |  >>
> |  >>> The process could be: Every member can nominate any number of
> |  >>> extensions, to include, maybe a small rationale and then we do one
> |  >>> round of independent approval voting, requiring a supermajority to
> |  >>> really only pick uncontested extensions.
> |  >>
> |  >> So instead of long debates, we start with GHC2020 being just those
> |  >> extensions that a supermajority on the committee considers to be ok.
> |  >>
> |  >> This is much more lightweight process that we could get done in a
> |  week
> |  >> or two (maybe using a doodle-like voting page). Maybe we would leave
> |  >> out one or two extension that initially people are reserved about,
> |  but
> |  >> could be swayed after lengthy discussions. But is that worth the
> |  >> lengthy discussion?
> |  >>
> |  >> cheers,
> |  >> Joachim
> |  >>
> |  >> --
> |  >> Joachim Breitner
> |  >> mail at joachim-breitner.de
> |  >>
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
> |  achim-
> |  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D
> |  &reserved=0
> |  >>
> |  >>
> |  >> _______________________________________________
> |  >> ghc-steering-committee mailing list
> |  >> ghc-steering-committee at haskell.org
> |  >>
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
> |  haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
> |  amp;reserved=0
> |  >
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org
> |  >
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
> |  haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
> |  amp;reserved=0
> |  
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
> |  haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
> |  amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200908/f0fbcff5/attachment-0001.html>