Re: [ghc-steering-committee] GHC 20xx process

This is an effective argument; you've changed my mind. I'm now in favor of Joachim's simpler process. Thanks for writing this all out! Richard
On Nov 6, 2020, at 4:02 AM, Joachim Breitner
wrote: Hi,
we may be repeating points here, but I am still strongly leaning towards a more lightweight process. At least initially, so that we can iterate towards something more heavy in later rounds, rather than going the other way (in general easier to add process than remove process).
You mention that discussions will pop us elsewhere. I don’t find that bad! We committee members are here to represent the community, and I expect that enough of us are “in touch” with the community to pick up useful signal, even if it happens on reddit or twitter, and will carry that into their votes and rationales. There will be discussion in reddit and twitter and mailing lists _anyways_!
What I want to avoid is sending a signal to the community to say “we are going to do about 100 individual decisions soon and, by the way, we really encourage you to comment on all of them (why else would we give you the explicit space). I’d rather send the signal “we are going to make 100 individual decisions, here you can follow the process, and if you _really_ think we are missing something, this PR is where your input is welcome.”
Also, speaking as the secretary, managing a separate repo and expecting all of us to following many different issues seems out of proportion of what we want to achieve here.
Maybe popping up a bit: It’s worth noting that the first round will be very different than all the subsequent roads. In the first round we have a _large_ number of low-hanging fruit to pluck. In fact, it’s so many of them, that I expect we simply don't have the capacity to do very careful deliberation of each of them.
This implies that the first round, we should aim _low_, and be very conservative, knowing that the following rounds we have less to discuss, and can then be more careful discussions about those extensions that need those discussions.
So what does this mean for community involvement? There are two cases for a given extension FooBar:
* Our vote initially doesn’t include FooBar.
Yes, for almost every extension there will be a few people who think that it should be in. This is not very useful signal!
In fact, in this case, we’d likely say “thanks for your input! For the first round, we are going to be conservative, and we didn’t include FooBar for now. But maybe next year!”
I don’t think we or the community benefits from first making space for that discussion, to then only cut it off politely.
* Our vote initially includes FooBar.
Then, maybe, someone has a good argument why FooBar is actually less harmless than we have thought. That _is_ useful signal!
But I expect this to be rare: It only applies to the already filtered list of extensions, not all 100, and if we do our job good, only a few cases like this arise. Thus a normal discussion on the PR on our normal repository, just like with any other proposal, suffices to get that signal.
I am making a few assumptions here about how we want to run this (aiming for a conservative list of extensions in the first round, and trying to be efficient with our own resources), and with these assumption the more lightweight process seems more appropriate to begin with.
One can of course disagree with these assumption (e.g. aiming for a very elaborate process to pick a very “complete” set right away), and then deduce that Alternative 2 is needed.
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg:
This is an effective argument; you've changed my mind.
I'm now in favor of Joachim's simpler process.
thanks, also for making me get more clarity on this as well. Is anyone still preferring Alternative 2, or should we take it off the table? Is anyone not in favor of this proposal, or has questions, or shall we declare consensus and merge it? It seems that now is a good time to then actually do the first iteration of the process – the State of Haskell survey data, once out, will be fresh, and we'd be well in time for inclusion in the Spring release of GHC, likely 9.1 (unless the 9.0 delay shifts things around… oh well, let’s just make sure we have GHC2021 defined before or near the start of 2021, not late in that year :-)) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

| Is anyone not in favor of this proposal, or has questions, or shall we
| declare consensus and merge it?
In my message of 4 Nov, I asked for feedback within "a week or two". Let's set a deadline of the end of this week.
All: please respond before then, if you want to.
I don't think this is terribly controversial, so I'll take silence as assent.
All this assuming we adopt Alternative 1.
Simon
| -----Original Message-----
| From: ghc-steering-committee

Thanks Alejandro and Joachim for pushing this forward! I also suggested a heavier process along the lines of (2) at some point, but after reading the proposal and Joachim's argument here, I feel comfortable with (1) as well. Also, I think @AntC2 made a good point about -fglasgow-exts on the PR [1]. For the initial round it would be useful to list the extensions enabled by -fglasgow-exts as a reference point. [1]: https://github.com/ghc-proposals/ghc-proposals/pull/372#issuecomment-7160669... On Tue, Nov 10, 2020, at 06:18, Simon Peyton Jones via ghc-steering-committee wrote:
| Is anyone not in favor of this proposal, or has questions, or shall we | declare consensus and merge it?
In my message of 4 Nov, I asked for feedback within "a week or two". Let's set a deadline of the end of this week.
All: please respond before then, if you want to.
I don't think this is terribly controversial, so I'll take silence as assent.
All this assuming we adopt Alternative 1.
Simon
| -----Original Message----- | From: ghc-steering-committee
On | Behalf Of Joachim Breitner | Sent: 09 November 2020 16:28 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 20xx process | | Hi, | | Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: | > This is an effective argument; you've changed my mind. | > | > I'm now in favor of Joachim's simpler process. | | thanks, also for making me get more clarity on this as well. | | Is anyone still preferring Alternative 2, or should we take it off the | table? | | Is anyone not in favor of this proposal, or has questions, or shall we | declare consensus and merge it? | | | It seems that now is a good time to then actually do the first iteration of | the process – the State of Haskell survey data, once out, will be fresh, and | we'd be well in time for inclusion in the Spring release of GHC, likely 9.1 | (unless the 9.0 delay shifts things around… oh well, let’s just make sure we | have GHC2021 defined before or near the start of 2021, not late in that year | :-)) | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C125f812494db4225 | 0f4808d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63740536191896 | 4507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BfuHY7eCNyF5QlP7BfXDrNjxgWhoj%2FGI92S | esCy1gLA%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C125f812494db42250f480 | 8d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637405361918974502% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=TyxdMqz%2FXFY9WYgZKdUHkFSQEvqRMJdoVEajh39JNs | A%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim puts his opinion quite eloquently and convincingly :-)
I was initially in favour of one conversation space by proposed extension,
but, at least for the first round this is likely to be overwhelming. At
least, I haven't found or seen, yet, a way to make this manageable. So let
me vote with the majority opinion here.
Let's see how it goes really, if it doesn't work out how we expected this
time around, we can change the process for the next iteration.
/Arnaud
On Tue, Nov 10, 2020 at 8:11 PM Eric Seidel
Thanks Alejandro and Joachim for pushing this forward!
I also suggested a heavier process along the lines of (2) at some point, but after reading the proposal and Joachim's argument here, I feel comfortable with (1) as well.
Also, I think @AntC2 made a good point about -fglasgow-exts on the PR [1]. For the initial round it would be useful to list the extensions enabled by -fglasgow-exts as a reference point.
[1]: https://github.com/ghc-proposals/ghc-proposals/pull/372#issuecomment-7160669...
| Is anyone not in favor of this proposal, or has questions, or shall we | declare consensus and merge it?
In my message of 4 Nov, I asked for feedback within "a week or two". Let's set a deadline of the end of this week.
All: please respond before then, if you want to.
I don't think this is terribly controversial, so I'll take silence as assent.
All this assuming we adopt Alternative 1.
Simon
| -----Original Message----- | From: ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> On | Behalf Of Joachim Breitner | Sent: 09 November 2020 16:28 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 20xx process | | Hi, | | Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: | > This is an effective argument; you've changed my mind. | > | > I'm now in favor of Joachim's simpler process. | | thanks, also for making me get more clarity on this as well. | | Is anyone still preferring Alternative 2, or should we take it off the | table? | | Is anyone not in favor of this proposal, or has questions, or shall we | declare consensus and merge it? | | | It seems that now is a good time to then actually do the first iteration of | the process – the State of Haskell survey data, once out, will be fresh, and | we'd be well in time for inclusion in the Spring release of GHC,
| (unless the 9.0 delay shifts things around… oh well, let’s just make sure we | have GHC2021 defined before or near the start of 2021, not late in
On Tue, Nov 10, 2020, at 06:18, Simon Peyton Jones via ghc-steering-committee wrote: likely 9.1 that year
| :-)) | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com %7C125f812494db4225 | 0f4808d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63740536191896 | 4507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BfuHY7eCNyF5QlP7BfXDrNjxgWhoj%2FGI92S | esCy1gLA%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com %7C125f812494db42250f480 | 8d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637405361918974502% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=TyxdMqz%2FXFY9WYgZKdUHkFSQEvqRMJdoVEajh39JNs | A%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hello,
I like the simple process, however I think I'd prefer a bit more discussion
in phase 2,when we know the current tallies, and also I think we should
give ourselves the option to decide *not* to have GHC2020---it seems odd
that this is a proposal that is phrased as "we are definitely going to end
up with GHC 2020, we just don't know what's in it :-)
-Iavor
On Fri, Nov 13, 2020 at 5:41 AM Spiwack, Arnaud
Joachim puts his opinion quite eloquently and convincingly :-)
I was initially in favour of one conversation space by proposed extension, but, at least for the first round this is likely to be overwhelming. At least, I haven't found or seen, yet, a way to make this manageable. So let me vote with the majority opinion here.
Let's see how it goes really, if it doesn't work out how we expected this time around, we can change the process for the next iteration.
/Arnaud
On Tue, Nov 10, 2020 at 8:11 PM Eric Seidel
wrote: Thanks Alejandro and Joachim for pushing this forward!
I also suggested a heavier process along the lines of (2) at some point, but after reading the proposal and Joachim's argument here, I feel comfortable with (1) as well.
Also, I think @AntC2 made a good point about -fglasgow-exts on the PR [1]. For the initial round it would be useful to list the extensions enabled by -fglasgow-exts as a reference point.
[1]: https://github.com/ghc-proposals/ghc-proposals/pull/372#issuecomment-7160669...
| Is anyone not in favor of this proposal, or has questions, or shall we | declare consensus and merge it?
In my message of 4 Nov, I asked for feedback within "a week or two". Let's set a deadline of the end of this week.
All: please respond before then, if you want to.
I don't think this is terribly controversial, so I'll take silence as assent.
All this assuming we adopt Alternative 1.
Simon
| -----Original Message----- | From: ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> On | Behalf Of Joachim Breitner | Sent: 09 November 2020 16:28 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 20xx process | | Hi, | | Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: | > This is an effective argument; you've changed my mind. | > | > I'm now in favor of Joachim's simpler process. | | thanks, also for making me get more clarity on this as well. | | Is anyone still preferring Alternative 2, or should we take it off
| table? | | Is anyone not in favor of this proposal, or has questions, or shall we | declare consensus and merge it? | | | It seems that now is a good time to then actually do the first iteration of | the process – the State of Haskell survey data, once out, will be fresh, and | we'd be well in time for inclusion in the Spring release of GHC,
| (unless the 9.0 delay shifts things around… oh well, let’s just make sure we | have GHC2021 defined before or near the start of 2021, not late in
On Tue, Nov 10, 2020, at 06:18, Simon Peyton Jones via ghc-steering-committee wrote: the likely 9.1 that year
| :-)) | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com %7C125f812494db4225 | 0f4808d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63740536191896 | 4507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BfuHY7eCNyF5QlP7BfXDrNjxgWhoj%2FGI92S | esCy1gLA%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com %7C125f812494db42250f480 | 8d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637405361918974502% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=TyxdMqz%2FXFY9WYgZKdUHkFSQEvqRMJdoVEajh39JNs | A%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, I am not worried; this is a process outline, not a constitution. It’s enough for us to now say “yes, let’s try this” (which implies “if it goes badly, we’ll reconsider”) and just give it a try! We could replace
After these four weeks, the proposal with the current tally gets accepted by the secretary, and defines GHC20xx
with
After these four weeks, the proposal with the current tally gets, as a whole, voted on by the committee.
Is that your intention? Im inclined to be optimistic and hope that the process will lead to a result that does no need another vote. But I also think that if, at that time, you or anyone else on the committee says “hold a moment, this doesn’t feel right, can we have a final vote”, neither or nor the Chairs will deny that wish. As to how much discussion we have in phase two – again noting to worry about now. The mailing list will not be suddenly moderated, and if discussion comes up and turns out to be productive and fruitful, nobody will stop it. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Seems reasonable, let's do it!
On Fri, Nov 13, 2020 at 8:47 AM Joachim Breitner
Hi,
I am not worried; this is a process outline, not a constitution. It’s enough for us to now say “yes, let’s try this” (which implies “if it goes badly, we’ll reconsider”) and just give it a try!
We could replace
After these four weeks, the proposal with the current tally gets accepted by the secretary, and defines GHC20xx
with
After these four weeks, the proposal with the current tally gets, as a whole, voted on by the committee.
Is that your intention?
Im inclined to be optimistic and hope that the process will lead to a result that does no need another vote. But I also think that if, at that time, you or anyone else on the committee says “hold a moment, this doesn’t feel right, can we have a final vote”, neither or nor the Chairs will deny that wish.
As to how much discussion we have in phase two – again noting to worry about now. The mailing list will not be suddenly moderated, and if discussion comes up and turns out to be productive and fruitful, nobody will stop it.
Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I believe that we have a consensus in favour of acceptance, using Alternative 1.
Yell if you disagree; but otherwise Joachim you can merge.
Simon
| -----Original Message-----
| From: ghc-steering-committee
participants (6)
-
Eric Seidel
-
Iavor Diatchki
-
Joachim Breitner
-
Richard Eisenberg
-
Simon Peyton Jones
-
Spiwack, Arnaud