[ghc-steering-committee] Procedural change vote

[Manuel M T Chakravarty]

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 <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