[ghc-steering-committee] GHC 20xx process

[Richard Eisenberg]

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 <mail at joachim-breitner.de> 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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee