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.h...@nebula.com
> To: thie...@openstack.org
> Date: Fri, 22 Jun 2012 17:20:06 +0000
> CC: foundat...@lists.openstack.org; openstack-poc@lists.launchpad.net
> 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
> foundat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
_______________________________________________
Mailing list: https://launchpad.net/~openstack-poc
Post to : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help : https://help.launchpad.net/ListHelp
