DEI.md

Disclaimer: This file should not be used when creating your DEI.md file. Please use the Template.DEI.md and Guide.DEI.md when creating your own DEI.md file.

DEI Project Statement

Include Your Project Name/Logo Here

Include a description of the scope of the DEI.md file. For example, does this DEI.md file cover one particular repository, a collection of repositories, or an entire organization?

[Project Name] prioritizes and reflects on DEI through a regular review of project policies and performance based on the ever-evolving CHAOSS project DEI metrics and information in the All In DEI Resource Hub.

[Project Name] has reflected on DEI related to:

1. Project Access

• Description of how your project addresses project access. A sample description is provided in the following points. These points are not required for your project but are meant to help consider things you could be doing or are already doing. The points could also include efforts that your project is doing but are not listed here:

  • Project access is addressed in the [Project Name] through various efforts. Through these efforts, we aim to support access for all. Specific efforts in our project include:
    1. All virtual meetings are transcribed via the Zoom annotation tool, and members can join via their computer or phone. Video is not required to participate in virtual meetings.
    2. Virtual meetings are attentive to global time zones. While most of our meetings occur during times that are most easily accessed by members in North America, South America, Western Europe, and Africa, virtual meetings are also held to support [Project Name] members in Asia-Pacific and Eastern Europe.
    3. [Project Name] project maintainers and merge request coaches span global time zones and work asynchronously with contributors across the world.
    4. Translation services are provided for all website pages.
    5. All areas of [Project Name] are considered open to community contributions. A stated goal of our project is that “everyone can contribute."
    6. The [Project Name] SaaS product is conformant with the Voluntary Product Accessibility Template (VPAT 2.4) revised in June 2023 as well as to level AA of the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines 2.1.
    7. [Project Name] is developing a unified contributor program that recognizes and rewards non-code contributors, including contributions through events, blog posts, and comments in issues and merge requests.

2. Communication Transparency

• Description of how your project addresses communication transparency. A sample description is provided in the following points. These points are not required for your project but are meant to help consider things you could be doing or are already doing. The points could also include efforts that your project is doing but are not listed here:

  • Communication Transparency is addressed in the [Project Name] through a variety of different efforts. Through these efforts, we aim to support transparency for all. Specific efforts in our project include:
    1. All project documentation is publicly available via Google Docs and shared via our [Project Name] community handbook.
    2. Appropriate documentation is shared at the start of every working group meeting.
    3. Slack channels are regularly reviewed to determine if they should be public or private channels as well as considering if a channel is needed any longer.
    4. All virtual meetings are recorded and uploaded to our project YouTube channel.
    5. Decisions that impact the project are shared across numerous working groups meetings and associated Slack channels to ensure that as many project members can participate in the process.
    6. Any information that cannot be made public (e.g. security and abuse vulnerabilities, financial information, private data) is marked as internal to the project. All of the internal information is listed publicly by name and any other information not marked as internal are available externally to the public.
    7. [Project Name] operates using a single source of truth for all community members.
    8. [Project Name]'s handbook is public and open to contribution.
    9. [Project Name] operates an unfiltered YouTube channel that shares all publicly available meetings, recordings, and community pairing sessions.

3. Newcomer Experiences

• Description of how your project addresses the newcomer experience. A sample description is provided in the following points. These points are not required for your project but are meant to help consider things you could be doing or are already doing. The points could also include efforts that your project is doing but are not listed here:

  • The newcomer experience is addressed in the [Project Name] through a variety of different efforts. Through these efforts, we aim to support the newcomer experience for all new members. Specific efforts in our project include:
    1. Newcomer events are held on a weekly basis in the [Project Name]. These events include newcomer orientation sessions and office hours open to all with an interest.
    2. [Project Name] has a dedicated #newcomer channel on Slack where newcomers can join and learn about different ways to connect with the project. In the channel, we have a newcomer bot that provides detailed information on how to engage with the [Project Name]. The bot is available by typing ‘newbie’ in the #newcomer Slack channel.
    3. A quickstart guide for newcomers is posted on our website and made available through the main website navigation.
    4. [Project Name] uses weekly triage reports on first time contributors who are awaiting a response to a merge request. This ensures newcomers always hear back from a real person about their merge request.
    5. [Project Name] reviews contributor documentation for inclusivity of newcomers, including improvements to documentation navigation, technical content and jargon, and improving workflow processes for newcomers.
    6. [Project Name] automatically applies a 1st contribution label to first-time contributors who open a merge request so they may be better identified and assisted by reviewers and coaches.
    7. [Project Name]'s contributor documentation includes a full walkthrough tutorial for newcomers to make their first contribution. This includes setting up the development environment, making code changes, documentation updates and ways to find support.
    8. [Project Name] has a dedicated Contributor Success team to facilitate newcomer onboarding, help newcomers find issues, assist newcomers through merge requests and communicate to reviewers on the behalf of contributors to ensure a smoother review experience.
    9. [Project Name] offers a community fork which helps newcomers collaborate with other contributors under a shared fork. This means newcomers do not have to maintain and update a personal fork.
    10. [Project Name] tracks metrics for new contributors with the goal of increasing total contributors to the project and helping convert new contributors into returning contributors.

4. Inclusive Leadership

• Description of how your project addresses inclusive leadership. A sample description is provided in the following points. These points are not required for your project but are meant to help consider things you could be doing or are already doing. The points could also include efforts that your project is doing but are not listed here:

  • Inclusive leadership is addressed in the [Project Name] through a variety of different efforts. Through these efforts, we aim to support leadership opportunities for project members with an interest. Specific efforts in our project include:
    1. Our [Project Name] governance document is reviewed and affirmed on a yearly basis to identify and articulate roles within the project that help guide the strategic direction of the project.
    2. Global chapters of our project are led by people from those regions. Chapter leads help set the strategic direction of the [Project Name] as best suited in different global settings.
    3. Working group meetings provide the opportunity to be led by different people at each meeting. While each working group has identified ‘chairs’, leading a meeting provides an opportunity to lead for all members.
    4. Our projects ensures a diverse candidate slate and interview panel when selecting new maintainers.
    5. All of our project maintainers have completed neurodiversity and other DEI training.
    6. One or more of our project maintainers are a member of a working group related to a DEI initiative.
    7. One or more of our project maintainers participate in DEI group meetings or events.

[Project Name] recognizes that the inclusion of the DEI.md file and the provided reflection on the four DEI metrics does not ensure community safety nor community inclusiveness. The inclusion of the DEI.md file and CHAOSS DEI review statement signals that we are committed to continually improving our DEI by regularly reviewing and reflecting on our project DEI practices, and on a regular and annual basis, updating this statement and project policies in-line with the review findings.

If you do not feel that the DEI.md file appropriately addresses concerns you have about community safety and inclusiveness, please let us, in the [Project Name], know. You can do this by checking out our Code of Conduct (link) to raise concerns you have with the Code of Conduct team.

Last Reviewed: [Enter Date]

Additional Recommendations Regarding the DEI.md File

1. If using a development platform, place the DEI.md file in an organizationally available repository, similar to your CODE_OF_CONDUCT.md file
2. If an organizationally availble folder is not available or used, place the DEI.md file in a community repository
3. If you have a project website, provide a link to your DEI.md file from the main project navigation