Re: [ghc-steering-committee] Procedural change vote

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