|
| 1 | +# Architecture as Code Governance Policies |
| 2 | + |
| 3 | +This document describes the governance policies of the FINOS Architecture as Code project. The project is also governed by the [Linux Foundation Antitrust Policy](https://www.linuxfoundation.org/antitrust-policy/), and the FINOS [IP Policy]( https://community.finos.org/governance-docs/IP-policy.pdf), [Code of Conduct](https://community.finos.org/docs/governance/code-of-conduct), [Collaborative Principles](https://community.finos.org/docs/governance/collaborative-principles/), and [Meeting Procedures](https://community.finos.org/docs/governance/meeting-procedures/). |
| 4 | + |
| 5 | +## Governance |
| 6 | + |
| 7 | +### Roles |
| 8 | + |
| 9 | +The project community consists of Contributors and Maintainers: |
| 10 | +* A **Contributor** is anyone who submits a contribution to the project. (Contributions may include code, issues, comments, documentation, media, or any combination of the above.) |
| 11 | +* A **Maintainer** is a Contributor who, by virtue of their contribution history, has been given write access to project repositories and may merge approved contributions. |
| 12 | +* The **Lead Maintainer** is the project's interface with the FINOS team and Board. They are responsible for approving [quarterly project reports](https://community.finos.org/docs/governance/#project-governing-board-reporting) and communicating on behalf of the project. The Lead Maintainer is elected by a vote of the Maintainers. |
| 13 | + |
| 14 | +### Contribution Rules |
| 15 | + |
| 16 | +Anyone is welcome to submit a contribution to the project. The rules below apply to all contributions. (The key words "MUST", "SHALL", "SHOULD", "MAY", etc. in this document are to be interpreted as described in [IETF RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).) |
| 17 | + |
| 18 | +* All contributions MUST be submitted as pull requests, including contributions by Maintainers. |
| 19 | +* All pull requests SHOULD be reviewed by a Maintainer (other than the Contributor) before being merged. |
| 20 | +* Pull requests for non-trivial contributions SHOULD remain open for a review period sufficient to give all Maintainers a sufficient opportunity to review and comment on them. |
| 21 | +* After the review period, if no Maintainer has an objection to the pull request, any Maintainer MAY merge it. |
| 22 | +* If any Maintainer objects to a pull request, the Maintainers SHOULD try to come to consensus through discussion. If no consensus can be reached, any Maintainer MAY call for a vote on the contribution. |
| 23 | + |
| 24 | +### Maintainer Voting |
| 25 | + |
| 26 | +The Maintainers MAY hold votes only when they are unable to reach consensus on an issue. Any Maintainer MAY call a vote on a contested issue, after which Maintainers SHALL have 36 hours to register their votes. Votes SHALL take the form of "+1" (agree), "-1" (disagree), "+0" (abstain). Issues SHALL be decided by the majority of votes cast. If there is only one Maintainer, they SHALL decide any issue otherwise requiring a Maintainer vote. If a vote is tied, the Lead Maintainer MAY cast an additional tie-breaker vote. |
| 27 | + |
| 28 | +The Maintainers SHALL decide the following matters by consensus or, if necessary, a vote: |
| 29 | +* Contested pull requests |
| 30 | +* Election and removal of the Lead Maintainer |
| 31 | +* Election and removal of Maintainers |
| 32 | + |
| 33 | +All Maintainer votes MUST be carried out transparently, with all discussion and voting occurring in public, either: |
| 34 | +* in comments associated with the relevant issue or pull request, if applicable; |
| 35 | +* on the project mailing list or other official public communication channel; or |
| 36 | +* during a regular, minuted project meeting. |
| 37 | + |
| 38 | +### Maintainer Qualifications |
| 39 | + |
| 40 | +Any Contributor who has made a substantial contribution to the project MAY apply (or be nominated) to become a Maintainer. The existing Maintainers SHALL decide whether to approve the nomination according to the Maintainer Voting process above. |
| 41 | + |
| 42 | +### Changes to this Document |
| 43 | + |
| 44 | +This document MAY be amended by a vote of the Maintainers according to the Maintainer Voting process above. |
0 commit comments