[ghc-steering-committee] Procedural change vote

[Simon Peyton Jones]

AB > B > A > 0

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Joachim Breitner
| Sent: 01 May 2019 19:51
| To: ghc-steering-committee <ghc-steering-committee at haskell.org>
| 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 at joachim-breitner.de
|   http://www.joachim-breitner.de/