We See You! Reaching Diverse Audiences in FOSS
This is the third in a series of posts reporting findings from research into the state of D&I in Mozilla’s communities. The current state of our communities is a mix, when it comes to inclusivity: we can do better, and as with the others, this blog post is an effort to be transparent about what we’ve learned in working toward that goal.
This post shares findings focused on inclusive outreach, communication and engagement.
When joining Mozilla or any other open source community, we look to see our identities reflected in the values, language(s), methods of connection and behaviors of the community and project leadership. We uncovered a number of challenges, and opportunities in making project communication more accessible and inclusive.
Say my name, say my name
Research showed, that in communication and project initiatives and even advocacy messaging, we appear to tiptoe around naming diversity dynamics such as gender-identity, sexual orientation, age, physical ability and neurodiversity. Some we interviewed, shared an impression that this might be intended to not overstep cultural lines, or to upset religious beliefs. It was also suggested that we lean on ‘umbrella’ identities like ‘Women’ as catch-all for non-male, non-binary people.
“This goes into the gender thing — a lot of the time I see non-binary people get lumped in with “women” in diversity things — which is very dysphoria-inducing, as someone who was assigned female but is definitely *not*.” — community interview
Through inclusive language, by identifying people the way they self-identify in project communication and invitation — only then are we truly welcoming diverse collaboration, connection and engagement.
The Community Participation Guidelines are a great reference for how to work with inclusive language and the full range of diversities we seek to include.
Breaking the Language Barrier
Qualitative research showed only 21% of our respondents spoke English as a first language. Although this snapshot was taken with limited data-sets, our interviews also generated a narrative of struggles for non-native English speakers in an English-first organization*.
Most striking was how the intersection of language and other diversity raises barriers for those already limited — for example parents and non-binary contributors who struggle with English for an almost impossible challenge.
“My friend was a contributor until she had her baby, and since most time she had would be taken trying to translate information from English, she stopped” — community interview
* Primary project communication channels, media, print/copy resources are in English. Mozilla has a very active L10N community.
“Non-English speakers struggle to find opportunity before it expires — People want to feel part, but they feel they are late to everything that Mozilla throws. They need enough contact with those responsibilities or someone who speaks their language.” — community interview
Overall our interviews left us with a strong sense of how difficult, frustrating and even heartbreaking the experience of speaking, and listening within an English-first project is — and that the result was reduced opportunity for innovation, and the mission overall.
As a result it’s clear that creating strategies for speaking and listening to people in their own language is critical in obtaining global perspectives that would otherwise remain hidden.
We found early evidence of this value in this research, conducting a series of first language interviews, especially for people already marginalized within their culture. This could possibly align with our other recommendations for identity groups.
Exclusion by Technical Jargon
‘Technical Jargon/Lingo’, and overly complicated/technical language was cited as a primary challenge for getting involved, and not always for the reasons you might think — with data showing that a type of ‘technical confidence’ might be influencing that choice.
In one community survey, men had much greater confidence in their technical ability than women which might explain low technical participation from women and is backed up by other research showing women only apply for jobs they feel 100% qualified for.
“I feel uncomfortable when they talk about a new technology [at community events].” “I am excited about the new technology and want to jump in, but level of talk and people can be exclusive. I end up leaving.” — community interview
“Technology focus only feels exclusive — we need to say why that technology helps people, not just that it is cool” — community interview
By curbing unnecessary technical language in project descriptions, invitations, issues and outreach anyone can step into a project. This, combined with opportunities for mentorship may have huge impact on diversity of technical projects. Intending to do just that is the Rust project starting with this fantastic initiative.
Making Communication Accessible
As part of the interview process we offered text-based focus groups, and interviews in Telegram — and approximately 25% of people selected this option over video.
While we initially offered text-based interviews to overcome issues of bandwidth and connectivity it was noticeable that many chose Telegram for other reasons. This method of communication, we found, better allowed people to translate questions at their own pace, and for those leaning towards introvert space to think, and time to respond.
“More than half of the world is still without Internet, and even people who do have access may be limited by factors like high cost, unreliable connections or censorship. Digital Inclusion” — The Internet Health Report
A repeated theme was that the project standard of using Vidyo created struggle, or existed as a blocker for many to engage for reasons of bandwidth and technology compatibility. Additionally, media produced like plenaries and important keynotes from All Hands lack captioning and which would benefit non-English speakers, and those with visual impairment.
Overall... Connecting people to Mozilla’s mission, and opportunity to participant is largely dependent on our ability, and determination to make communication accessible and inclusive.
These findings though conducted on Mozilla’s communities — are ‘open communities’ issues, and thus we look to solve and build on with our peers.
We will form recommendations based on these findings, and we welcome your feedback and ideas for standards & best practices that we can work on together.
Our next post in this series ‘Frameworks for Incentive & Consequence in FOSS’, will be published in the first week of August. Until then, check out the Internet Health Report on digital inclusion.
