Open Stack

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)