<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now that I am thinking about it we would then need a hopefully clear description</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
of the responsibilities of the sheperd before submission
</blockquote></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Our current statement of those responsibilities is here:<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><a href="https://github.com/ghc-proposals/ghc-proposals#committee-process-for-responding-to-a-proposal" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process-for-responding-to-a-proposal</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I wonder if we should make it clearer or more prominent. It says:</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>Shepherd should make a recommendation within weeks.</li><li>Committee should decide within a month after that</li></ul><div>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 <b>perhaps an author can request a shepherd to consult</b>, in advance of submitting the proposal. That puts the initiative on the author, to which we can (and should) be responsive. Would that work?</div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 29 Oct 2024 at 22:11, Malte Ott <<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2024-10-29 20:35, Adam Gundry wrote:<br>
> At the moment I usually wait until a proposal author explicitly submits the<br>
> proposal for committee consideration before assigning a shepherd. It is then<br>
> the shepherd's responsibility to make progress in a reasonable time.<br>
> <br>
> One change I've been wondering about is that we might try to identify<br>
> shepherds from the committee at an earlier stage, and/or encourage shepherds<br>
> to volunteer when they see an interesting proposal. The shepherd could then<br>
> help the original author respond to the discussion and move through the<br>
> process (perhaps including taking over the proposal if the original author<br>
> is no longer engaging). For example I'm effectively trying to do this on<br>
> #668. This might result in fewer proposals getting blocked indefinitely, at<br>
> the cost of more shepherding work for the committee. What do you all think?<br>
> <br>
> Adam<br>
<br>
Thank you Adam. I think this is a great idea. The proposal process is<br>
perceived daunting by many so we should try to be excellent and welcoming hosts.<br>
(Which does not mean compromising in rigor.)<br>
<br>
Main argument in favor is in my opinion, that in the last year the (felt)<br>
proposal throughput has decreased will the backlog of work for the committee is<br>
mostly empty. That is actually partially an accomplishment of the committee, but<br>
it also shows that we can probably do more to foster progress in GHC.<br>
<br>
The only problem I see - and it is the obvious one - is that we have<br>
historically had sheperds on the committee which were very unresponsive, for<br>
various (probably quite understandable reasons). With more responsibilities the<br>
gap between expectation and delivery would likely increase.<br>
<br>
So we should probably only do this if a clear majority of the committee is in<br>
favor. (Or more generally if we can still find enough volunteers to commit to<br>
doing this.) Otherwise we would promise something we can’t deliver.<br>
<br>
Now that I am thinking about it we would then need a hopefully clear description<br>
of the responsibilities of the sheperd before submission.<br>
I think it is sometimes kind of problematic, that there is supposed to be a<br>
community discussion during preparation of the proposal, but then the committee<br>
is only formally asked to look at it after that discussion happened.<br>
We should be part of the discussion. Simon has at times pointed us at proposals<br>
in the discussion phase, but maybe there is a slightly more structured way to<br>
do this.<br>
<br>
Best<br>
Malte<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>