Open Stack

Indeed, nice work Thierry.

The one thing I'd say is that it would benefit from elaborating on the
responsibilities of the TC. Perhaps we all feel we have a rough idea
what falls under the TC, but it'd be nice to see those enumerated.

As a simple example - release management is listed as part of the
"project management" role of the foundation. Does the foundation board
delegate to the TC decisions around the release schedule, go/no go on
release candidates, etc.?

Mark.

On Mon, 2012-02-20 at 12:10 -0500, Jay Pipes wrote:
> This is a well-written proposal, and I can't find anything that I would 
> disagree with.
> 
> +1
> 
> -jay
> 
> On 02/20/2012 11:46 AM, Thierry Carrez wrote:
> > Hi everyone,
> >
> > 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
> > [0]), 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[1].
> >
> > == 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 ultimately vote.
> >
> > == Motions ==
> >
> > Before being put to a vote, motions presented before the TC should be
> > discussed publicly on the mailing-list[2] 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[3], 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[4].
> >
> > == 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[5].
> >
> >
> > [0] From http://wiki.openstack.org/ProjectTypes
> >
> > [1] 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.
> >
> > [2] 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.
> >
> > [3] More on this later.
> >
> > [4] 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.
> >
> > [5] 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.
> >
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation