Initial structure and reference documents
Create initial repository structure and add the following reference documents: - charter: The authoritative copy of the TC charter (copied from wiki) - members: Current TC members with election expiration - programs.yaml: List of official programs including PTLs, codenames, mission statements... - extra-atcs: List of people being granted an ATC exception Change-Id: Ia2df3bf0808af8cfa306092442160d5ecb14dfb0
This commit is contained in:
Thierry Carrez
parent
18f1aa6500
commit
be9fc6e412
|
|
@ -0,0 +1,15 @@
|
|||
This repository contains OpenStack Technical Committee reference documents
|
||||
and tracks official resolutions voted by the committee.
|
||||
|
||||
Directory structure:
|
||||
|
||||
reference/
|
||||
Reference documents which need to be revised over time.
|
||||
Some motions will just directly result in reference doc changes.
|
||||
resolutions/
|
||||
When the motion does not result in a change in a reference doc, it
|
||||
can be expressed as a resolution.
|
||||
Those must be named YYYYMMDD-short-name with YYYYMMDD being the
|
||||
proposal date in order to allow basic sorting.
|
||||
|
||||
See https://wiki.openstack.org/wiki/Governance/TechnicalCommittee for details.
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
= OpenStack Technical Committee charter =
|
||||
|
||||
=== Mission ===
|
||||
|
||||
The Technical Committee ("TC") is tasked with providing the technical leadership for OpenStack as a whole (all official programs, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality...), decides on issues affecting multiple programs, forms an ultimate appeals board for technical decisions, and generally has oversight over all the OpenStack project.
|
||||
|
||||
=== OpenStack Programs ===
|
||||
|
||||
OpenStack "Programs" are efforts which are essential to the completion of the OpenStack project mission, which is ''to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable''. Programs can create any code repository and produce any deliverable they deem necessary to achieve their goals.
|
||||
|
||||
Programs are placed under the oversight of the TC, and contributing to one of their code repositories grants you ATC status (see below). Current efforts or teams which want to be recognized as a Program should file a motion to the TC. The TC has ultimate authority over which programs are accepted or declined.
|
||||
|
||||
The current, official list of programs can be found [[Programs|here]].
|
||||
|
||||
=== Program Leads ===
|
||||
|
||||
Program leads ("PTLs") manage day-to-day operations, drive the program goals and resolve technical disputes within their program. Each program 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 program-internal decisions, it still has oversight over program-specific decisions, especially when they affect other programs or go contrary to general OpenStack project goals.
|
||||
|
||||
=== TC Members ===
|
||||
|
||||
The TC is composed of 13 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.
|
||||
|
||||
=== Meeting ===
|
||||
|
||||
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 13-member committee 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.
|
||||
|
||||
=== Motions ===
|
||||
|
||||
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 13-member committee that means a minimum of 5 approvers).
|
||||
|
||||
=== Proxying ===
|
||||
|
||||
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 program. 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 program PTL election are the active program contributors ("APC"), which are a subset of the Foundation Individual Members. Individual Members who committed a change to a repository of a program over the last two 6-month release cycles are considered APC for that program.
|
||||
|
||||
=== Candidates for PTL seats ===
|
||||
|
||||
Any APC can propose his candidacy for the corresponding program PTL election. Sitting PTLs are eligible to run for re-election each cycle, provided they continue to meet the criteria.
|
||||
|
||||
=== Election for TC seats ===
|
||||
|
||||
The 13 TC seats are partially renewed every 6 months using staggered elections: 6 seats are renewed every Fall, and 7 seats are renewed every Spring. Seats are valid for one-year terms. 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 TC seats ("ATC") ===
|
||||
|
||||
The 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 a repository under ''any'' of the official OpenStack programs (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 programs 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 TC seats ===
|
||||
|
||||
Any Foundation individual member can propose his candidacy for an available, directly-elected TC seat.
|
||||
|
||||
=== Initial committee ===
|
||||
|
||||
The current TC will serve as TC until the elections in Fall 2013. At that point, the two TC members who still had 6 months to serve get a 6-month seat, and an election is run to determine the 11 other members. Candidates ranking 1st to 6th would get one-year seats, and candidates ranking 7th to 11th would get 6-month seats. Spring 2014 elections should see the normal renewal of 7 seats.
|
||||
|
||||
=== 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.
|
||||
|
||||
=== Amendment ===
|
||||
|
||||
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 13-member committee that means a minimum of 9 approvers).
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# Full name (email) [expires in]
|
||||
Jaromir Coufal (jcoufal@redhat.com) [September 2014]
|
||||
Liz Blanchard (lsurette@redhat.com) [September 2014]
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
# Full name (IRC nickname) [expires in]
|
||||
Russell Bryant (russellb) [September 2013]
|
||||
Thierry Carrez (ttx) [March 2014]
|
||||
Julien Danjou (jd__) [September 2013]
|
||||
John Dickinson (notmyname) [September 2013]
|
||||
Anne Gentle (annegentle) [September 2013]
|
||||
John Griffith (jgriffith) [September 2013]
|
||||
Steven Hardy (shardy) [September 2013]
|
||||
Gabriel Hurley (gabrielhurley) [September 2013]
|
||||
Vish Ishaya (vishy) [March 2014]
|
||||
Dolph Mathews (dolphm) [September 2013]
|
||||
Mark McClain (markmcclain) [September 2013]
|
||||
Mark McLoughlin (markmc) [September 2013]
|
||||
Michael Still (mikal) [September 2013]
|
||||
Monty Taylor (mordred) [September 2013]
|
||||
Mark Washenberger (markwash) [September 2013]
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
Compute:
|
||||
codename: Nova
|
||||
ptl: Russell Bryant (russellb)
|
||||
url: https://wiki.openstack.org/wiki/Nova
|
||||
|
||||
Object Storage:
|
||||
codename: Swift
|
||||
ptl: John Dickinson (notmyname)
|
||||
url: https://wiki.openstack.org/wiki/Swift
|
||||
|
||||
Image Service:
|
||||
codename: Glance
|
||||
ptl: Mark Washenberger (markwash)
|
||||
url: https://wiki.openstack.org/wiki/Glance
|
||||
|
||||
Identity:
|
||||
codename: Keystone
|
||||
ptl: Dolph Matthews (dolphm)
|
||||
url: https://wiki.openstack.org/wiki/Keystone
|
||||
|
||||
Dashboard:
|
||||
codename: Horizon
|
||||
ptl: Gabriel Hurley (gabriel-hurley)
|
||||
url: https://wiki.openstack.org/wiki/Horizon
|
||||
|
||||
Networking:
|
||||
codename: Neutron
|
||||
ptl: Mark McClain (markmcclain)
|
||||
url: https://wiki.openstack.org/wiki/Neutron
|
||||
|
||||
Block Storage:
|
||||
codename: Cinder
|
||||
ptl: John Griffith (jgriffith)
|
||||
url: https://wiki.openstack.org/wiki/Cinder
|
||||
|
||||
Metering/Monitoring:
|
||||
codename: Ceilometer
|
||||
ptl : Julien Danjou (jd__)
|
||||
url: https://wiki.openstack.org/wiki/Ceilometer
|
||||
|
||||
Orchestration:
|
||||
codename: Heat
|
||||
ptl: Steven Hardy (shardy)
|
||||
url: https://wiki.openstack.org/wiki/Heat
|
||||
|
||||
Database Service:
|
||||
codename: Trove
|
||||
ptl: Michael Basnight (hub_cap)
|
||||
mission:
|
||||
To provide scalable and reliable Cloud Database as a Service
|
||||
functionality for both relational and non-relational database
|
||||
engines, and to continue to improve its fully-featured and
|
||||
extensible open source framework.
|
||||
url: https://wiki.openstack.org/wiki/Trove
|
||||
|
||||
Bare metal:
|
||||
codename: Ironic
|
||||
ptl: Devananda van der Veen (devananda)
|
||||
mission:
|
||||
To produce an OpenStack service and associated python libraries capable
|
||||
of managing and provisioning physical machines, and to do this in a
|
||||
security-aware and fault-tolerant manner.
|
||||
url: https://wiki.openstack.org/wiki/Ironic
|
||||
|
||||
Common Libraries:
|
||||
codename: Oslo
|
||||
ptl: Mark McLoughlin (markmc)
|
||||
mission:
|
||||
To produce a set of python libraries containing code shared by OpenStack
|
||||
projects. The APIs provided by these libraries should be high quality,
|
||||
stable, consistent, documented and generally applicable.
|
||||
url: https://wiki.openstack.org/wiki/Oslo
|
||||
|
||||
Infrastructure:
|
||||
ptl: Monty Taylor (mtaylor)
|
||||
url: https://wiki.openstack.org/wiki/Infrastructure
|
||||
|
||||
Documentation:
|
||||
ptl: Anne Gentle (annegentle)
|
||||
mission:
|
||||
Provide documentation for core OpenStack projects to promote OpenStack.
|
||||
Develop and maintain tools and processes to ensure quality, accurate
|
||||
documentation. Treat documentation like OpenStack code.
|
||||
url: https://wiki.openstack.org/wiki/Documentation
|
||||
|
||||
Quality Assurance:
|
||||
codename: QA
|
||||
ptl: Sean Dague (sdague)
|
||||
mission:
|
||||
Develop, maintain, and initiate tools and plans to ensure the upstream
|
||||
stability and quality of OpenStack, and its release readiness at any
|
||||
point during the release cycle.
|
||||
url: https://wiki.openstack.org/wiki/QA
|
||||
|
||||
Deployment:
|
||||
codename: TripleO
|
||||
ptl: Robert Collins (lifeless)
|
||||
mission:
|
||||
Develop and maintain tooling and infrastructure able to deploy OpenStack
|
||||
in production, using OpenStack itself wherever possible.
|
||||
url: https://wiki.openstack.org/wiki/TripleO
|
||||
|
||||
Devstack:
|
||||
ptl: Dean Troyer (dtroyer)
|
||||
mission:
|
||||
To provide an installation of OpenStack from git repository master, or
|
||||
specific branches, suitable for development and operational testing.
|
||||
It also attempts to document the process and provide examples of command
|
||||
line usage.
|
||||
url: https://wiki.openstack.org/wiki/DevStack
|
||||
|
||||
Release cycle management:
|
||||
ptl: Thierry Carrez (ttx)
|
||||
mission:
|
||||
To organize the release cycle and the work necessary to produce
|
||||
coordinated releases of the integrated components of OpenStack.
|
||||
To collect bugfix backports and produce stable point releases for the
|
||||
previously-released branch. To coordinate the publication of security
|
||||
patches and advisories (OSSA) for security-supported branches.
|
||||
url: https://wiki.openstack.org/wiki/Release_Cycle_Management
|
||||
|
||||
Queue service:
|
||||
codename: Marconi
|
||||
ptl: Kurt Griffiths (kgriffs)
|
||||
mission:
|
||||
To produce an OpenStack message queueing API and service that affords
|
||||
a variety of distributed application messaging patterns in an efficient,
|
||||
scalable and highly-available manner, and to create and maintain
|
||||
associated Python libraries and documentation.
|
||||
url: https://wiki.openstack.org/wiki/Marconi
|
||||
|
||||
Data processing service:
|
||||
codename: Savanna
|
||||
ptl: Sergey Lukjanov (SergeyLukjanov)
|
||||
url: https://wiki.openstack.org/wiki/Savanna
|
||||
Loading…
Reference in New Issue