Howto engage Python contributors in the long term?

Your slides talk about misogyny, bullying and racism. Those are bold statements. Did something happen at conferences, ml, github, BPO or something? Are there practical examples regarding candidates or contributors who have been marginalized due to their gender, ethnicity, etc.?

The PSF can (and should) spend money on Python development. Unfortunately, we do not receive grant requests for such funding. We are not yet in a place where we (the PSF) can actively search for these types of requests ourselves, but once the SC is in place I would love to start a discussion on this.

5 Likes

I am volunteer to help to organize such grant. I didn’t complain about that in my talk since it is also my fault of not organizing grants :grin:

My talk tries to be more general than just the Python community, but yeah these things happen in Python as well. Multiple core developers were against my master/slave change. Sorry, I cannot elaborate here because victims don’t want to talk and events usually happen in private. I tried to only mention events which only involve myself to not put the spotlight on victims who didn’t ask anything.

Maybe ask people who handle Python CoC reports if … they get reports?

Ah, by the way, I have been harassed for 2 years in Python as well, but I don’t want to talk about that. Not in Python at least.

1 Like

I started to collect links to public events and articles: https://pythondev.readthedocs.io/diversity.html

Once I became aware of the issues, I have been amazed by the number of victims and the violence of reactions. I am not talking about the specific case of Python here, I am talking about “the Internet” in general.

Some women started to speak out, write articles and books. They are usually targets of trolls and haters. Some get murder threat or worse.

Maybe ask some women around you if they feel respected and safe online, and if they get offended or harassed online. Or if they know any friends in this case. If you get no complain, it may be because they don’t feel comfortable to talk about these sensitive topics with you. It doesn’t mean that everything is fine.

4 Likes

I am a bit familiar with this topic and I can say this is a field I would treat with caution. And the reason for that is because you’re entering a political territory which has been subject to abuse by a minority of external (often anonymous) contributors (including python). I skimmed through some of the links you mentioned. This is one I was familiar with:

Transphobic maintainer should be removed from project · Issue #941 · opal/opal · GitHub

The author of that ticket is well known. She is the author of the Contributor Covenant CoC which has been (ab)used in order to try to kick developers out of open source projects on account of what they write on their Twitter profile as the CoC explicitly allows for that:

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.

The same thing happened to Linux, which also adopted a variant of the Contributor Covenant CoC (here’s the diff and a long, heated discussion), and I’m pointing this out because in another thread you mentioned the Linux Code of Conflict as an example of aggressive behaviors.

So I would not take those 2 cases as an example of “positive diversity”. I could provide links about other open source projects which have been subject to similar attacks (almost always portrayed via CoCs and a distorted concept of “diversity”), but I don’t want to go too OT here. Both cases (Opalgate and Linux CoC) are summarized here.

I am at Brno (Czech Republic) for Devconf.CZ where I just gave a talk:

I’m not far from there. Wasn’t aware of the conference. Depending on your schedule we could meet in person. :wink:

2 Likes

Yes, inclusion is a topic that should be treated with respect and thoughtfulness.

There are many aspects to what helps make a community inclusive, healthy, and productive. It’s my hope that this is kept in mind as our community grows. It would be unfortunate to only approach from sensationalist media coverage where often only one point of view is presented.

2 Likes

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.

1 Like

@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.

8 Likes

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.

2 Likes

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.

2 Likes

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.

2 Likes

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 :wink:

1 Like

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.

4 Likes

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.

1 Like

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 :slight_smile: I just feel guilty of not sharing more often my experience. Well, I’m doing that in this thread :wink:

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.

2 Likes

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.

3 Likes

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) :wink:

(note: edited a double negative inserted by mistake :wink: )

2 Likes

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 :slight_smile: I have to confess that I used a clickbait (sub)title to keep my audience listening until the end :slight_smile:

2 Likes

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?

3 Likes