Open Stack

Excerpts from Barrett, Carol L's message of 2015-12-03 21:06:22 +0000:
> I'm a bit confused as to the role of Themes today. If they emerge as a result of Project plans, then it seems like documentation, not trying to provide input to set priorities/directions for Projects.
> 
> Doug: Can you clarify this for me?
> 
> My interest is to provide input to Project planning, and agree with Thierry,a discussion these ahead of the design summit activities would be valuable to this end.

While it would be ideal to identify themes far enough in advance
to build the summit discussions for individual projects around them,
I'm not sure how that would work practically.  At the Folsom or
Grizzly summits people would propose entirely new initiatives, reach
some sort of agreement in a room, and then push ahead with the work
during the cycle. These days, an initiative is much less likely to
be successful if it is not more developed and introduced before the
summit, so that the discussion there is the middle or the end of
the conversation, and not the beginning.  Any theme so big as to
apply to the entire community would have to either be easy to
implement without a lot of discussion, worked out far enough in
advance in sufficient detail that no more discussion is needed, or
be applicable as a "background" theme to influence the direction
of other discussions but not necessarily spawn a specific session.

The themes that emerged this time were not controversial and
implementing them didn't require a lot of coordination.

Look back at the themes that we discussed:

1. Functional testing -- no one disagrees with the need, and the teams
just need to identify someone to do the work. I believe this came up in
the contexts of some other sessions, and some teams did have specific
sessions already planned for addressing this topic.

2. Adding tests for DefCore -- same

3. Being more opinionated -- This isn't really an actionable theme, but
it has influenced the distributed lock manager discussion.

4. Improving consistency of quota management -- There was no consensus,
and no one volunteered to do anything with this.

5. Rolling upgrades -- Everyone agrees this is the way to go and
many projects were already working on it.  Dan and some of the other
Nova devs involved in creating versionedobjects and pushing the
rolling upgrade process there have been documenting how that works.
But this isn't something we stop and build and then move on from.
It's a shift in the way all new work needs to happen. So it's going
to be a gradual roll out, and each project team will, when it is
ready, need to do the initial implementation work and educational
work for reviewers.

6. os-client-config support -- The cross-project spec is still under
discussion, but hasn't seen a lot of comments.

7. Fixing existing things as a priority over features -- This is a
perennial frustration, and while there were some proposals for ways to
ways to provide cover for teams that want to do this, there was also
agreement that we should not do this for *all* of OpenStack at the same
time as a forced priority, because different projects are in different
stages of their lifecycles, and for some of them adding features is
still critically important. So this was treated as a background theme.

8. Increasing third-party CI -- Mike Perez is driving this, for the
teams where it applies. Not every project needs to do this, though.

9. Training more folks to debug the gate -- Anita Kuno has been
gathering useful information in a mailing list thread. I hope, when
there is enough detail there, we can find a place to put it all together
in a document where it's easy to keep it up to date, etc. so we can make
future training go more quickly.

10. Ensuring we have liaisons in place -- This wasn't really a theme,
just an aspect of getting ourselves organized for this cycle.

My interpretation of most of those items is that we were surfacing
an agreement that emerged from previous discussions that had happened
in other venues, either with smaller or different groups of
participants (for example, the testing and DefCore items), or on
the mailing list (for example, rolling upgrades and fixes vs.
features). I think that's still a useful conversation to have,
because we have a large enough community, with many teams functioning
independently, so having them share priorities that might apply
outside of their team can be educational and inspirational, even
if those priorities aren't adopted immediately.

Maybe the best way to think about how to do what you're looking
for, and influence the planning project teams do for the next cycle,
is to actually propose a theme or two that you would like to see.
Then we can look at each of them and decide what it means, and how
we would take action on it.

Doug

> 
> Thanks
> Carol
> 
> -----Original Message-----
> From: Thierry Carrez [mailto:thierry at openstack.org] 
> Sent: Monday, November 09, 2015 4:52 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [all] summarizing the cross-project summit session on Mitaka themes
> 
> Doug Hellmann wrote:
> > One thing I forgot to mention in my original email was the discussion 
> > about when we would have this themes conversation for the N cycle.
> > I had originally hoped we would discuss the themes online before the 
> > summit, and that those would inform decisions about summit sessions. 
> > Several other folks in the room made the point that we were unlikely 
> > to come up with a theme so surprising that we would add or drop a 
> > summit session from any existing planning, so having the discussion in 
> > person at the summit to add background to the other sessions for the 
> > week was more constructive.
> 
> So I was stuck in Design Summit 101 during this session and couldn't attend. Saying that discussing common themes before summit planning is unlikely to change design summit session contents strikes me as odd.
> That's equivalent to saying that the right themes are picked anyway.
> That may be the case for some projects, but certainly not the case for all projects, otherwise we wouldn't be having that discussion to begin with...
> 
> Personally I think we need to have the cycle themes discussion before the design summit so that it can really influence what gets discussed there and ends up in real action items. Adding background at the last minute to already-decided session topics is just not enough to trigger real progress in those key areas.
> 
> Why can't we have that discussion on the ML in the second half of the cycle, between the midcycle sprints and the summit planning ?
> 
> --
> Thierry Carrez (ttx)
> 
> __________________________________________________________________________
> 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