Much as I like GitHub for some kinds of work, I don't think I'd move this sort of thing to GitHub. Attached screenshot is of the gmail folder my emails from GitHub get redirected to. I get many and very few of them are something I should look at. I clear my notifications using the GitHub notifications menu rather than via email, yet email is the primary way I'd consume to respond to anything on this mailing list. Naturally, YMMV. --- Chris On Tue, Feb 20, 2018 at 8:23 PM, Manuel M T Chakravarty wrote:

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 :

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-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com

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 | 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 : | > | > 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

Great, thanks.

Am 22.02.2018 um 00:54 schrieb Joachim Breitner :

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@haskell.org] On Behalf Of Manuel M T Chakravarty Sent: 21 February 2018 02:23 To: Joachim Breitner 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 :

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- 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-committee