airship/governance
Code Issues Proposed changes

Merge the Working and Technical Committees

Browse Source 
This merges the Working and Technical Committees into a single body
with 9 members, retaining the name "Technical Committee".  The new
TC has the responsibilities of both previous groups, and splits
the difference in election timing with an election that falls in July.

Feedback is welcome on this governance change. The current Working
Committee will ultimately vote, with four members' +2s required
to commit the change.

Change-Id: I4f000e3eef45a46ad09cd30f12868b3825e729f2
This commit is contained in:
Matt McEuen 2021-06-07 15:40:38 -05:00
parent 8601fa9be7
commit de03ba148d
1 changed files with 21 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
README.md
View File

@ -14,10 +14,7 @@
* [Contributor](#contributor)
* [Core Reviewer](#core-reviewer)
* [Committees](#committees)
* [Technical Committee](#architecture-committee)
* [Working Committee](#working-committee)
* [Technical Committee](#technical-committee)
* [Grandfather Clause](#grandfather-clause)
* [Committee Elections](#committee-elections)
@ -91,65 +88,38 @@ participants in the projects. Any Core Reviewer can nominate someone to be a Co
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.
### Committees
### Technical Committee
There are two committees responsible for helping to guide Airship projects:
#### Technical Committee
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,
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 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](https://opendev.org/airship/election).
#### Working Committee
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
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 Working Committee may evolve over time based on the needs and growth of the project, but
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.
Elections take place each August. The candidates and elected members to the Working Committee can be
The candidates and elected members to the Technical Committee can be
found at [airship-election](https://opendev.org/airship/election).
### Grandfather Clause
Both the Technical and Working Committees follow a rule that no more than 2 seats per committee can be
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.
@ -159,7 +129,7 @@ employer representation on the committee. The established rules will be used whe
### Committee Elections
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
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
@ -167,10 +137,9 @@ appointing an individual to a position in the project, not a company or organiza
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:
- The Technical Committee is responsible for organizing and running the Working Committee elections.
- The Working Committee is responsible for organizing and running the Technical Committee elections.
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
@ -191,13 +160,6 @@ same month as a standard election, instead the vacant seat will be filled via a
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
Working Committee with a super-majority (2/3rds) vote. The Working Committee should strive for consensus for any change
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.
### Disputes Across Committees
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).