airship/governance
Code Issues Proposed changes

Implementing a simplified governance model

Browse Source 
This change implemets a simplified governance model to support
the community's current needs and operational needs. The proposed
changes are supported by the last active TC group.

Signed-off-by: Ildiko Vancsa <ildiko.vancsa@gmail.com>
Change-Id: Ife3efe183347a78cf50cde4bfe904562d24f0bc8
This commit is contained in:
Ildiko Vancsa 2022-09-27 18:10:51 -07:00
parent de03ba148d
commit e170795f5f
1 changed files with 9 additions and 83 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
README.md
View File

@ -72,94 +72,20 @@ which are open source, open design, open development, and open community. Techni
contributors and a representative Technical Committee. The community is committed to diversity, openness, and encouraging
new contributors and leaders to rise up.
### Developers
The Project Maintainers are tasked with providing technical stewardship to the open source project, enforcing project principles, and finally deciding on issues where there is no consensus in the community.
For code contributors, there are currently two roles relevant to project governance:
### Members
#### Contributor
The Project Maintainers group is composed of all individuals with approval rights on code reviews (Gerrit core reviewers, GitHub maintainers…).
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.
### Decision-making process
#### Core Reviewer
Motions are brought to the Project Maintainers through a discussion on the project discussion mailing-list. Consensus across active project maintainers is required for the motion to pass.
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.
Addition and removal of project maintainers
### Technical Committee
Addition of a project maintainer is done through a motion, requiring consensus. Removal of a project maintainer is done through a motion requiring consensus, but the examined individual is not taking part in the discussion.
The Technical Committee is intended to influence 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 Technical Committee is also responsible for ensuring that Airship projects are adhering to the project's core principles,
promote standardization, define and organize the Airship versioning and release process. It is comprised of 9 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 August (9 seats available). Anyone who is a Contributor (as defined above),
or who has demonstrated a commitment to Airship (community building, communications, or had code merged to the Airship
project repositories) within the last 12 months prior to the election, is eligible to run.
All Core Reviewers of projects will be eligible to vote. There are no term
limits, but in order to encourage diversity, no more than 3 of the 9 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. There is opportunity for more contributors to get involved in various sub-teams working on specific
topics, such as product management or conformance.
The candidates and elected members to the Technical Committee can be
found at [airship-election](https://opendev.org/airship/election).
### Grandfather Clause
The Technical Committee follows a rule that no more than 3 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.
### Committee Elections
All elections for committee positions in Airship shall follow standard OpenStack procedures and methods. Ballots will be
distributed to each Core Reviewer'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.
Technical Committee elections will be run by the current Committee membership. To maintain accountability, multiple
members of the Committee should help facilitate, and elections must be held in a fully transparent way, with anonymized
results being shared after the fact.
### Tie Breaking
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.
### Special Committee Elections
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.
### Governance Changes
The project’s formal governance document is maintained in the [airship-governance](https://opendev.org/airship/governance)
repository. Changes to the document can be proposed by any project Contributor but would need to be ratified by the
Technical Committee with a super-majority (2/3rds) vote. The Technical Committee should strive for consensus for any change
to the project’s formal governance.
### Amendment
Amendment of this charter is done through a motion, requiring consensus.