DRAFT FOR COMMENTS
The Technical Committee (TC) is tasked with providing the technical leadership for the OpenStack project. It enforces OpenStack core projects ideals (Openness, Transparency, Commonality, Integration, Respect of release deadlines, Facilitation of downstream distribution ), decides on issues affecting multiple projects, and generally forms an ultimate appeals board for technical decisions.
The TC is composed of 9 elected members. You can cumulate other roles (Project technical lead, Foundation board member...) with a TC seat. Note that Project technical leads do not get appointed seats to the TC: they should run for election.
TC meetings happen publicly, weekly on IRC. The TC maintains an open agenda on the wiki. A TC meeting is called if anything is posted to that wiki at least one day before the meeting time. For a meeting to be actually held, at least two thirds of the members need to be present (6 people). Non-members, in particular unelected PTLs or release manager, are more than welcome to participate to the meeting and voice their opinion, though they can't ultimately vote.
Before being put to a vote, motions presented before the TC should be discussed publicly on the mailing-list for a minimum of 5 days to give a chance to the wider community to express their opinion. Members can vote positively, negatively, or abstain. Decisions need more positive votes than negative votes, and a minimum of 3 positive votes.
The TC is renewed every 6 months using staggered elections: 5 seats are renewed every 6 months. People ranking 1st to 4th get elected for a one-year term. The 5th person gets elected for a 6-month term. People ranking after 6th are retained as potential substitute members (see "Revocation").
Technical members of the Foundation, as determined by the Technical membership committee, are able to participate in this election.
TC members are expected to be available and participate to weekly meetings. If a particular TC member misses 3 of the last 5 called meetings, he should automatically be revoked. He would be replaced by the top substitute (person ranking 6th and after in previous election). Even when replacing someone elected for 1 year, the substitute inherits from the shortest term; the highest ranking elected person inherits from the potential longer term.
To initially populate the TC, all 9 seats are up for election. People ranking 1st to 4th get elected for one year. People ranking 5th to 9th get elected for 6 months.
-  From http://wiki.openstack.org/ProjectTypes
-  The idea is that we want to de-correlate the number of PTLs (and the relative importance of their projects) from the TC composition, to reduce committee bloat and be more fair. Influential PTLs from large projects should get elected anyway.
-  Could be the openstack ML or a specific TC ML. The idea is to avoid surprising the community with a decision, and avoid the usual kabbale critics.
-  More on this later.
-  Example: Fx got elected in Fall 2012, while Sx got elected in Spring 2013. Current board as F1, F2, F3, F4, S5 elected until Fall 2013, and S1, S2, S3, S4 elected until Spring 2014. S2 is a slacker is is revoked. S6 is called as a substitute. He should not get a longer term than S5 though. So S5 inherits from the 1-year-long term and S6 from the 6-month-long term. Resulting board is: F1, F2, F3, F4, S6 elected until Fall 2013, and S1, S3, S4, S5 elected until Spring 2014.
-  We may want to re-align elections with release cycles. Example: If TC is created in July 2012, we may want to align elections with the next design summits, so the first term only be 2 months or 8 months.