Skip to content

Latest commit

 

History

History
69 lines (45 loc) · 5.47 KB

Governance.md

File metadata and controls

69 lines (45 loc) · 5.47 KB

Architecture as Code Governance Policies

This document describes the governance policies of the FINOS Architecture as Code project. The project is also governed by the Linux Foundation Antitrust Policy, and the FINOS IP Policy, Code of Conduct, Collaborative Principles, and Meeting Procedures.

Governance

Roles

The project community consists of Contributors and Maintainers:

  • 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.)
  • 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.
  • The Lead Maintainer is the project's interface with the FINOS team and Board. They are responsible for approving quarterly project reports and communicating on behalf of the project. The Lead Maintainer is elected by a vote of the Maintainers.

Contribution Rules

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.)

  • All contributions MUST be submitted as pull requests, including contributions by Maintainers.
  • All pull requests SHOULD be reviewed by a Maintainer (other than the Contributor) before being merged.
  • 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.
  • After the review period, if no Maintainer has an objection to the pull request, any Maintainer MAY merge it.
  • 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.

Maintainer Voting

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.

The Maintainers SHALL decide the following matters by consensus or, if necessary, a vote:

  • Contested pull requests
  • Election and removal of the Lead Maintainer
  • Election and removal of Maintainers

All Maintainer votes MUST be carried out transparently, with all discussion and voting occurring in public, either:

  • in comments associated with the relevant issue or pull request, if applicable;
  • on the project mailing list or other official public communication channel; or
  • during a regular, minuted project meeting.

Maintainer Qualifications

Any Contributor who has made a substantial contribution to the project MAY apply (or be nominated) to become a Maintainer. The existing Maintainers SHALL vote on whether to approve the nomination according to the Maintainer Voting process above. A nomination MUST receive a majority of votes to be approved.

Removal of Maintainers

A Maintainer MAY be removed due to inactivity or by their own request, subject to the following processes:

Voluntary Removal

  1. A Maintainer wishing to step down MUST raise a GitHub issue stating their intent to be removed.
  2. The remaining Maintainers SHALL acknowledge the request and proceed with removal.
  3. No vote is required for voluntary removal.

Removal Due to Inactivity

A Maintainer is considered inactive if they have had no commits and no involvement in any issue or pull request discussions for a period of 3 months or more.

  1. A Maintainer MUST raise a GitHub issue proposing the removal, clearly stating the reason (e.g., period of inactivity) and tagging the inactive Maintainer.
  2. The inactive Maintainer SHALL be notified via the issue and any other known contact methods (e.g., email).
  3. A minimum notice period of 4 weeks MUST be observed from the date the issue is raised before any vote on removal may occur.
  4. During the notice period, the inactive Maintainer MAY respond to the issue to contest the removal or indicate their intent to resume activity.
  5. After the notice period, if the Maintainer has not responded or resumed activity, the remaining Maintainers SHALL vote on removal according to the Maintainer Voting process above.
  6. If the Maintainer resumes meaningful activity during the notice period, the removal issue SHOULD be closed without a vote.

Reinstatement

A Maintainer who has been removed due to inactivity MAY be reinstated at any time if they resume activity and wish to rejoin. The reinstatement process follows the standard Maintainer Qualifications process above.

Changes to this Document

This document MAY be amended by a vote of the Maintainers according to the Maintainer Voting process above.