An example of Inclusivity and Diversity
Observations from my first few days in The Turing Way community
I recently had the pleasure of joining The Turing Way community. What stood out to me was their effort and success in creating an inclusive and diverse community. Here I will share my initial interactions and experiences, and what I have so far learnt about creating inclusive communities.
Introduction
The Turing Way is, from their homepage,
an open source community-driven guide to reproducible, ethical, inclusive and collaborative data science.
Currently most data scientists are (white?) men, so you will share my surprise when you see this screenshot from their November ‘Book Dash’:
Out of 23 participants, only 5 appear to be male. Furthermore, they come from at least 10 different countries. This is remarkable and a clear sign that The Turing Way is doing something different.
I was curious to know more and to see if I could contribute. For several months, I put it off, but kept loosely up to date via their monthly newsletter. However, in their February 2021 newsletter, they introduced a weekly onboarding call to help new contributors and community members get involved. This was the nudge I needed to take the plunge.
My first interactions
To help provide context, here are the first interactions I have had with The Turing Way project:
Reading through the Contributing Guidelines.
Joining their slack channel, having a short conversation with one of their community managers, and agreeing to help with this issue on a new chapter about how new people can join the project.
Creating a couple of issues regarding the Contributing Guidelines. One regarding a couple of dead hyperlinks and another asking whether the Gitter channel is redundant.
Reviewing a first draft for the issue in Point 2 above.
Couple of days later, having onboarding call with Kirstie Whitaker (one of the founders of The Turing Way), Malvika Sharan (the lead community manager) and Emma Karoune (a community manager).
Work on a few issues about making various parts of the book more consistent: leadership pages, resources on github and maintenance in github.
If you go to the hyperlinks in Point 2 or Point 3 above, you may notice there is a certain clunkiness in my communication. Maybe there is no clunkiness, but at the time (and even now when I re-read it), I sensed there was miscommunication or a mismatch in communication styles.
The onboarding call I had was particularly helpful and insightful for me, and helped me understand the source of my clunkiness (but I am admittedly still unsure on some points).
Lessons learnt
Based on these interactions, here are my current thoughts on how The Turing Way has successfully created an inclusive and diverse community. There will be some overlap in the thoughts.
Explicitly, consciously and actively pursuing inclusivity and diversity as a top priority. E.g. one of their current big projects is to make it as easy as possible to translate the content into other languages.
Valuing the community and people involved more than the content being created. In this introductory session for a Book Dash, Kirstie says, “The book is in my opinion not the most interesting part. The book is the thing we all gather around, but it is the community that is the most exciting aspect. My ultimate goal for success is that people feel that they are empowered to contribute into an open ecosystem.”
Learning from good practice elsewhere. E.g. the Government of UK’s writing guide (which I highly recommend!), creating visuals that are colour-blind friendly, having a Code of Conduct, etc.
Reflecting on what makes other spaces unpleasant for minority groups. Idea that other open source communities tend to be ‘loud’, ‘shouty’ and ‘aggressive’, which means that quieter or humbler voices (which are correlated with being in minority groups) will fade away. See this article on the culture of ‘#bropenscience’ for a more in depth discussion.
Having a project in which people with many different skills can contribute and reducing the barriers to entry. The book is not just about technicalities in data science, but also things like project management, communication, ethics, legal issues, etc.
Celebrating people’s contributions, big or small. As well as thanking people in person, they have automated systems to post big, bright and cheerful images when you make your first contributions (see for example the first pull request I made), and automated systems to easily add you to a list of contributors.
Being mindful of how one gives feedback and how one’s words can affect other people. For example, they recommended that I be ‘extra gentle’ in certain contexts. Also, being being mindful of the fact that different people react to the same words in different ways, so taking that into account in your communication.
Not pushing for speed or fast contributions. Not expecting perfection from contributions. “We prioritise accessibility over perfection/polished content.”
Having leaders from minority backgrounds. I have so far interacted with five people and none of them were white males.
I do not have a good intuition for how important these different factors are and which ones a community should prioritise if they want to become more inclusive and diverse. However, some of these will be easier to transfer to other contexts than others, e.g. one can introduce a Code of Conduct into any community, whereas speedy and perfect contributions might be crucial in some contexts.
On that note, I do feel there is a source of tension in Point 8 above, about not pushing for fast or perfect contributions and valuing accessibility more. I think details make a big difference to accessibility, so pushing for accessibility implies pushing for perfection. Examples of such details include creating colour-blind friendly images, using gender-neutral language, or using simple and correct language. But perhaps I am misunderstanding what was said.
Concluding remarks
I hope this gives you some ideas on how to improve communities you are in. There are likely mistakes or misunderstandings in my observations, so I recommend having a look around for yourself.
The Turing Way homepage
The introductory session for one of their ‘Book Dashes’
Their Contributing Guidelines and Code of Conduct
I will be curious to know your thoughts on what I have written or if you make any different observations.
This was a really weird read, and I let the essay sit in a browser window without responding for quite a while, because I wasn't sure that our goals and desires had enough in common to make my input useful, or seem like anything but trolling.
I can't recall ever seeking diversity for its own sake. I'm very much down on exclusionary behaviour, but if the people who turn up for e.g. a class in traditional Armenian cooking turn out to all have long lost family roots in Armenia, I'm not going to be unhappy about my failure to attract blacks, Asians, natives, and Hispanics. (I hope you wouldn't be either.)
I'm uncomfortable with the idea of "valuing the community and people involved more than the content being created." And having a goal being "that people _feel_ that they are empowered to contribute into an open ecosystem" leaves me shaking my head and asking what % of empowered-feeling people are actually empowered, or for that matter competent - and what % of non-empowered-feeling people are both.
There are plenty of communities and friendship groups that exist for their own sake, and then go out and attempt to do some good. I don't see anything wrong with that in principle, though it's very much not my personal style.
The Turing Way is an interesting experiment, and seems to be doing what the organizers want. But in what sense is it better? And where else would such a sense of "better" apply - or not apply?
I become concerned about diversity issues when I find people interested in the topic/mission bouncing off the group in question, with comments ranging from "what a collection of assholes" to "I just couldn't figure out where to start". My first guess tends to be that the problem is due to a self-satisfied clique, on-boarding only those they already know and like. Or it's sheer incompetence - no one's documented anything, including "how to contribute" - or similar. Or there's politics among the existing clique, and you are only welcome to those whose side you may benefit.
But when the folks fleeing in disgust tend to share demographic attributes not shared by most of those who stay, we're in diversity territory, not mere cliquishness and incompetence. And when the people leaving identify the problem as sexism/racism/agism/ablism/etc. this gets even clearer. It's not certain -some people, sadly, presume every personal rejection they encounter is due to their least popular demographic attribute, even with strong evidence to the contrary. But usually where there's smoke, there's also fire.
And large swathes of the various open source communities display these signs very very prominently. This has been saddening to me for a while, even though it's been cliquishness that's bit me personally, not diversity issues. (I'm very much acculturated into open source norms, though more from the 1980s than anything current - even though I'm demographically not the stereotypical open source developer these norms supposedly favour. Sometimes I try to explain the norms to outsiders - who don't know it's OK to fork the source, or offer an unsolicited patch, or argue forcefully and without diffidence. Sometimes they'll listen to me, if I'm demographically similar to them, rather than to those they feel excluded by.)
I see _The Turing Way_ as one approach to addressing this.
The other one I'd like to see, is clearer explanation and fair enforcement of what I consider to be traditional open source/nerd culture norms. Those norms are unabashedly coming from a place that emphasizes facts, data, code etc. over personal feeling. We know it can hurt when someone fixes your mistakes, or even when they tell you about them, but the product will be better for it, so when it happens, we try hard to learn from the changes, and keep our pain and embarrassment out of the interaction. Code reviews can hurt, particularly when we have a lot to learn, but we model ourselves on the senior developer who respond "nice catch" and promptly pushes a fixed version, because that's how a "good" open source developer/engineer behaves.
These norms produce two things, done right: solid products, and improving skills among the developers. This should bring feelings of empowerment in their train, but this (sub)culture mostly doesn't talk about feelings.
Of course they are also very much European, Enlightenment, left brain, literate, and educated norms. And they are usually accompanied with some fairly giant levels of pride as well as self confidence, at least once one begins to routinely succeed. Some people will reject them for this reason. And I'm OK with that - provided I don't need to participate in their projects. I won't even snicker very loudly at their diversity claims, as they exclude people like me, thereby demonstrating ablism (these norms are very congenial for folks on the autistic spectrum), agism (some of this is passe), sexism (since many identify these norms with one gender), and of course racism (such norms are often referred to as "white".)
I'm waiting to see whether the diversity-seeking parts of the open source and engineering communities manage to produce good solid products. I'm also waiting to see whether they produce projects I'd want to work on, but with significantly less hope. (Neither autistics nor older people are wanted in any "diverse" setting I've so far encountered, and since I'm both ...)
Meanwhile, the more things that are tried, the better chances we all have - both of finding a place where we belong, and of decent products being produced.