Open Stack

Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +0000:
> Jeremy Stanley <fungi at yuggoth.org> 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