Posting this reply speaking only for myself.
I’m quite reluctant to post on this topic, for reasons I hope will be evident below.
I completely agree, and in fact I have been writing up my own thoughts which sound like they echo @malemburg 's closely. I had plans to share these more widely after a bit of more review.
As expressed by @emily and @pablogsal, serving on the SC has been a joy, but for the CoC enforcement discussions. This is true even when the technical issues before us are difficult and challenging, and I can state unequivocally that on every term I have served, the SC members have always strived to do what’s best for the Python language, its ecosystem, and its users.
Even on the terms I have not served, when decisions may not have gone the way I would have wanted, I never for a second doubted that the SC making those decisions didn’t deeply deliberated the pros and cons, the long term benefits and costs of such technical decisions, doing their best within human capability to selflessly and objectively make the right decision. The SC election process gives us the avenue to express our collective agreement or disagreement with that assessment using the democratic power of the vote.
While I hadn’t planned on sharing this publicly, to add some additional context, I’ll reveal that I abstained from the last round of CoC deliberations, just as Brett and Łukasz did in the CoC WG as stated in that communication. For me, the reasons included a) I didn’t feel like I could be unbiased, and b) for personal reasons completely unrelated to Python, the people involved, or the issue at hand. I won’t go into more detail, but echo that the mental and emotional toll of such deliberations can be overwhelming.
I have nothing but the highest admiration and gratitude for my fellow SC members who accepted my abstention with grace, understanding, and compassion, and still took that responsibility upon themselves. Trust them when they say this is really really difficult. When I had to bow out, they found the strength to continue on, and I personally thank each of them for it.
PEP 13 conveys CoC enforcement powers to the SC by way of example only, in the Powers section:
Enforce or update the project’s code of conduct
This is an authority the SC can utilize, but isn’t mandated to, and in fact PEP 13 suggests:
[i]t’s better to establish a Code of Conduct committee than to rule on individual cases.
The only power explicitly given to the SC in PEP 13 is ejecting core development team members. This requires a 2/3rds majority, effectively a 4:1 vote in favor of ejection, and this is one power that the SC cannot delegate, nor can this power be used while a vote of no confidence is in process. Exactly what “ejection” means isn’t defined, but I think it means at a minimum[1] revoking that developer’s “commit bit”. The rationale for an ejection aren’t spelled out, but again only by way of example is CoC violations mentioned.
I point this out because while I do think PEP 13 needs to be updated, it was a bit eye-opening to me to actually dig into PEP 13 and research exactly what powers of enforcement it gives to the SC. As it turns out, it really is just that one mandated power.
The Steering Council’s core mission is stewardship of the technical evolution of the Python language and CPython reference implementation. IMHO, the CoC governs conduct across all Python spaces for the entire Python community, and thus ultimately falls within the authority of the PSF and its delegates, officers, and members. I think we’re all most effective when we refocus our work keeping this in mind.
I hope you’ll respect any future silence I choose to invoke on this topic.
and perhaps a maximum ↩︎