[python-committers] What is a CPython core developer?

[Carol Willing]

Thanks Victor for your commitment to this. :D

I particularly like Mariatta's comment on responsibility, Antoine's comments on humility and respect, and Victor's linked document.


> On Sep 22, 2017, at 10:26 AM, Brett Cannon <brett at python.org> wrote:
> 
> +1 for the list Victor and Antoine have here!
> 
> On Fri, 22 Sep 2017 at 09:48 Antoine Pitrou <antoine at python.org <mailto:antoine at python.org>> wrote:
> 
> Hi Victor,
> 
> Thank you, this is a useful write-up!
> 
> Le 22/09/2017 à 16:26, Victor Stinner a écrit :
> >
> > I started to list "responsabilities" (is it the correct word?) of a
> > core developer.
> >
> > 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 ;-))
> 
> Well, it gives both, which is the only way things can work sanely.
> If you give power without responsabilities, you are creating a jungle;
> if you give responsabilities without the power to exert them properly,
> you are creating frustration and a dysfunctional environment.
> 
> > I identified the following CPython core developers responsabilities:
> >
> > * 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 ;-)
> 
> Unfortunately we can't evaluate that in advance.  Even the person being
> promoted often does not known whether they'll still be there in 5 or 10
> years.  Hopefully that's on their horizon, but many factors can interfere.
> 
> I, personally, can only think of a couple of cases where a person being
> promoted core developer vanished a few months after that.  It's not a
> big deal in the grand scheme of things, though it *is* frustrating to
> spend your time mentoring and promoting someone (which also engages your
> own responsability, since you're the one vouching that they'll be up to
> the task) only to see that person produce little to no work as a core
> developer.
> 
> > * 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.
> 
> Yes, I believe this is the most important part of being a core
> developer.  What it means is that core developers care about the quality
> of the whole code base (and also the non-code parts), not only their own
> contributions to it.
> 
> > * 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.
> 
> This part is also required from regular contributors, at least the
> experienced ones.
> 
> > * 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? ;-)
> 
> This is no different from regular contributors posting patches with C
> code in them.
> 
> > * 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.
> 
> Or, if the code isn't good at the first iteration, the author is able to
> figure it out by themselves and doesn't rush merge it.  Of course,
> nobody is perfect, which is why non-trivial code written by core
> developers ideally goes through a review phase anyway.  But a general
> sense of what is "in good state for review/merging" vs. "just a draft
> I'm working on" is indeed, IMHO, preferrable.
> 
> > * Pushing core means becoming responsible for this code. For
> > regressions, backward compatibility, security, etc.
> 
> Yes, this is the whole "know the project's lifecycle" thing.  It also
> includes knowing what to backport or not.
> 
> > * Something else?
> 
> Two things I would add:
> 
> - Know to be nice and respectful to the others, at least to the extent
> they're nice and respectful to yourself :-)  We don't have a rock-star
> (or "bro", "wizard", "ninja", whatever the hyperbole of the day is)
> culture here.
> 
> - Show a bit of humility towards existing work and try to understand the
> decisions behind something before deciding to change it all.  That said,
> given Python's current position on the technical evolution and adoption
> curve, we get less and less proposals for sweeping changes (perhaps not
> enough, actually, since even when rejected, they help challenge the
> statu quo).
> 
> Regards
> 
> Antoine.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers <https://mail.python.org/mailman/listinfo/python-committers>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170922/8243fc94/attachment-0001.html>