| 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@haskell.org> | On Behalf Of Manuel M T Chakravarty | Sent: 04 May 2019 16:06 | To: Eric Seidel <eric@seidel.io> | Cc: ghc-steering-committee@haskell.org; Joachim Breitner <mail@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@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@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@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@joachim-breitner.de | >>> http://www.joachim-breitner.de/ | >>> | >>> _______________________________________________ | >>> ghc-steering-committee mailing list | >>> ghc-steering-committee@haskell.org | >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commi | >>> ttee | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit | >> tee | > | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee