[ghc-steering-committee] committee deliberation discussions

[Simon Peyton Jones]

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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
Sent: 18 July 2019 13:58
To: Richard Eisenberg <rae at richarde.dev>
Cc: Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org>
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 <rae at richarde.dev<mailto:rae at 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 at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190718/21386530/attachment-0001.html>