[ghc-steering-committee] Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ

[Chris Dornan]

I wouldn’t worry too much about the optics of approving proposals that don’t get implemented — if that were the only issue I wouldn’t object to having a heap of proposals ready to be implemented by a keen implementor.  Healthy backlogs are better than the alternative in my view.

Having proposals in the twilight zone, absorbing committee time and frustrating proposers that are never likely to get implemented is not good and this proposal should help with that so I support it.

Chris

> On 2022-08-05, at 13:34, Richard Eisenberg <lists at richarde.dev> wrote:
> 
> I support this proposal. Having many accepted but unimplemented proposals is not a good look. If need be, we can create a ready-for-submission-but-lacking-implementor label so that potential contributors can find ideas, but I favor waiting for a demand before creating that structure.
> 
> Simon's idea of un-accepting proposals is interesting, but should probably not get tucked into this idea.
> 
> Richard
> 
>> On Aug 4, 2022, at 7:02 PM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>> 
>> Dear committee,
>> 
>> See https://github.com/ghc-proposals/ghc-proposals/pull/517 
>> 
>> Joachim suggests that a prerequisite for submitting a proposal to the committee is that someone is offering to implement it.
>> 	• This would avoid us spending precious cycles debating a proposal that no one is going to implement.
>> 	• An offer of implementation cannot be binding, so it is something of a soft constraint.  (An author could cynically volunteer themselves, without having any intention of carrying through, but we expect better of the Haskell community.)
>> 	• We should stress that nothing stops someone creating a proposal, making a PR, and debating it with the community, all without an implementor.  Only when it is submitted to the committee for review and approval is an implementor required.
>> 	• Joachim suggests that this replaces the (never used) "Endorsements" section.
>> I wonder if a proposal that is accepted but not implemented (for whatever reason) should be un-accepted after, say, a year.  That would provide some incentive to get on with it; and the language context might be different by then.
>> 
>> I suggest that we debate the principle first.  I have a few word-smithing suggestions, but principles first!
>> 
>> On balance I recommend acceptance, with the above nuances clarified.
>> 
>> Simon
>> 
>> On Mon, 1 Aug 2022 at 07:50, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> Dear Committee,
>> 
>> I have submitted a meta-proposal to require implementors to be named
>> before proposal submission, to focus on those proposals that are likely
>> to be actually implemented.
>> 
>> https://github.com/ghc-proposals/ghc-proposals/pull/517
>> 
>> Because this is a process-related proposal, I’d like to ask Simon to shepherd it.
>> 
>> Please guide us to a conclusion as outlined in 
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> 
>> Thanks,
>> Joachim
>> 
>> 
>> 
>> -- 
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee