Skip to content

Latest commit

 

History

History
53 lines (36 loc) · 3.98 KB

governance-basic.md

File metadata and controls

53 lines (36 loc) · 3.98 KB

Open Source Inclusion Basic Checklist for Projects

This checklist provides open source projects with basics for evaluating the inclusive design in key areas. This checklist is intended to provide insight, and education.

Governance

Code of Conduct

A Code of Conduct sends a signal to your project & community that you invested in creating a safe and empowered community for everyone, regardless of background, family status, gender, gender-identity or expression, marital status, sex, sexual orientation, native language, age, ability, race/ethnicity, national origin, socioenconimic status, religion, geographic location or any other dimension of diversity.

It's not enough to have a Code of Conduct. Creating transparent, and effective processes for enforcement is key. The following questions represent the most basic requirements for establishing a CoC.
An advanced checklist will be available in the future.

  • We have a Code of Conduct ("CoC").
  • Our Code of Conduct is visible from our main project page and/or repository root and linked from all communication channels.
  • It is clearly stated in the COC how to report behaviors that are illegal or make individuals/groups feel unsafe, unwelcome or uncomfortable.
  • It is clear to whom that report will go.
  • We have a process for responding-to reports that ensures reporter, reported and all others impacted are regularly updated.

Leadership

il

Leadership is central to project and community culture, and thus require intentional design, and accountability for the empowerment of others. NOTE: The term 'leader' doesn't always resonate, if that's the case for your project, replace with 'roles of influence'.

  • Our project leadership is designed with cycles of feedback and review to avoid gatekeeping and to encourage inclusive behavior.
  • Responsibilities of leadership are clearly documented.
  • We recognize leadership equally, including non-technical leadership.
  • We recognize 'empowering others' as a core attribute of leadership, and discourage self promotion.
  • We reach out to people we know would be great leaders, including underrepresented people who might not recognize their potential.

Here is an example of an inclusive leadership page (Firefox Developer Tools).

Project & Community Design

This section describes some simple ways your project and community design can be more inclusive.

Communication & Language

  • We have a welcoming and open channel for community participation.
  • We strive to avoid jargon and other non-inclusive language that can alienate, and make underrepresented people feel excluded.
  • We strive to encourage and recognizes the quietest voices, and not just those with the most confidence, and volume.
  • We recognize that the primary language of the project may not be the first language of all contributors, and where possible provide transcripts of meetings and other key project correspondence are easily found.
  • We have provided a way for everyone to share their pronouns, and respect those in our conversations and communication.

Documentation

  • We have taken one or more steps to improve the accessibility of our documentation/website?
  • We encourage and support localization of our documentation.

Tasks

  • We provide non-technical tasks for first-time contributors to learn about, and participate in our project.
  • To encourage community leadership, we have good 'first-pr' label, encouraging people to support maintainer review of PRs.