Formalize the process to promote a contributor as a core developer

[vstinner (Victor Stinner)]

Hi,

@nad wrote:

Vote to promote Cheryl Sabella as a core developer

Can you please elaborate? @vstinner, obviously the whole process of how we decide to give “commit-bit” privileges to people is an extremely important one as the role of Python core developer has traditionally come with a lot of assumptions about responsibilities, duties, and authorities. We’ve had a lot of informal discussions about the role over the years so it seems to me to be potentially a natural and important topic for the steering committee

I wrote a draft PEP to formalize the process to become a core dev: RFC: Process to become a core developer.

I also wrote a process as part of my PEP 8015:

Promote a contributor as core developer

Once an existing core developer considers that a contributor is ready to join the core group, to become a core developer, that core developer asks the contributor if they would like to become a core developer. If the contributor is interested in such new responsibilities, a vote is organized.

The vote is reserved to core developers, is public, and is open for 1 week. Usually the core developer who proposes the promotion has to describe the work and skills of the candidate in the description of the vote. A contributor is only promoted if two thirds (>= 2/3) of votes approve (“+1”) the promotion. Only “+1” and “-1” votes are accounted; other votes (ex: null, “-0”, “+0.5”) are ignored.

If the candidate is promoted, usually they get a mentor for 1 month to help them to handle new responsibilities.

If the candidate is not promoted, a new vote can be organized later, when the candidate gets the missing skills, for example 6 months later.

I agree with @nad that it would be nice to better formalize the process. The PEP 13 is quite vague on that part: PEP 13 – Python Language Governance | peps.python.org

[pf_moore (Paul Moore)]

It’s not clear from the explanation, but if the vote is handled in the form of a conversation thread with people stating their vote plus any comments they want to add, then this is not much different from the current process, in which case I see no problem with it.

But if it’s an unqualified +1/-1 with no supporting comments allowed, I’m a strong -1 - we gain nothing by refusing to allow people to add their own views, and we lose a lot of the community feeling that the current process has.

I’d like to see the proposal modified to make it clear that the current “discussion style” of thread remains as the form of voting to be used.

[vstinner (Victor Stinner)]

Oh. I’m not really concerned by the vote itself. By the way, I prefer to see an explanation of each vote, not a raw “+1” and “-1” without text.

What I would like is a process which describes different steps. Right now, it’s a boolean flag: you are either a core dev or not a core dev. I would prefer to see intermediate steps:

• being mentored
• getting the bug triage permission
• vote for promotion
• still mentored after becoming a core dev

It would also help to have a raw estimation of how many months you have to be involved in Python become someone can consider to promote you. In my experience, it varies between 6 months and a very long time (multiple years, 6 years sometimes).

For example, I see Mark Shannon name in commits made in 2011, and I recall that he was always around to help on low-level stuff in CPython since that time. I always expected him to be a core. Nope. He only became a core dev in May 2018! He also attended Language Summit, no? He authored PEP 412 ( Key-Sharing Dictionary: accepted!) and PEP 576 (Rationalize Built-in function classes: draft). PEP 412 is a key feature of Python. Well, I will not try to list all of his contributors: the list would be too long My point is just that sometimes it can take a very long time. Sometimes we “forget” to promote valuable contributors

I know that it’s really hard to fit all various cases into a single “box”. My first intent is to clarify what are the expectation: common denominator of strictly required skills. I understood that the only really required skill to the long term commitment. Ok, but where is that explained?

My problem is that a lot of people come to me and ask me that they want to become a core developer. Well, they never explained me why. What’s the point? Do they really understand the responsibilities of core developers? Again, what are these responsibilities described?

More and more core developers are trying to explain the “price” of being a core developer: the maintenance cost of pressing a cute [Merge] button for example. I tried to list a few responsibilities in my document, but I may be too specific: we may try to find a more general description.

Another goal for me is to ensure that the whole process is fair. For example, ensure that people are promoted because of their skills and involvement in Python. And not only because the candidate is a friend of some core developers. I’m not against friendship But it must not be only required “skill” I’m not saying that it happened in the past. But I’m not sure that in the past, the promotions were always “fair”.

[pitrou (Antoine Pitrou)]

@vstinner

I’m not saying that it happened in the past.

I don’t know. But we certainly granted core dev rights to people that didn’t have any consistent history of contributing. I don’t think it was officially done in the name of “friendship”, generally there’s an other reason such “X is a core developer on project Y and therefore we would like them to contribute to CPython too”.

Of course, in reality, you don’t get more contributions by granting core developer rights