[python-committers] Suggestion: A PSF grant for running a "Core Dev Mentorship Program"

Tal Einat taleinat at gmail.com
Sat Nov 3 13:06:09 EDT 2018


I'll try to address some of the points brought up here without trying to
"sell" this too much.

To reiterate: I'm suggesting the "Mentorship Program" only because of an
apparent lack of regular contributors, many devs who would like to be
mentored, and a low availability of core devs for mentoring.


On Fri, Nov 2, 2018 at 6:34 PM Victor Stinner wrote:

Mentoring is an investment in the long term. Is it better to pay
> someone to review and merge PRs?
>

This would basically be paying someone to do just one part of a core dev's
work, and IMO that's a bad idea in general. I also specifically think it
would far less effective in the long-term than mentoring, but that's hard
to qualify.


> Reviewing PRs is also a way to help and train contributors. It's not
> very different from mentoring, depending on your definition of
> mentoring :-)


It's *very* different from my method of mentoring. I do many additional
things, among them:

* first and foremost, those mentored having a long-term plan and partner
* settings expectations and providing encouragement
* helping choose appropriate tasks
* answering little "silly" questions that many feel uncomfortable to raise
in public forums
* explaining lots of small details about process, tools, priorities and
more; for example, what kind of changes are backported and how far back
* maintaining momentum over a significant period of time

Reviewing PRs is one significant piece of my mentoring, but IMO not the
most important one.


On Sat, Nov 3, 2018 at 4:26 AM Steve Dower wrote:

The problem here is that most of the reviews require either specialised
> knowledge of the area being changed (essentially the ability to predict
> the flow-on impact of any change), or a strong decision that the change
> is good. This severely limits the people who can approve most PRs.
>
> Every time I start going through the list of PRs, I find that I'm
> obviously not the right person to approve the change, or that I should
> not be unilaterally approving the change (without discussing it on
> python-dev). Which means that you can't pay me to review most PRs,
> because I simply can't do it :) So who do we get to review them?
>
> Without a stated direction/vision for CPython, it's very hard for any
> individual developer to make unilateral decisions on many PRs. And since
> there are many major areas, each with their own "team" or "expert", we
> really need those maintainers to be reviewing PRs in their areas, and
> also feeling empowered and supported to make leadership-like decisions
> for their areas.
>

>From my experience, these domain experts are often forced to spend much
more time on each PR due to the writers having little experience or
guidance developing *this* codebase. Having the new contributors submit
higher quality PRs, and having those first reviewed by a non-expert core
dev or an experienced contributor, would benefit everyone IMO. For example,
it is not a good use of our experts' time to repeatedly deal with minor
deficiencies: code style, wording, minor design issues, missing NEWS
entries etc.

I've experienced this recently with PRs submitted for itertools. I had to
revise my first PR several times to conform to Raymond's (justified!)
requirements, which required him to spend a lot of time on the reviews, so
the whole process to took a very long time. Later, someone else made a PR
for another of Raymond's modules; I reviewed the PR and after several
iterations is was ready for Raymond's final review, which was short and
simple.


> Mentoring is certainly the solution to the latter, provided the current
> experts are mentoring new experts in their area, and landing a
> governance model that helps us decide what sorts of other changes are
> good for Python solves the former. Simply paying "someone" doesn't help.
>

My mentoring would aim to bring experienced developers to the point where
they can consistently create high-quality PRs, requiring mostly high-level
decisions from the experts. They could also effectively help to move
forward many issues and PRs which are not yet at the point where they
really need an expert's attention. And perhaps most importantly, they would
be at the point where they could begin to gain expertise in specific parts
of the codebase and eventually become "domain experts" themselves.

- Tal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181103/a3ecdcd0/attachment.html>


More information about the python-committers mailing list