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