Mailman 3 What is a CPython core developer? - python-committers

newer
Requesting reviews

What is a CPython core developer?

older
Hacktoberfest

Victor Stinner

22 Sep 2017 22 Sep '17

2:26 p.m.

Hi,

Recently, I asked their opinion to a few core developers about promoting some active contributors to core developers.

It seems like we have no clear rules to decide if a contributor can be promoted or not. The problem is that sometimes, I am explicitly asked: What are the steps to become a core developer? Well, I'm not sure why some people really want to become core developers, but that's not question here :-)

I started to list "responsabilities" (is it the correct word?) of a core developer.

First of all, I like how Mariatta summarized a promotion (in an oral discussion that we had). Becoming a core developer doesn't give *power*, but *responsabilities*. (Sorry, I'm not sure about the exact wording, maybe Mariatta can correct me here ;-))

I also see that some core developers are more conservative, want to reduce the risk of regressions, while some others are more on the "forgiveness" trend ("it's better to ask forgiveness than permission"). I think that it's perfectly normal and expected to have people on the two sides. The question is how to find a compromise in the middle.

I identified the following CPython core developers responsabilities:

Long term commitement. We someone lands a big chunk of code, we need someone to maintain it for at least the next 2 years. Maybe for the next 10 years. I think that some people sign with their blood to maintain crappy code for their own life, but it's better to not elaborate this part ;-)
Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews.
Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches.
For C developer: know CPython specific issues like reference leaks and the garbage collector. We expect that a core developer write code with no reference leak, right? ;-)
Good quality patches: proposed changes are good (or almost good) at the first iteration. I'm not sure about this point, but I know a few other developers have this requiurement to promote someone.
Pushing core means becoming responsible for this code. For regressions, backward compatibility, security, etc.
Something else?

I don't expect this list to be complete. A vote for a promotion is always done on a case by case basis, mostly because it's really hard to be ready on *all* expected points. The discussion is more to estimate how far is the contributor in its learning, if it's enough, if more learning is needed, or if mentoring is needed.

Maybe we should also formalize the mentoring for contributors identified as potential core developers. It can be an explicit step in the promotion process. Each last core developers who get promoted last year get a mentor if I recall correctly. What do you think?

I started to write an article "What is a CPython core developer?" which describes even more things:

https://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_cor...

Victor

Show replies by date

Antoine Pitrou

22 Sep 22 Sep

4:48 p.m.

Hi Victor,

Thank you, this is a useful write-up!

Le 22/09/2017 à 16:26, Victor Stinner a écrit :

...

I started to list "responsabilities" (is it the correct word?) of a core developer.

First of all, I like how Mariatta summarized a promotion (in an oral discussion that we had). Becoming a core developer doesn't give *power*, but *responsabilities*. (Sorry, I'm not sure about the exact wording, maybe Mariatta can correct me here ;-))

Well, it gives both, which is the only way things can work sanely. If you give power without responsabilities, you are creating a jungle; if you give responsabilities without the power to exert them properly, you are creating frustration and a dysfunctional environment.

...

I identified the following CPython core developers responsabilities:

Long term commitement. We someone lands a big chunk of code, we need someone to maintain it for at least the next 2 years. Maybe for the next 10 years. I think that some people sign with their blood to maintain crappy code for their own life, but it's better to not elaborate this part ;-)

Unfortunately we can't evaluate that in advance. Even the person being promoted often does not known whether they'll still be there in 5 or 10 years. Hopefully that's on their horizon, but many factors can interfere.

I, personally, can only think of a couple of cases where a person being promoted core developer vanished a few months after that. It's not a big deal in the grand scheme of things, though it *is* frustrating to spend your time mentoring and promoting someone (which also engages your own responsability, since you're the one vouching that they'll be up to the task) only to see that person produce little to no work as a core developer.

...

Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews.

Yes, I believe this is the most important part of being a core developer. What it means is that core developers care about the quality of the whole code base (and also the non-code parts), not only their own contributions to it.

...

Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches.

This part is also required from regular contributors, at least the experienced ones.

...

For C developer: know CPython specific issues like reference leaks and the garbage collector. We expect that a core developer write code with no reference leak, right? ;-)

This is no different from regular contributors posting patches with C code in them.

...

Good quality patches: proposed changes are good (or almost good) at the first iteration. I'm not sure about this point, but I know a few other developers have this requiurement to promote someone.

Or, if the code isn't good at the first iteration, the author is able to figure it out by themselves and doesn't rush merge it. Of course, nobody is perfect, which is why non-trivial code written by core developers ideally goes through a review phase anyway. But a general sense of what is "in good state for review/merging" vs. "just a draft I'm working on" is indeed, IMHO, preferrable.

...

Pushing core means becoming responsible for this code. For regressions, backward compatibility, security, etc.

Yes, this is the whole "know the project's lifecycle" thing. It also includes knowing what to backport or not.

...

Something else?

Two things I would add:

Know to be nice and respectful to the others, at least to the extent they're nice and respectful to yourself :-) We don't have a rock-star (or "bro", "wizard", "ninja", whatever the hyperbole of the day is) culture here.
Show a bit of humility towards existing work and try to understand the decisions behind something before deciding to change it all. That said, given Python's current position on the technical evolution and adoption curve, we get less and less proposals for sweeping changes (perhaps not enough, actually, since even when rejected, they help challenge the statu quo).

Regards

Antoine.

Brett Cannon

5:26 p.m.

+1 for the list Victor and Antoine have here!

On Fri, 22 Sep 2017 at 09:48 Antoine Pitrou antoine@python.org wrote:

...

Hi Victor,

Thank you, this is a useful write-up!

Le 22/09/2017 à 16:26, Victor Stinner a écrit :

...
I started to list "responsabilities" (is it the correct word?) of a core developer.

First of all, I like how Mariatta summarized a promotion (in an oral discussion that we had). Becoming a core developer doesn't give *power*, but *responsabilities*. (Sorry, I'm not sure about the exact wording, maybe Mariatta can correct me here ;-))

Well, it gives both, which is the only way things can work sanely. If you give power without responsabilities, you are creating a jungle; if you give responsabilities without the power to exert them properly, you are creating frustration and a dysfunctional environment.

...
I identified the following CPython core developers responsabilities:

Long term commitement. We someone lands a big chunk of code, we need someone to maintain it for at least the next 2 years. Maybe for the next 10 years. I think that some people sign with their blood to maintain crappy code for their own life, but it's better to not elaborate this part ;-)

Unfortunately we can't evaluate that in advance. Even the person being promoted often does not known whether they'll still be there in 5 or 10 years. Hopefully that's on their horizon, but many factors can interfere.

I, personally, can only think of a couple of cases where a person being promoted core developer vanished a few months after that. It's not a big deal in the grand scheme of things, though it *is* frustrating to spend your time mentoring and promoting someone (which also engages your own responsability, since you're the one vouching that they'll be up to the task) only to see that person produce little to no work as a core developer.

...

Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews.

Yes, I believe this is the most important part of being a core developer. What it means is that core developers care about the quality of the whole code base (and also the non-code parts), not only their own contributions to it.

...

Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches.

This part is also required from regular contributors, at least the experienced ones.

...

For C developer: know CPython specific issues like reference leaks and the garbage collector. We expect that a core developer write code with no reference leak, right? ;-)

This is no different from regular contributors posting patches with C code in them.

...

Good quality patches: proposed changes are good (or almost good) at the first iteration. I'm not sure about this point, but I know a few other developers have this requiurement to promote someone.

Or, if the code isn't good at the first iteration, the author is able to figure it out by themselves and doesn't rush merge it. Of course, nobody is perfect, which is why non-trivial code written by core developers ideally goes through a review phase anyway. But a general sense of what is "in good state for review/merging" vs. "just a draft I'm working on" is indeed, IMHO, preferrable.

...

Pushing core means becoming responsible for this code. For regressions, backward compatibility, security, etc.

Yes, this is the whole "know the project's lifecycle" thing. It also includes knowing what to backport or not.

...

Something else?

Two things I would add:

Know to be nice and respectful to the others, at least to the extent they're nice and respectful to yourself :-) We don't have a rock-star (or "bro", "wizard", "ninja", whatever the hyperbole of the day is) culture here.

Show a bit of humility towards existing work and try to understand the decisions behind something before deciding to change it all. That said, given Python's current position on the technical evolution and adoption curve, we get less and less proposals for sweeping changes (perhaps not enough, actually, since even when rejected, they help challenge the statu quo).

Regards

Antoine.

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/

Carol Willing

5:49 p.m.

Thanks Victor for your commitment to this. :D

I particularly like Mariatta's comment on responsibility, Antoine's comments on humility and respect, and Victor's linked document.

...

On Sep 22, 2017, at 10:26 AM, Brett Cannon brett@python.org wrote:

+1 for the list Victor and Antoine have here!

On Fri, 22 Sep 2017 at 09:48 Antoine Pitrou mailto:antoine@python.org> wrote:

Hi Victor,

Thank you, this is a useful write-up!

Le 22/09/2017 à 16:26, Victor Stinner a écrit :

...
I started to list "responsabilities" (is it the correct word?) of a core developer.

First of all, I like how Mariatta summarized a promotion (in an oral discussion that we had). Becoming a core developer doesn't give *power*, but *responsabilities*. (Sorry, I'm not sure about the exact wording, maybe Mariatta can correct me here ;-))

Well, it gives both, which is the only way things can work sanely. If you give power without responsabilities, you are creating a jungle; if you give responsabilities without the power to exert them properly, you are creating frustration and a dysfunctional environment.

...
I identified the following CPython core developers responsabilities:

Long term commitement. We someone lands a big chunk of code, we need someone to maintain it for at least the next 2 years. Maybe for the next 10 years. I think that some people sign with their blood to maintain crappy code for their own life, but it's better to not elaborate this part ;-)

Unfortunately we can't evaluate that in advance. Even the person being promoted often does not known whether they'll still be there in 5 or 10 years. Hopefully that's on their horizon, but many factors can interfere.

I, personally, can only think of a couple of cases where a person being promoted core developer vanished a few months after that. It's not a big deal in the grand scheme of things, though it *is* frustrating to spend your time mentoring and promoting someone (which also engages your own responsability, since you're the one vouching that they'll be up to the task) only to see that person produce little to no work as a core developer.

...

Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews.

Yes, I believe this is the most important part of being a core developer. What it means is that core developers care about the quality of the whole code base (and also the non-code parts), not only their own contributions to it.

...

Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches.

This part is also required from regular contributors, at least the experienced ones.

...

For C developer: know CPython specific issues like reference leaks and the garbage collector. We expect that a core developer write code with no reference leak, right? ;-)

This is no different from regular contributors posting patches with C code in them.

...

Good quality patches: proposed changes are good (or almost good) at the first iteration. I'm not sure about this point, but I know a few other developers have this requiurement to promote someone.

Or, if the code isn't good at the first iteration, the author is able to figure it out by themselves and doesn't rush merge it. Of course, nobody is perfect, which is why non-trivial code written by core developers ideally goes through a review phase anyway. But a general sense of what is "in good state for review/merging" vs. "just a draft I'm working on" is indeed, IMHO, preferrable.

...

Pushing core means becoming responsible for this code. For regressions, backward compatibility, security, etc.

Yes, this is the whole "know the project's lifecycle" thing. It also includes knowing what to backport or not.

...

Something else?

Two things I would add:

Know to be nice and respectful to the others, at least to the extent they're nice and respectful to yourself :-) We don't have a rock-star (or "bro", "wizard", "ninja", whatever the hyperbole of the day is) culture here.

Show a bit of humility towards existing work and try to understand the decisions behind something before deciding to change it all. That said, given Python's current position on the technical evolution and adoption curve, we get less and less proposals for sweeping changes (perhaps not enough, actually, since even when rejected, they help challenge the statu quo).

Regards

Antoine.

python-committers mailing list python-committers@python.org mailto:python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/ https://www.python.org/psf/codeofconduct/

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/

Serhiy Storchaka

23 Sep 23 Sep

5:26 a.m.

22.09.17 20:26, Brett Cannon пише:

...

+1 for the list Victor and Antoine have here!

+1 from me too!

Victor Stinner

4 Oct 4 Oct

4:58 p.m.

2017-09-22 18:48 GMT+02:00 Antoine Pitrou antoine@python.org:

...

...

Long term commitement. (...)

Unfortunately we can't evaluate that in advance. Even the person being promoted often does not known whether they'll still be there in 5 or 10 years. Hopefully that's on their horizon, but many factors can interfere.

To be clear, I disagree with the "long term commitement", but I tried to summarize what I heard from other core developers. I think that it would be wrong to at least not mention it. If most core developers disagree with this requirement, we should remove it. If there is no consensus, I prefer to mention it *but* also explains that it's not strictly a "requirement", but more a "whish".

I will try to clarify expectations in term of time, evenings, weekends and holidays :-)

...

I, personally, can only think of a couple of cases where a person being promoted core developer vanished a few months after that. It's not a big deal in the grand scheme of things, though it *is* frustrating to spend your time mentoring and promoting someone (which also engages your own responsability, since you're the one vouching that they'll be up to the task) only to see that person produce little to no work as a core developer.

While it's sad, I don't think that we can prevent this. It's hard to "force" someone to work for free on a free software during nights and weekends.

...

...

Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews.

Yes, I believe this is the most important part of being a core developer. What it means is that core developers care about the quality of the whole code base (and also the non-code parts), not only their own contributions to it.

I completed my list. I'm lazy, I copied/pasted what you wrote (not only this paragraph) :-)

https://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_cor...

...

...

Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches.

This part is also required from regular contributors, at least the experienced ones.

Ah yes, I didn't say that these requirements are specific to CPython core developers. Most items are "expected" from regular contributors. I wrote it explicitly before my list :-)

...

Two things I would add:

Know to be nice (...)

Show a bit of humility (...)

Oh, you're right. Thank you for being explicit on these points.

I think that we already expected this from promoted core developers, just that it wasn't written down previously.

Victor

Paul Moore

5:11 p.m.

On 4 October 2017 at 17:58, Victor Stinner victor.stinner@gmail.com wrote:

...

2017-09-22 18:48 GMT+02:00 Antoine Pitrou antoine@python.org:

...
...

Long term commitement. (...)

Unfortunately we can't evaluate that in advance. Even the person being promoted often does not known whether they'll still be there in 5 or 10 years. Hopefully that's on their horizon, but many factors can interfere.

To be clear, I disagree with the "long term commitement", but I tried to summarize what I heard from other core developers. I think that it would be wrong to at least not mention it. If most core developers disagree with this requirement, we should remove it. If there is no consensus, I prefer to mention it *but* also explains that it's not strictly a "requirement", but more a "whish".

To me, it's about caring about the long-term health of the project, and not just a short-term interest in scratching your personal itch. Sometimes people will only focus on particular areas, and that's fine, but they should be prepared to help out anywhere they can be of use. Equally, people can find that they don't have the time to commit that they used to - again that's OK, but they should care enough to make sure their "area" gets handed over, or is covered by others.

Being a core committer is about caring about Python as a whole, and for the long haul. But people give their time and skills where they can, and to the extent that they can.

...

I will try to clarify expectations in term of time, evenings, weekends and holidays :-)

You don't have to write code at the weekend or while you're on holiday, but you should be thinking about Python ;-)

Paul

Ezio Melotti

9:47 p.m.

On Wed, Oct 4, 2017 at 6:58 PM, Victor Stinner victor.stinner@gmail.com wrote:

...

2017-09-22 18:48 GMT+02:00 Antoine Pitrou antoine@python.org:

...
...

Long term commitement. (...)

Unfortunately we can't evaluate that in advance. Even the person being promoted often does not known whether they'll still be there in 5 or 10 years. Hopefully that's on their horizon, but many factors can interfere.

To be clear, I disagree with the "long term commitement", but I tried to summarize what I heard from other core developers. I think that it would be wrong to at least not mention it. If most core developers disagree with this requirement, we should remove it. If there is no consensus, I prefer to mention it *but* also explains that it's not strictly a "requirement", but more a "whish".

I think it really depends on the reason the developer has been given commit privileges:

generic work on the documentation, tests, or stdlib? several people can take over if the dev disappears
changed something specific in the language (e.g. import system, Unicode representation)? some people can take over
added new features to the language (e.g. typing, asyncio) or a new module? few people can take over

IOW, the lower the bus factor, the higher are the expectations of long term commitment.

In my case I used to do lot of generic work on CPython and when I became less active other people took over with not many repercussions. For more specific areas (e.g. html.parser or Unicode) I still try to participate to the discussions. For the bug tracker I have to commit long-term because other devs lack the time and/or knowledge required to maintain it.

Best Regards, Ezio Melotti

...

I will try to clarify expectations in term of time, evenings, weekends and holidays :-)

...
I, personally, can only think of a couple of cases where a person being promoted core developer vanished a few months after that. It's not a big deal in the grand scheme of things, though it *is* frustrating to spend your time mentoring and promoting someone (which also engages your own responsability, since you're the one vouching that they'll be up to the task) only to see that person produce little to no work as a core developer.

While it's sad, I don't think that we can prevent this. It's hard to "force" someone to work for free on a free software during nights and weekends.

...
...

Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews.

Yes, I believe this is the most important part of being a core developer. What it means is that core developers care about the quality of the whole code base (and also the non-code parts), not only their own contributions to it.

I completed my list. I'm lazy, I copied/pasted what you wrote (not only this paragraph) :-)

https://cpython-core-tutorial.readthedocs.io/en/latest/what_ is_a_cpython_core_developer.html

...
...

Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches.

This part is also required from regular contributors, at least the experienced ones.

Ah yes, I didn't say that these requirements are specific to CPython core developers. Most items are "expected" from regular contributors. I wrote it explicitly before my list :-)

...
Two things I would add:

Know to be nice (...)

Show a bit of humility (...)

Oh, you're right. Thank you for being explicit on these points.

I think that we already expected this from promoted core developers, just that it wasn't written down previously.

Victor

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/

Nick Coghlan

24 Sep 24 Sep

11:05 a.m.

On 23 September 2017 at 00:26, Victor Stinner victor.stinner@gmail.com wrote:

...

First of all, I like how Mariatta summarized a promotion (in an oral discussion that we had). Becoming a core developer doesn't give *power*, but *responsabilities*. (Sorry, I'm not sure about the exact wording, maybe Mariatta can correct me here ;-))

That formulation also came up in a recent developer's guide discussion that resulted in the addition of this section: https://docs.python.org/devguide/coredev.html#what-it-means

I think what we put there really does cover the essence of the role, so the main questions I personally ask about a potential new core developer are:

Would gaining core developer privileges improve their ability to contribute effectively (in my opinion or the opinion of another core developer)?
Do I (or another core developer that is willing to mentor them) trust their judgment on when things should be escalated for further review & discussion (or even rejected outright) vs just going ahead and merging them?

...

I also see that some core developers are more conservative, want to reduce the risk of regressions, while some others are more on the "forgiveness" trend ("it's better to ask forgiveness than permission"). I think that it's perfectly normal and expected to have people on the two sides. The question is how to find a compromise in the middle.

I identified the following CPython core developers responsabilities:

Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches.

For C developer: know CPython specific issues like reference leaks and the garbage collector. We expect that a core developer write code with no reference leak, right? ;-)

Good quality patches: proposed changes are good (or almost good) at the first iteration. I'm not sure about this point, but I know a few other developers have this requiurement to promote someone.

Pushing core means becoming responsible for this code. For regressions, backward compatibility, security, etc.

I think these make sense, since they're about *how* we contribute, and *what* we should be looking for when reviewing code (whether our own or other people's).

...

Long term commitement. We someone lands a big chunk of code, we need someone to maintain it for at least the next 2 years. Maybe for the next 10 years. I think that some people sign with their blood to maintain crappy code for their own life, but it's better to not elaborate this part ;-)

Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews.

I'm less certain of these, as they're about *how much* we contribute, and while there's certainly a significant time element involved (since it takes time and engagement to build trust in someone else's judgment), we also expect people's level of involvement to ebb and flow based on their other commitments and their current level of interest in the core development process (regardless of whether they're a core developer or not).

...

Something else?

I don't expect this list to be complete. A vote for a promotion is always done on a case by case basis, mostly because it's really hard to be ready on *all* expected points. The discussion is more to estimate how far is the contributor in its learning, if it's enough, if more learning is needed, or if mentoring is needed.

Maybe we should also formalize the mentoring for contributors identified as potential core developers. It can be an explicit step in the promotion process. Each last core developers who get promoted last year get a mentor if I recall correctly. What do you think?

An offer of post-promotion mentoring is already noted as part of the nomination process here: https://docs.python.org/devguide/coredev.html#what-it-takes

I agree it may make sense to make that a clearly separate step in the process, such that someone makes the explicit decision that becoming a core developer is a goal they want to pursue, and then seeks an existing core developer to coach them through that process. Currently, that tends to only happen informally, by virtue of an existing core dev reviewing quite a few of a contributor's patches, and then asking if becoming a core developer themselves is a goal they've considered.

There are some additional responsibilities listed at https://docs.python.org/devguide/coredev.html#responsibilities, but aside from the first paragraph about respecting the CoC, they're more in the nature of FYI's for just-promoted core devs.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Victor Stinner

4 Oct 4 Oct

5:07 p.m.

2017-09-24 13:05 GMT+02:00 Nick Coghlan ncoghlan@gmail.com:

...

I think what we put there really does cover the essence of the role, so the main questions I personally ask about a potential new core developer are:

Would gaining core developer privileges improve their ability to contribute effectively (in my opinion or the opinion of another core developer)?

Do I (or another core developer that is willing to mentor them) trust their judgment on when things should be escalated for further review & discussion (or even rejected outright) vs just going ahead and merging them?

Nice. I also copy/pasted you in my page :-)

https://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_cor...

...

An offer of post-promotion mentoring is already noted as part of the nomination process here: https://docs.python.org/devguide/coredev.html#what-it-takes

I'm not sure that proposing a mentor as a result of the vote is a good practice. Slowly, I'm trying to propose to mentor some potential candidate before even starting discussing a potential promotion. IMHO it works better in this way.

Technically, it's "pre-promotion" mentoring :-)

I started to formalize the "Different stages of core developers": https://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_cor...

Newcomer
Contributor: as soon as you post a comment, send an email, ask a question, you become an active contributor!
Permission for bug triage: once peers estimated that your behaviour is correct and that you are active, you may be proposed to be promoted to “bug triage”
Followed by a mentor: spotted active contributors can be asked to get a mentor to speedup their learning
Core developer, allowed to merge a pull request: once other core developers consider that a contributor is ready to be promoted, a core dev opens a vote on python-committers

I would like to introduce *new* formalized steps between "contributor" and "core developer". "Bug triage" already existed, but I'm not sure that it was explicitly a part of a "long term promotion process".

I added a *new* explicit mentoring stage.

...

There are some additional responsibilities listed at https://docs.python.org/devguide/coredev.html#responsibilities, but aside from the first paragraph about respecting the CoC, they're more in the nature of FYI's for just-promoted core devs.

I'm working on a new CPython tutorial. I have a "Community" page with:

Code Of Conduct
Diversity
CPython Communication Channels

I tried to put this page near the start.

https://cpython-core-tutorial.readthedocs.io/en/latest/community.html

I plan to have a story mode in this tutorial in which you would have to validate a step to access new parts of the tutorial. For example, you would have to read the Community section before being allowed to access the "Open your first issue on bugs.python.org" or "Write your first Pull Request" sections. It's a way to make sure that all contributors are aware of the code of conduct and diversity statement.

Victor

2395

Age (days ago)

2407

Last active (days ago)

List overview

Download

9 comments

8 participants

participants (8)

Antoine Pitrou
Brett Cannon
Carol Willing
Ezio Melotti
Nick Coghlan
Paul Moore
Serhiy Storchaka
Victor Stinner

What is a CPython core developer?

tags

participants (8)