I’m Barry Warsaw, and I’m nominating myself for re-election to the Python Steering Council, 2025 Term. I have been a core Python developer since 1994, and have served on the 2019, 2020, 2021, and 2024 Steering Councils. I ran unsuccessfully for the 2022 term. I work for NVIDIA.
First and foremost, my gratitude goes to my fellow 2024 SC members, all of whom are compassionate, smart, and dedicated to Python’s best interests. It’s been an honor serving with them; the ones that run for re-election deserve your vote.
Serving on the SC is, for the most part, a joy. I believe the SC functions most effectively when it focuses its energy on the technical stewardship of Python. I am incredibly optimistic about Python’s future, and I firmly believe an active SC is essential to help balance competing objectives, and to ensure consistent, coordinated forward progress. The SC works closely with the developer community to navigate a complex, interwoven computing landscape, making thoughtful and timely decisions so that Python continues meeting the needs of our vast ecosystem of users, developers, library and application authors, tool builders, volunteers, paid and corporate contributors, packagers, documentarians, enthusiasts, and more.
As a language and community that has grown so much in the last[1] 30 years, it’s no surprise that technical opportunities and challenges both large and small continue to emerge. The diverse efforts aimed at speeding up Python, removing the GIL, evolving the type system, preserving debugging and profiling capabilities, modernizing the C API, and more, cannot be decided in isolation. Python packaging and the PyPI ecosystem has also seen incredible growth and its own challenges addressing the needs of GPUs, improving binary extension module distribution standards, maintaining and supporting PyPI, managing a diverse constellation of packaging tools, and so on.
Any one of these topics is complex enough, but when combined, the interactions and side-effects can seem overwhelming. Still, working through them appeals deeply to the engineer in me, and I think the 2024 SC has done a great job navigating them.
The community also has challenges, such as growing and diversifying the core developer community, enlarging the voting constituency, making sure all voices are heard and respected, and ensuring that mentorship is effective. More than anything, I want others to experience the same joy that first attracted me to Python.
I believe we must also acknowledge that the community is hurting, that our sense of shared purpose is suffering, and that many folks feel unwelcome and unappreciated. The responsibility to improve this rests on all of us — it is ultimately our community, and each of us should feel empowered to make a difference in whatever way we’re able.
Traditionally, the Steering Council has enforced the PSF Code of Conduct. I support the CoC and its goals. Despite the SC’s conscientious best efforts, I believe that we have not succeeded in this role. I take responsibility for my part in that; in a recent core developer suspension, I abstained for personal reasons and because I did not feel I could be unbiased. That was a mistake because I didn’t step up to take a principled stand, and because the burden and stress fell on my fellow SC members, which they accepted gracefully, and with my gratitude.
Since then, I have heard and read feedback from many people, and I’m left with a sense that nobody was well-served by the experience. I now believe the Steering Council is simply not the right body to act as the final arbiter of the CoC, for the following reasons:
- The SC’s small size increases the likelihood of bias, and makes it less resilient to abstentions, absences, and conflicts of interest compared to a larger, more diverse group.
- CoC discussions can consume precious available bandwidth during particularly busy times of a Python release cycle. This manifests in lingering and lengthy CoC discussions starving out important and time-sensitive technical discussions.
- The Python CoC governs conduct in all Python spaces, and thus should be under the auspices of the Python Software Foundation. Authority to enforce the CoC in all Python spaces derives from the PSF.
- CoC enforcement is not actually a mandated role of the SC. PEP 13 mandates to the SC exactly one responsibility: ejecting core members. While CoC violations can be a basis for ejection (and is given in PEP 13 only by way of example), it isn’t the only conceivable reason to eject a core member.
For these reasons, I believe the Steering Council should explicitly focus itself on Python’s technical stewardship, and avoid voluntarily assuming the role of CoC enforcer. If elected to the 2025 SC term, I’ll advocate for this position.
I believe the 2025 SC must work with the PSF to find the right group for this important responsibility. Given its stated enforcement procedures, this may be the PSF Conduct Working Group, or a new body may be needed. I therefore propose that the PSF, CoC WG, and the SC work together in 2025 to establish clear guidelines and processes under a PSF mandate so that all Python community members are well served, and more importantly, work to find ways to nurture healthier community interactions.
You may agree or disagree! If you prefer the SC’s traditionally role in CoC proceedings, please express your views in the most democratic way possible, by not voting for me in 2025. No hard feelings!
I’m still as passionate about Python as ever and if you still decide to vote for me, you have my appreciation, and commitment.
for me! ↩︎