[ghc-steering-committee] Steering committee discussions

[Manuel M T Chakravarty]

I am sorry, but I am against moving the committee discussion to GitHub. This is for the following reasons:

* I don’t think, we will gain anything by moving to GitHub. Nothing is lost on the email list. The proposal author and anybody else can follow along as this is a public list.

* Proposals have a life cycle: writing, public commenting, refinement, and finally committee discussion (and then it may go around again if the proposal needs to be revised). Having the public, collaborative writing, public commenting, refinement steps on GitHub and the somewhat closed committee decision process on different media makes the mode change very explicit, which is good.

* I get a lot of email from GitHub. Most of it I deleted right away (including most ghc-proposal GitHub messages). Having the committee decision process by email makes it clear when I need to pay attention (without having to consult GitHub ticket labels).

* The Shepard has an incentive to briefly summarise the outcome of the committee discussion on GitHub after the decision is made (if it is all on GitHub, everybody needs to wade though everything).

* On GitHub it is much harder to see which comments are new, especially if the thread is long, because there was already a long community discussion phase.

* The committee discussion may be interleaved with additional public comments, because anybody else can comment, too, at the time, making it even harder to distinguish the committee discussion.

Cheers,
Manuel

> 21.02.2018 00:58 Joachim Breitner <mail at joachim-breitner.de>:
> 
> Hi,
> 
> Am Dienstag, den 20.02.2018, 11:19 +0000 schrieb Simon Peyton Jones:
>> The thread below is a case in point.  Good stuff from Joachim, but
>> not visible to the author or the world; result, lost insights.
> 
> actually, in this case, I did bring this up in the discussion on
> GitHub; the author was not convinced and brought the proposal forward
> anyways, so now I am trying to sway the committee instead :-)
> 
> 
>> Suggestion: could we hold all the committee debase on the proposal
>> thread, thereby allowing the author to chime in if need be?   There
>> might be some messages we want to be private -- very well, use the
>> email list for those, but my sense is that 95% are absolutely
>> publishable.
> 
> This list is public, do not post private stuff here! It is just a bit
> “less visible” and less noisy.
> 
> Having technical discussions on GitHub is a reasonable thing to do. It
> will be more noisy, i.e. many people chiming in, but that can of course
> also be a good thing.
> 
>> What changes when the shepherd kicks in?  Answer: the committee
>> switches from observer (and contribute if you like) mode, to
>> obligation-to-consider mode.
> 
> Correct.
> 
> Shall we still require mails to the list when
> 
> * A proposal was put forward
> * A shepherd makes a suggestions, and invites the committee to 
>   comment (now on GitHub)
> * The shepherd or the secretary observes consensus, and declares
>   a decision?
> 
> 
> (This will actually make my life of assembling the “Status” mails
> easier, but it will make it harder to determine consensus.)
> 
> All in all, I’m up for trying it out!
> 
> 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