I've posted an update from the Steering Council to our repo:
https://github.com/python/steering-council/blob/master/updates/2019-04-26_st...
I will also link to this on python-dev and on Discourse (discuss.python.org ).
For completeness, below is the full text.
# Steering Council Update
Date: 2019-04-26
Steering Council updates will be posted irregularly and as needed. We strive to post at least once every month. We provide these updates to foster open and transparent communication about Steering Council activity.
## Message from the Steering Council
Sorry we've been silent for a while! We've all been swamped with work, but we've been meeting regularly. Below are some of the outcomes of our conversations. Many of you will be happy to hear that we've cleared the backlog of PEPs by assigning BDFL-Delegates to almost all outstanding PEPs. We're also appearing at PyCon US.
## Mandate
This section organizes Steering Council (SC) activity and projects using the mandates listed in PEP 13.
### Language
Maintain the quality and stability of the Python language and CPython interpreter
- We've begun to explore the options for improving the interpreter in the future, but apart from the PEP work detailed below we've not come to any conclusions yet. In the coming months we hope to come up with guidelines and a process for evolving the interpreter, to be developed in close participation with the core developers and representatives of various user bases.
Contributors
Make contributing as accessible, inclusive, and sustainable as possible
**Communications channels:** We have an array of communication options, depending on the context.
To reach core committers specifically, we will use python-committers@python.org.
To reach the entire Python developer community, we will use python-dev@python.org.
For specific requests to the SC, please use the public GitHub tracker at https://github.com/python/steering-council/issues.
To reach just the SC, you can email us at steering-council@python.org.
We will also occasionally use Discourse, at https://discuss.python.org (for example, Discourse is useful for polls and votes).
**Issue tracker:** We've discussed PEP 581, "Using GitHub Issues for CPython" by Mariatta Wijaya. We're in favor of this move, and feel that the transition should be professionally planned and executed. In collaboration with the PSF we're exploring ideas on how to do that (using the successful roll-out of the new Warehouse infrastructure for PyPI as a model).
PEPs
Establish appropriate decision-making processes for PEPs
To request a PEP review, please file an issue on the SC issue tracker.
We've appointed BDFL-Delegates (BDs) to a number of PEPs, after ensuring that the proposed BD and the PEP author(s) agree on the appointment:
PEP 558 "Defined semantics for locals()", Nick Coghlan. *Appointed Nathaniel J. Smith as BD.*
PEP 497, "A standard mechanism for backward compatibility", Ed Schofield. *Appointed Brett Cannon as BD on behalf of the SC.*
PEP 387 "Backwards Compatibility Policy", Benjamin Peterson. *Appointed Brett Cannon as BD on behalf of the SC.*
PEP 554, "Multiple Interpreters in the Stdlib", Eric Snow. *Appointed Antoine Pitrou as BD.* (BD and author have indicated that this PEP will be postponed until Python 3.9.)
PEP 586, PEP 589, PEP 591 (various typing PEPs by members of the mypy team and others, topics Literal, TypedDict, and Final). *Appointed Guido van Rossum as BD.* (PEP 544, Protocols, also belongs in this list; Guido made himself BD last year.)
PEP 578, "Python Runtime Audit Hooks", Steve Dower. *Appointed Christian Heimes as BD.*
PEPs 576, 579, 580, 590 (competing PEPs on C function call optimizations by Mark Shannon and Jeroen Demeyer; note that PEP 576 is withdrawn in favor of PEP 590). *Appointed Petr Viktorin as BD.*
PEP 533, "Deterministic cleanup for iterators", Nathaniel J. Smith. *Appointed Yury Selivanov as BD.*
PEP 570, "Python Positional-Only Parameters", by Larry Hastings, Pablo Galindo and others. *Appointed Guido van Rossum as BD.* (And he approved it!)
PEP 574, "Pickle protocol 5 with out-of-band data", Antoine Pitrou. *Appointed Nick Coghlan as BD.*
PEP 573, "Module State Access from C Extension Methods", Petr Viktorin and others. *Postponed to Python 3.9. Appointed Stefan Behnel as BD.*
And we've updated the status of some other PEPs:
PEP 557 "Data Classes", Eric V Smith. *Marked Final.*
PEP 467 "Minor API improvements for binary sequences", Nick Coghlan, Ethan Furman. *Deferred.*
Interaction with PSF
Formalize and maintain the relationship between the core team and the PSF
The PSF Code of Conduct Workgroup is working on a revision of the CoC. Brett and Carol serve on the Workgroup.
We've agreed to a panel discussion at PyCon US in Cleveland, Sunday morning May 5th between 9:20am and 10:00am.
Governance
Seek consensus among contributors and the core team before acting in a formal capacity, Act as a "court of final appeal" for decisions where all other methods have failed.
Established a weekly SC meeting cadence (Tuesdays 3-4pm US West Coast time).
We proposed two updates to PEP 13, setting the voting period for new core devs to one week and for PEP 13 changes to two weeks. The vote is still ongoing on Discourse:
https://discuss.python.org/t/vote-on-pep-13-change-to-specify-voting-time-fr...
## Reference
This reference section summarizes the Steering Council's mandate and powers.
### Mandate (PEP 13)
The steering council shall work to:
- Maintain the quality and stability of the Python language and CPython interpreter,
- Make contributing as accessible, inclusive, and sustainable as possible,
- Formalize and maintain the relationship between the core team and the PSF,
- Establish appropriate decision-making processes for PEPs,
- Seek consensus among contributors and the core team before acting in a formal capacity,
- Act as a "court of final appeal" for decisions where all other methods have failed.
Powers (PEP 13)
The council has broad authority to make decisions about the project. For example, they can:
- Accept or reject PEPs
- Enforce or update the project's code of conduct
- Work with the PSF to manage any project assets
- Delegate parts of their authority to other subcommittees or processes
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...
On Fri, Apr 26, 2019 at 5:55 PM Guido van Rossum guido@python.org wrote:
- **Issue tracker:** We've discussed PEP 581, "Using GitHub Issues for CPython" by Mariatta Wijaya. We're in favor of this move, and feel that the transition should be professionally planned and executed. In collaboration with the PSF we're exploring ideas on how to do that (using the successful roll-out of the new Warehouse infrastructure for PyPI as a model).
I don't think there was a consensus on switching to GitHub Issues last time it was discussed. The most recent discussion about PEP 581 only has 12 messages. I think the council is making a premature decision here.
I'm strongly against using GitHub Issues. I will change my mind once I see a sign that GitHub is actually listening to our feedback. We can't even get them to make the use of #NNNN and GH-NNNN in the commit title configurable (https://github.com/maintainers/early-access-feedback/issues/77) and have the ability to automatically strip intermediate commit messages from the commit message body (https://github.com/maintainers/early-access-feedback/issues/153) The only time I got a response from them was this: https://github.com/python/miss-islington/issues/16#issuecomment-396095622
I volunteered to maintain our Roundup instance a while ago and already fixed some bugs: https://hg.python.org/tracker/python-dev/ I've also submit patches to improve UX and fix issues. I'd list list them here but I can't reach out to http://psf.upfronthosting.co.za/roundup/ at the moment. I hope the problem with the hosting is temporary because I have several non-trivial patches there.
--Berker
On Apr 26, 2019, at 09:12, Berker Peksağ berker.peksag@gmail.com wrote:
I don't think there was a consensus on switching to GitHub Issues last time it was discussed. The most recent discussion about PEP 581 only has 12 messages. I think the council is making a premature decision here.
Technically speaking, the PEP is still in Draft state. I have a PR up for splitting the migration into two separate PEPs, one for the rationale and a second one for the migration plan:
https://github.com/python/peps/pull/1013
I'm strongly against using GitHub Issues. I will change my mind once I see a sign that GitHub is actually listening to our feedback. We can't even get them to make the use of #NNNN and GH-NNNN in the commit title configurable (https://github.com/maintainers/early-access-feedback/issues/77) and have the ability to automatically strip intermediate commit messages from the commit message body (https://github.com/maintainers/early-access-feedback/issues/153) The only time I got a response from them was this: https://github.com/python/miss-islington/issues/16#issuecomment-396095622
It would be very helpful if you could add these comments to the PR.
I volunteered to maintain our Roundup instance a while ago and already fixed some bugs: https://hg.python.org/tracker/python-dev/ I've also submit patches to improve UX and fix issues. I'd list list them here but I can't reach out to http://psf.upfronthosting.co.za/roundup/ at the moment. I hope the problem with the hosting is temporary because I have several non-trivial patches there.
And as a fan of Roundup and its critical importance to the Python development process, I want to personally thank you for all your —and everyone who has contributed to it over the years— hard work in maintaining it.
Cheers, -Barry
On Fri, Apr 26, 2019 at 9:50 PM Barry Warsaw barry@python.org wrote:
It would be very helpful if you could add these comments to the PR.
Sure, I just left a comment there.
And as a fan of Roundup and its critical importance to the Python development process, I want to personally thank you for all your —and everyone who has contributed to it over the years— hard work in maintaining it.
Thank you! :)
--Berker
On Fri, Apr 26, 2019 at 10:26 AM Berker Peksağ berker.peksag@gmail.com wrote:
On Fri, Apr 26, 2019 at 5:55 PM Guido van Rossum guido@python.org wrote:
- **Issue tracker:** We've discussed PEP 581, "Using GitHub Issues for CPython" by Mariatta Wijaya. We're in favor of this move, and feel that the transition should be professionally planned and executed. In collaboration with the PSF we're exploring ideas on how to do that (using the successful roll-out of the new Warehouse infrastructure for PyPI as a model).
I don't think there was a consensus on switching to GitHub Issues last time it was discussed. The most recent discussion about PEP 581 only has 12 messages. I think the council is making a premature decision here.
I'm strongly against using GitHub Issues. I will change my mind once I see a sign that GitHub is actually listening to our feedback. We can't even get them to make the use of #NNNN and GH-NNNN in the commit title configurable ( https://github.com/maintainers/early-access-feedback/issues/77)
Because that repo is private I will say that the last comment on that issue was exactly a month ago from someone at GitHub saying that they are looking into this feature request.
-Brett
and have the ability to automatically strip intermediate commit messages from the commit message body (https://github.com/maintainers/early-access-feedback/issues/153) The only time I got a response from them was this: https://github.com/python/miss-islington/issues/16#issuecomment-396095622
I volunteered to maintain our Roundup instance a while ago and already fixed some bugs: https://hg.python.org/tracker/python-dev/ I've also submit patches to improve UX and fix issues. I'd list list them here but I can't reach out to http://psf.upfronthosting.co.za/roundup/ at the moment. I hope the problem with the hosting is temporary because I have several non-trivial patches there.
--Berker
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 Fri, Apr 26, 2019 at 11:37 PM Brett Cannon brett@python.org wrote:
Because that repo is private I will say that the last comment on that issue was exactly a month ago from someone at GitHub saying that they are looking into this feature request.
Thank you, I forgot those links are private. I'll also note that the issue was opened almost 1,5 years ago.
Based on their recent track record, I'm pretty sure they are going to come up with a solution that's totally unsuitable to our workflow :)
--Berker
On Fri, Apr 26, 2019 at 7:18 PM Berker Peksağ berker.peksag@gmail.com wrote:
On Fri, Apr 26, 2019 at 5:55 PM Guido van Rossum guido@python.org wrote:
- **Issue tracker:** We've discussed PEP 581, "Using GitHub Issues for CPython" by Mariatta Wijaya. We're in favor of this move, and feel that the transition should be professionally planned and executed. In collaboration with the PSF we're exploring ideas on how to do that (using the successful roll-out of the new Warehouse infrastructure for PyPI as a model).
I don't think there was a consensus on switching to GitHub Issues last time it was discussed. The most recent discussion about PEP 581 only has 12 messages. I think the council is making a premature decision here.
Recently Ernest migrated the tracker on a new machine, and he has been working on setting up a new test tracker. On the Roundup side, they have been working on porting Roundup to Python 3 and integrating the REST API we developed a few years ago with a GSoC student. I also submitted another GSoC proposal for this year with the goal of updating Roundup on b.p.o and writing tools that take advantage of the REST API (http://python-gsoc.org/psf_ideas.html). I was planning to write to python-committers and ask what features do we want to develop first, but I was already coordinating between Ernest, the Roundup folks, and GSoC admin/students so I was waiting to make sure things were viable before involving python-committers. On May 9 we will know for sure if we got a student, but things are currently looking good.
I'm also aware of PEP 581 and the fact that we might eventually decide to abandon Roundup, however this work will still benefit Roundup and its users regardless of what we end up doing -- that's why I went ahead and submitted the proposal without discussing it with python-committers first.
I'm strongly against using GitHub Issues. I will change my mind once I see a sign that GitHub is actually listening to our feedback. We can't even get them to make the use of #NNNN and GH-NNNN in the commit title configurable (https://github.com/maintainers/early-access-feedback/issues/77) and have the ability to automatically strip intermediate commit messages from the commit message body (https://github.com/maintainers/early-access-feedback/issues/153) The only time I got a response from them was this: https://github.com/python/miss-islington/issues/16#issuecomment-396095622
I volunteered to maintain our Roundup instance a while ago and already fixed some bugs: https://hg.python.org/tracker/python-dev/ I've also submit patches to improve UX and fix issues. I'd list list them here but I can't reach out to http://psf.upfronthosting.co.za/roundup/ at the moment. I hope the problem with the hosting is temporary because I have several non-trivial patches there.
The meta tracker at upfronthosting is gone for good, but nothing is lost, we have backups and can retrieve the patches if we need them.
Best Regards, Ezio Melotti
--Berker
Would it be possible to discuss these PEPs on python-dev? Or is it a deliberate choice to not let non core dev to be involved in the discussion?
Victor
-- Night gathers, and now my watch begins. It shall not end until my death.
On Sat, Apr 27, 2019 at 11:10 AM Victor Stinner vstinner@redhat.com wrote:
Would it be possible to discuss these PEPs on python-dev? Or is it a deliberate choice to not let non core dev to be involved in the discussion?
It was not a deliberate choice by the Steering Council. I remind you that this is always going to remain controversial. I have one request: please don't start a vote or poll.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...
On Sat, Apr 27, 2019 at 10:44 PM Guido van Rossum guido@python.org wrote:
On Sat, Apr 27, 2019 at 11:10 AM Victor Stinner vstinner@redhat.com wrote:
Would it be possible to discuss these PEPs on python-dev? Or is it a deliberate choice to not let non core dev to be involved in the discussion?
It was not a deliberate choice by the Steering Council. I remind you that this is always going to remain controversial. I have one request: please don't start a vote or poll.
Do you mean that the decision to switch to GitHub Issues has already been taken (so vote/polls would be pointless), or is the discussion still open?
On Sun, Apr 28, 2019 at 2:05 PM Ezio Melotti ezio.melotti@gmail.com wrote:
On Sat, Apr 27, 2019 at 10:44 PM Guido van Rossum guido@python.org wrote:
On Sat, Apr 27, 2019 at 11:10 AM Victor Stinner vstinner@redhat.com
Would it be possible to discuss these PEPs on python-dev? Or is it a
deliberate choice to not let non core dev to be involved in the discussion?
It was not a deliberate choice by the Steering Council. I remind you
wrote: that this is always going to remain controversial. I have one request: please don't start a vote or poll.
Do you mean that the decision to switch to GitHub Issues has already been taken (so vote/polls would be pointless), or is the discussion still open?
The latter. I meant to warn Victor not to start a poll before prematurely -- we should first attempt to find (rough) consensus.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...
On Sun, Apr 28, 2019 at 11:58 PM Guido van Rossum guido@python.org wrote:
On Sun, Apr 28, 2019 at 2:05 PM Ezio Melotti ezio.melotti@gmail.com wrote:
On Sat, Apr 27, 2019 at 10:44 PM Guido van Rossum guido@python.org wrote:
On Sat, Apr 27, 2019 at 11:10 AM Victor Stinner vstinner@redhat.com wrote:
Would it be possible to discuss these PEPs on python-dev? Or is it a deliberate choice to not let non core dev to be involved in the discussion?
It was not a deliberate choice by the Steering Council. I remind you that this is always going to remain controversial. I have one request: please don't start a vote or poll.
Do you mean that the decision to switch to GitHub Issues has already been taken (so vote/polls would be pointless), or is the discussion still open?
The latter. I meant to warn Victor not to start a poll before prematurely -- we should first attempt to find (rough) consensus.
Thanks for clarifying.
participants (6)
-
Barry Warsaw -
Berker Peksağ -
Brett Cannon -
Ezio Melotti -
Guido van Rossum -
Victor Stinner