This checklist provides projects & contributors alike, with a basic set of criteria to evaluate an open source project for participation. This is intended to be light-weight, and only includes that which you can evaluate in a short amount of time.
This checklist is intended to provide insight, and education. It does not provide assurances, but is rather intended to support informed decision making about potential, or extended involvement in an open source project.
A Code of Conduct sends an signal that a project & community is invested in creating a safe and empowered spaces 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.
- I can locate a Code of Conduct.
- That Code of Conduct is in the root of the repository, and not buried in another file content (like README, or CONTRIBUTING).
- The Code of Conduct is visible from the main project page and/or repository root and linked from all communication channels.
- It is clearly stated in the COC how to report behaviors at that are illegal or make individuals/groups feel unsafe, unwelcome or uncomfortable.
- It is clear to whom that report will go.
- It is clear what to expect if I report.
Want to deep dive into the quailty of a Code of Conduct? Try this tool, with marking grid.
Leadership is central to project and community culture, and thus requires 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'.
- It's easy to understand who the project leaders are (maintainers, committers, community team).
- The roles of leadership in a project are publically documented.
- The roles of leadership in a project have cycles of renewability and accountability (voting terms, community input). Note this one can be harder to locate.
- It's clear how to step into, or achieve a leadership role.
Here is an example of an inclusive leadership page (Firefox Developer Tools).
- Of the last 100 commits by non-staff contributors at least 3 appear to be* by someone other than male.
- yes... many people use male-avatars, and names to hide their gender-identity. This is just intended to provide early insights into demographics of a community. Given only 3% of open source contributors are women, it's likely that you will see mostly male contributions, but having zero women is a flag. Ideally the number is far higher.
This section describes some simple ways your project and community design can be more inclusive.
Communication channels is meant to include issue queues, pull request comments, discussion forums, an chat channels like Slack.
- There is a welcoming and open channel for community particpiation.
- Project channels are friendly, and not overly assertive (i.e. people flexing tech knolwedge and shouting (or shaming) each other down).
- Participation in channels, includes and activeliy seeks to include voices of people who are not the dominant demographic.
- There is a way for everyone to share their pronouns, and those show up in conversations and communication.
- Documentation is accessible accessiblity of our documentation/website?
- Localization of documentation is supported and encouraged.
- Non-technical tasks helpful for first-time contributors to learn about, and participate in a project are available.