On Fri, May 18, 2018 at 3:58 PM, Ivan Levkivskyi <levkivs...@gmail.com> wrote:
> I would like to clarify, what would be a typical time-line for a PEP? Will > it look like this: > > 0. Preliminary discussions to determine whether an idea is PEP-worthy (can > happen anywhere, python-ideas, SIGs, even offline) > 1. A PEP number is requested by a champion and assigned by a PEP editor > (in python/peps repo) > I expect some proposals to get stuck before they're ever in a state acceptable even as draft PEP, so I'd like to put off requesting a PEP number as long as possible. > 2. PEP is drafted and discussed by a narrow circle of interested > participants (happens in a separate repo) > 3. When PEP is ready and polished make a PR to python/peps repo, and post > it to python-dev to get feedback (if any) from a wider audience > I expect there to be a long trajectory where the PEP does exist in the peps repo but should still be discussed in its own repo. Mentions on python-dev should be limited to the occasional link to the PEP's own repo, with strongly worded requests to go to that repo to provide feedback. > 4. If reasonable objections appear at this step, go to step 2 > The process should be clear that objections posted to python-dev will be ignored -- only objections posted to the PEP's own repo's issue tracker will be considered. > 5. Repeat steps 2-4 until accepted/rejected/deferred > > Is this what you propose? Or you want to completely avoid posting to > python-dev? > I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.) There are probably some other parts needed too, e.g. guidelines as to when a PEP is considered ripe for copying to the peps repo (and scripts/bots to make repeated copies easy -- e.g. there could be a bot that copies a PEP from that PEP's own repo to the peps repo each time a commit is made to the master branch in its own repo). There could also be guidelines to ensure a PEP is in a fairly non-controversial state (probably using the IETF's motto "rough consensus and working code") before being considered for approval. There's definitely some time when a PEP has an assigned number but is still controversial -- during that state debate on python-dev should be strictly redirected to the PEP's own repo. For some PEPs it may make sense to assign a senior reviewer who decides what's considered non-controversial. We can borrow more from the IETF process for RFCs: https://www.rfc-editor.org/pubprocess/ --Guido PS. Carol: Jupyter's process looks great! I just don't have the guts to propose any serious changes to the physical logistics of publishing PEPs, since changes to the structure of the peps repo are so hard. We still haven't converted all PEPs to .rst format, despite efforts by Mariatta and others, and attempts to move all PEPs to a subdirectory have also failed, due to perpetual lack of resources to complete the task (and e.g. the need to update scripts on python.org whenever the peps repo structure changes). > > -- > Ivan > > > > On 18 May 2018 at 18:25, Guido van Rossum <gu...@python.org> wrote: > >> Discussing PEPs on python-dev and python-ideas is clearly not scalable >> any more. (Even python-committers probably doesn't scale too well. :-) >> >> I wonder if it would make sense to require that for each PEP a new GitHub >> *repo* be created whose contents would just be a draft PEP and whose issue >> tracker and PR manager would be used to debate the PEP and propose specific >> changes. >> >> This way the discussion is still public: when the PEP-specific repo is >> created the author(s) can notify python-ideas, and when they are closer to >> submitting they can notify python-dev, but the discussion doesn't attract >> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's >> much easier for outsiders who want to learn more about the proposal to find >> all relevant discussion. >> >> PEP authors may also choose to use a different repo hosting site, e.g. >> Bitbucket or GitLab. We can provide a script that allows checking the >> formatting of the PEP easily (basically pep2html.py from the peps repo). >> >> Using a separate repo per PEP has the advantage that people interested in >> a topic can subscribe to all traffic in that repo -- if we were to use the >> tracker of the peps repo you would have to subscribe to all peps traffic. >> >> Thoughts? (We can dogfood this proposal too, if there's interest. :-) >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> _______________________________________________ >> python-committers mailing list >> python-committers@python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ >> >> > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
