jupyter/enhancement-proposals

Accepting proposals as drafts

rgbkrk opened this issue · 6 comments

rgbkrk commented

Rather than go back and forth in a PR to accept a proposal, how about we accept a PR and call it a draft state. When we've accepted it, we make a PR to update the status. If it's deprecated, not implemented, etc. we make another PR to address that.

minrk commented

Fine with me.

captainsafia commented

I'll update the wording of the guidelines to reflect this later today.

rgbkrk commented

Cool. I'm thinking similar to how https://github.com/tc39/ecma262 works, though they call them stages. Taking parallels to other projects, zeromq uses:

  • draft: Has at least one implementation
  • stable: Deployed to real users
  • legacy: Being replaced by newer specs
  • retired: Replaced, no longer used
  • deleted: Abandoned before becoming stable

Some proposals end up as PRs to individual repos (e.g. jupyter/notebook, jupyter/nbformat) while others may end up as wholly new projects. I'm not sure what this means for how we phrase these.

ellisonbg commented

Maybe move this process discussion over to the governance repo?

Like the direction though...

nealmcb commented

How might this relate to #27?

rgbkrk commented

Extremely related. Since that's a newer discussion with the same folks, I'll close this one.