Open Stack

If our goal is improving the quality of code and cross project communication, then removing PTLs from the TC seems antithetical to that goal. 

Devin 


On Monday, February 20, 2012 at 12:53 PM, Anne Gentle wrote:

> Hi Thierry -
> 
> If the stated goal is efficiency, is that in running the meetings or
> in gathering consensus? Or perhaps you mean efficiency in setting up
> the organization itself?
> 
> As a potential member of the TC based on the criteria for both the PTL
> being on the C and the projects that have TLs, I'd like some time to
> hear more about the stated efficiency gains before evaluating your
> proposal further.
> 
> Thanks,
> Anne
> 
> On Mon, Feb 20, 2012 at 10:46 AM, Thierry Carrez <thierry at openstack.org (mailto:thierry at openstack.org)> 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.
> > 
> > --
> > Thierry Carrez (ttx)
> > Release Manager, OpenStack
> > _______________________________________________
> > Foundation mailing list
> > Foundation at lists.openstack.org (mailto:Foundation at lists.openstack.org)
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
> > 
> 
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org (mailto:Foundation at lists.openstack.org)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20120220/e7af852b/attachment-0003.html>