Open Stack

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.

-- 
Russell Bryant