Folks, can you take debating Tim’s exact circumstances to some other thread?
We ought to be able to discuss the proposal on the table on its own merits.
17 Likes
I agree. This topiic is more appropriate,
but after 12 days nobody yet has tried to defend any of the specific charges against me.
6 Likes
Thank you for all your input on the proposal. Regardless of whether this motion passes or not, having such an open discussion is already a net win over what we had in the past 
.
Moving the responsibility somewhere else
The main critique about the proposal seems to be that it doesn’t directly suggest an alternative to where the responsibility for handling conduct issues should go in the future.
That’s true, but a unfortunately a consequence of our current situation within the PSF. I would have loved to move the responsibility for handling such cases to the PSF Board, but the PSF conduct processes are (and have been for a long while) in a completely broken state, so this was not an option at this point.
As I mentioned in the message I linked to at in the OP, this proposal is a small part of a much larger list of changes I would like to suggest to get the PSF back on track and better set up for fulfilling its mission.
So for the time being, my suggestion is to start fixing things with smaller patches until we have a better idea of where things are moving with the PSF and what the relation between the core developers and the PSF should be going forward.
Moving the responsibility to the core developers
Since the SC will no longer be in charge of handling CoC cases, my suggestion is to have these handled by the group of core developers themselves. In the open, on this forum and between us.
If we find that we need to take extreme actions such as bans or even ejections from the core membership, we can have a vote among the core developers and then collectively ask the SC to implement any needed actions.
Our group is small enough that we can easily handle this and having such deliberations in the open is better than the current opaque approach the PSF is taking with CoC questions.
Formalizing core developer votes
We may want to formalize this process in PEP 13 by adding core developer motions and votes (these are often called “proposals by the members” and “general assembly votes” in other orgs) as a way for the core developers to take action on things which we find important enough, but that would go into a separate proposal, with a separate patch to PEP 13.
My personal take on handling conduct issues
Overall, and in my experience, I believe that open communication, tolerance, professional mediation and asking people to tone down in discussions is a much better approach to handling these things, than everything that’s being interpreted into codes of conducts.
You don’t create a welcoming atmosphere by pointing people to methods of punishment. It’s smiling faces, passion, joy and offering help without reward, that creates a welcoming atmosphere.
Just to clarify: I’m not a perfect citizen in Python land either. I have a very direct way of expressing my thoughts, which people may find offensive at times. I usually try to let people know upfront and ask them to be just as open when approaching me. IMO, clarifying misunderstandings and agreeing to disagree are key concepts for useful interactions. And if this takes a longer email or forum thread to accomplish this, that’s perfectly fine.
BTW: This proposal is not something which was triggered by Tim’s temporary ban. I’ve been trying to get people to understand that we need a better approach for many many years. The ban just reminded me of perhaps starting another attempt.
Next steps
I will send out an email to all voting core developers (our “general assembly”) today and point them to this topic, so that they are aware that a poll is coming up.
This may also require adding a few more people to this sub-forum. I’ll point them to the moderators to get the arranged.
I’ll open the poll sometime on Sunday. It’ll then close automatically the Sunday AoE two weeks later and show the results.
Thanks.
19 Likes
Done. Thanks for the hint.
1 Like
FYI, @pradyunsg and I are going to open a poll for Adding a "deadline" for seconding a vote of no confidence and will run it to coincide with the SC voting period from PEP 8106: Monday 25th November through Monday 9th December AoE.
It might be a good idea for all three to follow the same schedule?
3 Likes
Done.
In theory yes, but the outcome of this poll may actually influence the vote of the SC, so I’m not sure whether keeping the results private until after the SC vote ends is such a good idea.
1 Like
I still feel that taking the responsibility away from the SC without a clear path to a working alternative (I think making it a responsibility of the core devs as a whole is an interesting, but untried, idea) is rather more risk than I’m comfortable with. Maybe it would be better if the proposal was to ask the SC to initiate a process to transfer the responsibility? That way, the will of the core devs is clear, the SC have a mandate to take explicit action, but there’s no sudden void where we have no process at all.
I note that many of the SC nominations for this election have covered CoC matters - we have another option to influence things by how we vote for the SC. My feeling is that if we vote in the SC election based on our preferred outcome on the CoC, and this vote is more clearly a signal of the core devs’ desire rather than being a very specific action, we’ll have enabled a much smoother transition than if we push for a simple removal of CoC responsibility from PEP 13.
21 Likes
I believe it’s better to ask the core devs as a whole for their opinion on whether to transfer responsibility for handling conduct cases at some point the future when we may have more options.
I also don’t think that we need to be afraid of handling such cases in open discussions, as I suggested. There is something to learn in there for everybody and it’ll make us more confident as a group as well.
PS: I do wonder where all this fear and uncertainty I’m hearing is coming from. It’s definitely not a good sign and I very much hope that we can get over it.
6 Likes
Open discussions about generalized issues, maybe. But discussing particular cases has risks, both in harming everyone involved in a particular case, and in the group in general. That’s especially true for when discussions are effectively open for the entire internet and archived for ever.
I’m not in favor of the current proposal because it takes CoC handling away from the SC without finding a new group that will be responsible. But more importantly, the steering council has a leadership role for the Python language and the CPython implementation, and IMHO CoC enforcement is part of such a role.
14 Likes
FYI: Barry found another occurance of conduct handling in PEP 13, which I now also removed. See PEP 13 Change Proposal - Remove CoC responsibility (WIP) by malemburg · Pull Request #4134 · python/peps for details.
1 Like
For me, it’s not so much fear and uncertainty as:
- Wanting to ensure we have continuity for our CoC process.
- Not wanting the (emotional) stress of having contentious discussions turn into even more contentious debates over who’s at fault and what to do about it.
- Frankly, not wanting to be involved in CoC enforcement.
I agree that more openness and willingness to discuss offenses would be a good thing. But sometimes I feel that people can be too sensitive to really have an open discussion, and that just makes the debate harder, and pushes people with less extreme views away, leaving the debate polarised.
To give a very personal viewpoint, I’m old enough that I grew up in an era when “casual behaviour” would these days be considered utterly unacceptable. Racism, sexism and homophobia were the subject of jokes, not to be taken seriously (some of the 1970s comedies in the UK were horrifying to today’s eyes). I’ve obviously learned better over the years, but whenever I engage on CoC style discussions[1], I’m in constant fear of accidentally using a turn of phrase, or an analogy, from my youth which won’t be taken in the way I mean it. That means that what looks like a short[2] comment can have taken sometimes literally hours of stressful crafting just to be sure I won’t offend anyone. And I’m always afraid at the end that in crafting my words so carefully, I’ve diluted my position to the point where I’m no longer saying what I want to.
The problem is, conduct discussions start from a position of people already being offended. I don’t know if I (or any of the other core devs) could do a good job in that context. And conversely, I’m willing to forgive a lot of missteps from the SC in their handling of CoC issues, as I can’t imagine doing any better and I’m immensely grateful that they take the responsibility so I don’t have to.
19 Likes
Reading that PR, this change does not seem to actually change anything. PEP 13 already specifies that the SC would probably be better off delegating CoC issues to a committee set up for the purpose, and this change just removes that. Elsewhere, CoC enforcement/policy update is listed in the non-exhaustive examples of what the SC can do, which to my reading means for this change to have the intended effect you would actually need to add language specifying that the SC is not allowed to deal with CoC issues.
Like others, I am very much against leaving a vacuum. However, to my reading this change still leaves the CoC in the SC’s hands.
Overall, I don’t see how this change of text actually improves anything, regardless of where you stand on the status quo.
9 Likes
I expect people are (legitimately) concerned about that “CoC enforcement” often involves a report about bad behavior(s) filed with the CoC WG by someone who wishes to remain anonymous. In which case “the evidence” may well not be possible to ethically disclose to core devs, let alone to the public.
That’s worth fretting over, although it’s not always the case. For example, when Stefan Krah was booted, mounds of evidence was made public. In my own case, we’ve been given no reason to believe a CoC complaint was filed against me (and see my blog for strong reasons to believe there was not).
However, public bans are extreme cases too. Since we’re never told anything about what - or even if ever - the SC does about “CoC enforcement” in non-public cases, there’s no way for us to guess how often privacy is a concern in real cases.
We know approximately infinitely more about PyCon CoC enforcement actions, due to PyCon “CoC transparency reports”, which are very brief summaries of the nature and number of actions taken, with no identifying information. But the CoC WG and the SC don’t yet produce such reports for their own deliberations, so the core devs here don’t really have a clue about the nature or number of cases they may be asked to judge.
So I think there’s good reason for caution about leaving CoC enforcement responsibility fuzzy…
1 Like
I didn’t want to go that far. Not including it explicitly in the example list should be enough.
The point of the change is that the SC gets a clear message from the core developers to not be responsible for dealing with conduct issues.
I also want to point out that the intent behind this change is to eventually arrive at a situation where we only need to deal with conduct issues in extreme cases. Ideally, mediation by fellow core devs and some common sense should help with most issues that arise.
3 Likes
Thank you for sharing your thoughts, Paul.
We should definitely do something about removing such stress from participating in our online discussions.
The goal cannot be to try to not offend anyone, since someone on the Internet will always feel offended for whatever reason and regardless of what you say. Instead, we should get back to a good understanding of how to apply tolerance for different backgrounds, opinions, beliefs and fears, and have all participants take this into account.
8 Likes
[@barry edited for typo]
For reasons I’ve stated in other threads, I don’t actually believe that PEP 13 requires the SC to be the final arbiter of CoC violations. The one mandated responsibility is to eject core members. “Enforc[ing] and updat[ing] the project’s code of conduct” is a power the SC can – and traditionally has – assumed authority for. Others disagree with this point of view… and that’s okay!
I also don’t think MAL’s PR actually strips any powers from the SC.
By removing mention of code of conduct involvement from PEP 13, it focuses the central role of the SC on technical stewardship, which I think is the right long term role for the SC.
I agree that the SC cannot responsibly just abdicate the enforcement role, or foist it back on the CoC WG, and so I proposed in my nomination posting that in 2025 the PSF, SC, and CoC WG[1] should figure out what the right body (existing or new) the enforcement responsibility should be given to.
I also think that because the CoC governs all Python spaces, and it’s a community-wide policy, the mandate for enforcement should ultimately flow from the PSF and its leadership.
I enumerated my reasons for why I think the SC is not the right body for CoC enforcement. I totally respect the alternative point of view! Just because the SC has done it in the past doesn’t mean it is the right thing for the future. The relationship between the PSF, SC, project, and community is always changing, and I think a discussion about this topic is healthy, as long as it is respectful and adheres to the CoC of course!
I fully support the CoC. I do think that focusing only on enforcement isn’t quite right either. A more positive viewpoint is, how do we foster healthier communities? Our north star should be that no CoC enforcement actions are ever needed. Human nature being what it is, we may never achieve it, but that doesn’t mean that shouldn’t be our guiding light.
and of course any community members who are motivated to participate ↩︎
8 Likes
Over the years especially 8-10 years ago, I was told that core development is distinct from the PSF. Depending on who shared information with me, the perspectives ran the spectrum from the extremes of the PSF has no governance of core development and core developers to the PSF governs spaces that are resourced by the PSF.
I suspect these fuzzy interpretations make discussion of the CoC challenging.
I also think that because the CoC governs all Python spaces, and it’s a community-wide policy, the mandate for enforcement should ultimately flow from the PSF and its leadership.
If that is the fact, that belongs explicitly in PEP 13.
Fundamentally, I agree with Barry that there should be one body responsible for CoC policy, process, and actions. I think we would be best served by making it explicit and not silently avoiding it.
15 Likes
I echo the sentiment that Thomas, Alex and others have expressed. There may be merit in transferring responsibility of CoC enforcement to another group - but without a clear understanding of where CoC enforcement responsibility will transfer to, a vote on this proposed change seems, at best, premature. I will be voting against this proposal.
8 Likes
You are wrong here, which I already addressed in my first response here. But as others asked, we should focus on the PEP 13 change proposal in this topic.
5 Likes
My apologies for missing that. I agree it’s possible to read part of your first response that way.
Then please do so. I already pointed to an appropriate topic for stuff about my specific case. If you care to bring that up there, I’d be happy to elaborate.
3 Likes