The steering committee mailing list is actually open to everybody to post. So on the technical side, I don't see a problem. On the social side, though, I see more difficulties. It will tend to create more barrier of entries for authors to make successful proposal, for instance (one more thing to get subscribed to, I should also mention that I've noticed that people in their twenties tend to be pretty uncomfortable with mailing lists). So I think a hybrid discussion where the committee speaks among themselves, then come back to the author, is probably the best option. It does put some more work for the shepherd which needs to organise the back and forth. But hopefully not too much. Other than that, I agree with everything Richard says and proposes. I'll add one argument: there is no good reason why the public discussion on a proposal should stop just because the committee is having a chinwag about it. On Wed, Jul 17, 2019 at 8:31 PM Richard Eisenberg wrote:

On Jul 17, 2019, at 2:15 PM, Sandy Maguire wrote:

Could we grant proposal authors access to the mailing list during the discussion period?

I'm not sure how technically easy or hard this would be. We could always accept emails from authors on a case-by-case basis, simply by changing the mailman settings.

Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I recall a non-committee member posting to the list a few months ago to try to clarify something in our discussion. So it must be possible, I think it’s just much more obvious to the public that the list is primarily for committee discussions. I’ve also had trouble tracking which proposals are in an active committee deliberation. I’d favor some sort of hybrid model where we have discussions on the list, but don’t immediately reject proposals without inviting the author to address our concerns. Another option could be to invite the author to join the committee discussion on the list from the beginning. Then there’s a bit less back and forth between GitHub and the list. Sent from my iPhone

On Jul 18, 2019, at 08:03, Richard Eisenberg wrote:

I thought they were, but perhaps I'm wrong. I've contacted Ben, the owner of the list, to volunteer to become the new list owner since Ben's departure. Then we can decide how to turn the knobs.

Richard

...

On Jul 18, 2019, at 5:46 AM, Joachim Breitner wrote:

Hi,

Am Mittwoch, den 17.07.2019, 11:30 -0400 schrieb Richard Eisenberg:

...

Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected.

are they rejected? I hope not: The mailing list is the recommended point of contact if someone wants to talk to the committee:

https://github.com/ghc-proposals/ghc-proposals/#who-is-the-committee

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

The thing I like about using GitHub is that it means that all the substantial technical critique is one place. Since the bandwidth for proposals under discussion is high, I often think “I’ll wait till the dust has settled and the proposal has been revised and submitted to the committee before giving a thorough look.” But when I do look I often have technical questions. Using the mailing list for all SC discussion means that the technical discussion ends up in two places; and non-SCE members are prevented (by convention at least) from responding. In our SC-email -list phase, I found myself putting comments on Github and (tiresomely) posting a link to email list as well. Here’s a straw man idea. During the SC phase, * If SC members have technical comments or questions, they should post them to GitHub, where the author or anyone else can respond. * If members want to post evaluations such as “I think we should accept because...” or similarly for reject, use the email list. That would allow the authors and others to continue to contribute without impeding the committee’s evaluation work. After some reflection I like this a lot better than having all SC contributions on the SC list. It would mean that SC members might have to track those posts on GitHub. I think we should also make it clearer that “submit to the committee” means “I have revised the proposal, so that it reflects precisely what I propose”. Committee members are obligated to read the proposal, but it should not be necessary to read the discussion thread and they should not feel obliged to do so. (If, say, they ask a technical question that is answered further up, that question should by now be answered by the proposal itself.) Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 18 July 2019 13:58 To: Richard Eisenberg Cc: Simon Peyton Jones via ghc-steering-committee Subject: Re: [ghc-steering-committee] committee deliberation discussions Agree with Richard. I've had exactly the same concerns. One suggested tweak: we currently recommend that the shepherd discusses with the author if they plan to recommend rejection. I suggest we also expand that to the situation where the shepherd recommended acceptance, but the ensuing discussion led the committee towards a reject decision. In that case we should also go back to the author and given them a chance to rebut. Cheers Simon On Wed, 17 Jul 2019 at 16:31, Richard Eisenberg mailto:rae@richarde.dev> wrote: Hi committee, A few months ago, we decided to move final proposal deliberations to GitHub, knowing that this might not work. I'd like to claim: it's not working. Here is why: * Though I've configured my mail reader to flag messages that invite the committee to deliberate (and this works), later messages in the thread are not thus flagged (and I don't know how I would do so), and so I have to remember the proposals under deliberation manually. This is error-prone. * The requests to the community to be quiet during deliberation are not working. Some participants miss that message (it can be quite far up the thread!) and then participate. Others doubtless have something to say, but refrain... and then possibly get annoyed at those who don't heed the request. * Though I haven't collected data, my guess is that there has been less involvement from the committee in these discussions than the ones we had previously. I thus propose we move deliberations back to this list. However, some good has come from all this, so I wish to further propose: * Shepherds still post to the GitHub thread before making a "reject" recommendation. Then the shepherd and the author can work out their differences. * After emailing their recommendation, shepherds post a link to the email archive of the recommendation. This makes the deliberation more transparently a public phenomenon, while still focusing our (committee members') inboxes and our attention. The shepherd may also cross-post thoughts to the GitHub trail seeking more public or author feedback, if that is warranted. Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected. The owner of the list (who is that, anyway?) could then approve posts from proposal authors. This is an annoying manual step, but I don't think it will be burdensome in practice. What do we think? I'm happy to post a diff to the process descriptor if there is support. Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee