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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com