[ghc-steering-committee] Procedural change vote

[Christopher Allen]

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



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