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

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 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 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 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee