I will start by saying that I am a process-turned-product person.

That is, I’m a process-turned-product person with a passion for making systems just, equitable, and transparent. It’s these values that drew me to the Wikimedia Foundation in the first place. I wanted to be part of the nonprofit with a vision where everyone, everywhere has access to freely share in the sum of all knowledge — and I wanted to dedicate myself full-time to making that vision a reality by centering diversity, equity, and inclusion (DEI) in our work.

“I wanted to dedicate myself full-time to making Wikimedia’s vision a reality by centering diversity, equity, and inclusion in our work.”

In my early years at the Foundation as a Technical Program Manager, I became familiar with the breadth of 13 Wikimedia projects spanning 300 languages, edited by hundreds of thousands of volunteers from all over the world. These dedicated people help make knowledge available to millions of global readers. There are many multilingual editors that contribute to large language wikis like English Wikipedia, while also creating articles on growing language wikis like Yoruba Wikipedia.

At the same time, I got to know actual Wikimedia movement leaders (the volunteers who lead the creation and curation of content on projects like Wikipedia and Wikidata), and the host of barriers and biases they face while doing this important work. I discovered how challenging it is to ensure our products represent the nuances of different geographical contexts and cultures across languages while remaining an open source free knowledge movement.

“I got to know actual Wikimedia movement leaders (the volunteers who lead the creation and curation of content on projects like Wikipedia), and the host of barriers they face while doing this important work.”

I also saw an opportunity.

I saw that there were several initiatives and champions eager to make the Wikimedia movement and projects more diverse, equitable, and inclusive. But there was no model to connect these efforts, ensure their consistency, or standardize the way we assessed their impact.

We were missing a standard, cohesive framework that included concrete resources and examples of how we build the technology that powers the Wikimedia movement. Also missing was a way to ensure Foundation product and technology teams check for potential bias at each step in the software development lifecycle.

“We were missing a standard, cohesive framework that included concrete resources and examples of how we build the technology that powers the Wikimedia movement.”

Not only was there no framework at the Wikimedia Foundation; it was also nearly impossible to find a detailed DEI-centered software development framework outside the organization with concrete steps for open source environments.

In June 2020, during the resurgence of the Black Lives Matter movement, I felt a greater sense of urgency to organize my observations and ideas into a plan for action. My goal was to ensure Foundation development teams had access to resources for checking their biases and ensuring transparent, intersectional, and contextual practices, all informed by existing DEI efforts across the Wikimedia movement was baked into their work.

In a proposal to Foundation leadership and colleagues, I laid out how we could approach inclusive development practices — and why it is critical to our mission. With their buy-in, a working group was formed, and our shared journey began to put DEI at the center of the technology behind Wikimedia projects.

“In June 2020, during the resurgence of the Black Lives Matter movement, I felt a greater sense of urgency to organize my observations and ideas into a plan for action. … I laid out how we could approach inclusive development practices — and why it is critical to our mission.”

Since that time, our working group has learned a lot.

We have a fundamental belief that organizations, especially those working in open source environments, should publicly share their software development process models, so that we can all continue to learn from each other in a proactive way. Although our framework is still a work in progress, we hold ourselves to that same standard.

To that end, here are ten things we have learned thus far in developing a framework for equitable product development.

1. Buy-in from organization leadership is essential.

Achieving a DEI-centered software development process requires commitment from those who are at the top of the organization.

“This work entails tough calls of choosing equity over speed.”

This work entails tough calls of choosing equity over speed. It requires support for resources such as multicultural, multilingual research. Importantly, teams will need to feel they have the agency to prioritize metrics other than efficiency and scale as they measure success in reaching specific audiences.

2. Start with research.

It can be tempting to jump right in with solutions and anecdotes when developing a playbook, or even when doing product development work in general; however, steer clear of putting forward a one-size-fits-all approach. No matter the eagerness to implement, it cannot be impactful without doing the work up front in understanding context.

Our inclusive product development working group started with establishing a baseline by conducting a comprehensive review of existing best practices, or bright spots as we called them, and areas for improvement. The working group interviewed 15 software development teams at the Foundation with different focuses. We also researched best practices for inclusive product development, as well as the opportunities and pitfalls software development teams at other technology companies.

“Steer clear of putting forward a one-size-fits-all approach.”

Our research helped us glean important insights and shaped our approach. First, it cemented for the group that the type of open source software development framework we were seeking to build — one that centered voices that have been traditionally underrepresented in our movement — was not currently as accessible as it should be. We determined that we needed to work in the open and iteratively to continue to establish and evolve a framework.

3. Unlock your next steps by sharing insights early, and really listening to reactions.

After synthesizing our research, we shared findings at an all-staff meeting. In that forum, we heard from other Foundation teams who shared our appetite for building products with DEI at the center. The outcomes of our surveys, paired with the feedback from this meeting demonstrated that, in many cases, teams had an appetite for this work and were already on this journey in their own ways.

“Teams craved cohesion and tangible guidance on how to intentionally build products in an inclusive way.”

What was also evident was that because teams were going about this separately without a common framework, clear gaps existed. Some teams needed a standard process for language support; others hadn’t figured out how best to be inclusive of low-vision users; many had requested more support and guidance around understanding if their products were furthering gender bias or favoring one country within a language wiki more than another.

There was also interest in understanding what demographic of Wikimedia editors and readers we were not hearing from and how to best reach them. Above all, teams craved cohesion and tangible guidance on how to intentionally build products in an inclusive way, and the permission to take more time to build for a more equitable outcome.

4. Draw on the expertise of DEI professionals.

A persistent question for our working group was how to define diversity, equity, and inclusion. When questions like this come up, it is important to recognize different roles and responsibilities surrounding DEI work. It is everyone’s shared responsibility to advance DEI. However, to do this work thoughtfully and effectively, there is a responsibility to consult those with professional DEI expertise.

“To do this work thoughtfully and effectively, there is a responsibility to consult those with professional DEI expertise.”

We turned to colleagues on the Foundation’s Global DEI team within our Talent and Culture Department to share their expertise and establish the following organization-wide definitions to guide our working group:

• Diversity is about our people: about the variety of identities represented in our movement, workforce, departments and teams. Individuals cannot be diverse; only groups can. We focus on identities that include but are not limited to caste, race, ethnicity, colour, national origin, nationality, gender identity, gender expression, sexual orientation, age, religion, language, culture, education, abilities, income, and environment.
• Equity about fair access to resources and opportunities for people by identifying and dismantling barriers that result from direct and structural systems of oppression and injustice. Equitable outcomes are realized through our behaviors, actions, policies, processes and the distribution of resources.
• Inclusion is about the intentional steps that give all people, and especially those who are excluded or prevented from having a say, meaningful representation in planning and decision making across the Foundation.

5. Categorize your insights to make them actionable.

After we collected feedback on our research from others in the Foundation, we worked with a design expert to tease apart the findings and provide shared insights and opportunities based on overarching themes and tensions.

We were able to identify six categories:

1. Process (the flow of work): User perspectives should appear earlier and more consistently in the product development processes.
2. Strategy (setting relevant and clear goals): Teams crave more clarity around DEI goals from the top of the organization, and they require more resources to deliver.
3. Incentives (how desired behavior is rewarded): Employee incentives do not explicitly reward good DEI-related behavior at present.
4. Structure (role and relational clarity): All teams operate under resource constraints and need to be smart and structured about how they connect with other teams, experts, communities, and volunteers to bring DEI to their work.
5. Talent (recruitment, resourcing and development): While people generally aspire for greater demographic representation within teams, more teams could benefit from a range of roles.
6. Tools (organizational software, methods, or spaces): Tools to measure DEI impact in Wikimedia communities are challenging to incorporate given the importance of user privacy.

With these organized findings, and inspiration from industry leaders, the double diamond and agile methodologies, we were positioned to develop the first draft of our Inclusive Product Development Playbook. The playbook aimed to start with the process category, while the Product Platform Strategy set by Product leadership provided the guardrails for setting equity strategy goals.

6. Before testing, get input from your key stakeholders and end users.

Before putting the draft Playbook into practice, we shared it with a key constituency: the Wikimedia volunteer community. At our annual Wikimania conference in 2021, the working group presented the draft playbook and shared our intentions for the inclusive product development framework to get feedback from the community on what to include and iterate on.

Following the presentation, we joined a virtual discussion of prospective opportunities and challenges from the community’s perspective. We also shared ways in which people could work with us as we continue on this journey, which included the creation of a MediaWiki page to watch for updates. This type of community and stakeholder engagement is always key, but it’s especially critical in open source environments like the one in which Wikimedia operates.

7. Foster a community among a smaller test group.

It was important to test our draft Playbook with a smaller group of teams before rolling it out to everyone. In October 2021, seven beta teams at varying phases in their development lifecycle agreed to adopt the Playbook and, for at least one stage of their development, attempt to complete each task in the framework and provide feedback on obstacles, successes, and learnings.

The seven teams — who are in the process of finalizing testing of the Playbook — include front end teams and one back end team serving desktop and mobile users. The teams meet monthly to discuss their progress and to surface challenges and insights. We were excited to see that the regular syncs resulted in the development of a FAQ document and an open Slack channel that we hope will benefit future Foundation teams as we iterate and roll out the Playbook more broadly. We have been intentional with keeping the scope of the teams tight but diverse enough to build a base Playbook. We have the intention to add even more supplementary materials to our framework as we expand the teams we serve and their unique needs.

8. Avoid assumptions, and enable teams to establish their own baselines.

The working group was responsible for the process and resources to ensure our software development lifecycle promotes DEI. As part of this, it was important for us to not be anecdotal or provide made-up benchmarks numbers without understanding the context of each team’s available metrics capabilities and relevant platform audiences.

In some cases, teams have data analysts on staff, while others do not. Some teams can access quantitative data to inform decisions, while others rely on qualitative surveys. It was for this reason that we encouraged every test team to start by establishing a baseline understanding of who their current audiences were and pragmatically understand where there was potential to grow and diversify audiences.

9. Reinforce that this work is never “done.”

I’ll say that again: There is no such thing as done when it comes to inclusive product development.

As our VP of Product Carol Dunn puts it, asking when the framework and a team’s adoption of it is done is akin to asking “when will I be done being healthy?” Everyone’s health is contextual to their own body at a given point in time, and rituals of being healthy evolve as your body changes and grows. We see building inclusively the same way.

“Asking when the framework and a team’s adoption of it is done is akin to asking ‘when will I be done being healthy?’”

There is always more to do, not just at a team level, but as an organization and movement as well. As we learn more, we will adapt accordingly. Adaptation will take the form of the artifacts we produce, who serves in the working group, what our processes are for soliciting feedback, and other ways that may not be apparent to us at this moment. It can be enticing to look for concrete answers that can be broadly applied, but inclusive product development requires adaptability.

10. Share the journey.

As we continue to learn from the teams that are currently testing the Playbook and providing feedback, we will expand the number of test groups, add more resources, and continue to transparently share what we learn and create (including through more blogs like this!).

We hope this process can remain participatory and that we can bring everyone with us on this journey of ensuring that every human can freely share in the sum of all knowledge — openly, inclusively, safely, and equitably.

Personally, I hope to see more open source organizations take similar steps or share their existing work in this area so we can learn from each other. It is our collective responsibility to ensure these DEI-centered practices and learnings are accessible to all.

Author’s note: I would like to thank the many people who contributed to this work. Namely, members of the working group; the Beta teams; community members who provided insights at Wikimania; and the Black, Indigenous, and Women of Color who forged a path for this work (Anne Jean Baptise, Timnit Gebru, Joy Buolamwini and Safiya Noble).

Jazmin Tanner is a Lead Product Manager at the Wikimedia Foundation focused on inclusive product development and Android app development. You can follow her on Twitter at @ItsJazTanner.