With PEPs now being hosted on github, is there any specific process for handling reviews/discussions on the github tracker? PEP 1 doesn't mention the matter, other than to note that discussions "may also occur on a list other than python-dev" although the approach of having a Discussions-To header doesn't really work well there.
My suggestion (which is basically what we've been doing with PEP 514) is that PEP discussions are acceptable on the tracker, but comments on the core list should be monitored as well (and responded to on-list). When the PEP is ready for acceptance, a posting of the final version should be made to the list, and the acceptance email should be posted to the list (so that there's a permanent record of the acceptance, which can be linked to in the PEP).
Is that reasonable? Does it need an update to PEP 1 to cover it? If so, should I post a PR for PEP 1? Or is it obvious enough to be assumed without needing the bureaucracy of updating PEP 1?
Paul
On Jul 23, 2016, at 08:15 PM, Paul Moore wrote:
With PEPs now being hosted on github, is there any specific process for handling reviews/discussions on the github tracker? PEP 1 doesn't mention the matter, other than to note that discussions "may also occur on a list other than python-dev" although the approach of having a Discussions-To header doesn't really work well there.
I think it could. A Discussions-To header could point to the tracker issue URL; it doesn't have to be an email address. You just want to give people a pointer for where the discussion is happening, or has happened.
My suggestion (which is basically what we've been doing with PEP 514) is that PEP discussions are acceptable on the tracker, but comments on the core list should be monitored as well (and responded to on-list). When the PEP is ready for acceptance, a posting of the final version should be made to the list, and the acceptance email should be posted to the list (so that there's a permanent record of the acceptance, which can be linked to in the PEP).
Is that reasonable? Does it need an update to PEP 1 to cover it? If so, should I post a PR for PEP 1? Or is it obvious enough to be assumed without needing the bureaucracy of updating PEP 1?
It seems generally reasonable to me.
My own opinion is that PEPs should not be accepted without at least some interactions on python-dev. For PEPs where the primary discussion happens on that list, no Discussions-To should be need. Where most of the discussion happens elsewhere (e.g. on a topic sig), the Discussions-To header points the way, but regular postings on python-dev helps make sure that people are aware of it.
I don't think we need any substantive changes to PEP 1, but if you want to suggest some better wording to make this new avenue of PEP development more clear, please do submit a PR against PEP 1.
Cheers, -Barry
On Sat, Jul 23, 2016, 12:15 Paul Moore p.f.moore@gmail.com wrote:
With PEPs now being hosted on github, is there any specific process for handling reviews/discussions on the github tracker? PEP 1 doesn't mention the matter, other than to note that discussions "may also occur on a list other than python-dev" although the approach of having a Discussions-To header doesn't really work well there.
My suggestion (which is basically what we've been doing with PEP 514) is that PEP discussions are acceptable on the tracker, but comments on the core list should be monitored as well (and responded to on-list).
The problem with this is it bifurcates the discussion. I do think that all grammar fixes and such like that should be on GitHub as a PR. And I do think PEPs still need to be announced here. But whether the discussion happens here or GitHub, I don't think we should split it.
-Brett
When the PEP is ready for acceptance, a posting of the final version
should be made to the list, and the acceptance email should be posted to the list (so that there's a permanent record of the acceptance, which can be linked to in the PEP).
Is that reasonable? Does it need an update to PEP 1 to cover it? If so, should I post a PR for PEP 1? Or is it obvious enough to be assumed without needing the bureaucracy of updating PEP 1?
Paul
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/
On Sat, Jul 23, 2016, 13:17 Brett Cannon brett@python.org wrote:
On Sat, Jul 23, 2016, 12:15 Paul Moore p.f.moore@gmail.com wrote:
With PEPs now being hosted on github, is there any specific process for handling reviews/discussions on the github tracker? PEP 1 doesn't mention the matter, other than to note that discussions "may also occur on a list other than python-dev" although the approach of having a Discussions-To header doesn't really work well there.
My suggestion (which is basically what we've been doing with PEP 514) is that PEP discussions are acceptable on the tracker, but comments on the core list should be monitored as well (and responded to on-list).
The problem with this is it bifurcates the discussion. I do think that all grammar fixes and such like that should be on GitHub as a PR. And I do think PEPs still need to be announced here. But whether the discussion happens here or GitHub, I don't think we should split it.
And I should mention that the reason I think it worked with the latest PEP is people seemed fine wirh the overall pep while you and Steve hashed out the finer details on GitHub. If you want to say general discussion is here and I once it's down to the finer details with the pronouncer on GitHub then that seems fine as well.
-Brett
When the PEP is ready for acceptance, a posting of the final version
should be made to the list, and the acceptance email should be posted to the list (so that there's a permanent record of the acceptance, which can be linked to in the PEP).
Is that reasonable? Does it need an update to PEP 1 to cover it? If so, should I post a PR for PEP 1? Or is it obvious enough to be assumed without needing the bureaucracy of updating PEP 1?
Paul
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/
I encourage adding this flow to PEP 1 so that it's clear that it's supported, and also to ensure that the flow doesn't ignore python-dev.
On Sat, Jul 23, 2016 at 1:15 PM, Barry Warsaw barry@python.org wrote:
On Jul 23, 2016, at 08:15 PM, Paul Moore wrote:
With PEPs now being hosted on github, is there any specific process for handling reviews/discussions on the github tracker? PEP 1 doesn't mention the matter, other than to note that discussions "may also occur on a list other than python-dev" although the approach of having a Discussions-To header doesn't really work well there.
I think it could. A Discussions-To header could point to the tracker issue URL; it doesn't have to be an email address. You just want to give people a pointer for where the discussion is happening, or has happened.
My suggestion (which is basically what we've been doing with PEP 514) is that PEP discussions are acceptable on the tracker, but comments on the core list should be monitored as well (and responded to on-list). When the PEP is ready for acceptance, a posting of the final version should be made to the list, and the acceptance email should be posted to the list (so that there's a permanent record of the acceptance, which can be linked to in the PEP).
Is that reasonable? Does it need an update to PEP 1 to cover it? If so, should I post a PR for PEP 1? Or is it obvious enough to be assumed without needing the bureaucracy of updating PEP 1?
It seems generally reasonable to me.
My own opinion is that PEPs should not be accepted without at least some interactions on python-dev. For PEPs where the primary discussion happens on that list, no Discussions-To should be need. Where most of the discussion happens elsewhere (e.g. on a topic sig), the Discussions-To header points the way, but regular postings on python-dev helps make sure that people are aware of it.
I don't think we need any substantive changes to PEP 1, but if you want to suggest some better wording to make this new avenue of PEP development more clear, please do submit a PR against PEP 1.
Cheers, -Barry
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)
On 23 July 2016 at 21:24, Guido van Rossum guido@python.org wrote:
I encourage adding this flow to PEP 1 so that it's clear that it's supported, and also to ensure that the flow doesn't ignore python-dev.
OK, I'll pull together a PR for PEP 1. Paul
On 24 July 2016 at 05:15, Paul Moore p.f.moore@gmail.com wrote:
Is that reasonable? Does it need an update to PEP 1 to cover it? If so, should I post a PR for PEP 1? Or is it obvious enough to be assumed without needing the bureaucracy of updating PEP 1?
One of the advantages of moving the PEPs repo to GitHub is that updating PEP 1 is no longer as painful as it used to be: you can post a PR with the suggested changes, and as long as python-dev is generally amenable, approving the change/clarification in the process is just a matter of clicking the big green merge button :)
In this case, I think the key point of the Discussions-To header is that it's a way for the BDFL-Delegate to say "If you want your opinion on this topic to be heard by the responsible BDFL-Delegate, express it *here*".
Historically, that location was always python-dev (and that's still the default for any PEP without a BDFL-Delegate assigned). Then we tweaked it a few years ago to say that for topics that don't result in a change specifically to CPython or the standard library, the final disposition of the PEP may take place on another python.org mailing list (specifically so packaging interoperability PEPs could be handled on distutils-sig, with folks from python-dev that wanted to participate in those discussions signing up to both lists).
This time, I think a suitable tweak may be that while initial high level discussion should still take place on python-dev (or the appropriate corresponding venue), Guido or the BDFL-Delegate may direct discussion of the finer details to a GitHub PR if the mailing list consensus is that the overall PEP is a good idea, but there are some specifics to work out before the PEP can be accepted.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Barry Warsaw -
Brett Cannon -
Guido van Rossum -
Nick Coghlan -
Paul Moore