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:
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@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@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee