Thank you so much, Jeremy, for this excellent statement of my objection to #3 as it stands. I know there are others from marginalized communities who feel the same way, and a few have said so on this thread. Again we are not dealing in hypotheticals—I certainly am not. Read the open letter from Python Africa to the PSF (linked below) for a concrete instance of marginalized people being treated to unfair weighting, and—I’ll just say it—plain colonialism—from the direction of power. When such things happen you can’t expect some of us not to be wary of lowering the barriers to excluding people. As I said, around the Works of Shakespeare’s length of text above, I would accept a change of #3 to require a supermajority. For me, that is just a mollifying lowering of risk.
As pointed out earlier, “supermajority” has little effect when the total number of possible votes is small. For a 200-vote assembly, absolutely hard to meet… For a 12-person Board, not so much:
simple majority: 12/2 + 1 = 7
2/3rds supermajority: 2*12/3 = 8
It’s a difference of just 1 vote in the most favorable (to what you want) case (all 12 Board members present at a meeting). The more total votes, the more significant the difference (for example, at 13 Directors, it makes a difference of 2 votes).
You could instead hop on the “unanimous vote among the Board members present” bandwagon, for the strongest possible protection based on votes. That’s my preference.
But it’s already been made clear that this vote is about the text as already written: we’re voting on simple majority. Period. Voting that in wouldn’t preclude requiring a higher threshold by a later revision. And I wouldn’t be too surprised if “supermajority” were approved later. But, alas, precisely because it makes such little difference “even in theory” here.
This has been an interesting discussion to follow and it’s cool to see a range of perspectives. My perception is that a lot of the concerns with Change #3 actually have to do with broader uncertainty about the CoC process and/or the board’s powers and/or the board’s alignment with the perspectives of the membership. Basically seeing this proposed change is drawing attention to a penumbra of related matters that aren’t directly part of the change but are important for thinking about its consequences, and maybe make people reconsider aspects of the status quo even though they’re not on the ballot. My own reservations fall into this category as well.
One of my concerns, for instance, is that just because a process is proposed as a way to help people in vulnerable positions doesn’t mean that’s how it will always be used. When a relatively small group of people has the power to take action against someone without revealing all the details, that also leaves the door open for them to quietly sanction a comparatively powerless person. Somewhat similar to @DavidMertz and @uogbuji, my fear is not so much of a fiendish evil board trying to screw people over, but more that the board may be nudged in some ways by personal pressure, implicit bias, or competing goals[1]. This can happen even if the board members want to do the right thing and even if they believe themselves to be doing the right thing.
Another example has to do with the persistently raised concerns of privacy/secrecy. I confess I don’t full understand the ground rules here. It seems that the board and/or CoC group want to avoid revealing details of internal discussions — which sounds fine, but I also get the impression that they want to avoid revealing the results of the discussions (i.e., that a particular person was banned, de-fellowed, or otherwise sanctioned). I’m struggling to understand how to fit this together with the desire to remove someone from a public list (the list of fellows) and thereby send a warning to other communities that the person is not endorsed by the PSF.
If the goal is to prevent a person from trading on the imprimatur of the PSF, quietly removing their name from a list on a website seems unlikely to have such an effect. There would need to be a more affirmative announcement that “Person X has been stripped of their PSF Fellow status”. But if the decision has already been made to do that, then couldn’t the board, even under current rules, simply issue a similar statement but just without the actual removal? I confess I’m no expert in these matters, but I feel like this often what I see in the news in similar situations: someone does something bad, and some organization of which they are a part says something like “Person X has been placed on leave/removed from committee assignments” or even just “We repudiate the actions of Person X” — even if this is then followed by protracted legal wrangling to decide whether the person will be formally stripped of certain titles. Or, in short, if what Person X did is so bad that they have to be un-fellowed, surely there is some action that can be taken already to alert people regardless of whether the actual un-fellowing can be performed.
Like I said, both of these concerns bear on matters well outside the scope of the proposed rule change. The scenarios I’m imagining could happen with or without this rule change, so in some sense, yeah, this proposal wouldn’t change much. I’m just saying that, when I think about this, those are things I’m thinking about, and I get the impression some others are too, and that may be why this discussion is getting a bit far afield. But I’m glad to see that the PSF is holding an additional discussion to hear people’s concerns while also crafting a response to this thread. I think that kind of openness and listening is part of a healthy organization.
for example, a desire to be seen as responsive to complaints but also a desire to be seen as properly deliberative ↩︎
I saw what you said earlier. For me, even though 8 might not seem a big difference from 7, a supermajority IS a big difference from a simple majority.
Also, I know we can’t change it before the vote, which is why I’ve clearly said that I’ll vote against.
It’s all very difficult, and I think people are still feeling their way forward by trial & error. For example, here’s a message from 4 years ago:
It’s an announcement of a 3-month ban from Python core development. But it doesn’t say anything about who was banned, or why. It was apparently a copy of an email sent to the dev in question, but stripped of any identifying info.
I can’t answer why it was sent to python-committers, but doubt it had the hoped-for effect. It did ramp up paranoia among those inclined to doubt the process already.
But you can’t generalize from it either, because there really haven’t been that many “bans” in all. They’re all at least a little different,. and I don’t recall another that didn’t at least identify who was being banned.
I don’t want to sidetrack the rest of your thoughtful message to focus on this, so I’ll leave it there. Really just want to assure you that I don’t think anyone “understands all the ground rules”, because they’re still a work in progress 
.
To my eyes, we’ve overdone the “privacy” aspect, when it comes to the offenders’ roles, but less & less so in more recent times. Complicated.
I disagree with the Change 3. I don’t see the board responsible for doing this descission.
I do see the PSF Fellow Work Group responsible to review theire decission. I want also suggest that this workgroup is using the sociocracy Consent Decision-Making pattern and that we Fellows do support this.
When they found the requirements are not fullfilled anymore this group has an Objection which hardly can become resolved. By this a member of PSF Fellow Work Group can withdraw at any time her Consent. This will give a new review of the Work Group about the state of the fellow member. When the group can resolve the Objection then the fellow stays. If not the fellow can be offered a normal member state.
Note:
short video about the concept of sociocracy https://www.youtube.com/watch?v=KNcVLJy0i2k
best regards
Reimar
As stated, in the very beginning of this conversation, there is only one way to remove a PSF fellow:
There are a lot of reasons why this isn’t an ideal way to remove someone’s PSF fellowship status (or any other member’s status). I feel like those reasons have been litigated pretty heavily already in this thread, but I’ll point to the one originally stated in the announcement:
Thanks @cacherules I am aware of this cost, and in weighing the tradeoffs of this cost and the potential effects of change 3 if passed , I decide to vote against it for the practical reasons I have already elaborated which have also been expressed by others on this thread.
Correcting the record: my memory of this was faulty. The vote was closer than I recalled. The public record of Board votes shows instead that it passed by one vote:
“”"
RESOLVED, that the Python Software Foundation request the PyPI administrators to remove the package “XXXX” (https://pypi.python.org/pypi/XXXX)
Approved 6-4-1 by IRC vote, 31 January, 2014.
“”"
where I replaced the “offensive word” in question twice with “XXXX”. It’s in the public record quoted if you care.
For context, there wasn’t a passionate debate on any side, and attempts to contact the package’s author went unanswered. “XXXX” had even worked its way into the names of API functions, so it would have required major work to purge it from the project - which was very niche and had no downloads anyway. It was domain-specific wordplay. For good or ill, it was hard to care much either way.
EDIT: boy, my memory is apparently shot 
. There was no passion in the Board meeting at which the vote was taken, but I had forgotten we actually debated it in email before, over about 3 months(!). That had some passion. Not really over the package in question, but over the general question of just how low a bar it should take to purge a package from PyPI. The name of the package here - XXXX - was a one-letter play on the name of an established package - YXXX - and it was a significant piece of work. This wasn’t some troll project seeking to offend, or to test some limit, it was serious (albeit very niche) work that indulged in some unfortunate wordplay.
No consensus was reached on that. or - worse - even on the principles that might inform such a consensus. The answer we were left with was “whatever it takes to get 6 votes from the Board today”.
That’s how these things go. Messy.
As was stated in the first post on this topic, the amendment is explicitly endorsed by the current board:
I apologize that this is another long one, but I believe it informs the actual dynamics of Boards. Prior to the actual vote on a PyPI package with an apparently offensive name that Tim discusses, the Board had discussed it for a very long time.
Somewhere in that discussion, I had written the below email, which tried to bring more precision to the decision making about names to allow on PyPI. Others (such as MAL) had written similar long notes. The thing is that that decision was utterly trivial compared to whether to remove a “lifelong honor” as is being discussed now (or whether doing so should be easy and convenient rather).
To me, being a Fellow is analogous (though vastly less prestigious) to being elected to the National Academy of Sciences, or winning a Nobel Prize, or to a sports Hall of Fame, or getting an honorary doctorate. It is very rare to remove people from such things, very difficult to do, and many recipients of those things have been truly horrific people who have done awful things.
After much discussion, a Board composed 100% of very well meaning people, all acting with noble intentions and trying to follow their consciences, voted to remove that package because the name felt offensive, but without articulating any actual standard or rule about how such decisions should be made.
I very specifically fear that expelling a Fellow (which I do single out because the election is a promise of lifelong “title”… even though the actually powers granted are minute) will follow a similar “gut feeling at the moment” rather than a rational and articulable standard.
---------- Forwarded message ---------
From: David Mertz mertz@gnosis.cx
Date: Fri, Dec 6, 2013, 1:47 PM
Subject: More thoughts on package names
To: PSF Board psf@python.org
Cc: David Mertz mertz@gnosis.cx
Someone in the IRC mentioned the ‘+git’ option of ‘pip’, which reminded me of the fact that the name “git” is itself a pejorative. I don’t think we are going to take down PyPI packages with that name in them!
The pejorative name chosen was picked self-consciously by Linus Torvalds:
Torvalds has quipped about the name git, which is British English slang roughly equivalent to “unpleasant person”. Torvalds said: “I’m an egotistical bastard, and I name all my projects after myself. First ‘Linux’, now ‘git’.” The man page describes git as “the stupid content tracker”.
Perhaps “git” is less pejorative than “XXXX”–but that’s possibly only true of American English, since the former is pretty much only a British pejorative. In any case, I continue to worry about the “slippery slope” issue–it’s not at all difficult for me to imagine a half-dozen complaints coming in for something that I find less bothersome than ‘XXXX’ and I feel awkward acting without some more formal guidelines here.
It is unfortunate that we can’t reach the author of ‘XXXX’. If we actually had heard from him an explanation of why the name had a non-pejorative sense, that would give us more to go on (e.g. he had an acronym in mind, perhaps based on his initials). Or in the other direction, if the README or contents somehow said anything more about the pejorative sense, that would also provide some clarity. But we don’t have that, so it’s all guesses.
In all truth, if the [fellow Director who managed PyPI] had just taken down the package, and mentioned doing so to the Board, I really wouldn’t care much at all either way. But once it becomes this formal matter, I feel like we need to act in a more procedurally careful way. A hand count of “yeah, I don’t like the name” doesn’t feel like that.
In terms of a procedure, I guess I’d like something like this:
-
Nothing is addressed on content/CoC grounds unless it gets N complaints. Not sure what N is, but a half-dozen seems reasonable. By “content” I mean only things that really are Python packages but whose naming or documentation might be offensive to some users.[*]
-
We make an earnest effort to contact the author of a complained-of package to find their explanation of the name/content choice. We make all reasonable efforts to interpret their choices as coming from good faith.
-
If we think the offense exceed the explanation (or if an explanation can’t be solicited), at that point only do we make a judgment call about removal.
I respectfully ask that the rehashing of sexual terms here and on the mailing list cease. While some may believe that these terms have no harm, I view them very differently based on my lived experience as a survivor of childhood abuse. To me, these terms are offensive, derogatory, and bullying, and they lack respect for women and empathy that others may have a different viewpoint.
I respect that open discourse is important. I ask that everyone step back before posting to consider the impact on other Pythonistas. If you feel it is important to say, then say it, but please do recognize that your individual perspective is one of many.
Since governance impacts a collection of all individuals in a community, its success or failure is grounded in trust. The bylaws vote on item 3 comes down to:
- voting in favor of wording as is
- voting against the wording
Regardless of the outcome of the vote, the bylaw can be further amended in the future.
David mentioned the National Academy of Sciences which appealed to my scientific sensibilities. They do have bylaws (Article I Section 5) to rescind membership by 2/3rd vote of council and reinstatement by 2/3rd membership. They also have a page indicating that memberships which have been rescinded for cause.
Thank you for reading.
You’re asking for a rigid set of rules to handle a wide variety of issues that may be brought to the CoC WG and potentially to the Board (if the CoC WG thinks something is worthy). The situations that will arrive will be complex and probably impossible to map to a strict set of rules. I think we can trust our existing Board, and our existing CoC WG members to evaluate these situations as best they can.
If we cannot trust our Board, and our CoC WG members to make the right decisions, then we probably have way bigger issues to deal with. I say this as someone who has voted in a pile of PSF elections and only had a few of my votes be for candidates who were elected.
I believe that we already have plenty of safe guards in place to pass these proposed changes as is, and feel confident that the system we have built is safe. If you think improvements could be made, then we should work with the PSF to bring further improvements to the bylaws at a future election.
I am saying this stuff not because I am some naive person, but because I come from a strong background in community management, having been a meetup organizer for about a decade, and having founded a successful regional Python conference. I see the types of complaints that have come through because I have served on Code of Conduct committees, and because I have spent a lot of my time running events, and because I’ve helped people file reports to CoC committees. No one is making rash decisions or going out of their way to punish people, and decisions are not made lightly.
This thread has veered severely off topic for some time now. Mods have received quite a bit of feedback regarding this thread and posts in it, both publicly and privately. Setting slow mode is a bare minimum step if there’s any hope to getting back on topic. Please, everyone, review the PSF Code of Conduct and strive to go above and beyond its guidelines to have a respectful discussion.
Just a side note, I hope some of the views on this thread are not generalized as not trusting the board, it would be a bit of a misrepresentation to think or claim so. There is a reason I and many here for example will vote for changes 1 and 2 but not 3. In the end, we all mean good and represent a view point of a certain sect of our community that we are also actively serving btw. Like @willingc said, lets go vote on what we think. I don’t think any of the options is that dreadful that it will be the end of us.
That’s interesting reading! Offhand I’d be in favor of a similarly brief public record of major actions, but I’d have to ponder it more to be sure.
I noticed that only 4 enforcement actions across all time have been recorded there. Are they that much more saintly than us? That is, the NAS has over 6 times more members than the PSF has Fellows, and has been around over 150 years, so “4 total” seems very low.
Then I saw that they don’t conduct their own investigations. Instead they require that “complaints [must] be supported by the outcome of an investigation by an organization with jurisdiction over the complaint, usually an employer, journal, or funding agency”.
Perhaps that’s a bit of relevant corporate CYA (“hey, can’t sue us! we didn’t say you were guilty - an outside party made that judgment”), but regardless it seems to raise the bar by a lot.
I am in favor of the proposed bylaws changes.
- An organization that can grant a title should also be able to remove the title without subjecting the accuser or the accused to undue duress.
- I trust the Board as our elected officials to make decisions in our best interest and to protect the reputation of our organization (please vote in the upcoming election).
- An honor such as knighthood does not grant the recipient immunity from community standards. History has shown that there is due cause for needing to revoke a title in order to protect the sanctity of the title and organization.
I am voting in support of all three of these changes. I’ve watched the Python community grow significantly, in so many ways. I’ve been watching this growth since I started using Python in ~2006, and since I started attending conferences in 2012.
The CoC has been hugely beneficial to the community, and that’s because it’s backed by so much hard work that very few people have to see. It works in part because of the difficult balance people have maintained between what’s made public and what’s kept confidential.
I’ve looked at the Fellows list off and on over the years, and wondered if it was an append-only list. I’m happy to see this gap closed. I trust the board to use majority votes appropriately when the need arises.
I trust that if we as a community would like to refine this to require a supermajority at some point in the future, that the board will not object to that move. But I don’t want to wait longer to close this gap in order to have that requirement put in place.
And it’s well worth saying, thank you to everyone who deals with the ugly side of CoC enforcement, and thank you to everyone who digs into moderation in all aspects of the Python community.
I think it’s thoroughly on-topic 
to post a reminder that Tuesday, June 25th, 2:00 pm UTC is the deadline for affirming your intention to vote, which is mandatory this year (and is the subject of the 2nd bylaw change proposed here), That’s tomorrow where I live as I type, and you should do it ASAP in case of problems. Details are here.
Short course:
You should have received an email from “psf@psfmember.org ” with subject “[Action Required] Affirm your PSF Membership voting status” that contains information on how to affirm your voting status.
For context, I am a PSF Fellow and the current project lead of Matplotlib.
I am planing to vote in favor of all three changes (and had from when I first read them). From this discussion and the two mailing list threads, the points I found I found most persuasive about 3:
- the board can already do far more damage via majority vote
- if we were to set up the Fellows program now, it would not be set up with a committee to grant but a vote of the membership to revoke (that is weird asymmetry and likely due to path dependence as the PSF grew)
- in cases where this is going to be necessary there is likely to also be concerns about putting the full details in the open on the internet so it should be handled by a smaller group who can manage a degree of confidentiality
I am not sure if this is best solution (maybe tweak the board threshold, maybe have the same group that names fellows responsible for un-naming them, maybe have the board stand up an ad-hoc committee, maybe …) but it is to me an acceptable solution that carries little extra risk.
Practicality beats purity.