Skip to content

Latest commit

 

History

History
104 lines (73 loc) · 5.06 KB

GOVERNANCE.md

File metadata and controls

104 lines (73 loc) · 5.06 KB

Dalec Project Governance

The Dalec project is dedicated to creating a community of individuals interested in software build systems.

This governance explains how the project is run.

Values

The Dalec project and its leadership embrace the following values:

  • Openness: Communication and decision-making happens in the open and is discoverable for future reference. As much as possible, all discussions and work take place in public forums and open repositories.

  • Fairness: All stakeholders have the opportunity to provide feedback and submit contributions, which will be considered on their merits.

  • Community over Product or Company: Sustaining and growing our community takes priority over shipping code or sponsors' organizational goals. Each contributor participates in the project as an individual.

  • Inclusivity: We innovate through different perspectives and skill sets, which can only be accomplished in a welcoming and respectful environment.

  • Participation: Responsibilities within the project are earned through participation, and there is a clear path up the contributor ladder into leadership positions.

Maintainers

Dalec Maintainers have write access to the project GitHub repository. They can merge their own patches or patches from others. The current maintainers can be found in MAINTAINERS.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 Dalec 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.

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

Maintainer responsibilities and other role descriptions can be found in the contributor ladder.

Code Changes

All code changes should go through the Pull Request (PR) process. PRs should only be merged after receiving approval (via GitHub) from at least one other maintainer. We do not vote formally on every code change, but we do expect that every code change merged has the same community support as if the change were approved by a formal vote. When a merge occurs without sufficient community support, the change should be reverted until the dispute is resolved through discussion. Any team member who feels that a technical decision cannot be reached can call for a formal vote following the rules outlined below in either the PR or a separate issue.

Branch Protection

Repository settings in GitHub enforce protection on the main branch. Required rules include the dco-2 status check and at least one approval from a maintainer who is not the author before merge. Force pushes are disabled, ensuring traceable, reviewable history for every release.

Meetings

Maintainers will have ad-hoc 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.

CNCF Resources

Any Maintainer may suggest a request for CNCF resources, either in the mailing list, or during a meeting. A simple majority of Maintainers approves the request.

Security Response Team

The Maintainers will serve as a Security Response Team to handle security reports. The Security Response Team is responsible for handling all reports of security holes and breaches according to the security policy.

Voting

While most business in Project Dalec is conducted by "lazy consensus", periodically the Maintainers may need to vote on specific actions or changes. A vote can be taken on the developer mailing list or the private Maintainer mailing list for security or conduct matters.
Votes may also be taken at community meetings or through Github Issues. 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 Charter

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