Mailing List Archive

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

This is very well done. I completely agree. Would you propose we move
to this at the next election in a couple months?

Rick

On 02/20/2012 10: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.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20120220/87aef4f8/attachment.pgp>

Rick Clark wrote:
> This is very well done. I completely agree. Would you propose we
> move to this at the next election in a couple months?

The next election is run in a few weeks, so we may run out of time:

http://www.openstack.org/blog/2012/02/openstack-governance-elections-spring-2012/

I guess if the current PPB agrees, we could switch to that -- meaning
we would keep jk0, ewanmellor and pvo (elected until Fall 2012), elect
6 people instead of two, then have the first 4 elected until Spring
2013 and the last 2 elected until Fall 2012.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

It seems like the best thing would be to start transitioning to this new
structure, since it is likely to happen anyway, and it would give the
project some stability over the next several months while the foundation
is formalized.

Perhaps people with appointed seats and the PTL's can facilitate
transition towards the TC by putting their seat up for election if they
want to. The of course could run for their seat.

If enough would do it, it would give us a majority of the TC that would
stay the same, rather than having a massive change after the foundation
forms.


Rick



On 02/20/2012 11:34 AM, Thierry Carrez wrote:
> Rick Clark wrote:
>> This is very well done. I completely agree. Would you propose we
>> move to this at the next election in a couple months?
>
> The next election is run in a few weeks, so we may run out of time:
>
> http://www.openstack.org/blog/2012/02/openstack-governance-elections-spring-2012/
>
> I guess if the current PPB agrees, we could switch to that -- meaning
> we would keep jk0, ewanmellor and pvo (elected until Fall 2012), elect
> 6 people instead of two, then have the first 4 elected until Spring
> 2013 and the last 2 elected until Fall 2012.
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20120220/6fa07a73/attachment.pgp>

Hey Thierry,

I believe it is worth asserting that potential members of the Technical Committee *must* have made a commit to at least one of the OpenStack core projects, and need to have a signed a contributor's agreement. I believe this is already expected, and likely just semantics, but it's worth making it clear.

I get that we want to drop PTL's from the committee to deal with bloat (especially as the number of core projects is increasing, making the group unwieldy in size), but I think we do want a linkage at least between being a core committers and being a Technical Committee member. So that point, I propose that the committee members should all be a core contributor on one of the core[0] OpenStack projects. I'm proposing this given the committee is intended to be a cross-project technical decision point and technical appeals board. (Related, I believe the Docs, Tempest and OpenStack-CI projects should both be moving to become "core projects".

- joe

On Feb 20, 2012, at 8: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.
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>

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

On Mon, 2012-02-20 at 17:46 +0100, Thierry Carrez wrote:
> == 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.

You'll probably have very little sympathy for this given that you manage
to chair the OpenStack team meeting at 10pm your time every week,
but ... :)

Timezones are a killer here; if folks absolutely have to attend the
meetings, we'd need to rotate the time of the meetings to line up with
different TZs.

Cheers,
Mark.

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> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

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-0001.html>

2012/2/20 Devin Carlen <devin.carlen at gmail.com>:
> If our goal is improving the quality of code and cross project
> communication, then removing PTLs from the TC seems antithetical to
> that goal.

I'd be deeply surprised if many or even most of the seats were not
occupied by PTL's even if their seats were not automatic.

There are a number of reasons why PTL's should not automatically be
members of the TC. My favourite one, though, is that I don't want to end
up in a situation where we refrain from splitting up a project because
it would cause the TC to bloat.

--
Soren Hansen ? ? ? ? ? ? | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer ? ? ? ? | http://www.ubuntu.com/
OpenStack Developer ? ? ?| http://www.openstack.org/

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

Rick Clark wrote:
> It seems like the best thing would be to start transitioning to
> this new structure, since it is likely to happen anyway, and it
> would give the project some stability over the next several months
> while the foundation is formalized.
>
> Perhaps people with appointed seats and the PTL's can facilitate
> transition towards the TC by putting their seat up for election if
> they want to. The of course could run for their seat.
>
> If enough would do it, it would give us a majority of the TC that
> would stay the same, rather than having a massive change after the
> foundation forms.

Time is running a bit short, but that would definitely help to smooth
the future transition. A few gotchas:

1/ The current system is 4 appointed + 5 elected + n PTLs (currently
n=5 so 14 members). To drop to a static 9, the PTLs would have to
collectively accept to put their seat up to election... which is more
likely if most appointed seats are also transitioned to elected seats.

2/ We would still use the old corpus of voters (members of the
openstack Launchpad group) for this "transition" election.

I'll add a discussion item to the PPB meeting today.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

Joe Heck wrote:
> I believe it is worth asserting that potential members of the Technical Committee *must* have made a commit to at least one of the OpenStack core projects, and need to have a signed a contributor's agreement. I believe this is already expected, and likely just semantics, but it's worth making it clear.
>
> I get that we want to drop PTL's from the committee to deal with bloat (especially as the number of core projects is increasing, making the group unwieldy in size), but I think we do want a linkage at least between being a core committers and being a Technical Committee member. So that point, I propose that the committee members should all be a core contributor on one of the core[0] OpenStack projects. I'm proposing this given the committee is intended to be a cross-project technical decision point and technical appeals board.

I think it's a bit restrictive. I'd rather have "any technical member of
the Foundation" be a potential TC member. I.e. if you vote for the TC
composition, you should be able to run for a seat.

This goes a bit into the next discussion I wanted to have, which is
"what is a technical member of the foundation" (TM). Obviously all core
committers are TMs. But in order to not restrict "technical" to "code
contributor", my original idea was to have a Technical membership
committee (TMC) which would review the rare applications from people
contributing technically to OpenStack but who are not pure code
contributors.

We'll also have to discuss how to expire membership for those who are no
longer technically active in the project.

> (Related, I believe the Docs, Tempest and OpenStack-CI projects should both be moving to become "core projects".

To avoid overloading, I'd like to keep "core" terminology to mean
"having deliverables shipped as part of a given official OpenStack
release". We'll probably need a new category ("official projects") to
have projects that are technically part of "OpenStack" but not released
in the same way as the "OpenStack product".

Then I guess we could simplify TM to mean "relatively recent committers
for any official OpenStack project", and not need a TMC at all. But
wouldn't that exclude a few technical contributors ? Think bug triagers
? But maybe encouraging them to commit is simpler than forming a
bureaucratic TMC.

Thoughts ?

--
Thierry Carrez (ttx)
Release Manager, OpenStack

Mark McLoughlin wrote:
> On Mon, 2012-02-20 at 17:46 +0100, Thierry Carrez wrote:
>> == 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.
>
> You'll probably have very little sympathy for this given that you manage
> to chair the OpenStack team meeting at 10pm your time every week,
> but ... :)
>
> Timezones are a killer here; if folks absolutely have to attend the
> meetings, we'd need to rotate the time of the meetings to line up with
> different TZs.

Once elected, the TC should select a meeting time that works for all
members.... If that implies rotating meeting times to share the
inconvenience, so be it.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

Anne Gentle wrote:
> 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?

By efficiency I mean efficiency in running the meeting and keeping TC
members focused. I don't want the "PTL gets one seat" rule to result in
inefficient 20-members committees. I don't want the elected seats to
quickly become a minority just because we split projects into more
manageable parts.

But my ultimate goal is fairness. With all votes coming from elected
members, nobody gets "free seats". All votes have equal representative
power.

In the TC, I want the members to represent what "OpenStack" technically
is. When it comes to a vote, I don't want people to wear their company
hat (appointed seats) or their project hat (PTL seat). Everyone is
welcome in the discussion, but the final decision should be taken with
the good of "OpenStack" as a whole in mind.

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

I hope my other recent answers in the thread make it clearer. A
fully-elected TC with a manageable, static number of members removes
imbalance in the value of a vote. The PTLs are still very much part of
the discussion.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

Andrew Clay Shafer wrote:
> == 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.

These objectives comes from a current PPB document
(http://wiki.openstack.org/ProjectTypes). I agree that Quality should
definitely be in that list :)

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

The idea is to avoid a motion passing with 1 positive and 5 abstentions.
Maybe 4 is a more reasonable minimum.

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

You need more positive than negative votes... so that wouldn't pass.

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

Yes.

> Who is eligible for this position?

Any technical member of the foundation (more on that in my discussion
with Joe Heck in the thread)

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

Could you expand on that ?

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

In every organization I've been in, whenever revocation had to be
confirmed by a committee, there were no revocation happening. I want TC
members to be available for their role. If someone's agenda is too full
to commit to it, they should probably reconsider running for election.

Maybe having the ability to designate a proxy to substitute for you
would efficiently limit the arbitrary aspect. I don't think we should
allow write-in votes, since everything is in the discussion that happens
just before the vote.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

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


For example, some subset of seats might be designated as representing
'users' with different eligibility and voting requirements. That's the one
that seems obvious, but there are a few others that might be considered
beyond the 'Technical Community' at large.

In every organization I've been in, whenever revocation had to be
> confirmed by a committee, there were no revocation happening. I want TC
> members to be available for their role. If someone's agenda is too full
> to commit to it, they should probably reconsider running for election.
>
> Maybe having the ability to designate a proxy to substitute for you
> would efficiently limit the arbitrary aspect. I don't think we should
> allow write-in votes, since everything is in the discussion that happens
> just before the vote.


This seems to be an issue you have past frustration with. I can see there
being potential issues with politics depending on committees, but I'd like
something that provides sensible outcomes when good faith efforts are made.
If we allow temporary proxies, 3 of 5 seems more reasonable.

If motions have been discussed on the mailing list, I'm not sure how
'everything' would be in the discussion before a vote. There will certainly
be times when new information or interpretation will change a perspective,
but as often as not, positions will likely be researched and decided before
the meeting, whether write ins are allowed or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20120221/3590bb83/attachment.html>

Given that the election process is already underway and there is still
debate on this topic, I think it makes sense to complete the elections
under the current process and look to a future cycle to transition the
model.



On 2/20/12 11:34 AM, "Thierry Carrez" <thierry at openstack.org> wrote:

>Rick Clark wrote:
>> This is very well done. I completely agree. Would you propose we
>> move to this at the next election in a couple months?
>
>The next election is run in a few weeks, so we may run out of time:
>
>http://www.openstack.org/blog/2012/02/openstack-governance-elections-sprin
>g-2012/
>
>I guess if the current PPB agrees, we could switch to that -- meaning
>we would keep jk0, ewanmellor and pvo (elected until Fall 2012), elect
>6 people instead of two, then have the first 4 elected until Spring
>2013 and the last 2 elected until Fall 2012.
>
>--
>Thierry Carrez (ttx)
>Release Manager, OpenStack
>_______________________________________________
>Foundation mailing list
>Foundation at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Thierry,

Good job overall. I agree with 9 members and abandoning auto appointment of
PTLs.

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
complicated later.

-Boris



-----Original Message-----
From: foundation-bounces@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

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
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Boris Renski Jr. wrote:
> 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
> complicated later.

You're probably right. I may not be worth the hassle of tracking
presence and the complex substitution mechanism... after all someone
missing a meeting also loses his influence on the decisions. My concern
would be that so many people would go missing that quorums can't be met
to take any decision. But it may just be so hypothetical that it's not
worth the resulting complexity.

What do other people think ? Would adding the ability to name a
temporary substitute be sufficient ?

--
Thierry Carrez (ttx)
Release Manager, OpenStack

Thierry Carrez wrote:
> The current structure document is quite open on the Technical committee
> organization. Here are my proposals to keep it efficient... Please comment.
> [...]

For easier revision control, I copied this initial draft to the wiki at:
http://wiki.openstack.org/Governance/Foundation/TechnicalCommittee

I'll soon integrate the feedback you all gave me in future revisions of
this same wiki page, in particular:

* Precise election rule (CIVS Schulze + Proportional Representation)
* Drop strict revocation rule
* Allow proxies to represent in case of member absence
* Add "Quality"
* Elaborate on "Technical Members" of the foundation

--
Thierry Carrez (ttx)
Release Manager, OpenStack

On Feb 23, 2012, at 3:04 AM, Thierry Carrez wrote:
>
> You're probably right. I may not be worth the hassle of tracking
> presence and the complex substitution mechanism... after all someone
> missing a meeting also loses his influence on the decisions. My concern
> would be that so many people would go missing that quorums can't be met
> to take any decision. But it may just be so hypothetical that it's not
> worth the resulting complexity.
>
> What do other people think ? Would adding the ability to name a
> temporary substitute be sufficient ?

Since we've been managing the PPB agenda better, we haven't had problems getting the needed quorum. I would say not worth the extra complexity.

Jonathan.

Thierry Carrez wrote:
> I'll soon integrate the feedback you all gave me in future revisions of
> this same wiki page, in particular:
>
> * Precise election rule (CIVS Schulze + Proportional Representation)
> * Drop strict revocation rule
> * Allow proxies to represent in case of member absence
> * Add "Quality"
> * Elaborate on "Technical Members" of the foundation

Rev2 is now up at:
http://wiki.openstack.org/Governance/Foundation/TechnicalCommittee

--
Thierry Carrez (ttx)
Release Manager, OpenStack