Open Stack

Excerpts from Hayes, Graham's message of 2016-08-02 13:49:06 +0000:
> On 02/08/2016 14:37, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-08-02 11:53:37 +0000:
> >> On 29/07/2016 21:59, Doug Hellmann wrote:
> >>> 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"
> >>
> >> I am confused. When I proposed my patch for doing something very similar
> >> (Equal Chances for all projects is basically a multiple release goal) I
> >> got the following rebuttals:
> >>
> >>  > "and it would be
> >>  > a mistake to try to require that because the issue is almost always
> >>  > lack of resources and not lack of desire. Volunteers to contribute
> >>  > to the work that's needed will do more to help than a
> >>  > one-size-fits-all policy."
> >>
> >>  > This isn't a thing that gets fixed with policy. It gets fixed with
> >>  > people.
> >>
> >>  > I am reading through the thread, and it puzzles me that I see a lot
> >>  > of right words about goals but not enough hints on who is going to
> >>  > implement that.
> >>
> >>  > I think the right solutions here are human ones. Talk with people.
> >>  > Figure out how you can help lighten their load so that they have
> >>  > breathing space. I think hiding behind policy becomes a way to make
> >>  > us more separate rather than engaging folks more directly.
> >>
> >>  > Coming at this with top down declarations of how things should work
> >>  > not only ignores reality of the ecosystem and the current state of
> >>  > these projects, but is also going about things backwards.
> >>
> >>  > This entirely ignores that these are all open source projects,
> >>  > which are often very sparsely contributed to. If you have an issue
> >>  > with a project or the interface it provides, then contribute to it.
> >>  > Don't make grandiose resolutions trying to force things into what you
> >>  > see as an ideal state, instead contribute to help fix the problems
> >>  > you've identified.
> >>
> >> And yet, we are currently suggesting a system that will actively (in an
> >> undefined way) penalise projects who do not comply with a different set
> >> of proposals, done in a top down manner.
> >>
> >> I may be missing the point, but the two proposals seem to have
> >> similarities - what is the difference?
> >>
> >> When I see comments like:
> >>
> >>  > Project teams who join the big tent sign up to the rights and
> >>  > responsibilities that go along with membership. Those responsibilities
> >>  > include taking some direction from the TC, including regarding work
> >>  > they may not give the same priority as the broader community.
> >>
> >> It sounds like top down is OK, but previous ML thread / TC feedback
> >> has been different.
> >
> > One difference is that these goals are not things like "the
> > documentation team must include every service project in the
> > installation guide" but rather would be phrased like "every project
> > must provide an installation guide". The work is distributed to the
> > vertical teams, and not focused in the horizontal teams.
> 
> Well, the wording was actually "the documentation team must provide a
> way for all projects to be included in the documentation guide". The
> work was on the horizontal teams to provide a method, and the vertical
> teams to do the actual writing, as an example (that is actually
> underway, so it is a bad example.)

We have set minimum expectations for horizontal teams. They're lower
than you want, but they're there.

> A better example would be OSC / Horizon has to provide a way for plugins
> to set quotas - it is up to the project teams to actually implement the
> code the sets quotas.

That sounds like an implementation or design detail that we wouldn't
want to get involved with.

> I am confused about why the same theory of people vs policy is not
> applied for this - if on one hand the TC says that if you want something
> done in a different project, to pony up people and do it, and in this
> case, "if you want to be a OpenStack project you must do the work the TC
> assigns".
> 
> What is the difference? If it is the latter, the arguments against
> telling horizontal projects are moot, if it is the former, this policy
> would seem to be moot.

Yes, if projects have chosen to join the big tent, there have always
been and will continue to be responsibilities associated with that
membership.

We treat the horizontal and vertical teams differently in some
respects because as we add vertical teams the work load on the
horizontal teams grows. So we do tell horizontal teams that they
must support all vertical teams, but we don't tell them exactly how
to do that or to provide the same level of support because that's
not fair to the contributors on the horizontal teams.

In this case, we're telling all teams of all sorts that the community
wants something, and the TC wants them to do it in a specific
time-frame. These are community goals, which we want teams in the
community to adopt. I don't expect teams to need more resources or
more contributors to accomplish the goals, especially because in
most cases there will be small groups of folks set up to help with
the work.

It is easy to interpret this as being a TC mandate, but these goals
are about focusing team attention on short-term tasks that benefit
the entire community.  If you look at the existing proposals and
consider the anticipated long lead time before a goal is "adopted"
I hope it will be clear that none of these things are supposed to
be surprises to anyone.  This is meant to be a way to bring community
goals to all teams as themes for a cycle.  We're bootstrapping with
some items dealing with technical debt because we want to have
something in place in time for project teams to be able discuss it
at the design summit. For the next cycle we'll take more input
into the goal options, but we have to start somewhere.

> 
> > Doug
> >
> >>
> >> - Graham
> >>
> >>> __________________________________________________________________________
> >>> 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
> >>>
> >>
> >
> > __________________________________________________________________________
> > 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
> >
>