Hi,
Note that some PEPs are, still, mostly uncontroversial (PEP 574 is an example).
I agree with Nathaniel : PEP 572 is the poster child for lengthy, heated discussions. I'm still surprised you thought it was a good idea to discuss this. Perhaps it we tried to discourage syntax change and/or builtin change PEPs a little more we'd have less heated PEPs :-)
It would be *very* interesting if someone was willing to do some stats on PEPs over time: e.g. number of PEPs discussed every year, discussion length, number of discusssion participants. I actually expect overall PEP activity to have gone down since the 2000s.
Le 19/05/2018 à 01:41, Guido van Rossum a écrit :
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.)
Are you saying PEPs wouldn't even be *validated* by python-dev? If so, it's not a mere change to focus discussions, it's also a change in governance.
And while we may decide to change this piece of the governance model, the replacement process should IMO be something a little less vague than « discussion happens on Github with whoever happens to be interested or available ». Sorry if this is misrepresenting your position.
Regards
Antoine.
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 http://python.org whenever the peps repo structure changes).