Open Stack

Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700:
> 
> On 10 Aug 2016, at 8:29, Doug Hellmann wrote:
> 
> > Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400:
> >> One of the outcomes of the discussion at the leadership training
> >> session earlier this year was the idea that the TC should set some
> >> community-wide goals for accomplishing specific technical tasks to
> >> get the projects synced up and moving in the same direction.
> >>
> >> After several drafts via etherpad and input from other TC and SWG
> >> members, I've prepared the change for the governance repo [1] and
> >> am ready to open this discussion up to the broader community. Please
> >> read through the patch carefully, especially the "goals/index.rst"
> >> document which tries to lay out the expectations for what makes a
> >> good goal for this purpose and for how teams are meant to approach
> >> working on these goals.
> >>
> >> I've also prepared two patches proposing specific goals for Ocata
> >> [2][3].  I've tried to keep these suggested goals for the first
> >> iteration limited to "finish what we've started" type items, so
> >> they are small and straightforward enough to be able to be completed.
> >> That will let us experiment with the process of managing goals this
> >> time around, and set us up for discussions that may need to happen
> >> at the Ocata summit about implementation.
> >>
> >> For future cycles, we can iterate on making the goals "harder", and
> >> collecting suggestions for goals from the community during the forum
> >> discussions that will happen at summits starting in Boston.
> >>
> >> Doug
> >>
> >> [1] https://review.openstack.org/349068 describe a process for managing community-wide goals
> >> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
> >> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo libraries"
> >>
> >
> > The proposal was discussed at the TC meeting yesterday [4], and
> > left open to give more time to comment. I've added all of the PTLs
> > for big tent projects as reviewers on the process patch [1] to
> > encourage comments from them.
> >
> > Please also look at the associated patches with the specific goals
> > for this cycle (python 3.5 support and cleaning up Oslo incubated
> > code).  So far most of the discussion has focused on the process,
> > but we need folks to think about the specific things they're going
> > to be asked to do during Ocata as well.
> >
> > Doug
> >
> > [4] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-09-20.01.log.html
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> Commonality in goals and vision is what unites any community. I
> definitely support the TC's effort to define these goals for OpenStack
> and to champion them. However, I have a few concerns about the process
> that has been proposed.
> 
> I'm concerned with the mandate that all projects must prioritize these
> goals above all other work. Thinking about this from the perspective of
> the employers of OpenStack contributors, and I'm finding it difficult
> to imagine them (particularly smaller ones) getting behind this
> prioritization mandate. For example, if I've got a user or deployer
> issue that requires an upstream change, am I to prioritize Py35
> compatibility over "broken in production"? Am I now to schedule my own
> work on known bugs or missing features only after these goals have
> been met? Is that what I should ask other community members to do too?

There is a difference between priority and urgency. Clearly "broken
in production" is more urgent than other planned work. It's less
clear that, over the span of an entire 6 month release cycle, one
production outage is the most important thing the team would have
worked on.

The point of the current wording is to make it clear that because these
are goals coming from the entire community, teams are expected to place
a high priority on completing them. In some cases that may mean
working on community goals instead of working on internal team goals. We
all face this tension all the time, so that's nothing new.

> I agree with Hongbin Lu's comments that the resulting goals might fit
> into the interests of the majority but fundamentally violate the
> interests of a minority of project teams. As an example, should the TC
> decide that a future goal is for projects to implement a particular
> API-WG document, that may be good for several projects, but it might
> not be possible or advisable for others.

Again, the goals are not coming from the TC, they are coming from the
entire community. There will be discussion sessions, mailing list
threads, experimentation, etc. before any goal is settled on. By the
time the goals for a given cycle are picked, everyone will have had a
chance to give input. That's why I'm starting this conversation now, so
far in advance of the summit.

As far as not implementing a goal, if a team has a reason they feel a
goal does not fit with their project, then they should document that in
their response. That's part of the proposed process.

> I know the TC has no malicious intent here, and I do support the idea
> of having cross-project goals. The first goals proposed seem like
> great goals.  And I understand the significant challenges of
> coordinating goals between a multitude of different projects. However,
> I haven't yet added my own +1 to the proposed goals because the
> current process means that I am committing that every Swift project
> team contributor is now to prioritize that work above all else, no
> matter what is happening to their customers, their products, or their
> communities.

No, that's not what you're doing at all. You're saying that the
team, as a whole, will address the goal. That does not necessarily
mean every team member will be involved in it, any more than they
are all directly and intimately involved in every other task the
team takes on over the course of a cycle. But it does mean that
someone will sign up to do the work, and the team agrees to do
reviews or over whatever other help is needed to see it through.
And if a goal is completely outside the bounds of what the team can
agree to, then you are agreeing to document that in a sufficient
detail that the rest of the community, who asked for the goal, can
understand why, and then you move on.

Doug