[ghc-steering-committee] Procedural change vote

[Vitaly Bragilevsky]

Hi Joachim,

my vote is

AB > A > B > 0

Regards,
Vitaly


ср, 1 мая 2019 г. в 21:51, Joachim Breitner <mail at joachim-breitner.de>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190501/0ffb505b/attachment.html>