[openstack-dev] Motion on Technical Committee membership for Spring 2013 session

John Dickinson me at not.mn
Thu Jan 24 15:37:16 UTC 2013

The proposed option 3 (13 directly elected TC members), while perhaps the least bad of the four originally proposed options, also didn't seem to have strong supporters. It seems to me that trying to change the current structure is reactionary and hasty.

First, the claimed problem that needs to be solved is growing the TC above 13 total members and the worry of unbounded growth in the future based on new projects being included in the combined release. There are currently two projects in incubation status. If they are included in the combined release, under the current rules, the TC will grow to 15 members. How is 15 members worse than 13 members? Rushing into a change for the TC framework because 2 new projects might* be added seems hasty. I don't see that we have a time pressure to change. Keeping the current rules and planning for a change in the fall elections allows more time without adding undue burden to the current structure.

Second, there are valid concerns over what happens when a PTL doesn't get elected (either by choice or by vote) to the TC under the new structure. The responses I've seen include "most PTLs will get elected anyway" and "if a PTL is opposed, the TC really, really should take that into consideration" have serious issues, in my opinion. This implies that the PTL has an almost veto power over TC decisions but yet isn't allowed the ability to vote on those decisions. The PTLs would be required to attend meetings and keep up with the TC activities, which raises the effective size of the TC anyway.

Finally, I've seen arguments along the lines of "good people who care about XXX" are who we should elect. Of course. We should always elect good people, but that's true no matter the system that is set up. One difference in a good system and a bad system is how well it handles what happens when a "not good" person is elected. (and of course "good" and "not good" are different for every person.)

I'd prefer to see something more along the lines of Anne's proposed categories. I think there is much discussion to be had around what categories are there and how they are defined, but it still allows each project to have representation (including less active projects) and solves the unbounded growth problem.


*no incubated project has ever failed to be added as a core/integrated project

On Jan 24, 2013, at 5:17 AM, Thierry Carrez <thierry at openstack.org> wrote:

> Anne Gentle wrote:
>> I agree with Mark that there are no PTL seats. Is it possible that a PTL
>> is going to "lose" their TC seat if they lose the PTL election at the
>> six-month mark and the seats are for a year?
>> (Thinking of the defined "renew half the committee every 6 months (and
>> be elected for a one-year term)" from a previous thread.)
> With the new system, the fact that you are or not a PTL doesn't affect
> your TC term length. A person that is elected for one year is elected
> for one year, even if they also are a PTL (elected for 6 months) and
> even if they lose that PTL position after 6 months.
> -- 
> Thierry
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4082 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130124/3c3f13fd/attachment.bin>

More information about the OpenStack-dev mailing list