[ghc-steering-committee] Statistical analysis of GHC proposals

[Simon Peyton Jones]

>
> Now that I am thinking about it we would then need a hopefully clear
> description

of the responsibilities of the sheperd before submission


Our current statement of those responsibilities is here:
https://github.com/ghc-proposals/ghc-proposals#committee-process-for-responding-to-a-proposal

I wonder if we should make it clearer or more prominent.  It says:

   - Shepherd should make a recommendation within weeks.
   - Committee should decide within a month after that

I think it is helpful to have a clear moment at which the proposal is
submitted to the committee.  I agree that the involvement of a shepherd
prior to that point would be helpful.   But ideally the community at large
engages in discussion with the author to develop and refine their proposal.
I'm cautious about adding an obligation to proactively engage with all
proposals.  But *perhaps an author can request a shepherd to consult*, in
advance of submitting the proposal.  That puts the initiative on the
author, to which we can (and should) be responsive.  Would that work?

Simon

On Tue, 29 Oct 2024 at 22:11, Malte Ott <malte.ott at maralorn.de> wrote:

> On 2024-10-29 20:35, Adam Gundry wrote:
> > At the moment I usually wait until a proposal author explicitly submits
> the
> > proposal for committee consideration before assigning a shepherd. It is
> then
> > the shepherd's responsibility to make progress in a reasonable time.
> >
> > One change I've been wondering about is that we might try to identify
> > shepherds from the committee at an earlier stage, and/or encourage
> shepherds
> > to volunteer when they see an interesting proposal. The shepherd could
> then
> > help the original author respond to the discussion and move through the
> > process (perhaps including taking over the proposal if the original
> author
> > is no longer engaging). For example I'm effectively trying to do this on
> > #668. This might result in fewer proposals getting blocked indefinitely,
> at
> > the cost of more shepherding work for the committee. What do you all
> think?
> >
> > Adam
>
> Thank you Adam. I think this is a great idea. The proposal process is
> perceived daunting by many so we should try to be excellent and welcoming
> hosts.
> (Which does not mean compromising in rigor.)
>
> Main argument in favor is in my opinion, that in the last year the (felt)
> proposal throughput has decreased will the backlog of work for the
> committee is
> mostly empty. That is actually partially an accomplishment of the
> committee, but
> it also shows that we can probably do more to foster progress in GHC.
>
> The only problem I see - and it is the obvious one - is that we have
> historically had sheperds on the committee which were very unresponsive,
> for
> various (probably quite understandable reasons). With more
> responsibilities the
> gap between expectation and delivery would likely increase.
>
> So we should probably only do this if a clear majority of the committee is
> in
> favor. (Or more generally if we can still find enough volunteers to commit
> to
> doing this.) Otherwise we would promise something we can’t deliver.
>
> Now that I am thinking about it we would then need a hopefully clear
> description
> of the responsibilities of the sheperd before submission.
> I think it is sometimes kind of problematic, that there is supposed to be a
> community discussion during preparation of the proposal, but then the
> committee
> is only formally asked to look at it after that discussion happened.
> We should be part of the discussion. Simon has at times pointed us at
> proposals
> in the discussion phase, but maybe there is a slightly more structured way
> to
> do this.
>
> Best
> Malte
> _______________________________________________
> 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/20241030/90366e07/attachment.html>