AB > B > A > 0 I don't believe we should do nothing when someone has protested in good faith. I don't think GitHub discussion alone properly addresses their concerns and objections as well as the "B" option, but the best option overall seems to be AB to my mind. Transparency + responsiveness. On Wed, May 1, 2019 at 2:41 PM Simon Peyton Jones via ghc-steering-committee wrote:

AB > B > A > 0

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 01 May 2019 19:51 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Procedural change vote | | Dear committee, | | quick recap: one of our valued proposal writers, Matthew, expressed | unhappiness about our discussion proposal, with two important (but not the | only complains) issues the inability to react to a looming rejection, and | general bad insight into the discussion. Based on that feedback (thanks | again, Matt!) we discussed various options. Discussion has ebbed down, and | because it affects our policies, I’d like to hold a formal vote. | | There are three possible changes to consider, plus the option of doing | nothing. The options are | | A. All discussion on GitHub. | | Our process essentially stays the same, but all discussion happens | on GitHub. The mailing list is used only for status messages (new | proposal, new recommendation, result, regular summary messages). | During the deliberation phase, we will ask bystanders (non-members, | non-authors) to refrain from making the discussion noisy. | | Pros: Best visibility. Easy to get feedback from authors. No | fragmented discussion places. | | Cons: Less separation of discussion, less of a “protected space” for | us”, possibly more noise, can’t technically enforce that nobody else | comments | | B. Shepherd discussion looming rejection with the authors first. | | This keeps the discussion on the mailing list, but the shepherd, | before recommending to reject a proposal, needs to _first_ lay out | their reasons on GitHub, wait for the authors to rebut, and possibly | discusses with them. | | I spelled out possible wording of this already on | https://github.com/ghc-proposals/ghc-proposals/pull/221 | | Pros: Authors are taken more serious, have a say, while keeping our | discussion separate | | Cons: More work for shepherd. Incentives are set to lean towards | just recommending acceptance. Authors don't get to rebut if shepherd | wants to accept, but then the committee leans towards rejection. | | AB. The combination of the two above | | I.e. author rebuttal before shepherd recommends rejection | but then _also_ the committee discussion on GitHub | | Also spelled out already on | https://github.com/ghc-proposals/ghc-proposals/pull/225 | | 0. Do nothing. | | | Please vote by responding to this thread with a linear ordering of your | preferences. For example, my vote is | | AB > B > A > 0 | | Please cast a vote until Sunday May 5th. You can change your vote any time | until voting is concluded. Voting will be concluded when no votes have | been cast, but not before Sunday May 5th. We will accept the option that | is preferred over any other option by a majority of the votes. | | | 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

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

AB > B > A > 0 On Wed, 1 May 2019 at 23:54, Eric Seidel wrote:

AB > B > A > 0

...

AB > B > A > 0

I don't believe we should do nothing when someone has protested in good faith.

I don't think GitHub discussion alone properly addresses their concerns and objections as well as the "B" option, but the best option overall seems to be AB to my mind. Transparency + responsiveness.

On Wed, May 1, 2019 at 2:41 PM Simon Peyton Jones via ghc-steering-committee wrote:

...

AB > B > A > 0

Simon

| -----Original Message----- | From: ghc-steering-committee <

ghc-steering-committee-bounces@haskell.org>

...

| On Behalf Of Joachim Breitner | Sent: 01 May 2019 19:51 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Procedural change vote | | Dear committee, | | quick recap: one of our valued proposal writers, Matthew, expressed | unhappiness about our discussion proposal, with two important (but not the | only complains) issues the inability to react to a looming rejection, and | general bad insight into the discussion. Based on that feedback (thanks | again, Matt!) we discussed various options. Discussion has ebbed down, and | because it affects our policies, I’d like to hold a formal vote. | | There are three possible changes to consider, plus the option of doing | nothing. The options are | | A. All discussion on GitHub. | | Our process essentially stays the same, but all discussion happens | on GitHub. The mailing list is used only for status messages (new | proposal, new recommendation, result, regular summary messages). | During the deliberation phase, we will ask bystanders (non-members, | non-authors) to refrain from making the discussion noisy. | | Pros: Best visibility. Easy to get feedback from authors. No | fragmented discussion places. | | Cons: Less separation of discussion, less of a “protected space” for | us”, possibly more noise, can’t technically enforce that nobody else | comments | | B. Shepherd discussion looming rejection with the authors first. | | This keeps the discussion on the mailing list, but the shepherd, | before recommending to reject a proposal, needs to _first_ lay out | their reasons on GitHub, wait for the authors to rebut, and

...

...

| discusses with them. | | I spelled out possible wording of this already on | https://github.com/ghc-proposals/ghc-proposals/pull/221 | | Pros: Authors are taken more serious, have a say, while keeping our | discussion separate | | Cons: More work for shepherd. Incentives are set to lean towards | just recommending acceptance. Authors don't get to rebut if shepherd | wants to accept, but then the committee leans towards rejection. | | AB. The combination of the two above | | I.e. author rebuttal before shepherd recommends rejection | but then _also_ the committee discussion on GitHub | | Also spelled out already on | https://github.com/ghc-proposals/ghc-proposals/pull/225 | | 0. Do nothing. | | | Please vote by responding to this thread with a linear ordering of your | preferences. For example, my vote is | | AB > B > A > 0 | | Please cast a vote until Sunday May 5th. You can change your vote any time | until voting is concluded. Voting will be concluded when no votes have | been cast, but not before Sunday May 5th. We will accept the option

On Wed, May 1, 2019, at 16:13, Christopher Allen wrote: possibly that

...

...

| is preferred over any other option by a majority of the votes. | | | 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

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ 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

I'll go with AB > B > A > 0 Thanks for organizing this! Richard

On May 2, 2019, at 2:01 PM, Iavor Diatchki wrote:

Of the given options I'll pick: AB > A > B > 0

Qualifier: I like option A, with the modification that since we are discussing things on Github, the proposer can jump in and clarify stuff, if they feel that the committee is misunderstanding something.

-Iavor

On Wed, May 1, 2019 at 11:51 AM Joachim Breitner wrote:

...

Dear committee,

quick recap: one of our valued proposal writers, Matthew, expressed unhappiness about our discussion proposal, with two important (but not the only complains) issues the inability to react to a looming rejection, and general bad insight into the discussion. Based on that feedback (thanks again, Matt!) we discussed various options. Discussion has ebbed down, and because it affects our policies, I’d like to hold a formal vote.

There are three possible changes to consider, plus the option of doing nothing. The options are

A. All discussion on GitHub.

Our process essentially stays the same, but all discussion happens on GitHub. The mailing list is used only for status messages (new proposal, new recommendation, result, regular summary messages). During the deliberation phase, we will ask bystanders (non-members, non-authors) to refrain from making the discussion noisy.

Pros: Best visibility. Easy to get feedback from authors. No fragmented discussion places.

Cons: Less separation of discussion, less of a “protected space” for us”, possibly more noise, can’t technically enforce that nobody else comments

B. Shepherd discussion looming rejection with the authors first.

This keeps the discussion on the mailing list, but the shepherd, before recommending to reject a proposal, needs to _first_ lay out their reasons on GitHub, wait for the authors to rebut, and possibly discusses with them.

I spelled out possible wording of this already on https://github.com/ghc-proposals/ghc-proposals/pull/221

Pros: Authors are taken more serious, have a say, while keeping our discussion separate

Cons: More work for shepherd. Incentives are set to lean towards just recommending acceptance. Authors don't get to rebut if shepherd wants to accept, but then the committee leans towards rejection.

AB. The combination of the two above

I.e. author rebuttal before shepherd recommends rejection but then _also_ the committee discussion on GitHub

Also spelled out already on https://github.com/ghc-proposals/ghc-proposals/pull/225

0. Do nothing.

Please vote by responding to this thread with a linear ordering of your preferences. For example, my vote is

AB > B > A > 0

Please cast a vote until Sunday May 5th. You can change your vote any time until voting is concluded. Voting will be concluded when no votes have been cast, but not before Sunday May 5th. We will accept the option that is preferred over any other option by a majority of the votes.

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

The difficulty of keeping up with GitHub discussions is something a few of us have raised concerns about. On the GitHub discussion, someone suggested editing the title of a proposal once it’s been submitted to the committee (eg to add “under review”). This would let us create an email filter for committee-related notifications. Would that work for you? Sent from my iPhone

On May 4, 2019, at 08:15, Manuel M T Chakravarty wrote:

B > 0 > A > AB

(It’s boring if everybody votes the same way. No, seriously. I have trouble finding the time to follow the discussion anyway. If it is in my mailbox, I go through the emails that catch my attention. If it is on GitHub, I’ll probably completely forget about it. GitHub email notifications seems not very helpful here as I get so many of them already, so they go into a special dev-related mailbox…)

Manuel

...

Am 01.05.2019 um 20:51 schrieb Joachim Breitner :

Dear committee,

quick recap: one of our valued proposal writers, Matthew, expressed unhappiness about our discussion proposal, with two important (but not the only complains) issues the inability to react to a looming rejection, and general bad insight into the discussion. Based on that feedback (thanks again, Matt!) we discussed various options. Discussion has ebbed down, and because it affects our policies, I’d like to hold a formal vote.

There are three possible changes to consider, plus the option of doing nothing. The options are

A. All discussion on GitHub.

Our process essentially stays the same, but all discussion happens on GitHub. The mailing list is used only for status messages (new proposal, new recommendation, result, regular summary messages). During the deliberation phase, we will ask bystanders (non-members, non-authors) to refrain from making the discussion noisy.

Pros: Best visibility. Easy to get feedback from authors. No fragmented discussion places.

Cons: Less separation of discussion, less of a “protected space” for us”, possibly more noise, can’t technically enforce that nobody else comments

B. Shepherd discussion looming rejection with the authors first.

This keeps the discussion on the mailing list, but the shepherd, before recommending to reject a proposal, needs to _first_ lay out their reasons on GitHub, wait for the authors to rebut, and possibly discusses with them.

I spelled out possible wording of this already on https://github.com/ghc-proposals/ghc-proposals/pull/221

Pros: Authors are taken more serious, have a say, while keeping our discussion separate

Cons: More work for shepherd. Incentives are set to lean towards just recommending acceptance. Authors don't get to rebut if shepherd wants to accept, but then the committee leans towards rejection.

AB. The combination of the two above

I.e. author rebuttal before shepherd recommends rejection but then _also_ the committee discussion on GitHub

Also spelled out already on https://github.com/ghc-proposals/ghc-proposals/pull/225

0. Do nothing.

Please vote by responding to this thread with a linear ordering of your preferences. For example, my vote is

AB > B > A > 0

Please cast a vote until Sunday May 5th. You can change your vote any time until voting is concluded. Voting will be concluded when no votes have been cast, but not before Sunday May 5th. We will accept the option that is preferred over any other option by a majority of the votes.

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

| I like GitHub for code, but for the discussion we are having, I don’t | think the UI is really made for that. Why do you think email is better? I suppose that each email often includes a complete copy of the thread, which seems useful, if wasteful. Is it that that makes the difference for you? Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Manuel M T Chakravarty | Sent: 04 May 2019 16:06 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org; Joachim Breitner | Subject: Re: [ghc-steering-committee] Procedural change vote | | If we decide to move the discussion to GitHub, I will certainly try that. | | It can usually only serve as a reminder to hop onto GitHub again, though, | as the GitHub comment notifications usually lack context. | | In a long thread over a longer timespan, it is annoying to keep track of | what you have read already and what’s new. I also find that a lot of | people are not very consistent about citing the comments they are replying | to, which makes it hard to disentangle multiple interleaved subthreads. | | I like GitHub for code, but for the discussion we are having, I don’t | think the UI is really made for that. | | Cheers, | Manuel | | > Am 04.05.2019 um 14:28 schrieb Eric Seidel : | > | > The difficulty of keeping up with GitHub discussions is something a few | of us have raised concerns about. On the GitHub discussion, someone | suggested editing the title of a proposal once it’s been submitted to the | committee (eg to add “under review”). This would let us create an email | filter for committee-related notifications. | > | > Would that work for you? | > | > Sent from my iPhone | > | >> On May 4, 2019, at 08:15, Manuel M T Chakravarty | wrote: | >> | >> B > 0 > A > AB | >> | >> (It’s boring if everybody votes the same way. No, seriously. I have | >> trouble finding the time to follow the discussion anyway. If it is in | >> my mailbox, I go through the emails that catch my attention. If it is | >> on GitHub, I’ll probably completely forget about it. GitHub email | >> notifications seems not very helpful here as I get so many of them | >> already, so they go into a special dev-related mailbox…) | >> | >> Manuel | >> | >>> Am 01.05.2019 um 20:51 schrieb Joachim Breitner : | >>> | >>> Dear committee, | >>> | >>> quick recap: one of our valued proposal writers, Matthew, expressed | >>> unhappiness about our discussion proposal, with two important (but | >>> not the only complains) issues the inability to react to a looming | >>> rejection, and general bad insight into the discussion. Based on | >>> that feedback (thanks again, Matt!) we discussed various options. | >>> Discussion has ebbed down, and because it affects our policies, I’d | >>> like to hold a formal vote. | >>> | >>> There are three possible changes to consider, plus the option of | >>> doing nothing. The options are | >>> | >>> A. All discussion on GitHub. | >>> | >>> Our process essentially stays the same, but all discussion happens | >>> on GitHub. The mailing list is used only for status messages (new | >>> proposal, new recommendation, result, regular summary messages). | >>> During the deliberation phase, we will ask bystanders (non-members, | >>> non-authors) to refrain from making the discussion noisy. | >>> | >>> Pros: Best visibility. Easy to get feedback from authors. No | >>> fragmented discussion places. | >>> | >>> Cons: Less separation of discussion, less of a “protected space” for | >>> us”, possibly more noise, can’t technically enforce that nobody else | >>> comments | >>> | >>> B. Shepherd discussion looming rejection with the authors first. | >>> | >>> This keeps the discussion on the mailing list, but the shepherd, | >>> before recommending to reject a proposal, needs to _first_ lay out | >>> their reasons on GitHub, wait for the authors to rebut, and possibly | >>> discusses with them. | >>> | >>> I spelled out possible wording of this already on | >>> https://github.com/ghc-proposals/ghc-proposals/pull/221 | >>> | >>> Pros: Authors are taken more serious, have a say, while keeping our | >>> discussion separate | >>> | >>> Cons: More work for shepherd. Incentives are set to lean towards | >>> just recommending acceptance. Authors don't get to rebut if shepherd | >>> wants to accept, but then the committee leans towards rejection. | >>> | >>> AB. The combination of the two above | >>> | >>> I.e. author rebuttal before shepherd recommends rejection but then | >>> _also_ the committee discussion on GitHub | >>> | >>> Also spelled out already on | >>> https://github.com/ghc-proposals/ghc-proposals/pull/225 | >>> | >>> 0. Do nothing. | >>> | >>> | >>> Please vote by responding to this thread with a linear ordering of | >>> your preferences. For example, my vote is | >>> | >>> AB > B > A > 0 | >>> | >>> Please cast a vote until Sunday May 5th. You can change your vote | >>> any time until voting is concluded. Voting will be concluded when no | >>> votes have been cast, but not before Sunday May 5th. We will accept | >>> the option that is preferred over any other option by a majority of | >>> the votes. | >>> | >>> | >>> 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-commi | >>> ttee | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit | >> tee | > | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

| Because people are much better at providing context in email and my mail | reader keeps track of what I have read and what I haven’t read yet. Yes, those are good points. Specifically, perhaps they'd be good suggestions for improving GitHub (or GitLab)'s interface. Simon | -----Original Message----- | From: Manuel M T Chakravarty | Sent: 06 May 2019 20:59 | To: Simon Peyton Jones | Cc: Eric Seidel ; ghc-steering-committee@haskell.org; | Joachim Breitner | Subject: Re: [ghc-steering-committee] Procedural change vote | | > Am 06.05.2019 um 18:25 schrieb Simon Peyton Jones | : | > | > | I like GitHub for code, but for the discussion we are having, I | > | don’t think the UI is really made for that. | > | > Why do you think email is better? | | Because people are much better at providing context in email and my mail | reader keeps track of what I have read and what I haven’t read yet. | | It is a lot harder to see on GitHub what comment another comment is | referring to. | | > I suppose that each email often includes a complete copy of the thread, | which seems useful, if wasteful. Is it that that makes the difference for | you? | | I haven’t quoted everything, but just the bits I am responding to. | | GitHub allows you to quote, too, but you need to explicitly do it (by | copying text and adding markup or by highlighting it and pressing ’r’). | People often don’t do that, but in email it is the default and done by | your email reader. | | Manuel

Hi, Am Montag, den 06.05.2019, 18:32 +0200 schrieb Joachim Breitner:

Am Mittwoch, den 01.05.2019, 20:51 +0200 schrieb Joachim Breitner:

...

There are three possible changes to consider, plus the option of doing nothing. The options are

A. All discussion on GitHub. B. Shepherd discussion looming rejection with the authors first. AB. The combination of the two above 0. Do nothing.

Votes so far: AB > B > A > 0 Joachim, Simon, Simon, Chris, Eric, Richard AB > A > B > 0 Vitaly, Iavor B > 0 > A > AB Manuel

No vote from Ben, but I think we can go ahead with AB, which is already ready to be merged at https://github.com/ghc-proposals/ghc-proposals/pull/225

Merged, this is now official. Please review the section https://github.com/ghc-proposals/ghc-proposals#committee-process to have an overview of the new process, and start discussing things on Github. We can re-evaluate whether this was a good idea in a few months. I re-labeled the following proposal as waiting for shepherd recommendation: Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Type-annotated Quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/