Inclusive Leadership

Question: How well is a project setup for diverse leadership?


Leadership is central to project and community culture, and thus requires intentional design and accountability for the inclusion of others. The term 'leader' doesn't always resonate; if that's the case for your project, replace it with 'roles of influence'. As those in leadership roles have high visibility, the diversity of this group is critically important to fostering an inclusive community.


Signal to newcomers that everyone is welcome, as well as how to be successful within the project given any specified limitations listed as discussed in below.


Examples of open source leadership (aka 'roles with influence'):

  • Project maintainers (sometimes referred to as owners)
  • Contributors with repository merge access
  • Contributors who are organization members for the repository
  • OS Program Board Members
  • Official Program Roles (Program Representatives, Tech Speakers)
  • Those listed in project documents as contacts for issues with builds, documentation, etc.
  • Those with more than 5 pull requests to a project

Step 1: Understand

The first step is to understand the principles of inclusive leadership by asking some questions. This is structured in 6 principles which serve as a check-list.

Review & Renewal

  • Are all leadership roles limited by time and require term renewal?
  • Do the term renewals include opportunities for review and feedback from communities involved?
  • Is there a graceful way to move people out of leadership roles and into emeritus or advisory roles?

Distribution of Leaders

  • Are leaders limited in the number of leadership roles one person can hold?
  • Are new leadership opportunities and pathways decided and consulted on by the community involved in that area?
  • Are the criteria for the role requirements validated by the community involved?
  • Does the project create clear definitions for roles?
  • Does the project publicly document their definitions for roles?
  • Is leadership responsibility held by groups and not individuals, where possible?


  • Do the project’s leaders agree to a standard by which they can be held accountable?
  • Do the staff & community know and understand how they can hold leaders accountable?
  • Are leaders aware that they represent the organization/project in their actions?
  • Are leaders following and continually evolving a shared framework for decision making?
  • Does the leadership openly communicate periods of inactivity or unavailability with the project and community?

Diverse Participation

  • Do the project leaders strive to include diverse voices and groups whenever possible?
  • Does the project enforce the Code of Conduct consistently and strictly?
  • Do the leadership pathway explicitly consider inclusion dimensions (e.g., time zone, language, bandwidth, cultural norms)?

Roles & Consistency

  • Are the leadership roles valued similarly across the project (e.g., recognition, access to resources, opportunities)?
  • Do all leaders have clarity in their roles and expectations?
  • Do all leaders have a shared foundational knowledge base & skills (e.g., Community Participation Guidelines).
  • Does project leadership follow a shared framework for decision making?
  • Are project roles clearly defined?
  • Are the related tools consistent and coherent, where possible?

Equal Value

  • Does the project value and recognize different types of experts equally (e.g., technical and non-technical)?

Acknowledgement of Limitations

  • Have project leaders identified technical, financial, or other limitations out of their control that may have an adverse impact on inclusivity?
  • Has leadership clearly and explicitly acknowledged these limitations publicly?
  • Are leaders open to discussing and implementing suggestions that reduce the impact of these limitations?

Step 2: Evaluate The second step is to evaluate your project/community according to existing goals for leadership.

Example Goal: Increase % in contribution typically done by project maintainers (pull request review, responding to, and trying to replicate issues).

Step 3: Take Action The third step is to act on what you've learned. What those steps are depends on your specific project community and giving recommendations is outside the scope of this document. Below references have some ideas.



The principles and practices above were created and agreed upon by a cross-functional set of diverse group of Mozilla staff and volunteers who are most closely connected to the primary contribution areas SUMO, Mozilla Reps, L10N).

Read more here.

They have been applied to the following projects/products: