[ghc-steering-committee] Steering committee discussions

Wed Feb 21 13:54:13 UTC 2018

Hi,

I see a strong majority for keeping it this way.

I updated the section
https://github.com/ghc-proposals/ghc-proposals#committee-process
with Simon’s input and also generally made it reflect our de-facto
process.

Cheers,
Joachim

Am Mittwoch, den 21.02.2018, 09:14 +0000 schrieb 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
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180221/937019ad/attachment.sig>