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