Our governance refers to the "Core Principles" of Airship, but we've been lax in formally defining what those are. This patchset adds a general definition, based on discussion from the Working Comittee meeting on 2020-06-29. Change-Id: Ia912d14913dd540d9c3550b40ab22536e40431ab
|2 months ago|
|.gitignore||7 months ago|
|.gitreview||1 year ago|
|.zuul.yaml||1 year ago|
|CONTRIBUTING.md||3 months ago|
|README.md||1 month ago|
|principles.md||1 month ago|
Airship is a community of open source projects working to build a platform for the lifecycle management of open infrastructure. It’s designed from the ground up to make containers and Helm charts the fundamental units of software delivery and deployment.
An Airship feeds a collection of declarative site definition YAMLs through a single front door API, and then uses them to drive end-to-end provisioning of a site, from bare metal to fully functioning cloud.
Airship is working to build a global, diverse and collaborative community. Anyone interested in supporting the technology is welcome to participate. We are seeking different expertise and skills, ranging from development, operations, documentation, marketing, community organization and product management. The core principles of the Airship community can be found here.
You can join our community on any of the following places:
Visit our website
Join our mailing list.
irc.freenode.net IRC server to join the discussions:
Join our weekly meetings
Get in touch with us
Follow us on Twitter
See Airship in a bottle for details on how to install Airship inside a VM and take it for a test drive.
See Airship Treasuremap for sample manifests that are CI/CD tested on real baremetal infrastructure you can use as a starting place for your own environments.
See the contributing guide for details on how to contribute to the project.
The Airship project is governed according to the “four opens”, which are open source, open design, open development, and open community. Technical decisions are made by technical contributors and a representative Technical Committee. The community is committed to diversity, openness, and encouraging new contributors and leaders to rise up.
For code contributors, there are currently two roles relevant to project governance:
A Contributor to the Airship project is someone who has had changes merged within the last 12 months. Contributors are eligible to vote in the Technical Committee elections. Contributors do not have merging rights on Airship repositories.
A Core Reviewer has the ability to merge code into the Airship project. Core Reviewers are active Contributors and participants in the projects. Any Core Reviewer can nominate someone to be a Core Reviewer for a particular Airship project, but the nominee must be approved by the existing Core Reviewers for that project. Core Reviewers are added on an “as needed” basis determined by the core team or Technical Committee group.
There are two committees responsible for helping to guide Airship projects:
The Technical Committee is responsible to meet and ensure Airship projects are adhering to the projects core principles, promote standardization, define and organize the Airship versioning and release process. It is comprised of 5 members, who are elected by an election process.
In the event of a dispute on topics falling strictly in the domain of Technical Committee responsibilities, the Technical Committee will be responsible for abritrating. For a resolution to be confirmed, a super majority (2/3) vote (rounded up to nearest whole number) of the Technical Committee is required.
Technical Committee elections take place in June (5 seats available). Anyone who has demonstrated a commitment to Airship (community building, communications, or had code merged to the Airship project repositories) within the last 12 months is eligible to run for the Technical Committee. Anyone who is a Contributor (as defined above) before the election will be eligible to vote for the TC candidates. There are no term limits, but in order to encourage diversity, no more than 2 of the 5 seats can be filled by any one organization. The Technical Committee will meet regularly in an open forum with times and locations published in community channels.
The exact size and model for the Technical Committee may evolve over time based on the needs and growth of the project, but the governing body will always be committed to openness, diversity and the principle that technical contributors make technical decisions.
Elections take place each June. The candidates and elected members to the Technical Committee can be found at airship-election.
The Working Committee is intended to help influence the project strategy, help arbitrate when there is a disagreement between Core Reviewers within a single project or between Airship projects, define the project core principles, perform marketing and communications, and finally help provide product management as well as ecosystem support. The Working Committee should be the group that can speak externally on behalf of Airship and to this end the Working Committee may appoint a Lead at their own discretion and using their own process to help be a singular external voice of the project. Representatives are expected to be active contributors who are committed to the health and success of the project. It is comprised of 5 members, who are elected by an election process.
In the event of a dispute on topics falling strictly in the domain of Working Committee responsibilities, the Working Committee will be responsible for abritrating. For a resolution to be confirmed, a super majority (2/3) vote (rounded up to nearest whole number) of the Working Committee is required.
Working Committee elections take place in August (5 seats available). Anyone who is a Contributor (as defined above) before the election will be eligible to run. Core Reviewers of projects will be eligible to vote. There are no term limits, but in order to encourage diversity, no more than 2 of the 5 seats can be filled by any one organization. The Working Committee will meet regularly in an open forum with times and locations published in community channels.
The exact size and model for the Working Committee may evolve over time based on the needs and growth of the project, but the governing body will always be committed to openness, diversity and the principle that technical contributors make technical decisions. There is opportunity for more contributors to get involved in various sub-teams working on specific topics, such as product management or conformance.
Elections take place each August. The candidates and elected members to the Working Committee can be found at airship-election.
Both the Technical and Working Committees follow a rule that no more than 2 seats per committee can be filled by individuals from the same employer. This rule applies to all elections.
The grandfather clause is to recognize that an elected committee member may have a change of employer during their term. In those circumstances the committee member will be allowed to serve the remainder of their elected term regardless of employer representation on the committee. The established rules will be used when seeking re-election.
All elections for committee positions in Airship shall follow standard OpenStack procedures and methods. Ballots will be distributed to each Contributor’s (or in the case of the Working Committee, Core’s) primary email address. Elections will be held using CIVS and a Condorcet algorithm (Schulze/Beatpath/CSSD variant). Any tie will be broken using Governance Tie Breaking. In the event that a candidate runs unopposed for a position, the TSC can waive a formal vote. Membership in the Foundation itself is not a requirement for holding an elected position though it is preferred. Elections are appointing an individual to a position in the project, not a company or organization. Individuals are expected to continue to support the project in the event of career changes unless they notify the project that they are resigning their position.
Each committee is responsible for organizing, running, and reporting the results of each election for the opposite committee. For example:
Airship elections use a Condorcet algorithm (Schulze/Beatpath/CSSD variant) to determine winners of an election. In exceedingly rare cases, it is possible to have a tie for the last seat of a committee. In such an event, that tie will be broken by the committee that is responsible for organizing, running, and reporting the results of the election by a majority vote.
In the event that a committee seat is vacated before the end of a term a special election will be held to fill that seat. Special elections will begin the first week of the month following a vacancy in a seat. The same format and rules applied to the standard election process as defined above will also apply to the special election. The term of an individual elected via a special election will be the remainder of the original seat’s term. Special elections will not be held in the same month as a standard election, instead the vacant seat will be filled via a standard election process.
The project’s formal governance document is maintained in the airship-governance repository. Changes to the document can be proposed by any project Contributor but would need to be ratified by the Working Committee with a super-majority (2/3rds) vote. The Working Committee should strive for consensus for any change to the project’s formal governance.
Each of the Technical and Working Committees are expected to arbitrate disputes pertaining to topics that are related strictly to those covered by the respective committees responsibilities. If a dispute arises that is unclear on ownership of the topic, or spans multiple topics, both the Technical and Working Committees will be responsible for working together for a resolution. The resolution will require a super majority vote (2/3) of all committee members (rounded up to nearest whole number).