[python-committers] New core developers

[Victor Stinner]

Le jeu. 21 févr. 2019 à 08:46, Serhiy Storchaka <storchaka at gmail.com> a écrit :
> Alexey Izbyshev is not so active as the above two monsters, but his code
> and comments on the bug tracker look qualified.
>
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Aizbyshev

I'm in touch with him. That's why I gave him the bug triage permission:
https://mail.python.org/pipermail/python-committers/2019-February/006511.html

We are working together on subprocess, vfork() and
os.posix_spawn/os.posix_spawnp.

My process is first to contact a contributor, offer to mentor them,
give them the bug triage permission, follow their work.

It's still unclear to me to decide how a candidate is ready or not. My
rule is to make sure that a candidate knows how to:

* accept review and rework their solution
* find the best solution for an issue
* know the Python coding style (Python: PEP 8, C: PEP 7)
* remember to write tests
* write a NEWS entry
* update "What's New in Python 3.x?" document
* understand backward compatibility rules

Checking all these items require to work closely with a contributor.
It's not easy to check everything from a single PR for example.

My criteria are mostly about "coding skills", other core devs may have
coding skills.

Coding skills are not the only required skills IMHO. For me, what
matters the most is if the contributor accepts criticism, like accept
to attempt a different approach, understand that they didn't fix the
root issue. I'm not sure how to explain that. I estimate the ability
of a candidate to work as a team. I'm not interested by "rock stars"
or "ninja devs" who are unable to work as a team.

I also try to remind basic principles of the Python Code of Conduct
like being respectful.

Right now, I didn't check all checkboxes in my head for Alexey
Izbyshev, but I also would like to promote him, at least in the long
term.

--

I also noticed Zackery Spytz and Andre Delfino contributions. If
someone wants to start the process to train them as core dev, I
propose to:

* mentor them
* give them the bug triage permission
* follow more closely their work

I'm already mentoring 4 persons. I prefer to not mentor too many
people in parallel.

--

I dislike talking about potential candidates in public. Usually, I
prefer to talk in private. I don't want to put pressure on a
candidate. For example, it's not because I mentor someone, that I will
force the mentoree to become a core dev. Anyone is free to do what
they want :-) Becoming a core dev is a slow process which requires a
lot of free time, especially at the beginning. Everybody is busy.

I decided to reply because I like the 3 names that you gave ;-)

Victor