This document defines the project governance for GitVote including how someone become a maintainer, how decisions are made, how changes are made to the governance, and more.
Anyone can propose a change to GitVote. This includes the code, the documentation, and even the governance. Details on contributing can be found in the CONTRIBUTING.md file.
Maintainers are responsible for the development and operation of the project. This includes but is not limited to:
- Reviewing and merging pull requests
- The operation of the GitVote service and GitHub application
- Refining the projects governance
- Overseeing the resolution and disclosure of security issues
Changes to maintainers use the following rules:
- New maintainers can be added with a super-majority vote. The vote must happen in a tracked location (e.g., mailing list, GitHub issue, etc).
- If a maintainer is inactive for > 6 months they will automatically be removed unless a super-majority of the other maintainers agrees to extend the period of inactivity. This is useful when there is a known period of inactivity and a maintainer will be returning.
- A maintainer may step down at any time and remove themselves.
- If a maintainer needs to be removed, a super-majority vote of the other maintainer is required. This vote needs to happen in a tracked location.
There are 3 ways decisions can be made for non-code related decisions. Those are:
- Lazy-consensus is the default method to make decisions.
- When a lazy-consensus decision cannot be made it will move to a majority vote unless otherwise specified in this governance.
- Some decisions require a super-majority of maintainer to approve. Those include:
- Changes to the governance
- Removing a maintainer
- Licensing and intellectual property changes
Changes to source code requires a maintainer to approve the changes.