On 23 September 2017 at 00:26, Victor Stinner <victor.stin...@gmail.com> wrote: > First of all, I like how Mariatta summarized a promotion (in an oral > discussion that we had). Becoming a core developer doesn't give > *power*, but *responsabilities*. (Sorry, I'm not sure about the exact > wording, maybe Mariatta can correct me here ;-))
That formulation also came up in a recent developer's guide discussion that resulted in the addition of this section: https://docs.python.org/devguide/coredev.html#what-it-means I think what we put there really does cover the essence of the role, so the main questions I personally ask about a potential new core developer are: 1. Would gaining core developer privileges improve their ability to contribute effectively (in my opinion or the opinion of another core developer)? 2. Do I (or another core developer that is willing to mentor them) trust their judgment on when things should be escalated for further review & discussion (or even rejected outright) vs just going ahead and merging them? > I also see that some core developers are more conservative, want to > reduce the risk of regressions, while some others are more on the > "forgiveness" trend ("it's better to ask forgiveness than > permission"). I think that it's perfectly normal and expected to have > people on the two sides. The question is how to find a compromise in > the middle. > > I identified the following CPython core developers responsabilities: > > * Know the CPython workflow. Be aware of the pre-commit and > post-commits CIs. How ideas are discussed. It's not only about writing > and pushing patches. > > * For C developer: know CPython specific issues like reference leaks > and the garbage collector. We expect that a core developer write code > with no reference leak, right? ;-) > > * Good quality patches: proposed changes are good (or almost good) at > the first iteration. I'm not sure about this point, but I know a few > other developers have this requiurement to promote someone. > > * Pushing core means becoming responsible for this code. For > regressions, backward compatibility, security, etc. I think these make sense, since they're about *how* we contribute, and *what* we should be looking for when reviewing code (whether our own or other people's). > * Long term commitement. We someone lands a big chunk of code, we need > someone to maintain it for at least the next 2 years. Maybe for the > next 10 years. I think that some people sign with their blood to > maintain crappy code for their own life, but it's better to not > elaborate this part ;-) > > * Review patches and pull requests. While we don't require not expect > newcomers to review, we expect that core developers dedicate a part of > their time on reviews. I'm less certain of these, as they're about *how much* we contribute, and while there's certainly a significant time element involved (since it takes time and engagement to build trust in someone else's judgment), we also expect people's level of involvement to ebb and flow based on their other commitments and their current level of interest in the core development process (regardless of whether they're a core developer or not). > * Something else? > > I don't expect this list to be complete. A vote for a promotion is > always done on a case by case basis, mostly because it's really hard > to be ready on *all* expected points. The discussion is more to > estimate how far is the contributor in its learning, if it's enough, > if more learning is needed, or if mentoring is needed. > > Maybe we should also formalize the mentoring for contributors > identified as potential core developers. It can be an explicit step in > the promotion process. Each last core developers who get promoted last > year get a mentor if I recall correctly. What do you think? An offer of post-promotion mentoring is already noted as part of the nomination process here: https://docs.python.org/devguide/coredev.html#what-it-takes I agree it may make sense to make that a clearly separate step in the process, such that someone makes the explicit decision that becoming a core developer is a goal they want to pursue, and then seeks an existing core developer to coach them through that process. Currently, that tends to only happen informally, by virtue of an existing core dev reviewing quite a few of a contributor's patches, and then asking if becoming a core developer themselves is a goal they've considered. There are some additional responsibilities listed at https://docs.python.org/devguide/coredev.html#responsibilities, but aside from the first paragraph about respecting the CoC, they're more in the nature of FYI's for just-promoted core devs. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/