Calling for a Vote of No Confidence

Committers
1

According to the guidance in PEP 13, I am calling for a vote of no confidence for the entire council.

This motion is based on their recent action of suspending a core developer in which they withheld critical information:

  • The core developer’s name.

    Without this knowledge anyone who tries to work with them will be left wondering about their status: Have they left Python? Are they ill? Have they died?

    Without this knowledge people can only speculate and guess (sometimes incorrectly) about who it was.

  • Specific examples of the bad behavior. This is problematic for two reasons:

    • It denies us a learning opportunity – different cultures, different norms, different styles of up-bringing, and different life experiences means we don’t all have the same viewpoint, and something some of us take as normal could in fact get us in trouble.

    • When the reported violations do not match our personal experience with the individual, examples will help convince us that the consequences were warranted.

Finally, while suspensions can be necessary to preserve participation by the majority, the secrecy currently maintained around suspensions also has a chilling effect on participation. For example, I had to accept that I might be suspended or have my core developer status stripped from me before I could let myself post on the three month suspension thread as the only information available to me led me to believe that the suspended core developer had been targeted for their difference of opinion with the PSF.

For this vote to continue, one more core developer must agree with me that it should happen.

27 Likes
2

I disagree. I would like for the current SC to continue serving their term.

SC election is coming in a few short months. You could choose not to vote for the current members, you could choose to nominate yourself, or nominate someone else who you think could do a better job.

57 Likes
3

Just a “like” is not enough to convey my agreement with every word of Mariatta’s post.

26 Likes
4

I disagree. Not only do I agree with Mariatta about the timing, I don’t think the two key points called out warrant dissolving the council partway through their term even if they had more time left. It’s definitely feedback and something worth discussing or considering, but it doesn’t strike me as worthy of calling new elections early.

I personally don’t see how you reached that conclusion. I know some have made that accusation/assumption other places, but my reading of the reasons for suspension hinge on behaviour and not politics.

33 Likes
5

I also vehemently disagree, and wish to leave that on the record.

A lot has already been said about this, and we could still spend days arguing about it, but succinctly, I believe the public scrutiny you want CoC violations to be put under is an incredibly awful idea — it undermines the ability to enforce the CoC, and strips absolutely critical privacy protections from CoC violation victims.

As I pointed out in Three month suspension for a Core Developer - #22 by FFY00, the SC handling of this issue has been perfectly reasonable.
It is only problematic if you don’t trust the SC enough to make a decision like this in the first place, not the other way round.

20 Likes
6

I would also like to go on record as explicitly agreeing with Mariatta’s comments.

I could say more, but people have become sufficiently entrenched in their positions at this point that I doubt it would make any difference :slightly_frowning_face:

14 Likes
7

Even though I agree with your sentiment that this event was not handled correctly in many ways, I don’t feel that a “vote of no convidence” is the appropriate measure. I simply don’t believe that bad intentions played part in the process, which would make it a viable approach.

That said, I also don’t believe that the SC should be in charge of handling CoC cases or implementing any related actions at all. This should be solely in the realm of the PSF Board.

The SC should focus on what it’s best set up for, namely managing the Python programming language design and it’s CPython reference implementation.

I’m working on a longer proposal to address the process issues uncovered by the recent events. This will address and clarify the roles in our overall governance setup, the interactions between the PSF and the SC, as well as make suggestions for governing the PSF communication resources in a more ordered and transparent way, with the hope of getting us on a better track for helping the community grow.

Part of this will be to update PEP 13 and remove the power to “Enforce or update the project’s code of conduct”, as mentioned above.

29 Likes
8

This is a welcome change, IMO. The SC has been having conversations about its involvement in CoC enforcement and will publish a public stance on this soon.

I’ve loved every minute of serving on the SC until these recent CoC events. I don’t know that I could take on the mental and emotional toll of this for another term, and I certainly know that putting the responsibility of CoC enforcement (or even just figuring out how CoC enforcement should be delegated) is distracting to what I see as the primary focus of the SC, as @malemburg pointed out.

31 Likes
9

I’m still pondering my opinion on this, but I’ll note that such a vote is only useful if some of the people unhappy with the way moderation was handled also want to candidate to the next SC election. In a sense, if there are people so inclined (not me), it might be better to wait for the regular election so that you get more time to think about what you want to advocate for precisely (not only against).

11 Likes
10

Steve Holden’s final post.
David Mertz’ final post. (After which he was banned.)
And, of course:
A Core Developer’s suspension.

Agreed. The Steering Council should be free to manage Python the language.

And I actually am grateful for your willingness and service.

4 Likes
11

** I am speaking as myself **

Let me start by saying that I am sympathetic to how you feel and deeply sorry if how we handled this situation in the SC has made you lose all trust and made you think that a vote of no confidence is the best course of action.

I think it’s important that core developers and the community can hold us accountable and tell us if they believe we have made mistakes. In this regard, I can promise you that as with any other matter that has been brought to our attention, we have dedicated all our efforts to act the best we can and to honour PEP 13 and the responsibilities we have within our capabilities.

I think it’s not a surprise that the emphasis and the skillset of the SC is to help advance the Python programming language and help the core developer community advance and solve problems (technical or not). I think we have been very good at facing and navigating technical challenges, helping to solve disagreements, unblocking discussions, aligning the vision of the language, helping and facilitating the creation of working groups and managing to find funds, bootstrapping and guiding multiple core developers in residence.

I do not think a group of 5 people are the best group to make the ultimate decision for CoC incidents for core developers (remember that the CoC working group is the group that does the analysis and the recommendation that then is sent to the SC). The reasons are:

  • I do not think core developers should be different from anyone else in the community regarding these events and how they are handled. When the CoC working group has a ruling it directs it to the SC (instead of the board as like everyone else) only if the person is a core developer. I think the process should be the same for everyone whatever the process is.
  • We are already over the limit of what we can do. We had to double our meeting time to cope with all our responsibilities which now include managing 3 developers in residence, keeping track of the work, securing future funding, reviewing peps, addressing petitions and feedback via email, help creating working groups, and much more.
  • We are more biased than other groups because all these events are about core developers from the community we represent and all of this is extremely emotionally and mentally taxing. Separating our personal opinions to what it’s the best course of action for everyone like we do when we review PEPs (we try to represent what its best for everyone, not what we think) 's ridiculously hard.

Let me repeat that I am not trying to wash away responsibility. We made a decision and we are responsible for the decision. If you think we haven’t handled aspects of this correctly I hear you and I promise you that I (and the rest of the SC) take feedback very seriously.

It’s clear to me that we need to discuss together how we want to handle these situations and how we can be better here, and I think we should discuss what everyone thinks we (or future SC members) can improve here in terms of responsibilities (with changes to PEP 13) and communication.

Independently on the suspension, It looks like multiple folks are disappointed about some aspects of how we have communicated this and I can tell you that we are taking this feedback very seriously so we (this SC) and any future SC can improve here.

I don’t want to encourage you to drop this vote as it represents what you think is the best course of action, but in the same way that you pointed out that learning is a key point to manage this better in the future, so do I.

49 Likes
12

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.

  1. and perhaps a maximum ↩︎

21 Likes
13

I have many feelings and thoughts on the recent events and suspension.

I’m not sure that a vote of No Confidence is necessary though I respect @stoneleaf’s ability to raise this as a potential issue.

I want to preface this with the fact that I have never filed a CoC complaint. While I have certainly had cause over the past decades in tech, I never felt that it would personally benefit me and would instead make me a target for hostile messages.

As a former Steering Council member, I remember a time when I was told that the PSF has no formal authority over core development and conduct with CPython. With common PSF communication spaces, I can see that has changed somewhat.

While I would be fine with PSF CoC WG to determine conduct decisions, I do think the SC does have some responsibility for the CPython culture and core team priorities, which includes technical decisions as well as workflows and professional communication.

I thank the SC and everyone else for sharing their thoughts and making difficult decisions.

As someone who asked for a pause on sexually charged language, I do feel that those on Discourse complied. What prompted me to ask for the pause were comments on the mailing list that were not made by Tim. If you are someone that chose to continue using the derogatory four letter term on the mailing list, I hope that you will come to see the damage that perpetuating that word has, that it had no relevance to the bylaws amendment, and that it has a “chilling effect” on participation from people that had to decide whether to read the offensive messages or leave the conversation.

My sincere hope is that we learn from this as a community and move to make Python a healthy place for contributors.

18 Likes
14

Thank you everyone, and especially the Steering Council members, who replied. I am looking forward to the PEP 13 changes transferring CoC enforcement to the PSF.

I hereby withdraw my motion for a vote.

24 Likes