Mentoring and diversity for Python

A two-part session at the 2018 Python Language Summit tackled the core developer diversity problem from two different angles. Victor Stinner outlined some work he has been doing to mentor new developers on their path toward joining the core development ranks; he has also been trying to document that path. Mariatta Wijaya gave a very personal talk that described the diversity problem while also providing some concrete action items that the project and individuals could take to help make Python more welcoming to minorities.

Mentoring

Stinner said he has been spending time trying to get more people involved in the Python project. There is a bottleneck in the review process; more developers would help with that. In addition, more people involved means that there are more diverse viewpoints, which leads to better review since different reviewers spot different kinds of problems.

He has been unable to identify a clear path from being a contributor to becoming a core developer. It is an unclear and unwritten process that he is now trying to document. Becoming a core developer is not really a goal itself, he said, there are lots of ways to contribute without being a core developer.

There are multiple stages along the path: newcomer, contributor, mentoree, and core developer. He added mentoree and tried to write down the requirements for the next stage. He also tried to document the responsibilities of a core developer; for example, if a core developer merges some code, they are responsible for that code for the next ten years. He also formalized the role for bug triage, which can be a step on the road as well.

Stinner recently mentored three contributors over a two-month period. He was surprised that many of the questions he got asked were not related to the code, but were more about the process. Things like who to ask to review code or how to use Git were the kinds of questions he fielded. He also found that "people are shy", they do not want to ask questions, even on the core-mentorship mailing list, which is not publicly archived.

In practice, the topics he needed to teach his mentorees were things like how to write a good pull request, how to add good tests, and adding entries to the NEWS file. The most efficient tool to get more developers is to get more people mentoring, Stinner said. That is why he stopped writing code for a bit to focus on mentoring; he hopes others will do the same.

Kushal Das pointed out that CPython did not get into the Google Summer of Code (GSoC) program because of a lack of good mentors. Stinner said that GSoC takes a bigger time commitment than mentoring; he would generally just need to answer a few emails a week for his mentorees. Das agreed with that, noting that GSoC can sometimes take 10-15 hours per week.

Stinner wondered if his document should become a PEP or be handled in some other way. Nick Coghlan suggested it be turned into a pull request for the Python Developer's Guide and "let that decide whether it should be a PEP". Guido van Rossum said that he could see it is a PEP written from the perspective of mentors, but not just something with a bunch of check boxes.

There is definitely a problem with a checklist approach, Ned Deily said. There are a "fair number of intangibles" that go along with being a core developer: how well they work with the group and if they understand and accept the history of the project, its processes, and so on. Stinner said the document does not have items like "fix five bugs" or "get ten commits accepted". The criteria really depends on the kind of work that is being done and Python has a need for many different types of contributors.

Diversity

Wijaya started out by saying that she had been asked to give this talk; it is not something she would necessarily choose on her own because the topic is a trigger for her. She said she would try to control her emotions but that the presentation might be uncomfortable for attendees.

She had a list of facts about Python development that she said should make people uncomfortable. From February 2017 to April 2018, there were 848 contributors to Python on GitHub—of those, less than ten were women. That is not a percentage, but a raw number. It took a month after the switch to GitHub before a woman contributed.

In the last 12 months of posts to the python-dev mailing list, there are less than five women actively participating. There are more who are watching, she said, but who do not get involved. When she first started participating in the mailing list, she thought she was the only woman. Of the 168 committers for Python, only two are women. Both of those women were added in 2017. "This is wrong", Wijaya said. The project should not accept this situation.

She had some requests for the attendees as well. Please acknowledge that the lack of diversity is a real problem, she said. In addition, it is not her problem, it is a problem for everyone in the Python community. Those who cannot see the problem are actually part of the problem.

Attendees should not expect her to solve the problem for them, or to repeatedly explain it. There are resources available to educate everyone about the problem. "Don't ever tell me you don't see a problem", she admonished.

She listed some educational resources, including using Google ("really!") with keywords like "diversity in tech" or "open source diversity". She also suggested viewing the documentary CODE: Debugging the Gender Gap. In addition, follow women and people of color on Twitter, she said, as well as @betterallies. The project could also get professional advice. Two people that she knows who may be able to help are Sage Sharp and Ashe Dryden. Their jobs are to help organizations do better at diversity.

She made some specific suggestions of action items for the project. A better code of conduct is needed because there is no enforcement information in it. Who will handle complaints and how? Several good examples can be found, including the codes of conduct for Django, Write the Docs, and the PyCascades conference. PyCon 2018 also has a code of conduct with an enforcement manual, which is the first time the conference has added that piece.

She noted that Stinner had said people are shy, but she had a somewhat different take. Public spaces are not always seen as safe spaces for minorities. So, she suggested that Python developers be available privately. Van Rossum has been mentoring Wijaya and others, she said, separate from the core-mentorship mailing list. Don't expect minorities to post there and instead explicitly provide office hours or other ways for those folks to get their questions answered.

Give minorities opportunities to contribute, she said; pay attention when they are creating pull requests and review them. Actively seek out minorities and invite them to participate. Another possibility is to pair up with someone on something you are working on, she said.

Her last piece of advice was to "be a minority". She suggested attending a PyLadies event alone to just listen. A blog post about a man's visit to PyLadies London is worth reading; his worries about being in the minority echo what she and other minorities often feel.

Brett Cannon replayed some of the action items he heard: the code of conduct needs to be more clear and to include an enforcement manual. Thomas Wouters noted that the Python Software Foundation (PSF) is working on an update to its code of conduct that could be useful. Christian Heimes suggested adding photos of the enforcement people as well as multiple different contact options for them.

Das said that some are scared to ask questions in public spaces, so office hours can really help. Video calls can also be useful for those who are willing to do that. For most, text is probably easier, but any private communication mechanism is workable. Wouters said that predictable hours where one is available to talk or answer questions is the most important part. Van Rossum agreed, saying that there are people who want to ask questions but don't want to do so on python-dev with 20,000 readers.

Stinner wondered if a new mailing list to discuss diversity topics would be useful; there was one earlier, but it closed down due to lack of traffic. Coghlan said that a mentoring special interest group (SIG) might be good. Being a good mentor is a skill in its own right, he said.

Brian Curtin suggested that active outreach is a good way to increase diversity. He noted that after a PyCon that had only a single woman speaker, the two PyCons in Santa Clara, California specifically sought out more women speakers by talking to PyLadies groups and others. That was quite successful to increase the number of women speakers at the conference.

The conferences outside of the US and Europe are a different story, Das said. He has seen PyLadies looked down on at conferences outside those regions "again and again". The women's groups are trying hard to bring in more women to the project, but they get no support from the conferences or attendees, he said.

Heimes said that when developers are asked to speak at conferences they should ask if there is a code of conduct and diversity program. If there isn't, guide them to the PSF for examples. Van Lindberg said that anything funded by the PSF must have a code of conduct, though he acknowledged there are no rules about what must be in it; the PSF does provide examples, however. One attendee said that a conference had added a code of conduct after he asked. The conference is not sponsored by the PSF, but is now talking about adding a diversity program. Potential speakers can use that as leverage to help influence conferences to get on board.

Steve Dower asked about finding people to mentor; he has helped his colleagues at work, but how can others be found? Das said that new people with pull requests who are looking for review are good candidates. Adding some information to the Developer's Guide or as a new PEP would also raise the visibility of mentoring opportunities.

A technical walkthrough of some part of the interpreter or standard library is quite useful to those who are new to the code, Carol Willing said. Making sure that the presentation is recorded for others will help increase its reach. The move to GitHub has been a great move forward in making it easier for new people to get involved. But Python is fighting an uphill battle, she said, talented women can have their pick of open-source projects to join.

Dower suggested that perhaps speaking at a PyLadies meetup to do a review of some part of CPython might be a way to combine two of the suggestions from the session. As part of that, the speaker could make it clear that they are willing to mentor anyone who is interested. Eric Snow noted that simply introducing yourself to everyone you run into at PyCon is a good starting point; telling those with an interest about the core-mentorship list and that you are willing to be a mentor will help get the word out as well.