This is a governance template for Rust Innovation Lab projects. If your project already has a detailed governance structure then you can use that. This template is intended to help project maintainers who are creating their initial governance outline.
To use this template, start off by deleting this introduction section. Replace [ProjectName] with the name of your project. Edit the rest of the text to describe how your project operates, to someone who’s encountering it for the very first time.
This document describes the governance model for [ProjectName], an open source project dedicated to [insert project’s mission/goals]. It defines the roles, responsibilities, and processes that guide how the project operates and makes decisions.
We aim to operate transparently, make decisions in the best interests of [ProjectName] and its community, and ensure that no single person has unchecked control over its direction or resources.
The Project Lead(s) is/are the primary contact(s) with the Rust Foundation, and responsible for:
- Representing [ProjectName] in official matters.
- Coordinating major decisions about project direction.
- Signing off project expenses.
- Ensuring the project complies with the Rust Innovation Lab’s policies and requirements.
Project Leads are selected by consensus among maintainers. Two Project Leads should be selected, unless the project has only a single maintainer.
If a Project Lead steps down or becomes inactive, maintainers will select a new Project Lead by consensus or majority vote.
Maintainers are contributors who have write access to [ProjectName]’s source code. They review and merge contributions, participate in project decision-making, and help to onboard and mentor new contributors.
New maintainers are added by a consensus or majority vote of the current maintainers, based on sustained and high-quality contributions to the project, alignment with its goals, and a demonstrated commitment to community standards. Prospective maintainers should have a track record of participation in discussions, issue triage, and code or documentation improvements.
A maintainer may step down at any time by notifying the other maintainers. In rare cases, a maintainer may be removed by a consensus or a two-thirds supermajority vote of the other maintainers if they are inactive for an extended period, violate the Code of Conduct, or act against the project’s interests.
Anyone who submits code, documentation or other improvements is counted as a contributor. Contributors do not have formal decision-making power, but are encouraged to participate in discussions about project direction and propose changes.
[ProjectName] strives for consensus-based decision-making. When consensus cannot be reached, decisions are made by a majority vote of maintainers.
Funds held by the Rust Foundation on behalf of [ProjectName] must be used in alignment with the project’s mission and the Rust Foundation’s policies. Spending proposals should be discussed among maintainers to ensure that there is agreement.
Maintainers will ensure that there is up-to-date documentation of how to operate [ProjectName]’s infrastructure, how to access important accounts and other project assets, and any processes required to keep the project running smoothly.
Maintainers commit to working with the Rust Foundation, if they can no longer continue the project, to wind it down in an orderly fashion. This will include the disposal of any remaining funds, other assets, and intellectual property to an appropriate successor.
This governance policy may be amended by consensus or a two-thirds supermajority of maintainers, with changes documented in the project repository and communicated to the Rust Foundation.