Le jeu. 21 févr. 2019 à 08:46, Serhiy Storchaka storchaka@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%...

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.htm...

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