[ghc-steering-committee] Procedural change vote

[Iavor Diatchki]

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
<mail at joachim-breitner.de> 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 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