openstack-poc team mailing list archive

[Jan Drake <jan_drake@xxxxxxxxxxx>]

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: Joe.Heck@xxxxxxxxxx
> To: thierry@xxxxxxxxxxxxx
> Date: Fri, 22 Jun 2012 17:20:06 +0000
> CC: foundation@xxxxxxxxxxxxxxxxxxx; openstack-poc@xxxxxxxxxxxxxxxxxxx
> 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
> Foundation@xxxxxxxxxxxxxxxxxxx
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation