Open Stack

Excerpts from Hayes, Graham's message of 2016-08-02 16:30:06 +0000:
> On 02/08/2016 16:37, Doug Hellmann wrote:
> > 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.
> 
> For me "use olso" would fall into an "implementation or design detail"

OK, but that is not a proposed goal.

> 
> >> 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.
> 
> Treating differently is fine, it is just very difficult for an outsider
> to the TC to follow the various different exceptions. I try to follow TC
> meetings and the patches to governance, but trying to find the
> distinction between different sub groups can be very difficult.
> 
> My point is that this may not be fair to the other 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.
> 
> We have another thread currently where it has been said that if a
> project is not will to putting community in front of development, they
> should not be part of OpenStack.

If you're talking about the team diversity discussion, I think
you're misunderstanding or misconstruing that statement. The idea
there is to apply a little pressure to teams to actually work on
their diversity, since many claim that becoming part of the big
tent is a prerequisite to that. That is something all teams should
always be doing anyway.

> 
> Where does this land for those projects - should they work on community,
> on these themes, or on improving their project to increase users?
> 
> For a small or new team, all 3 of these are *really* important.
> 
> Piling work on projects is fine - if they have the team to deliver on
> it. Not all projects have the same development team size, or the same
> levels of skill or knowledge for integrating across the OpenStack
> eco-system.
> 
> Adding extra required work will not help these teams. If the TC is 
> trying to change up the make up of the big-tent, by removing projects,
> we should be clear about it, and have it as a single change to
> governance as a change to the big tent resolution.

This has nothing to do with removing teams from the big tent. Nothing.
It is about bringing all of the big tent teams into alignment to listen
to our users as a whole community.

> 
> > 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.
> 
> But, at the core, it is a TC mandate. If it was about focusing, there
> would not be requirement for PTLs to ack the goal, and have a
> requirement to complete the theme.
> 
> Don't get me wrong, I am OK with a TC mandate. But it seems at odds
> with the previously stated position of various TC members. If we are
> changing, that is OK, but we need to acknowledge the change.

The TC isn't going to make up these goals though. We're going to be
working with the community to identify them, clarify them, and then
schedule them.

Doug

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