DeRec Alliance Maintainers Policy

Updated February 14, 2024

The policy outlines how governance for DeRec Alliance projects (i.e., github repositories) are run.

Maintainers

Project Maintainers have write access to the corresponding GitHub repository for a project. They can merge their own pull requests or pull requests from others after appropriate review from two existing maintainers. The current maintainers list can be found at https://github.com/derecalliance/.github/blob/main/MAINTANERS.md. Maintainers collectively manage the project’s resources and contributors.

This privilege is granted with some expectation of responsibility: maintainers are people who care about the project and want to help it grow and improve. A maintainer is not just someone who can make changes, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code and docs, contribute high-quality code, and follow through to fix issues (in code or tests).

A maintainer is a contributor to the project’s success and a citizen helping the project succeed. Each maintainer is expected to comply with and uphold the DeRec Alliance Code of Conduct.

The collective team of all Maintainers is known as the Maintainers Council, and is the governing body for the project.

Initial Maintainers

Initial maintainers for a project are set by the Technical Oversight Committee, based on relevant technical expertise, involvement with the DeRec Alliance, and any of the criteria listed in “Becoming a Maintainer.”

Becoming a Maintainer

To become a Maintainer you need to demonstrate the following:

Commitment to the project: participate in discussions, contributions, code and documentation reviews, perform reviews for a significant number of non-trivial pull requests, contribute significant non-trivial pull requests and have them merged.
Ability to write quality code and/or documentation.
Ability to collaborate with the team.
Understanding of how the team works (policies, processes for testing and code review, etc).
Understanding of the project’s code base and coding and documentation style.

A new Maintainer must be proposed by an existing maintainer by sending a message to [email protected]. A simple majority vote of existing Maintainers approves the application. Maintainer nominations will be evaluated without prejudice to employer or demographics.

Maintainers who are selected will be granted the necessary GitHub rights, and invited to the maintainers’ private email distribution list.

Removing a Maintainer

Maintainers may resign at any time if they feel that they will not be able to continue fulfilling their project duties. Maintainers may also be removed after being inactive, failure to fulfill their Maintainer 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 a year or more, with no definite schedule to return to full Maintainer activity.

A Maintainer may be removed at any time by more than a 2/3 vote of the remaining maintainers. Depending on the reason for removal, a Maintainer may be converted to Emeritus status. Emeritus Maintainers will still be consulted on some project matters, and can be rapidly returned to Maintainer status if their availability changes.

Meetings

Time zones permitting, Maintainers are expected to participate in regular maintainers meetings as set by the Maintainer Council Chair. Maintainers will also have closed meetings in order to discuss security reports or Code of Conduct violations. Such meetings should be scheduled by any Maintainer on receipt of a security issue or CoC report. All current Maintainers must be invited to such closed meetings, except for any Maintainer who is accused of a CoC violation.

Code of Conduct

Code of Conduct violations by community members will be discussed and resolved in Maintainers meetings, slack, or the maintainers’ private email distribution list. If a Maintainer is directly involved in the report, the Maintainers will instead designate two Maintainers to work with the Technical Oversight Committee in resolving it.

Voting Process

While most business in https://github.com/derecalliance is conducted by “lazy consensus”, periodically the Maintainers may need to vote on specific actions or changes. A vote can be taken on Maintainer maintainers’ private email distribution list for security or conduct matters. Votes may also be taken at maintainers’ meetings. Any Maintainer may demand a vote be taken.

Most votes require a simple majority of all Maintainers to succeed, except where otherwise noted. Two-thirds majority votes mean at least two-thirds of all existing maintainers.

Modifying this Policy

Changes to this Governance and its supporting documents may be approved by a 2/3 vote of the Technical Oversight Committee.