Can we move this note to its own topic? I would like to share some thoughts but do not wish to take focus away from the original purpose of this thread.
I have moved @vstinner message and your answer to this topic as it was (in my opinion) very close to the subject of the discussion. Tell me if you would prefer a fresh new topic for the discussion
Two and a half years ago, @vstinner took the time to understand my feelings on core development. I am very grateful that he (and others) did so. Without their support, I would have left the Python community with the perspective that my involvement was unneeded and unvalued.
Core development can’t be easily reduced to one dimension. Reflecting on last week’s core sprint, we bring many people together to create something where the sum is greater than any one person’s contribution. Each of us are human, and we have our own strengths and weaknesses.
As we recommend and discuss the merits of promotion, I urge you to consider that you are human and the person being proposed is human. As humans, we may be biased or inaccurate in our assessment of someone’s readiness (or even our own readiness).
IMHO, metrics should be guidelines not the minimum requirement. Very few of us, if any, would meet the metrics and qualities of an “ideal” core developer. Though, all of us can and do make Python a better language with every contribution whether process-centric, person-centric, or code-centric.
Replying to @njs in this topic because I think this is more the locus of discussion about when we should and should not vote +1 / -1 for promotions:
I think this actually makes a case for only giving commit bits to people who need them to do reviews, because if the issue is “we are drowning in unreviewed PRs”, then it makes sense to prioritize giving commit bits to people doing reviews so that they can clear out the backlog.
If we were running this like a company with a fixed “commit bit” budget, I would probably focus on giving the commit bit to people who can help clear out the review backlog, which is people who have domain expertise in “understaffed” domains and experienced maintainers who we can count on to either merge or close PRs. We don’t have any shortage of people who want to participate in the conversation and generally where we do, we fill that gap with domain experts and experienced maintainers who are not core devs (e.g. this year’s language summit included many non-core devs). Generally speaking, you do not need a commit bit in order to gain that sort of experience.
That said, we are not running a company and there is not really a fixed budget for “commit bits”, which is why many of my objections are in the subjunctive. I believe the tension I’m feeling with these core dev votes is that there isn’t any guidance as to how we’re intended to vote. I tend to agree with you about this:
Under that rubric, I would promote Joannah and Karthikeyan and several other triagers today, because I consider commit bits essentially free. Right now what happens is that every vote is on the joint question “What does it take to be a core dev, and does this person have those qualities?” rather than “Here’s what it takes to be a core dev: does this person have those qualifications?” Some people sail through because they already meet nearly everyone’s definition of what a core dev should be and there’s no controversy. Other people qualify under one rubric but not under another, which leads to somewhat uncomfortable discussions and often no clear feedback or guidance for the candidates.
Contributors tend to think that way because we keep promoting people who aren’t interested in reviewing PRs. Personally, now I regret I wasted too much time reviewing patches on Rietveld. If I were a contributor in 2019, I’d just try to land a shiny feature and then promote it on Twitter.
Honestly, I rarely review pull requests. I only look a changes on few specific areas of Python and changes from some specific contributors. Some core devs rarely do bug triage. IMHO it’s unfair to require from contributors to review a lot of pull requests, and triage a lot of bugs, and produce tons on changes, and etc.
In my experience, contributors becoming core developers naturally review more and more changes as they build their “social network”: meet other (core) developers working on similar areas. Naturally, newly promoted core developers get more and more active, but also feel more confident to dare doing things that they didn’t do previously. Discuss maybe with recently promoted core devs to check how the way they contribute evolved after they have been promoted.
Personally, now I regret I wasted too much time reviewing patches on Rietveld.
You have been promoted in 2014. The promotion process evolved since that time. I don’t think that we should use your own promotion experience to decide for new rules.
When I started to contribute to Python, Brett Cannon contacted one to start discussion promotion. I misunderstood him, I understood that the promotion would be effective quickly. In short, it took me like 2 years to get promoted. I had to fix dozens and dozens of bugs to convince enough core developers to be promoted. Honestly, my own experience was not good, but it doesn’t mean that I would like to ensure that other all candidates have to suffer as I did to deserve to become a core dev
We are all volunteers, so we cannot force anyone to do something. We can promote good practices. And maybe try to understand why even core devs do so little reviews. Or try to make some tasks more attractive.
There were discussions to try to involve contributors more in the review, advice them to review each others for example.
As a core developer, I can merge my own PRs without a review by anyone else. I generally don’t like to do this, except for really trivial changes; but as has been pointed out, getting PRs reviewed quickly doesn’t happen very often, because there are a lot of PRs and relatively few reviewers.
If a PR of mine has a requested review and no review has materialized after a while, I sometimes merge the PR anyway, as not doing so would hold up progress in an area of work. While I generally do this when working in my “comfort zone” (
py.exe, and documentation), I sometimes work in areas with which I am less familiar (e.g.
shlex). Even in such cases, a core developer is trusted to commit their PRs without oversight.
Does that mean that after submitting e.g. only documentation improvements and getting them merged (which is a useful contribution) a person can become a core developer and therefore get the right to merge their own PRs, relating to e.g. the CPython core C code or the stdlib, without review by others? Couldn’t that in theory lead to a loss of quality in the things we’re producing, or an increase in technical debt which would have to be paid in the future, even with the best will in the world for all concerned?
You raise some good questions.
Does that mean that after submitting e.g. only documentation improvements and getting them merged (which is a useful contribution) a person can become a core developer and therefore get the right to merge their own PRs, relating to e.g. the CPython core C code or the stdlib, without review by others?
I know you value documentation (thank you).
As a project, I would hope that we can get to the point in our culture where it is recognized that many contributors to documentation understand the source code as well as those who prefer writing code.
Couldn’t that in theory lead to a loss of quality in the things we’re producing, or an increase in technical debt which would have to be paid in the future, even with the best will in the world for all concerned?
We have tests, CI, and buildbots to help maintain quality. We have the ability to ask for reviews and notifications when code is merged. Yes, it is possible that a mistake can happen. If it does, the project and its workflow need to be reviewed, and the blame does not rest on one individual.
Overall, I’m not a huge fan of self-merged code. Even a seasoned developer’s code benefits from review by a more junior developer.
Carol, thanks for your comments.
Sure, with some caveats. For example, understanding the C core is quite different from understanding the Python code which ships as part of CPython: IMO most Python developers can have a good understanding of the Python code in Python, but fewer would have a good understanding of the C core (I count myself in the latter category, though I would consider myself an experienced C developer - it’s a question of familiarity with the code base, as well as a skill set. Many core developers wouldn’t need to even look at the C code in order to contribute productively to Python).
Tests, CI, buildbots and the review process can indeed help with many things. But they won’t always catch design mistakes - they’re more effective at catching implementation mistakes.
I don’t believe blaming people helps a project. The focus has to be on the deliverables. But one also shouldn’t underestimate the inertia which makes reviewing workflow and processes difficult. Python is now easily big enough to qualify as a sort of oil tanker, with quite a large turning circle!
Agreed - any one can find things to improve in code. But it’s sometimes “unavoidable” to self-merge if one wants to make timely progress in one’s area of interest. Possibly, some tweaks need to be made to processes and different types of developer roles in order to minimise self-merges and better achieve continuous improvement.
I think there’s some dramatization here. We do not require all those things at once. We set up votes and people give their opinions about candidates. Different core developers have different criteria, so someone looking at it distractingly may get the impression that the entire conjunction of criteria has to be satisfied. But that’s not how it works in practice. People can (and do) get promoted even though they don’t satisfy every core developer’s criteria.
Quote of the day
Agree with your points too. It’s definitely about tradeoffs.
In a sense, yes, that’s always a risk when you trust people. But, this is actually how things work today I don’t think there’s a single core dev who’s so familiar with CPython that they can safely make unreviewed changes to every single part of it. But it’s ok, because we trust core devs to know their limits. And in practice, those limits are usually fluid – like you said, there are some areas where you’re more confident and some where you’re less confident, but sometimes you might be highly confident in a patch even though it’s in an area you’re generally less familiar with, or want extra eyes on a patch even though it’s in one of the areas where you’re normally the expert. And if someone does make a mistake, well, that’s why we have version control That’s why we don’t try to make super fine-grained permissions, where different core devs only get commit rights on specific files – trusting people just works better.
So yeah, I’d be totally fine with giving someone commit rights based on solely on their documentation work. (Besides, anyone who’s making meaningful contributions to the Python docs must have some substantial knowledge of programming, or how else could they do it?)
By the way, we actually do have some official criteria written down for core developers, in PEP 13:
Python core team members demonstrate:
- a good grasp of the philosophy of the Python Project
- a solid track record of being constructive and helpful
- significant contributions to the project’s goals, in any form
- willingness to dedicate some time to improving Python
As the project matures, contributions go beyond code. Here’s an incomplete list of areas where contributions may be considered for joining the core team, in no particular order:
- Working on community management and outreach
- Providing support on the mailing lists and on IRC
- Triaging tickets
- Writing patches (code, docs, or tests)
- Reviewing patches (code, docs, or tests)
- Participating in design decisions
- Providing expertise in a particular domain (security, i18n, etc.)
- Managing the continuous integration infrastructure
- Managing the servers (website, tracker, documentation, etc.)
- Maintaining related projects (alternative interpreters, core infrastructure like packaging, etc.)
- Creating visual designs
Core team membership acknowledges sustained and valuable efforts that align well with the philosophy and the goals of the Python project.
This is one of the sections that came from Django without many changes, and I don’t know if people really read this part carefully when we were voting on the governance PEPs, so it’s possible we might want to tweak it. But at least for now these are the official guidelines on who deserves to be a core dev.
Hi everyone. I’m writing this post on behalf of the Steering Council.
The Council’s weekly meeting was today and we briefly discussed the good points raised by many of you. If folks have an interest in starting a working group about core developer promotion, that would be a great next step.
To start a Working Group, we will use a process similar to the PSF. A group of individuals self-organize, create a proposed charter, and submit it to the Steering Council for approval.
Here are examples of a PSF Working Group charter:
FYI we have exactly the same discussion at each promotion vote…
Some people are concern that promotion candidates who are not fully ready can reduce the quality of Python, introduce regressions, etc. The candidate is promoted and… nothing. No increase of regression. Python quality doesn’t decrease. No announced “chaos”. IMHO Python is a good as it was before latest promotions, or maybe better, but not worse.
It’s maybe time to look back at previous promotions and realize that we were right to promote them, that they are doing great in Python and making Python better, etc.
Please don’t take my words as “we must promote everyone”. I don’t advice to remove the vote to promote canditates. The vote is the best heuristic to measure if a candidate is ready and to balance different opinions.
BTW, I’m mentoring Karthikeyan aka xtreak and want to promote him.
He is ready from my perspective, and I expect that his work with “Core Dev” hat on can make Python a little better without any harm.
He has triage permissions now and very active on PRs reviews already for areas if his expertise.
I believe that committer rights motivate for more reviews.
The review is done more carefully if the reviewer cares a responsibility on committing the PR and fixing possible outcome problems.
At least it is true for myself and, I believe, for all core devs.
If a new committer merges a PR that is not good a seasoned developer can fix it, e.g. by asking for reversion in a comment; it works well already.
We are all humans, this year I see a lot of revert commits done by very respected guys when an initial commit produced regressions on our build-bot fleet for example.
I did it a few times myself, that works fine I think.
Moreover, five or six years ago I’ve committed a patch from a newbie that introduced a regression in
random.triangular without waiting from others review.
Raymond Hettinger corrected me, the patch was reverted by myself.
The lesson is learned: ask for the review from domain expert.
I’d like to have more responsible people in our team. A permissive policy can help to make Python better I think. The procedure is good now: a core developer takes a mentorship on a newbie and promote his a she after some period.
The question is: what formal requirements we have to a candidate?
Frankly, I did not review PRs of most of candidates that was elected last years.
I usually voted positively after looking on the candidate history and I saw the candidate activity for a long enough time on bugs tracker and reviews, the candidate is polite and responsive.
Anyway, Karthikeyan and I decided to postpone his election until this discussion is finished.
I believe that Nathaniel’s summary of PEP 13 is a good summary of the “requirements”.
I enjoyed seeing Karthikeyan at the recent sprint, and I agree he would be a fine addition to the core dev team.
It seems like this discussion has petered off a bit. Are we just going to stick with the PEP 13 requirements? Stick with status quo ante where everyone votes based on their own criteria? Should we request a SC ruling on it to put this to bed, at least for now?
Well, you cannot prevent people from voting with their own criteria, even if they’re not what the standard says. So the best there can be is a list of guidelines that each core developer can follow, or not, to their wish.
Well, some discussions were heated, but it seems like the process is not stuck: many contributors have been promoted as core developers. It seems like the votes are closer to private people opinions than previously, thanks to anonymous votes. I think that it’s a sane process to discuss in public how we vote.