CHAOSS Governance

The CHAOSS Project Charter provides our official governance materials including the project mission, responsibilities of the Governing Board, voting process, budget, and other details about the governance of the CHAOSS project.

CHAOSS Community Structure

The work within the CHAOSS Community happens across a variety of different groups with a Governing Board to oversee this work, but much of the day to day work happens in our Working Groups, Chapters, and Software Subprojects as defined in the sections below.

Any CHAOSS community member can participate in any of our WGs, Subprojects, and Chapters. We hope that participation in these groups will eventually allow community members to gain experience and move into leadership roles within the project as defined below.

Governing Board

The CHAOSS Governing Board provides oversight for the entire CHAOSS project as defined in the CHAOSS Project Charter. New Governing Board members are selected by the existing Governing Board as defined in the CHAOSS Project Charter.

However, much of the day to day work within the CHAOSS Project is delegated to the various working groups, software subprojects, and chapters defined below. Each of these has one or more people in “Leadership” roles who are responsible for coordinating the activities and may have responsibilities to appoint other roles as defined in the sections below.

Working Groups (WG)

WGs are responsible for metrics discussions, which can include development and maintenance of metrics / metrics models, discussions about the use of metrics, and other metrics-related discussions. New WGs can be created with community consensus and are presented to the Governing Board to solicit feedback and/or concerns.

Each WG should have the following roles (the roles are defined in the Roles and Responsibilities section below):

• Chairs (Leadership role): WGs must have at least one chair (ideally 2), but can have more.
• Maintainers (optional)
• Liaisons (optional)

The full list of Working Groups can be found on the CHAOSS website.

Metrics Working Groups

These working groups are responsible for developing and maintaining metrics definitions and metrics models.

Context Working Groups

Context WGs are groups of people who share similar contexts related to open source project health. Context WGs are responsible for helping put CHAOSS metrics, metrics models, and software into practice in meaningful ways across varied contexts.

Operations Working Groups

The Operations Working Groups are supporting the metrics discussions and are responsible for various activities and operations for the CHAOSS project. In general, some of these are less formal than the other types of Working Groups. They may or may not have meetings and may not always be active (e.g., CHAOSScon).

Chapters

Chapters are geographically-based groups who drive awareness and activities for the CHAOSS project within their region. This could include events, translation, and other activities. Whenever possible, Chapters are expected to collaborate within our Working Groups on activities that are ongoing within the CHAOSS project; for example, development of new metrics would be done within the appropriate Metrics WG.

Each chapter will have at least one Lead (Leadership role) who is responsible for coordinating activities for their region and recruiting other participants for their chapter. These chapter leads are staffed positions.

The current list of Chapters can be found on the CHAOSS website.

Software Subprojects

Each of these subprojects are governed by a collection of Maintainers (Leadership role), which can be found in a MAINTAINERS.md file in a subproject repository. Decisions about the project are made by consensus among these Maintainers. If there is disagreement that cannot be resolved at the subproject level, the decision should be escalated to the Governing Board as defined in the CHAOSS Project Charter.

The CHAOSS Project has the following Software Subprojects:

• Augur software
• GrimoireLab software

Approval for adding a new Software Subproject requires a vote of the Governing Board as defined in the CHAOSS Project Charter.

Roles and Responsibilities

With the exception of the Staff Positions, community members who have a history of participation within the project can move into the various leadership roles as defined below. Current leadership of the various groups can be found on the Teams at CHAOSS page.

All of these roles are granted with some expectation of responsibility: they are people who care about the CHAOSS project and want to help it grow and improve. These are not just people who can make changes, but people who have demonstrated their ability to collaborate with the team, get the most knowledgeable people to participate, make high-quality contributions, and follow through to resolve issues and PRs. These are contributors to the project's success and a citizen helping the project succeed.

WG Chairs

Chairs set agendas, run meetings, and have maintainer responsibilities to make sure that the WG is keeping up with issues and PRs. Chairs have write access to the GitHub repository for their WG.

Becoming a WG Chair

To become a chair, you should demonstrate the following:

• commitment to the CHAOSS project
• participation in WG discussions, contributions, reviews, and meetings for a period of at least 6 months
• ability to define metrics, write quality code or documentation, or make other substantial contributions to the community
• ability to collaborate with the team
• understanding of how the WG conducts its work (policies, processes, etc.)

New WG chairs are selected by consensus within the WG or within the community for newly forming WGs. If there is disagreement that cannot be resolved at this level, the decision should be escalated to the Governing Board.

Liaisons

WGs, Software Subprojects, or Chapters may have a designated person responsible for liaising with other groups and providing input to all of the other groups as needed (e.g., communications, website, software subprojects). With so many groups and activities across the CHAOSS project, the Liaisons are how we keep the various groups in sync. In particular, these Liaisons play a critical role in creating feedback loops between our WGs and our software subprojects to help the CHAOSS project evolve our software to better meet the needs of the people using our software across various contexts.

Becoming a Liaison

To become a liaison, you should demonstrate the following:

• commitment to the CHAOSS project
• participation in WG discussions, contributions, reviews, and meetings for a period of at least 3 months
• ability to collaborate with the team
• understanding of how the WG conducts its work (policies, processes, etc.)

New Liaisons are selected by Leadership for the Working Group, Software Subproject, or Chapter to be represented.

Maintainers

CHAOSS Maintainers have write access to the project GitHub repository. They can merge their own patches or patches from others. Maintainers collectively manage the project's resources and contributors.

Becoming a Maintainer

• commitment to the CHAOSS project
• participation in discussions, contributions, reviews, and meetings
• perform substantial reviews for at least 5 PRs
• have at least 5 PRs merged as an author of those PRs
• ability to define metrics, write quality code / documentation, or make other substantial contributions to the community
• ability to collaborate with the team
• understanding of how the CHAOSS project conducts its work (policies, processes, etc)

Maintainers are selected by Leadership for the Working Group, Software Subproject, or Chapter to be represented.

Staff Positions

These positions are funded through grants with input from the Governing Board.

• Community Manager
• Data Science
• Chapter Leads

Removal

Anyone holding any role within the CHAOSS project may resign at any time without giving a reason. The CHAOSS community encourages members who hold a role to regularly assess if they plan to continue fulfilling their project duties and otherwise to resign.

Someone may also be removed after being inactive, failure to fulfill their responsibilities, violating the Code of Conduct, or other reasons. Inactivity is defined as a period of very low or no activity in the project for six months or more, with no schedule to return to full activity in that role. Involuntary removals are made by a vote of the Governing Board as defined in the CHAOSS Project Charter.

Meetings

Time zones permitting, people in the roles listed above are expected to participate in the CHAOSS Weekly Sync Meeting and any other meetings relevant to their area of responsibility. Details about these meetings can be found in the CHAOSS Calendar.

Code of Conduct

Code of Conduct violations by community members will be discussed and resolved by the Code of Conduct Enforcement Committee, which is appointed by the Governing Board.

Modifications

Any modifications to this governance document are made by a vote of the Governing Board as defined in the CHAOSS Project Charter.

Document History

• 2023-06-22: Governing Board approval of this document.