|
| 1 | +# Governance |
| 2 | + |
| 3 | +## Basic principles |
| 4 | + |
| 5 | +This project aims to operate by the following principles: |
| 6 | + |
| 7 | +- **Openness**: The project will be open in its operation, open to contributions, and produce open source software. |
| 8 | +- **Respect**: The project will foster respectful interactions with all participants. |
| 9 | +- **Scientific integrity**: The project will follow advancements in cryptographic research and will be guided by standards and best practices. |
| 10 | + |
| 11 | +Decision making in the project will follow the principles above, and be governed first and foremost by reason and mutually respectful interaction between all participants. |
| 12 | +The project will aim to build consensus for decisions, and will where possible operate by the approach of [lazy consensus](https://community.apache.org/committers/decisionMaking.html). |
| 13 | +If decisions cannot be reached using lazy consensus, voting will be used to come to a resolution. |
| 14 | + |
| 15 | +## Community and Roles |
| 16 | + |
| 17 | +The OQS community is open to all who would like to participate in the project following its principles, including academic, industry, public sector, and individual contributors. |
| 18 | + |
| 19 | +The following roles exist in the project: |
| 20 | + |
| 21 | +### Users |
| 22 | + |
| 23 | +A **User** is a person or organization using software produced by the project. |
| 24 | + |
| 25 | +Responsibilities: |
| 26 | + |
| 27 | +- Abide by the [license][LICENSE.txt] |
| 28 | +- Consider participating in the project! |
| 29 | + |
| 30 | +### Community Members |
| 31 | + |
| 32 | +A **Community Member** is a User who interacts with the project, for example by participating in discussions on Github or mailing lists, or in project meetings. |
| 33 | + |
| 34 | +Responsibilities: |
| 35 | + |
| 36 | +- Follow the [code of conduct](CODE_OF_CONDUCT.md) |
| 37 | + |
| 38 | +### Contributors |
| 39 | + |
| 40 | +A **Contributor** is a Community Member who contributes directly to the project by submitting code or documentation, or actively participating in issues or pull requests on Github. |
| 41 | + |
| 42 | +### Committers |
| 43 | + |
| 44 | +A **Committer** is a Contributor with increased experience in the project who helps review pull requests and actively participates in discussions about the project. Committers will be members of the open-quantum-safe GitHub organization and will have "write" permissions in GitHub. |
| 45 | + |
| 46 | +Responsibilities: |
| 47 | + |
| 48 | +- Further the goals of the project. |
| 49 | +- Monitor and respond to GitHub issues. |
| 50 | +- Review and merge pull requests. |
| 51 | +- Assist with security releases when required. |
| 52 | +- Participate in discussions and project meetings. |
| 53 | + |
| 54 | +### Release managers |
| 55 | + |
| 56 | +A release manager is a Contributor versed in creating releases of the project. |
| 57 | + |
| 58 | +Responsibilities: |
| 59 | + |
| 60 | +- Manage the release cycle, incl. creation of suitable user documentation. |
| 61 | +- Execution of downstream tests ascertaining quality of releases. |
| 62 | + |
| 63 | +### Maintainers |
| 64 | + |
| 65 | +A **Maintainer** is a Committer who makes significant and sustained contributions to the project, and is committed to guiding the direction of the project. Maintainers will have "administrative" permissions in GitHub and thus are also able to act as Release managers. |
| 66 | + |
| 67 | +Responsibilities: |
| 68 | + |
| 69 | +- Oversee the overall project health and growth. |
| 70 | +- Lead communication for the project. |
| 71 | +- Define general and technical guidelines for the project. |
| 72 | +- Identify priorities. |
| 73 | + |
| 74 | +### Change of role |
| 75 | + |
| 76 | +Any Community Member may become a Contributor by creating a pull request (PR) and getting it successfully reviewed and merged by Committers. |
| 77 | + |
| 78 | +Any Contributor can become a Committer by contributing sufficient code and displaying deep subject matter knowledge in discussions such that a majority of Committers vote for this change of role. A Maintainer can veto such a vote. Such a veto can be overruled by a 2/3 majority of Committers. |
| 79 | + |
| 80 | +As such a voting decision may be considered subjective, Contributors striving to become Committers are encouraged to ask for advice from Committers/Maintainers as to what they can do to obtain this role. Baseline requirements for contributions are documented in [CONTRIBUTING.md](CONTRIBUTING.md). Any Contributor can create a discussion item to request a vote to become Committer. |
| 81 | + |
| 82 | +Any Committer can become a Maintainer by majority vote of voting Committers. A current Maintainer can veto such a vote. Such a veto can be overruled by a 2/3 majority of all Committers. |
| 83 | + |
| 84 | +A Maintainer is not permitted to remove another Maintainer's GitHub privileges. |
| 85 | + |
| 86 | +A Committer may be automatically moved to Contributor status if not actively contributing by discussion or PR review during the last 90 days or by voluntarily suspending this status (e.g., by taking a ["Leave of absence"](#leave-of-absence)). If a Maintainer loses or relinquishes the Committer status and, hence, the Maintainer status, the Committers have to determine whether a new Maintainer needs to be elected. |
| 87 | + |
| 88 | +Any person violating the [code of conduct](CODE_OF_CONDUCT.md), consistently not fulfilling the role responsibilities, or for other reasons can lose the role held if a simple majority of Committers votes for such removal and no Maintainer vetos that decision. If a Maintainer is to be removed from that role a 2/3 majority of Committers must agree. |
| 89 | + |
| 90 | +Depending on the reason for removal, a Maintainer may be converted to Emeritus status. Emeritus Maintainers may still be consulted on some project matters, and can be returned to Maintainer status if their availability changes and a simple majority of Committers agrees. |
| 91 | + |
| 92 | +### Leave of absence |
| 93 | + |
| 94 | +Any Committer may voluntarily step down from the role for a documented period of time, losing voting rights for that time period. The period is documented in this file next to the person's name below. At the end of this time period, the Committer automatically regains their voting rights. |
| 95 | + |
| 96 | +A leave of absence may not be longer than a year. If the Committer needs to be away for longer than that, they must step down from that role unconditionally, and regaining that role becomes subject of normal procedures to become Committer, as described in ["Change of role"](#change-of-role) above. |
| 97 | + |
| 98 | +## Voting |
| 99 | + |
| 100 | +Change of role or changes to this document is subject to voting. |
| 101 | + |
| 102 | +Votes are to be executed by way of open GitHub discussions. No quorum is needed for votes open for 4 weeks. Urgent matters may be decided by majority vote among Maintainers or 2/3 majority by all Committers within an arbitrary voting period. |
| 103 | + |
| 104 | +## Current Maintainers and Committers |
| 105 | + |
| 106 | +### Maintainers |
| 107 | + |
| 108 | +@dstebila |
| 109 | + |
| 110 | +### Committers |
| 111 | + |
| 112 | +@geedo0 |
| 113 | +@xuganyu96 |
| 114 | +@andrewyounkers |
| 115 | +@alharrison |
| 116 | + |
| 117 | +### Release managers |
| 118 | + |
| 119 | +@geedo0 |
| 120 | +@xuganyu96 |
| 121 | +@andrewyounkers |
| 122 | +@alharrison |
| 123 | + |
| 124 | +### Emeritus Committers |
| 125 | + |
| 126 | + |
| 127 | + |
| 128 | +## Afterword |
| 129 | + |
| 130 | +*This governance document was based in part of the [Falco Project governance document](https://github.com/falcosecurity/evolution/blob/main/GOVERNANCE.md). |
0 commit comments