[OpenStack Foundation] Technical committee

Andrew Clay Shafer acs at parvuscaptus.com
Tue Feb 21 04:29:50 UTC 2012


>
>
> == 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.
>

I'm unclear on the responsibilities and the mandate of the TC under the
draft structure, but this is nice first pass.

I feel the word 'Quality' is conspicuously missing from the mission
statement.

I also personally think release deadlines should not be an OpenStack
project ideal and certainly not one to be prioritized over quality.


> == 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].
>

Seems reasonable, though depending on the mandate, rights and
responsibilities of the TC, I have mixed feelings about the PTL
involvement, particularly if they are going to veto what they don't like
anyway. I agree with the motive to avoid committee bloat 100%. Actually,
OpenStack should probably revisit what it means to be a project and PTL in
the greater context.

== 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.
>

Also, I know language and timezones play a role, but I think there are some
benefits to hearing people's voices.

IRC is reasonable for most weeks, but it seems like it might be worth
trying to meet face to face once a quarter and maybe have some mechanism
where some motions get discussed townhall style over skype or google+.


> == 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.
>

3 votes seems low on a committee with 9, but assuming every member is
required for every vote, it's probably not an issue.

what happens with 3 positive, 3 negative and 3 abstentions?


> == 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").
>

So 8 of 9 seats are for 1 year?

Who is eligible for this position?

Does it make sense to have every representative on this committee be from a
general pool of eligible candidates?

I propose there might be benefit to basing eligibility for the committee
based on representative constituencies, at least for some subset of the
seats.

== Voters ==
>
> Technical members of the Foundation, as determined by the Technical
> membership committee[3], are able to participate in this election.
>

Reasonable, adding that there might be some special eligibility
requirements for some seats.


> == 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].
>

Seems like there would be other ways to lose the seat and I think 3 of 5
meetings seems arbitrary. Can a meeting be attended by proxy? Can a member
write in the vote on an issue? Assuming people have other roles and
responsibilities, everyone is a double booked meeting, an illness and an
accident away from revocation. I think this should be tempered with some
understanding of circumstances and revocation should only apply in the case
where there is an obvious dereliction of duty or loss of capacity to
fulfill the role.



> == 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.


Thanks again for spending the time to put this together to frame a
discussion.

This is a good starting point.

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


More information about the Foundation mailing list