[ghc-steering-committee] Procedural change vote

[Richard Eisenberg]

I'll go with AB > B > A > 0

Thanks for organizing this!
Richard

> On May 2, 2019, at 2:01 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee