I have to say I concur with Mr. Heck's quite cogent perspective. Would love to see his points addressed on this thread.
Jan > From: [email protected] > To: [email protected] > Date: Fri, 22 Jun 2012 17:20:06 +0000 > CC: [email protected]; [email protected] > Subject: Re: [OpenStack Foundation] Technical Committee: reserved seats for > PTLs (or not) > > On Jun 20, 2012, at 3:18 AM, Thierry Carrez wrote: > > The current PPB had a discussion yesterday on the bylaws for the > > Foundation Technical Committee ("TC"), mainly around whether PTLs should > > get reserved seats on the TC. > > > > I would like to summarize the options and extend the discussion to the > > Foundation ML for wider input. > > > > My initial proposal [1] was to have a directly-elected committee (9 > > seats, all elected by technical contributors to OpenStack projects as a > > whole, in the same way each PTL is elected by the contributors of each > > project). Some members of the current PPB suggested that we should keep > > reserved seats for the core projects PTLs, and only directly elect 5 > > extra seats (TC = PTLs+5 seats, 11 seats for the original setup). > > > > The main argument against the "directly-elected" model is that you might > > run in a situation where a PTL of a smaller project does not get a vote > > on the TC, especially as the number of core projects grows. > > > > IMHO the potential drawbacks of the "PTLs+5" model are: > > * Committee bloat as we grow our number of projects > > * Skewed election power for smaller projects members > > * Projects have different sizes but PTL votes carry the same weight > > * Have fear of dilution play a role when deciding new core inclusion > > * Have fear of bloat play a role when deciding new core inclusion > > * Have fear of bloat or dilution discourage further core project splits > > > > In the end, the result should not be very different: I expect most PTLs > > to be elected anyway since the voters are the same people that elected > > them in each project. And the use of "proportional representation" > > option in the Schulze algorithm specifically ensures that smaller groups > > get a fair representation and cannot be displaced by a majority of > > voters. Additionally, PTLs have to accept that some TC decisions will > > not go their way: having one vote doesn't magically ensure that all > > decisions will go your way, especially in a large committee. > > > > So I think the key question is whether the TC should be considered "the > > college of the PTLs + a number of extra elected people", or "whoever the > > technical contributors elect for the job, who may or may not also be PTLs". > > > > One thing to remember is that the Technical Committee will define what > > "OpenStack" is technically, which goes beyond just core projects. It > > influences library projects, gating projects, plug-ins etc. > > I much prefer the "PTL+5" model. > > 1) the PTL is already an elected position > 2) I think it would be foolish of us to create a structure where technical > decisions that are supposed to be made across all the projects *could* be > voted on and set by a different group of people than the leads of those > projects. > 3) I think your fear of bloat of the group is not a valid concern - the > appointed positions dissipate, and the core projects growth has been minimal, > mostly fragmenting of Nova into it's relevant constituent parts. > > The core of why I'm so opposed to a separately elected model for the > technical committee is that it explicitly forms two groups that have > overlapping accountability, but which may not be the same people. In the best > of all worlds, this would be a non-issue, but it is the height of foolishness > to create a structure with a division of groups and not a corresponding > division of accountability. To me, this is suggesting that we create a > ticking time bomb of technical division within the foundation from the very > start. > > Thierry has made the argument that "It likely would be all the PTLs", but > that just begs of the question of why even set up a process that could > fragment and induce confusion the decision process over technical decisions. > > - joe > _______________________________________________ > Foundation mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
_______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
