[OpenStack Foundation] Technical committee
Boris Renski Jr.
b at renski.com
Thu Feb 23 02:18:30 UTC 2012
Good job overall. I agree with 9 members and abandoning auto appointment of
I am a little fuzzy on the revocation clause and subsequently convoluted
system for electing a prospective substitute. Seems like a lot of
complication is injected with this clause with little meaningful outcome. Do
we know that non-participation in the meetings is likely to be such a
recurring issue (has it been in the past)?
I assume that 95% of the time substitute will not end up having to
substitute. Hence, are there any actionable responsibilities that this
substitute will have while he/she remains in inactive substitute role and
what is the chance that the substitute himself has become a non-viable
replacement candidate by the time he/she ends up having to substitute?
Perhaps, it would make sense to simplify and do away with the substitute and
revocation deal altogether? Everyone on the committee is getting
reconsidered every 6 to 12 months already; I think that is a powerful enough
mechanism to keep everyone motivated and ivolved as is. The idea is to start
with the simplest and most efficient structure. We can always make it more
From: foundation-bounces at lists.openstack.org
[mailto:foundation-bounces at lists.openstack.org] On Behalf Of Thierry Carrez
Sent: Monday, February 20, 2012 8:46 AM
To: foundation at lists.openstack.org
Subject: [OpenStack Foundation] Technical committee
The current structure document is quite open on the Technical committee
organization. Here are my proposals to keep it efficient... Please comment.
= Technical committee =
== Mission ==
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.
== Members ==
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.
== Meeting ==
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
== Motions ==
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.
== Election ==
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").
== Voters ==
Technical members of the Foundation, as determined by the Technical
membership committee, are able to participate in this election.
== Revocation ==
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.
== Initial election ==
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
 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.
Thierry Carrez (ttx)
Release Manager, OpenStack
Foundation mailing list
Foundation at lists.openstack.org
More information about the Foundation