Suggestion: A PSF grant for running a "Core Dev Mentorship Program"
*tl;dr:* I’d like to apply for a PSF grant to mentor several developers towards becoming active contributors and hopefully core-devs.
- What do you think? Any +1/-1 would be very helpful.
- I'm looking for info on how successful mentoring has been in getting more contributors. Any such info or references would be a great help!
Recently there has been a recent "wave" of requests for mentoring on this list. This was triggered by Victor Stinner’s post "Looking for people from underrepresented groups to mentor" <https://mail.python.org/mm3/archives/list/core-mentorship@python.org/message...>, who later wrote that he received 20-30 requests for mentoring <https://mail.python.org/mm3/archives/list/core-mentorship@python.org/message...> (!).
My understanding is that many of us would like to have more active contributors and core developers. Additionally, many would like these to be a more diverse group. Guido and Victor have lately taken up mentoring several developers with the explicit intent of achieving these goals.
I would also like to work towards these goals. I have recently invested more time on the core-mentorship mailing list and Zulip stream, as well as doing my best to mentor two promising developers. However, my free time is becoming increasingly limited again, and I am learning that effectively mentoring a developer requires being able to spend a good amount of time nearly daily on such mentoring.
My life circumstances are such that I would be able to commit to a medium-term part-time paid project. Therefore, I’ve come up with an idea for a concerted effort to mentor a group of developers for a significant length of time, which I’ve called a “Core Dev Mentorship Program”.
My current suggestion is to remotely mentor five developers for 10 weeks, selecting the participants to be as diverse a group as possible among appropriate applicants. I wrote a proposal and submitted it to the PSF. They rightly asked that I first bring this before the core devs, so here I am.
I can think of reasons to oppose such a project, with the foremost being that most (all?) such mentorship has thus far been done on a volunteer basis, and we wouldn’t want to negatively impact future volunteer mentorship efforts. In my eyes this project would be a complementary effort, and I propose it only because it appears that we are currently unable to mentor as many as we would like, nor as many as would like to be mentored.
I am purposefully not including the details of my proposal, as I would like to first focus on whether the idea is supported in general.
Any and all comments, suggestions and criticism are most welcome.
Note: I also posted this in the "commiters" category on <https://discuss.python.org/t/suggestion-a-psf-grant-for-running-a-core-dev-m...> discuss.python.org; see additional discussion there.
Le 02/11/2018 à 14:19, Tal Einat a écrit :
I would also like to work towards these goals. I have recently invested more time on the core-mentorship mailing list and Zulip stream, as well as doing my best to mentor two promising developers. However, my free time is becoming increasingly limited again, and I am learning that effectively mentoring a developer requires being able to spend a good amount of time nearly daily on such mentoring.
I'd *really* like to know why that is the case. Most existing core developers didn't need "a good amount of time" to be spent "nearly daily" on their mentoring to get them up to speed. Instead they progressed slowly on the contribution curve, with due feedback from senior core developers, but without requiring extended attention.
Contributing to a large mature project like CPython requires dedication and significant prior experience. If someone needs a large amount of hand-holding then that's a bad sign IMO. There are much simpler and more approachable projects out there if they'd like to learn contributing to open source software.
I'd also like to know what the current outcomes of the "Core Mentorship" program are. How many core developers or seasoned contributors did we get from it? The core-mentorship mailing-list has been existing since 2011, so we should have ample experience by now.
Regards
Antoine.
As a side note, I'm not against the general principle of funding some mentorship or other contribution-related activity. I'm just unsure that this would be money well spent.
Regards
Antoine.
Le 02/11/2018 à 14:37, Antoine Pitrou a écrit :
Le 02/11/2018 à 14:19, Tal Einat a écrit :
I would also like to work towards these goals. I have recently invested more time on the core-mentorship mailing list and Zulip stream, as well as doing my best to mentor two promising developers. However, my free time is becoming increasingly limited again, and I am learning that effectively mentoring a developer requires being able to spend a good amount of time nearly daily on such mentoring.
I'd *really* like to know why that is the case. Most existing core developers didn't need "a good amount of time" to be spent "nearly daily" on their mentoring to get them up to speed. Instead they progressed slowly on the contribution curve, with due feedback from senior core developers, but without requiring extended attention.
Contributing to a large mature project like CPython requires dedication and significant prior experience. If someone needs a large amount of hand-holding then that's a bad sign IMO. There are much simpler and more approachable projects out there if they'd like to learn contributing to open source software.
I'd also like to know what the current outcomes of the "Core Mentorship" program are. How many core developers or seasoned contributors did we get from it? The core-mentorship mailing-list has been existing since 2011, so we should have ample experience by now.
Regards
Antoine.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Le ven. 2 nov. 2018 à 14:55, Antoine Pitrou <antoine@python.org> a écrit :
As a side note, I'm not against the general principle of funding some mentorship or other contribution-related activity. I'm just unsure that this would be money well spent.
This is a good question. We already a lot of core developers, but almost none is paid to contribute.
Mentoring is an investment in the long term. Is it better to pay someone to review and merge PRs?
Reviewing PRs is also a way to help and train contributors. It's not very different from mentoring, depending on your definition of mentoring :-)
Victor
On 02Nov2018 0933, Victor Stinner wrote:
Mentoring is an investment in the long term. Is it better to pay someone to review and merge PRs?
Reviewing PRs is also a way to help and train contributors. It's not very different from mentoring, depending on your definition of mentoring :-)
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.
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.
Cheers, Steve
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
On 03Nov2018 1006, Tal Einat wrote:
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.
This is a great point, and I'm supportive of having "general reviewers" who can get PRs to a point where they're ready for domain-specific reviews. Hopefully that would also responses like "this seems big enough to file and discuss on an issue before submitting a PR, so hold off on the code for a bit".
Given this seems to be your goal, I'm supportive of your proposal and program. Best of luck!
Cheers, Steve
Hi Antoine,
On Fri, Nov 2, 2018 at 3:38 PM Antoine Pitrou <antoine@python.org> wrote:
Le 02/11/2018 à 14:19, Tal Einat a écrit :
I would also like to work towards these goals. I have recently invested more time on the core-mentorship mailing list and Zulip stream, as well as doing my best to mentor two promising developers. However, my free time is becoming increasingly limited again, and I am learning that effectively mentoring a developer requires being able to spend a good amount of time nearly daily on such mentoring.
I'd *really* like to know why that is the case.
I've recently been mentoring two experienced developers: Gus Goulart and Jonathan Gossage. Initially, when their momentum was highest, every day at least one of them had non-trivial questions to ask and/or PRs ready for review. I attempted to be highly responsive to allow them to progress unhindered, and found myself spending at least 30 minutes on this nearly every day. I now spend less time on this simply because their momentum is reduced, partially because at one point I was not able to keep up with their progress.
Most existing core developers didn't need "a good amount of time" to be spent "nearly daily" on their mentoring to get them up to speed. Instead they progressed slowly on the contribution curve, with due feedback from senior core developers, but without requiring extended attention.
True, but this process is not suitable for many, and it does not seem to currently be yielding as many regular contributors and core developers as we'd like.
My personal experience is that it took me over a decade between beginning to contribute to Python to becoming an active core dev. I believe that that could have taken just a few months if I had had a mentor.
Contributing to a large mature project like CPython requires dedication and significant prior experience. If someone needs a large amount of hand-holding then that's a bad sign IMO. There are much simpler and more approachable projects out there if they'd like to learn contributing to open source software.
There appear to be many experienced developers interested in becoming contributors (and possibly core devs down the road). The two I'm now mentoring are such; they don't require "hand-holding" in the sense of more junior developers. No other core dev seemed to be available for mentoring them when they first asked for mentoring.
I'd also like to know what the current outcomes of the "Core Mentorship" program are. How many core developers or seasoned contributors did we get from it? The core-mentorship mailing-list has been existing since 2011, so we should have ample experience by now.
I'm looking for this info too!
- Tal Einat
Le 02/11/2018 à 14:19, Tal Einat a écrit :
I am learning that effectively mentoring a developer requires being able to spend a good amount of time nearly daily on such mentoring.
It really depends on the availability and skills of the mentoree. I have mentorees who are very busy and sometimes don't ask anything for 2 weeks. Others are making good progress and ask me for help multiple times per week. I wouldn't say daily, since neither mentorees nor me are available everyday.
I also know that I should try to answer as soon as possible to my mentorees, since they are usually blocked and unable to find the solution by themselves.
Le ven. 2 nov. 2018 à 14:38, Antoine Pitrou <antoine@python.org> a écrit :
I'd *really* like to know why that is the case. Most existing core developers didn't need "a good amount of time" to be spent "nearly daily" on their mentoring to get them up to speed. Instead they progressed slowly on the contribution curve, with due feedback from senior core developers, but without requiring extended attention.
Such profiles are the least common, and we already promoted all of them :-)
The trend on mentoring means that we need more core developers and that we have to help to prevent people moving to a more responsive project.
IMO saying that mentoring is not needed indirectly means that we have enough available core developers to handle the 6000 open issues, the 900 pull requests, maintain the continuous integration (Travis CI, AppVeyor, VSTS, buildbots), fix regressions, etc.
Contributing to a large mature project like CPython requires dedication and significant prior experience. If someone needs a large amount of hand-holding then that's a bad sign IMO.
We have documentations like the devguide, but to me it's now obvious that it's not enough. I don't see it as a bad sign. Python is a very mature project which has very high quality standard and a very strong constraint of backward compatibility. Python is different from other projects. IMHO breaking the backward compatibility in Django seems to be easiler than in Python.
There are much simpler and more approachable projects out there if they'd like to learn contributing to open source software.
Exactly. This is why we fail to convert volunteer contributors to core developers. They fly away because pull requests are not reviewed, whereas other projects are faster than us to review PRs, give better feedback and has less strict on quality/backward compat.
Victor
Le 02/11/2018 à 17:30, Victor Stinner a écrit :
There are much simpler and more approachable projects out there if they'd like to learn contributing to open source software.
Exactly. This is why we fail to convert volunteer contributors to core developers. They fly away because pull requests are not reviewed, whereas other projects are faster than us to review PRs, give better feedback and has less strict on quality/backward compat.
To be honest, often when PRs are reviewed the PR author never comes back to address the points raised. At least, that seems to have been my experience several times recently. Perhaps people expect their contributions to be reviewed in a very short timeframe and they lose patience afterwards? That sounds like a plausible explanation.
It's also the case that CPython bugs are more and more obscure, and probably less rewarding to fix because of that. Take for example this fix: https://github.com/python/cpython/pull/10305
It's nice that someone bothered to fix this issue. But the underlying concern is also completely fringy :-) Usually you don't want to send several gigabytes of data at once on a multiprocessing connection, because that's obviously more inefficient than finding a way not to duplicate the data. So the fix is good for correctness (and it should also be a very simple fix, even with the compatibility hack added in), but not very relevant if you care a little bit about optimizing your system.
To have more interesting issues to work on for new contributors, we should start adding new standard library modules (and/or new major core features) again!
Regards
Antoine.
participants (4)
-
Antoine Pitrou -
Steve Dower -
Tal Einat -
Victor Stinner