I think using this as an example for marginalization is very disingenuous. Whichever way it turned out I think the other core devs articulated their side of the argument and they might just disagree on how to be inclusive.
For example, I disagreed about changing the pty documentation here while being ambivalent on the other changes.
@pitrou, @grodola, everyone: Can I ask folks to take a deep breath and remember that there are real people on the other side of the screen? I don’t know if you clicked through to read the slides, but Victor talks about some super difficult and personal things, including screenshots of bullying he personally experienced. There’s plenty of room for discussion about what the project can or should do about these kinds of things. But when you respond to his personal experience with nitpicks about his phrasing and questions about whether bullying actually exists it comes across as just… inhumane, really.
I think @Mariatta and @ambv aren’t yet accepting proposals for the language summit, but I think it would be great to organize a discussion about how CPython could/should deal with funding – perhaps inviting folks from projects that have been down this road (Django, PyPI, NumPy, etc.) to come and answer questions.
I didn’t do any of that. Don’t try to insinuate things I clearly didn’t mean please. Labeling my comment as “inhuman” is pretty far reaching and it wasn’t certainly my intent. It’s not by silencing debate or keeping things private that you will address any of these issues.
Sorry, there may be some language issue here because I used one of those weird words that English loves… “inhuman” != “inhumane”. If someone called you “inhuman” it would mean they didn’t think you were worthy of basic human respect. I didn’t do that, and never would. If someone calls something you did “inhumane”, it’s very different – it means that action wasn’t treating other people with basic human respect.
No-one is silencing anyone. But I do believe you can do better than this.
Hi Nathaniel,
I did read carefully through the slides and it did notice that Victor was subjected to private insults by anonymous or pseudonymous harassers. I also noticed that Victor suffered from burnout issues due to his extremely high level of contribution.
Then I think you’re misunderstanding me. I’m not responding to Victor’s personal experience, which wasn’t the only topic of his presentation. I’m responding to the general points and statements he makes.
The topic of the discussion is “How to engage Python contributors in the long term”. If the discussion is based on general premises such as “tech is easy” and “Python is all about people” then I don’t understand why it would be inappropriate to challenge those statements.
Because, no, tech isn’t easy, and CPython isn’t easy either. Most core developers spent years (more realistically decades) improving their development skills and knowledge, their technical culture. Most people in the world would probably not have the kind of persistence and fondness for logical problems or tedious bug-solving that comes with becoming a core developer here.
I hope this clears things up 
Oh, I forgot a very recent example: someone posted under Emily Morehouse nomination for the Steering Committee that she doesn’t deserve to be a candidate because she is only a core dev for less than one year and the author gave names of 3 men developers would should be candidates according to him (I guess that the author of the post if a man). For me, this is called misogyny. I let you read the original message and answers to make your own opinion:
It’s just one recent public incident. I don’t try to maintain a complete public list of incidents.
There are more and more of such incidents which become public. I don’t think that there are more incidents than in the past, it’s just that victims feel more comfortable to talk about it.
In my experience, using the bug tracker is bad advice for newcomers, for the reasons that you just gave. When I mentor someone, I now prefer to find a simple task and give it in private to one of my mentoree. Instead of fixing something myself, I start to explain how I would fix it and help the mentoree to do it. Sometimes I’m giving too many hints, so it’s too easy. It’s better to only give a few hints, and let the mentoree discover the code alone, but then help in parallel.
IMHO the only explanation is that we don’t have enough core developers. By adding more core developers, I expect more reviews. In my experience, “regular contributors” don’t review because they are not allowed to merge and so feel less involved in a change. When a core dev has to merge something, they become more picky because they will have to maintain that modified code for the next 5 years!
It seems like since we moved to GitHub, finding contributors is no longer an issue (not sure if it was the bottleneck before GitHub?). The bottleneck is now clearly the review part.
That’s why I wrote a draft PEP to explain “howto become a core developer”: misc/cpython/pep-core_dev_process.rst at main · vstinner/misc · GitHub
I’m also trying to be transparent in how I’m involved in Python. Recently, I opened a public call to find mentorees on the core-mentorship mailing list. More than 30 candidates applied, sadly I was only able to mentor 1 or 2 (I was already mentoring 2 pr 3 persons).
I chose to not announce when I start or stop mentoring someone because I don’t want to put pressure on the mentoree nor on myself. I prefer to have more freedom. For example, I don’t want that others expect that each mentoree will become soon a core dev. It depends on the schedule of each person. Sometimes, I become more busy and has to stop mentoring. Sometimes, the mentoree has exams, moves to a different country or get a new job, etc. I’m learning a lot from mentorees and slowly more and more mentorees are ready to become core developers. I hope that I will be able to promote some of them soon!
I chose to take the freedom of choosing candidates with my own criteria. The call on core-mentorship succeed to find people who don’t already met/know other core developers (don’t attend the same events).
I don’t know if what I’m doing is correct or not, but at least I’m trying different things 
I just feel guilty of not sharing more often my experience. Well, I’m doing that in this thread
I will not suggest to stop helping friends to contribute. The most difficult part is Open Source is to build trust. And friendship helps a lot, we don’t have to start from scratch.
I participated to multiple sprints and sometimes I’m not sure that it’s a good way to involve contributors in the long term. It’s nice to get a few pull requests, but usually not of them are not review immediately. In the worst case, 6 months later, these changes are still not reviewed yet. Moreover, most people who participated at the sprint go away after the sprint and we never see them again. I don’t feel like most active contributors started to contribute because such sprint. Tell me if I’m wrong.
I’m not asking to stop organizing such sprint, they are great! I’m just saying that sprints is not and should not be the only way to get more contributors.
I tend not to participate in sprints but my indirect experience (i.e. by watching the outcome) is that indeed they produce a lot of one-time contributions that aren’t usually followed by further involvement. So I think sprints may not be terribly productive if the goal is to recruit new contributors. They probably can be useful for other things, though (such as helping existing contributors tackle more complex issues)
(note: edited a double negative inserted by mistake )
Please keep “Tech is easy. People are complex.” and “Python is all about people” in the context of my talk. Taken outside their context, they don’t make sense. If you understand that I said “tech is easy”, you missed my point.
My point is that to build Python, you need a trust relationship between core developers and contributors (and between core developers, obviously). With that, pull requests are slowly dying in the bug tracker and slowly, bugs are no longer fixed. Sadly, schools don’t teach how to do that. Most developers don’t know how to do that. It requires a special effort of everybody to spent time, discuss, review core, know each other, etc.
My talk is also about very concrete issues that I put into a global generic “toxicity” category which makes these things worse. I’m proposing a few solutions to work on that. Thankfully, these solutions are already applied, we should just continue our effort on that area.
I’m not sure why you reduced 50 slides to 2 quotes.
Maybe a better would be “People are harder than code”, but it sounds less catchy I have to confess that I used a clickbait (sub)title to keep my audience listening until the end
I’m not sure where exaclty, but somewhere in these discussions we moved from “howto engage Python contributors in the long term” (title of the discussion) to “Code of Conduct is a threat to developers” (what I understood when I read your latest message). I would prefer to stay on the original topic, but well, your point is related to the topic, so let me reply anyway.
I’m not sure why you see Code of Conduct or diversity as a threat. It is supposed to first protect developers of the project. In my experience, the Code of Conduct was only used recently to keep discussions productive and make trolls quite.
(What I call trolls are people who are opposed to the main opinion on purpose, just to =make people react and make other people angry. They don’t care about Python at all. I saw more and more of such troll messages recently in Python.)
Maybe there is an issue if you see the CoC as a threat. Maybe you should elaborate? Do you think that the CoC is misused? How is it a threat to you?
Though I don’t have mentoring experience myself I share the concerns of Barry on indecisiveness involved in easy issues. During meetups and on online interactions when people express interest on contributing to CPython I can point them to devguide for initial setup and workflow. Easy issues is the next logical step for me point to. Lot of issues were tagged as easy but later with discussions about the complexity and compatibility of the fix is not updated along with the easy tag in the discussion.
Given that it’s already very difficult to raise fresh easy issues or triage older ones given the maturity of the project it would be helpful if the existing list could at least be cleaned up. Though there are various factors are involved in the contributor moving to slightly harder issues, easy issues serve as a good hands on experience of workflow and discussion. For someone who doesn’t do full time mentoring it’s the only resource when some is enthusiastic on their first step towards becoming a contributor.
I think a big part of the CoC concerns (which I share) is that it’s only useful against known contributors, while it looks like most of the harassment comes from anonymous people. How are you supposed to apply a list of "don’t"s against single-use accounts created behind Tor with a temporary email address? Regular moderation is totally sufficient - if we don’t know you and you aren’t making a positive contribution, you have no right to use our forums.
Rather than the current popularised form of CoCs, I’d rather see more positive statements about how members of our community support, encourage and defend each other. This can be phrased as an ideal that we strive for, rather than rules that can only be failed. Some years back when the topic of mental illness came up at the language summit, the outpouring of support and encouragement then is what I’d like to see encouraged.
We shouldn’t need a citable document to tell each other to back off when we’re giving each other a hard time. We can’t enforce a citable document against those we don’t know, and we don’t need one to exclude anonymous venom. Having a document does not prevent unintentional offence, nor does it make it easier to deal with (though designated neutral parties certainly do).
Obviously this isn’t the same for conferences, they have different concerns and different recourses. But for participatory forums like we have online, a code that is only effective against serious contributors is not at all encouraging - the more you contribute, the more susceptible you become to having it used against you over innocent misunderstandings or lapses.
I hope that provides some context for those who don’t understand why CoCs are not universally popular. (Some of this clarity only just occurred to me, which is why I haven’t brought it up before.)
Well, I think accuracy and avoiding creating misunderstandings should trump catchiness here
You bring up some good points. I agree that with anonymous trolls the best we may able to do is mitigate the damage when directed at an individual.
Jupyter tried to strike a balance between what is expected goals and what is problematic. https://github.com/jupyter/governance/blob/master/conduct/code_of_conduct.md
Like many things, there is not one perfect solution or CoC, but we can try to strike a balance, such as apologize when needed and recognize where there is common ground. Respectfully agreeing to disagree is often more productive than prove one’s point at all costs
I don’t really understand this – maybe when you say “CoC” you’re thinking of something different than me? To me, the Update on moderation post has all the key features that define a CoC: it gives concrete guidance on acceptable and unacceptable behavior, describes potential consequences for the latter, and is written down so people know what to expect, or can critique it if necessary. It’s also in many ways a bad CoC: limited scope, limited range of behavior covered, didn’t get much review by the community, the enforcement mechanisms are pretty blunt (e.g. there’s no appeal), probably could have more positive encouragement like you suggest, etc. But that’s because it was written in a scramble while we actually had “single-use accounts created behind Tor with a temporary email address” posting. Dealing with this was way more painful/controversial/slow than it would have been if we’d written something like this down ahead of time.
Moderating is incredibly hard when you don’t know the rules you’re enforcing and don’t know if the community will have your back on any given decision.
Or: any simple change that you’re proposing is quickly considered controversial. The review process is very biased towards the status quo. There is some merit for that for features: there should be very good reasons to add a new language feature. That’s fair and I think that’s what the puppy slide with Brett Cannon’s quote refers to. However, for bug fixes, the bias towards status quo makes much less sense: they typically don’t come with maintenance overhead (they fix existing code, rather than add new code) and they solve real problems that people actually encountered. Therefore, chances are much higher that the bug fix actually improves things. If good testcases are added and maybe code is cleaned up, bug fixes might actually reduce maintenance cost.
Two examples in my personal experience:
Disclaimer
=========
Victor, first of all let me clarify that my intervention was not meant as an attack to you. This is not an easy topic to discuss and the risk of being misunderstood is very high. As such, I invite you and everybody else to please assume positive intent on my part and focus on the content of what I am about to write rather than the “form” (note: I’m not a native English speaker), because I would like to raise awareness about something which I believe deserves attention.
Terminology
==========
I think it makes sense to start from the master/slave terminology case, since you mentioned it in your slides and in here. If we remain in the realm of the Python community (python-* ml, BPO, etc.) I think the change was criticized mainly because the rationale was not clear. In practical terms one may argue that the terminology change in itself was harmless, and I have no doubt about your good intentions, but I personally agree with the sentiment that other core-devs have expressed in the ticket and IMHO I deem that as legitimate criticism. As for what happened outside of the python community (reddit, twitter, 4chan, etc.) that’s another story. I am sincerely sorry to hear you received strong personal attacks, but I wouldn’t consider “the internet” (and especially 4chan) as representative of the Python community. Also FYI, the master/slave thing is not a first. It happened in Drupal, Redis and most likely also in other projects, and it also caused endless discussions and backlash, so you’re not the first one who had to cope with this kind of pressure.
The real question here is IMO purely practical: does changing terms (in general, nevermind the specific master/slave thing) really increase “diversity” or prevent people from actually being offended? IMO the answer is no, and if there really is people who feel offended by this I think it should be up to them to step up and clarify exactly how changing terms will have a positive effect.
Anonymous users and CoC
=======================
After the master/slave case a couple of things happened that drew my attention:
Now, what do CoCs have to do with this (this was your original question)? I did notice that when such cases occur in other communities there is often an anonymous account appealing to what a CoC says in order to ban offensive terms or a community member due to some violations they may have done. And the OpalGate case I signaled above is an example of this and of how a strict CoC can be used for malicious intents instead of actually protecting the community. And when the CoC is not deliberately malicious it may be too vague/generic, and as such subject to personal (including malicious) interpretation (e.g. when the CoC doesn’t clearly define what constitutes “herassment”, “diversity”, and so on). Now, it seems there are many open source projects which recently adopted either restrictive or generic CoCs, and I’m of the opinion that they cause more harm than good. Here’s another example portrayed by anonymous accounts trying to instill CoCs into the NIM language.
The bullying
==========
I could link more of these but I think my point should be clear. So when you say “there is bullying” I totally I agree with you. It’s there, it’s real and it’s so vicious I seriously have issues to cope with it. And I think we are looking at the same coin, only from 2 opposite standpoints. The way I see it is that the bullying is portrayed by a certain set of people, often anonymous, who throw a bait disguised as good intention (“be kind”), cause a backlash within the community and disappear. And the immediate natural reaction is thinking: [we have a problem → let’s enforce the CoC → let’s remove offensive posts → let’s increase bans], which IMO it appears to be precisely what such anonymous people want.
But who is the real offender here? Those community members who react inappropriately to the OP or the ones who asked for “kindness” in the first place? And why do they never explain why or how exactly banning a term or enforcing a CoC will make things better? What makes things confusing here is IMO the fact that the request appears legitimate on the human level, and as something that any decent person would agree upon (“be kind”, “be inclusive”, “be diverse”, “set CoC/rules for good behavior”, …) but really it isn’t. It’s a subtle witch hunt. See the point I’m trying to make here?
Conclusion
==========
I realize this is a lot to chew on, and I hope who reads this message will understand that writing what I wrote is not precisely relaxing or something I ever desired doing. If I appeared “inquisitive” to some of you recently it was because of this. But it’s 13 years I’ve been on this python train, both as a core-dev and as a library author, and I always contributed out of passion and nothing else, so I feel I owe something to this language which gave me so much in so many ways. Only this time my contribution is not in form of code. I really hope I will not be misunderstood.
EDIT: after this I will do my vote and pull the plug from this and only focus on tech-related contributions whenever I’ll have the time/chance (and if I’ll still can :P). This thing kinda drained me and I also am between jobs, sentimental status changes and a relocation, so I seriously need a long break.
Best,
Giampaolo