melanie witt wrote:
[...] I have been trying to explain why over several replies to this thread. Fracturing a group is not something anyone does to foster cooperation and shared priorities and goals. [...]
I would argue that the group is already fractured, otherwise we would not even be having this discussion.
In the OpenStack governance model, contributors to a given piece of code control its destiny. We have two safety valves: disagreement between contributors on that specific piece of code are escalated at the PTL level, and disagreement between teams handling different pieces of code that need to interoperate are escalated at the TC level. In reality, in OpenStack history most disagreements were discussed and solved directly between contributors or teams, since nobody likes to appeal to the safety valves.
That model implies at the base that contributors to a given piece of code are in control: project teams boundaries need to be aligned on those discrete groups. We dropped the concept of "Programs" a while ago specifically to avoid creating subgroups ruled by larger groups, or artificial domains of ownership.
The key issue here is that there is a distinct subgroup within the group. It should be its own team, but it's not. You are saying that keeping the subgroup governed inside the larger group ensures that features that operators and users need get delivered to them. But having a group retaining control over other groups is not how we ensure that in OpenStack -- it's by using the model above.
Are you saying that you don't think the OpenStack governance model, where each team talks to its peers in terms of requirements and conflicts between teams may be escalated to the TC if they ever arise, will ultimately ensure that features that operators and users need get delivered to them ? That keeping placement inside Nova governance will yield better results ?
-- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
