Great discussion so far with well thought out positions! Weighing in... To me, it feels cleaner to separate the PTL roles from the TC roles. If a PTL is elected to be on the TC it should be because that PTL is deemed to be a good fit for the TC specifically and not just because they were previously deemed to be good at being a PTL. Those are two different roles with two different sets of skills (which may or may not overlap).
My personal preference is for the TC to be "whoever the technical contributors elect for the job, who may or may not also be PTLs". - Dallas On Jun 23, 2012, at 4:13 PM, Jan Drake <jan_dr...@hotmail.com> wrote: > Again, other people need to weigh in. I would simply recommend that the > nuances be considered and that potential downstream risks and the possibility > of introducing perverse incentives be considered. Sometimes the nature of > the thing we create is more important than the structure. > > At this point, I take myself out of the conversation as I am merely a > concerned citizen and the people with skin in the game need to be weighing in. > > And I hope for an awesome outcome. > > > > > On Jun 23, 2012, at 4:57 AM, Thierry Carrez <thie...@openstack.org> wrote: > >> Thierry Carrez wrote: >>> So another way to look at the choice ahead is: when we fail to reach a >>> consensus within our community, do we prefer to use the fairest possible >>> representation of our technical contributors, or one that slightly >>> overrepresents PTLs in order to protect our core projects from >>> hypothetical abuse ? >> >> One way to choose the lesser of the two evils is to consider the role >> and power of the future TC. >> >> If the TC defines what is a core project and what is not, talks about >> how collaboration between projects should be achieved, and then resolves >> potential disputes /between/ PTLs, then I think the risk for abuse to >> core projects is very limited (the PTL is still very much in full >> control of his project). >> >> On the other hand, if the TC clearly has authority over the PTLs and can >> potentially force them to do something a certain way inside their >> project, then I'd agree with Joe that slightly overrepresenting the PTLs >> in the TC is probably a good idea. >> >> Example case: openstack-common. If the TC can constrain a given core >> project, for the higher interests of OpenStack as a whole, to use a >> given feature in the library, then I agree that tilting the membership >> of the TC a bit towards the PTLs is probably a good idea. If the TC >> can't do that, then the potential damage to a core project from a >> PTL-adverse TC is no longer hypothetical, it is null. And we should >> prefer fair representation instead. >> >> -- >> Thierry Carrez (ttx) >> Release Manager, OpenStack >> >> > _______________________________________________ > 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