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

[Joachim Breitner]

Hi,

Simon, Richad and Chris in support. Any other opinions? Or should I
just merge this?

Cheers,
Joachim

Am Samstag, dem 06.08.2022 um 12:21 +0100 schrieb 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
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/