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:thie...@openstack.org] > Sent: Monday, November 09, 2015 4:52 AM > To: openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
