[Python-Dev] Interested in serving on Steering Council

[David Mertz]

I do not wish to presume too much on the judgement of the core developers.
But I thank Steve Dower for his characterizations which pretty much exactly
explain why I've had those involvements with the Python community and
language I have had, and haven't done other things.

I've been part of the Python community since 1998, but really active in it
since about 2001.  During the early 2000s, I wrote a large number of widely
read articles promoting Python, often delving into explaining semi-obscure
features and language design issues.  Most of these were with in my column
_Charming Python_.  I believe that several changes in Python itself—such as
making coroutines easier to use and the design of metaclasses and class
decorators—were significantly influenced by things I wrote on the topics.

Mostly in the period after writing that column, i.e. during the 2010s, I
served as a Director of the PSF; both before and since my time as a
Director, I've chaired several PSF committees.  That likewise felt like a
way I could advance Python best, but from more of an organizational or
social perspective than a technical one.  It is interesting to me that
whereas when I started volunteering for the PSF, there was significant
overlap between the PSF board and the core-committers, I think there is
little or no overlap today.  For better or worse, PSF is much more
community than technical today.  I feel like my own skills and interest
remain somewhat at the intersection of those aspects of Python.

I did not choose during that time, nor since, to become a CPython core
developer.  I've certainly contributed to other projects in the Python
ecosystem (I'm not sure if those are "related projects" in the sense Steve
mentions).  Part of that is time commitment needed, but more of it is my
personal strategic choices about what I could best do to advance Python in
the world.  I've felt I can do more by writing, speaking, and participating
in the PSF, than I would have by working on the CPython code base itself.

In particular, I always felt that I am not nearly as strong of a *C*
developer as are most core developers.  In Python itself, yes, but not in
C.  I am certain that I could have found some small bug to fix or small
feature to add, and gotten it accepted.  But doing that would have taken me
comparatively more effort than it would many others; I felt that effort was
better targeted towards educating Python users and teaching the user-level
language design choices Python has made.

If the core developers feel that the overwhelming qualification for the
Steering Committee is familiarity with the C code base of CPython, then
indeed I am not the best candidate for that.  If language design issues are
more important—and especially if thinking about Python's place among users
and industry are important, then I think I'm a very good candidate for the
role.  In particular, I believe my judgement about "Is this feature good
for Python users?" would be as good as that of most anyone (maybe other
than Guido); but I recognize that my judgement about "Is this feature
straightforward to implement in CPython?" or "What are the performance
implications of this features?" are weaker than those of most core
developers.  Not to say I have *no* instinct about those other questions,
but I know to defer.

Best, David...


> (*) (or Committee, I don't remember :-)
> David may of course provide an answer for himself, but allow me to
> provide my answer (and this is why I pushed for allowing external
> nominations).
>
> Historically, the only reason to become a core committer was to commit
> code. Some of us no doubt desired or demonstrated greater influence, but
> all of us have committed code or reviewed and merged PRs, either
> directly to CPython or one of the related projects.
>
> This is not a job for everyone, but it's been the only job we had on offer.
>
> The closest alternative job was to be elected to the board of the Python
> Software Foundation. But this is still not a job for everyone. They also
> are not considered core committers, despite making significant
> contributions.
>
> We now have a new job on offer. Exactly what that job involves isn't
> quite defined yet, but it will certainly include some amount of
> project/program/process management, likely some customer/user engagement
> (or relationship management, if you prefer), and potentially some
> independent decision making.
>
> Guido is the only core developer who has previously contributed to
> Python in this way (whatever "this way" turns out to mean). The rest of
> us happily worked under "someone else" doing it.
>
> Meanwhile, many non-core committers in the Python community have spent
> their time building companies, consulting businesses or educational
> courses. Spending time writing code and reviewing PRs is not how they
> want to contribute, and so they have contributed in other ways -
> including writing and often reviewing PEPs. There was no need for them
> to be a core committer, since they weren't doing any of the
> committer-specific tasks.
>
> In the PEP 8016 discussions (pre vote), we agreed that if we chose to
> elect someone who is not currently a core developer, we would also
> probably vote to make them a core developer, so there is no harm in
> allowing externals to be nominated. Also since the core committers are
> voluntarily submitting to their guidance, it makes sense that voting to
> elect/dissolve is restricted to us.
>
> In summary, members of the Steering Council are filling a new role with
> only one explicit precedent within the core committers. The
> qualifications are different, and so the pool of candidates is
> different. The existing core committers will submit to the Steering
> Council, and so are the ones who elect them.
>
> (Note that I've carefully used "core committer" and "core developer"
> above. I believe it's very important to distinguish between "write
> access on GitHub" and "project decision maker", and no reason to force
> an arbitrary overlap.)
>
> Cheers,
> Steve
>


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190104/30ae92e5/attachment.html>