Open Stack

On Jan 15, 2013, at 10:46 AM, Russell Bryant <rbryant at redhat.com> wrote:
> On 01/15/2013 11:09 AM, Mark McLoughlin wrote:
>> On Tue, 2013-01-15 at 16:52 +0100, Thierry Carrez wrote:
>> ...
>>> We are considering adding more projects in the integrated release in the
>>> future, but adding more PTLs with guaranteed TC seats doesn't really
>>> scale, quickly leading to committee bloat (personally I think 13 is the
>>> maximum workable number).
>> ...
>>> 3/ Limit the TC to 13 members, and have them all directly-elected (the
>>> most significant PTLs will get elected anyway)
>> 
>> This would be my preference - because it's simple.
>> 
>> 13 seats gives ample opportunity for diverse parts of the development
>> community to be represented.
>> 
>> It also means that the committee can't assume all parts of the project
>> are represented at its meetings and must reach out for broader input.
>> 
>> IMHO, the TC is a group of people charged with building a rough
>> consensus on cross-project topics. I'd much rather see the 13 seats open
>> to those who are actively interested in this cross-project consensus
>> building.
>> 
>> No TC could consider itself as having reached a consensus if PTLs are
>> objecting strongly to a proposal. Indeed, I think PTL come pretty close
>> to having a veto when it comes to proposals which affect their projects.
>> IMHO, that effective veto makes the "1 vote in 13" from a PTL's seat on
>> the TC look like a pretty minor thing.
>> 
>>> 4/ Limit the TC to 13 members, have them all directly-elected, *and*
>>> guarantee that a minimum of 8 PTLs end up in the committee
>> ...
>> 
>> This is the next best option but is a layer of bureaucracy and
>> over-engineering I think we could live without.
> 
> I'm pretty much agreement with this stance.  My preference is #3.
> 
> If #4 was necessary to reach some sort of consensus on a compromise, I'd
> live with it.  I'm firmly against #1 and #2.


I agree as well, I think #3 is the best option. As Mark says, any decisions the
PTLs are not in line with will end up falling out during discussions.

Thanks,
Kyle