[ghc-steering-committee] GHC 2020

[Joachim Breitner]

Hi,

Am Samstag, den 17.10.2020, 21:26 +0200 schrieb Alejandro Serrano Mena:
> I would really like this effort not to die, so I've given the
> proposal another push. Following the comments from Simon and Joachim,
> I've re-framed the proposal as laying down a process to create new
> "language versions" yearly. The idea is to have one of these every
> year (or 2, or 3, whatever is decided), coinciding with the spring
> release of GHC. 
> https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md


I like the idea of tying this to the Spring release of GHC, this
provides a lot of predictability, and also provides a hard deadline,
which makes it more likely to make _some_ progress (instead of never
achieving the perfect set of extensions).

To questions about the criteria:


If GHC2021 contains extension Foo, I assume that by default, GHC2020
also contains Foo. But should we allow ourselves to remove something?
(I would argue, yes: it should be a rare thing, but if Foo turned out
to be problematic, then it seems better to not include it in the next
version. Code that still declares 2021 wouldn’t be affected, and code
that wants to use GHC2021 and Foo would have to list Foo explicitly,
which is arguably a good thing.)


Should we make it a hard rule that the extension needs to be supported
by the last _n_ versions of GHC?
(Would we maybe make point releases of prior versions of GHC to
understand -XGHC2021, to make these sets of extensions available to
more users faster?)


> I think it's important for the community to be involved in the
> process. If it's clear that an extension is loved by most of the
> community, that's a big plus for acceptance. In addition, if we come
> with a list ourselves, we risk having made choices which only show
> our (biased) point of view.

I would hope that with 10 people on the committee, the bias is not too
big. And just like GHC proposals that attract discussions are sent back
as “needs review”, extensions that cause non-trivial discussion are, by
definition, not uncontroversial enough, and should simply be “maybe
next year”.

Therefore I would like to start with a slimmer, more effective and
efficient process that does not involve a full proposal-size discussion
on each extension, and does _not_ cause dozends of parallel discussions
with the community. So here is a first draft of the “slim proceess”:

=============================================================

 * 4 months before the expected GHC spring release day of 202x:
   The Secretary starts the GHC202x process. with an email to the list
   listing all language extensions supported by GHC that are not in 
   GHC202(x-1), and asking the committee for “votes” (which are also
   nominations).

   The secretary also creates a PR with a proposal saying (roughly) 
   > GHC202x contains the following extensions in addition to those
   > in GHC202(x-1):
   > 
   > * (none yet)

   The community may use comments on this PR to weigh in.

 * Within two weeks of the start of the process,
   every committee member is expected to send an 
   initial list of which extensions they expect to be in GHC202x
   to the mailing list. These mails may contain justifications
   for why a certain extension is or is not included.

   After these two weeks, the PR is continuously updated by the 
   secretary to reflect the _current_ tally of votes: 
   An extension is included if it is listed by at least ⅔ (rounded up)
   of committee members.

 * Within four weeks, of the start of the process,
   committee members can change their vote (by email to the list).

   It is absolutely ok to change your mind based on the explanations in
   the other members’ emails, or the general comments on the PR.

 * After these four weeks, the proposal with the current tally
   gets accepted, and defines GHC202x

=============================================================

The goal here is, of course, to efficiently find out which are the
uncontentious extensions, without spending a log of time on the
contentious ones (which I think we simply want to continue to guard
behind their own explicit extension).


Meta-process comments:
I’ll turn this into an alternative PR to Alejandro’s once he opened
his, and we can vote on both together (using ordered voting, I still
prefer Alejandro’s process to no GHC2021, this way we don’t step on
each other’s toes).



> Since in the first round the possible list of extensions may be quite
> big, we might introduce a "fast-lane process" for this one time, for
> extensions like EmptyDataDecls or different number formats which seem
> to have unanimous support.

I guess I agree, and I’d just make that the only process :-)

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/