To take in account all discussions around this PEP 8015, I updated it: it’s now the version 4. I added a Version History at the bottom of the PEP to help reviewers. In short: votes are now announced in advance (0, 1 or 3 weeks depending on the vote) and only open for 1 week instead of 1 month, the “Python (Core) Board” has been renamed to “Python Steering Committee” to clarify its role.
(I am reading again this discussion from the start.)
I discussed recently the promotion of contributors with other core developers, and I’m now convinced that your slate idea doesn’t fit with our strict rules to promote contributors.
I liked to quote Serhiy Storchaka @storchaka:
“ A core dev should know not only what changes should be made, but also (and this is more important) what changes should not be made. ”
It is not easy to estimate when a contributor understands this, and it seems even harder if it should be done on a whole slate. I really prefer to vote to promote a single contributor.
(I just wanted to elaborate my previous answer ;-))
TODO: clarify which exact Condorcet voting method is used and use secret ballot for Steering Committee votes.
I have no strong opinion on the exact voting method, nor on using secret ballot or not.
cc @dstufft
Hum, I wanted to elaborate one point. In my PEP, I wrote multiple times that the Steering Committee is away from the PEP approval…
… but it isn’t hard to see how the “Steering Committee” can trick the system to indirectly approve or reject a PEP.
Let’s say that a PEP is discussed for 1 month. Usually, developers who are the most involved in the discussion have a strong opinion on the PEP: really like or really dislike it. Since the Steering Committee can choose anyone for the PEP-delegate, they can pick someone who like the PEP as PEP-delegate to make sure that the PEP is approved.
IMHO it is just fine. This is why the Steering Committee is on top of core developers in term of hierarchy, are introduced as “the most trusted core developers”, and a voted by their peers, the other core developers.
I don’t think that it’s anything new compared to the previous “Guido as BDFL” governance, where Guido was free to select anyone as the BDFL-Delegate.
I decided to not explain how to trick the system in my governance PEP 
If someone considers that it’s an important point, would you mind to propose a short paragraph to explain that?
Thanks for additional context Victor.
While I’m fine with the conclusion to vote on individuals, I’m somewhat suspect that there is a good way to determine measure accurately a core dev or potential core dev’s ability re: “what changes should not be made”.
Ultimately, it comes down to trust. “Do I trust this person to make a good decision which will be reviewed by others (in most cases)?”
Thanks for the context 
Right now, there is a very big step between being a Python contributors and becoming a Python core developer. This PEP also builds a new middle step with the idea of Python teams. I’m not sure yet of the exact status that a contributor would get when joining a Python team. I’m not sure that it’s needed for formalize it neither 
Later, I would like to discuss (if my governance is selected) the ability to give the commit bit to a member of a Python team, but restricted to a set of files. The team would organize a vote inside the team, not a vote open to all core developers. That’s the main difference. I’m not sure if it’s doable nor if it makes sense. So I chose to not write it in my PEP. This idea doesn’t seem to be popular 
Anyway, being part of a team is a nice way to build a trust relationship and meet core developers, without the strict constraints of becoming a core developer.
… All these things are still unclear to me. The concept of Python teams already exist, but I’m not sure how it helps to become a core developer?
1 Like
I love how you are considering new ideas and open to continuing the discussion.
1 Like
I just published the 6th version of the PEP to “adjust” votes and to fix flaws/corner cases:
- Specify the Condorcet method: use Schulze/Beatpath/CSSD variant to elect Python Steering Committee members. Specify how to deal with tie and the constraint on the employers.
- Vote on promoting a contributor and on PEPs now requires >= 2/3 rather than 50%+1.
- Vote on changing this PEP now requires >= 4/5 rather than 50%+1.
- Explain how to deal with a company acquisition.
I’m updating my PEP frequently according to the different discussions on corner cases and the different aspects of the governance. Honestly, I really like the fact the governance PEPs are discussed The discussion is healthy!
I proposed a Version 7 which introduces significant changes in the Steering Committee: 5 members, can be PEP delegate, no term limits, don’t have to resign if they move to the same company.
https://github.com/python/peps/pull/837
Would you mind to review this change?
I made a last minute change (sorry for the delay!):
Version 7: Adjust the Steering Committee
- The Steering Committee is now made of 5 people instead of 3.
- There are no term limits (instead of a limit of 2 mandates:
6 years in total). - A committee member can now be a PEP delegate.
With this change, my PEP moves towards the PEP 8016
1 Like
How to determine the change? The ban ended or let each core dev decide on it using their vote? Maybe the proposer could consult the CoC workgroup before starting a vote? And is another vote necessary?
Hi Xiang
Oh, it’s difficult to know if someone changed… I imagine that we should wait a few months and “watch” the behavior of the previously banned core dev. Anytime, someone can organize a vote to take them back into the core dev team. The purpose of the vote is to measure if other core developers consider that the previously banned core dev changed their behavior.
What do you think?
… I never this case in practice, so everything looks theorical to me
It depends, in some other community, it can be based on our trust in the person. They can simply apologize for their behavior and promise not to repeat and that would be good enough
In yet a different community I’ve been, “change” can be demonstrated by the individual’s participation in other communities.
Just for example, say X was banned from mailing list ABC because of his behavior.
However X recognized he needs to change, however since he was banned from mailing list ABC, he started participating in mailing list DEF. After a period of several months, X can write back to mail in list ABC, showing his activities in DEF. ABC admins will review X’s activities in DEF.
In my mind though, all the specific details l of this should be handled by the CoC work group, not core Python governance, but that’s my opinion.
Yes. I hope that will never happen. But I remember I have seen news that such cases happened in some other communities, nodejs? My main confusion is, if a core dev is banned due to CoC reasons, it’s the CoC workgroup going to decide they are okay to back or the core devs.
Then do we need to take away their commit bit? If the CoC workgroup think it’s okay, the commit bit is automatically recovered?
I don’t want to put a strict relationship between core developers the conduct workgroup. The Conduct WG doesn’t remove the commit bit. From my point of view, it’s a side effect of the ban, because of “Core developers are expected to be exemplary when it comes to the Code of Conduct.” (and more simply, all core dev must respect the CoC). I don’t think that the role of the Conduct WG is to add back the commit bit. Well, I can be wrong here
I would expect that if the person has done something such that the CoC workgroup deemed that this person is not welcomed in the community and need to be banned, then the commit bit should be revoked, for security reason. Similar to when a person got fired and has to be escorted out of the building.
If the person wants to participate back, I would expect they go through normal process of getting promoted and earn the community trust again, so the commit bit shouldn’t get granted automatically.
3 Likes
This makes sense. Then I think the current wording is fine. 
2 Likes