Open Stack

On 15 Aug 2016, at 1:37, Thierry Carrez wrote:

> 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

I agree, too. This is a great process that covers nearly everything.

The reason the prioritization language is so important isn't so that
project teams can "get around" the TC or intentionally be different or
otherwise not be good community participants. I want to make sure we
are not setting up a process that tells projects to "toe the line" or
get out.

In a community as large and diverse in scope as OpenStack, it's
impossible for one person or one small group to be familiar enough
with all of the OpenStack projects to understand the design decisions,
trade-offs, and priorities for each one. The TC certainly doesn't want
to micromanage every project.

Supporting a common goal and making progress on it is much different
than "prioritize these goals above all other work". Like you, I expect
that all projects in OpenStack will work together for the common good.
I don't think any open source project can mandate prioritization on
its contributors and expect to maintain long-term growth.

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

Any chance you'd go for something like "project teams are expected to
make progress on these goals and report that progress to the TC every
cycle"?

Yes, I like Thierry's proposed wording better than the originally-
proposed language.

--John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160815/83eb0992/attachment.pgp>