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
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