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 _______________________________________________ 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
