[ghc-steering-committee] Steering committee discussions

[Simon Peyton Jones]

I don't feel strongly.

But then I think we should make it clear on the home page https://github.com/ghc-proposals/ghc-proposals  that

* What is the committee email address

* That it is publicly readable (but not writable?)

* That authors are strongly encouraged to follow the discussion about their
  proposal (during step 5), and use to improve their proposal, even
  if it is accepted.

Simon



|  -----Original Message-----
|  From: ghc-steering-committee [mailto:ghc-steering-committee-
|  bounces at haskell.org] On Behalf Of Manuel M T Chakravarty
|  Sent: 21 February 2018 02:23
|  To: Joachim Breitner <mail at joachim-breitner.de>
|  Cc: ghc-steering-committee at haskell.org
|  Subject: Re: [ghc-steering-committee] Steering committee discussions
|  
|  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-
|  committ
|  > ee
|  
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-
|  committee