Open Stack

Doug Hellmann wrote:
> [...]
> Choosing to be a part of a community comes with obligations as well
> as benefits.  If, after a lengthy discussion of a community-wide
> goal, involving everyone in the community, a project team is
> resolutely opposed to the goal, does that not indicate that the
> needs of the project team and the needs of the broader community
> are at odds in some way? And if the project team's needs and the
> community needs are consistently at odds, over the course of a
> series of such goals, why would the project team want to constrain
> itself to stay in the community?  Aren't they clearly going in
> different directions?
> 
> Understand, it is not my desire to emphasize any differences of
> this nature. Rather, I want to reduce them. To do that, I am proposing
> a process through which common goals can be identified, described,
> and put into action. I do hope, though, that through the course of
> the discussion of each individual proposal everyone involved will
> come to understand the idea and by the time a proposal becomes a
> "goal" to be implemented I "expect" everyone to, at the very least,
> understand why a goal is important to others, even if they do not
> agree with it. That understanding should then lead, on the basis
> of agreeing to be part of a collaborative community, to supporting
> the goal.
> 
> I also expect us to discuss a lot of proposals that we do not agree
> on, and that either need more time to develop or that end up finding
> another path to resolution. No one seems all that concerned with
> the concept that they might propose a goal that everyone else doesn't
> agree with.  :-)
> 
> So, yes, by the time we pick a goal I expect teams to do the work,
> because at that point in the process they will see it as the
> reasonable course of action.  There is still an "escape valve" in
> place for teams that, after all of the discussion and shaping of
> the goals is over, still take issue with a goal. By explaining their
> position in their response, we will have reference documentation
> to point to when the inevitable "why doesn't X do Y" questions
> arise. I will be interested to see how often we actually have to
> use that.

+1

> Excerpts from John Dickinson's message of 2016-08-12 16:04:42 -0700:
>> [...]
>> The proposed plan has a lot of good in it, and I'm really happy to see the TC
>> working to bring common goals and vision to the entirety of the OpenStack
>> community. Drop the "project teams are expected to prioritize these goals above
>> all other work", and my concerns evaporate. I'd be happy to agree to that proposal.
> 
> Saying that the community has goals but that no one is expected to
> act to bring them about would be a meaningless waste of time and
> energy.

I think we can find wording that doesn't use the word "priority" (which
is, I think, what John objects to the most) while still conveying that
project teams are expected to act to bring them about (once they said
they agreed with the goal).

How about "project teams are expected to do everything they can to
complete those goals within the boundaries of the target development
cycle" ? Would that sound better ?

-- 
Thierry Carrez (ttx)