[ghc-steering-committee] committee deliberation discussions

[Simon Marlow]

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> 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
> 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/30b13b50/attachment.html>