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