Why use the name “Expert” instead of “Working group”?
I used a name that is already in use, in the Experts Index which is part of the Dev Guide.
It is a bit more accurate than “Working Group” since some areas of interest will maybe only have one expert interested in them. But the two terms are very close in spirit.
What happens if there is no expert in a given area?
That part of the project will languish until there is interest to work on it. That’s the realistic answer. The alternative would be to force core developers with little experience in that given area to make decisions on it.
How often will committers have to vote?
PEP 8012 does not expect there to be many votes. PEP decisions will be made within self-organized expert teams, there is no formal committer-wide vote unless a core developer decides to block a PEP.
It is the PEP author’s responsibility to gather feedback from the entire community in a matter that is comprehensive and inclusive enough to avoid votes to reject PEPs.
It is the relevant expert team’s responsibility to make it clear to the PEP author long before they decide which way they are leaning towards so that the author has opportunity to make the PEP palatable.
The other votes are only to nominate or eject a core developer.
Why do you insist on votes through GitHub?
This is no different than the current mailing list -1/0/+1 but formalizes it so it’s easier to keep counts. Those are public right now, including when nominating a core developer.
Why do you require no -1 votes on new core developers?
The core team functions due to trust. Any core team member has tremendous fire power to do great harm to the project, both technically and politically.
If any existing member of the core team feels strongly enough to -1 a candidate, we should trust them. Maybe we can discuss and convince that person to drop the -1. Maybe the reasoning for the -1 is strong enough to hold off with the addition.
How does having self-organized working groups avoid “design by committee”?
PEP 8012 avoids voting when it’s not necessary. In areas of very wide and conflicting interest there will probably be many core developers taking part in discussions. The decision to accept a PEP must be signed off by all members of the given team. This promotes discussion prior to the final comment period.
Will this slow down radical changes to Python?
Yes, controversial ones. That’s not the worst thing to happen to a 30-year-old language, is it?
Does PEP 8012 allow it to be changed by the committers?
It doesn’t explicitly mention anything like that. If there is a need to overthrow the governance model entirely, it would require a “working group” to be formed around it which would consist of all core developers. They would likely use PEP 8001 as base for another round of proposals. Such motion could be bootstrapped by a vote to “reject PEP 8012”. If 2/3 of voters feel the model does not work, it’s uncontroversial to restart the search for a better one.
For small tweaks to the existing model, an update to the PEP or a follow-up PEP would be enough. An expert team around it would form to work on that. Any core developer strongly against the documented change would be able to raise a motion to vote to reject it, as per PEP 8012.
How is PEP 8012 compatible with PEP 8016?
PEP 8016 explicitly avoids discussing the PEP process, leaving this decision as part of the mandate of the steering council. In this light, PEP 8012 defines a possible design for a PEP process that could be adopted by the council.
PEP 8012’s entire goal was to show that with a strong enough decision process, the need for a “top of hierarchy” group can be avoided. PEP 8016 hopes that this group will exercise their powers responsibly and rarely. That will require a reform of the PEP process and PEP 8012 specifies a possible one.