Jump to: navigation, search


< Governance‎ | Foundation
Revision as of 19:11, 14 September 2012 by ThierryCarrez (talk)

OpenStack Technical Committee charter


The Technical Committee ("TC") is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has oversight over all OpenStack projects.

OpenStack projects

Official OpenStack projects come in different flavors:

  • OpenStack Core projects are the main product of the OpenStack developer community. All Core projects are released in a coordinated fashion periodically. Projects candidate to Core status should go enter Incubated status first. Projects need to be elevated to Core status before the start of a release cycle so that they can undergo a full cycle before final release. The TC recommends projects for Core status addition, combination, split or deletion to the Board of Directors, which has sole authority to approve them.
  • OpenStack Incubated projects are projects which want to become Core projects one day, or want to be merged with an existing Core project. They remain in Incubated status until they are mature enough to apply for Core status. The TC decides which projects are in Incubated status.
  • OpenStack Library projects are libraries directly or indirectly used by Core projects, including Python client libraries for each core project, and the openstack-common library. The TC decides which projects are official Library projects.
  • OpenStack Gating projects are components used in the continuous integration gating that protects our Core project branches from regressive changes. This includes deployment tools and integration test suites used in the validation. The TC decides which projects are official Gating projects.
  • OpenStack Supporting projects are extra projects that are necessary in the production of OpenStack Core projects. This includes documentation and infrastructure-related projects. The TC decides which projects are official Supporting projects.

The list of official projects can be found here.

Project Technical Leads (PTLs)

Project Technical Leads ("PTL") manage day-to-day operations, drive the project goals and resolve technical disputes within their project. Each project community should be self-managing by the contributors, and all disputes should be resolved through active debate and discussion by the community itself. However if a given debate cannot be clearly resolved, the PTL can decide the outcome. Although the TC is generally not involved in project-internal decisions, it still has oversight over project-specific decisions, especially when they affect other projects or go contrary to general OpenStack project goals.

Each OpenStack Core project elects one PTL. Exceptionally, some Library projects may be granted the right to elect a PTL as well (this is decided by the TC when the project is first accepted). Other project types can select or elect a project lead, but those won't be considered a "PTL" under this charter.

TC Members

The TC is composed of the elected PTLs (as defined above), plus 5 directly-elected members. It is partially renewed using elections every 6 months. All TC members must be OpenStack Foundation individual members. You can cumulate any other role, including Foundation Director, with a TC seat.

TC Chair

After each election, the TC proposes one of its members to act as the TC chair. In case of multiple candidates, it may use a single-winner election method to decide the result (see below). The Board of Directors has the authority to approve the TC chair and shall approve the proposition, unless otherwise justified by its bylaws. The TC chair is responsible for making sure meetings are held according to the rules described below, and for communicating the decisions taken during those meetings to the Board of Directors and the OpenStack community at large. It may be revoked under the conditions described in the Foundation bylaws.


TC meetings happen publicly, weekly on IRC. The meeting time should be decided among TC members after each election. If there isn't consensus on a meeting time, the option of rotating the time weekly should be explored. The TC maintains an open agenda on the wiki. A TC meeting is automatically called if anything is posted to that wiki by one of its members at least one day before the meeting time. For a meeting to be actually held, at least half of the members need to be present (rounded up: in a board with 8PTLs+5 that means a minimum of 7 people present). Non-members affected by a given discussion are strongly encouraged to participate to the meeting and voice their opinion, though only TC members can ultimately cast a vote.


Before being put to a vote, motions presented before the TC should be discussed publicly on the development mailing-list for a minimum of 4 business days to give a chance to the wider community to express their opinion. TC members can vote positively, negatively, or abstain. Decisions need more positive votes than negative votes (ties mean the motion is rejected), and a minimum of positive votes of at least one third of the total number of TC members (rounded up: in a board with 8PTLs+5 that means a minimum of 5 approvers).


When a TC member is unable to make a meeting, he is encouraged to name a proxy that will represent his opinion and vote on his behalf during the meeting. Only members really present at the meeting (directly or proxied) can vote. A TC member may proxy another member, but nobody should ever represent more than two votes.

Election for PTL seats

PTL seats are completely renewed every 6 months. A separate election is run for each core project and each library project that has its own PTL. These elections are collectively held 5 weeks prior to each design summit, with nominations due 6 weeks prior to the summit and elections held open for no less than five business days.

Voters for PTL seats ("APC")

Voters for a given project PTL election are the active project contributor for the project ("APC"), which are a subset of the Foundation Individual Members. Individual Members who committed a change to a project over the last two 6-month release cycles are considered APC for that project.

Candidates for PTL seats

Any APC can propose his candidacy for the corresponding project PTL election. Sitting PTLs are eligible to run for re-election each cycle, provided they continue to meet the criteria.

Election for extra TC seats

The 5 extra TC seats are partially renewed every 6 months using staggered elections: 3 seats are renewed every Fall, and 2 seats are renewed every Spring. For this election we'll use a multiple-winner election system (see below). The election is held 3 weeks prior to each design summit, with nominations due 4 weeks prior to the summit and elections held open for no less than five business days.

Voters for extra TC seats ("ATC")

The extra TC seats are elected by the Active Technical Contributors ("ATC"), which are a subset of the Foundation Individual Members. Individual Members who committed a change to any of the official OpenStack projects (as defined above) over the last two 6-month release cycles are automatically considered ATC. Specific contributors who did not have a change recently accepted in one of the OpenStack projects but nevertheless feel their contribution to the OpenStack project is technical in nature (bug triagers, technical documentation writers...) can exceptionally apply for ATC either by sending an email to the TC chair or by being nominated by an existing ATC via email to the TC chair. Final approval on the exception is decided by the TC itself, and is valid one year (two elections).

Candidates for extra TC seats

Any Foundation individual member can propose his candidacy for an available, directly-elected TC seat.

Initial committee

The current PPB will serve as TC until the first elections in September 2012. At that point, the two PPB members who still had 6 months to serve get a 6-month seat. Normal PTL elections are held to determine the PTL seats (valid for 6 months), and a normal staggered election (see above) is held to determine the remaining 3 extra seats (valid for one year).

Election systems

For single-winner elections, a Condorcet system shall be used.

For multiple-winner elections, a Condorcet or a STV system should be used.


Amendments to this Technical Committee charter shall be proposed in a special motion, which needs to be approved by the affirmative vote of at least two-thirds of the total number of TC members (rounded up: in a board with 8PTLs+5 that means a minimum of 9 approvers).