[python-committers] What is a CPython core developer?

[Nick Coghlan]

On 23 September 2017 at 00:26, Victor Stinner <victor.stinner at 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:

1. Would gaining core developer privileges improve their ability to
contribute effectively (in my opinion or the opinion of another core
developer)?
2. 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 at gmail.com   |   Brisbane, Australia