Question: How well is a project and community setup for diverse leadership?
Leadership is central to a project/community's culture and how the leadership is determined requires intentional design and accountability for the inclusion of others. Note the term leadership may vary depending on the project/community. Leadership roles have high visibility and the diversity of this group is critically important to fostering an inclusive community.
- Enable communities to reflect on their own leadership practices.
- Signal to newcomers that everyone is welcome, has an opportunity to take on leadership roles, and can be successful within the project.
The usage and dissemination of health metrics may lead to privacy violations. Organizations may be exposed to risks. These risks may flow from compliance with the GDPR in the EU, with state law in the US, or with other law. There may also be contractual risks flowing from terms of service for data providers such as GitHub and GitLab. The usage of metrics must be examined for risk and potential data ethics problems. Please see CHAOSS Data Ethics document for additional guidance.
Examples of open source leadership (e.g., influential community roles):
- Individuals serving as project maintainers (sometimes referred to as owners)
- Individuals with repository merge access
- Individuals who are organization members for the repository
- Individuals who have defined community roles (community representatives, community speakers)
- Individuals listed in project documents as contacts for issues with builds, documentation, or other community concerns
- Individuals serving as community event organizers
- Individuals serving as community mentors for available mentorship programs
Data Collection Strategies
Step 1: Understand
The first step is to understand the principles of inclusive leadership by asking some questions that can include:
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?
- 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, and cultural norms)?
Roles & Consistency
- Are the leadership roles valued similarly across the project (e.g., recognition, access to resources, and 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?
- 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.
- Related blog post
- Create an Inclusive Leadership team page
- Run an 'Open Source Maintainer training program
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).
They have been applied to the following projects/products: