Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +0000: > Jeremy Stanley <[email protected]> wrote: > > >I'm just going to come out and call bullshit on this one. How many of the > >>800 official OpenStack deliverable repos have a view like that with any > >actual relevant detail? If it's "standard" then certainly more than half, > >right? > > Well, that's a bit rude, so I'm not going to get in a swearing contest over > whether Nova, Neutron and Cinder are more "important" than 800+ other > projects. I picked a handful of projects that I'm most interested in and > which also happened to have really clear, accessible and easy to understand > information on what they have delivered in the past and are planning to > deliver in the future. If I slighted your favorite projects I apologize. > > So, are you saying the information shown in the examples I gave is not useful? > > Or just that I've been lucky in the past that the projects I'm most > interested in do a better than typical job of managing releases but the > future is all downhill? > > If you're saying it's not useful info and we're better off without it then > I'll just have to disagree. If you're saying that it has been replaced with > something better, please share the URLs. > > I'm all for improvements, but saying "only a few people were doing something > useful so we should throw it out and nobody do it" isn't a path to > improvement. How about we discuss alternate (e.g. better/easier/whatever) > ways of making the information available. >
This thread isn't going in a very productive direction. Please consider your tone as you reply. The release team used to (help) manage the launchpad series data. We stopped doing that a long time ago, as Jeremy pointed out, because it was not useful to *the release team* in the way we were managing the releases. We stopped tracking blueprints and bug fixes to try to predict which release they would land in and built tools to make it easier for teams to declare what they had completed through release notes instead. OpenStack does not have a bunch of project managers signed up to help this kind of information, so it was left up to each project team to track any planning information *they decided was useful* to do their work. If that tracking information happens to be useful to anyone other than contributors, I consider that a bonus. As we shift teams over to Storyboard, we have another opportunity to review the processes and to decide how to use the new tool. Some teams with lightweight processes will be able to move directly with little impact. Other teams who are doing more tracking and planning will need to think about how to do that. The new tool provides some flexibility, and as with any other big change in our community, we're likely to see a bit of divergence before we collectively discover what works and teams converge back to a more consistent approach. That's normal, expected, and desirable. I recommend that people spend a little time experimenting on their own before passing judgement or trying to set standards. Start by looking at the features of the tool itself. Set up a work list and add some stories to it. Set up a board and see how the automatic work lists help keep it up to date as the story or task states change. Do the same with a manually managed board. If you need a project to assign a task to because yours hasn't migrated yet, use openstack/release-test. Then think about the workflows you actually use -- not just the ones you've been doing because that's the way the project has always been managed. Think about how those workflows might translate over to the new tool, based on its features. If you're not sure, ask and we can see what other teams are doing or what people more familiar with the tool suggest trying. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
