[ghc-steering-committee] Procedural change vote

[Simon Peyton Jones]

| I like GitHub for code, but for the discussion we are having, I don’t
| think the UI is really made for that.

Why do you think email is better?  I suppose that each email often includes a complete copy of the thread, which seems useful, if wasteful.  Is it that that makes the difference for you?

Simon

| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
| On Behalf Of Manuel M T Chakravarty
| Sent: 04 May 2019 16:06
| To: Eric Seidel <eric at seidel.io>
| Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-
| breitner.de>
| Subject: Re: [ghc-steering-committee] Procedural change vote
| 
| If we decide to move the discussion to GitHub, I will certainly try that.
| 
| It can usually only serve as a reminder to hop onto GitHub again, though,
| as the GitHub comment notifications usually lack context.
| 
| In a long thread over a longer timespan, it is annoying to keep track of
| what you have read already and what’s new. I also find that a lot of
| people are not very consistent about citing the comments they are replying
| to, which makes it hard to disentangle multiple interleaved subthreads.
| 
| I like GitHub for code, but for the discussion we are having, I don’t
| think the UI is really made for that.
| 
| Cheers,
| Manuel
| 
| > Am 04.05.2019 um 14:28 schrieb Eric Seidel <eric at seidel.io>:
| >
| > The difficulty of keeping up with GitHub discussions is something a few
| of us have raised concerns about. On the GitHub discussion, someone
| suggested editing the title of a proposal once it’s been submitted to the
| committee (eg to add “under review”). This would let us create an email
| filter for committee-related notifications.
| >
| > Would that work for you?
| >
| > Sent from my iPhone
| >
| >> On May 4, 2019, at 08:15, Manuel M T Chakravarty <chak at justtesting.org>
| wrote:
| >>
| >> 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-commi
| >>> ttee
| >>
| >> _______________________________________________
| >> ghc-steering-committee mailing list
| >> ghc-steering-committee at haskell.org
| >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit
| >> tee
| >
| 
| _______________________________________________
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
| https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee