Open Stack

On 6/11/2018 3:31 PM, Doug Hellmann wrote:
> 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.

I'm reminded of something we talked about in IRC last week wrt tracking 
blueprint-type changes over a given series / release in storyboard. It 
was mentioned that storyboard has a not-yet-implemented epics feature 
which is really how we'd probably do this (nested stories is another way 
of thinking about this). So nova could, for example, have an epic for 
Stein and then track a story for each blueprint, with the old launchpad 
blueprint 'work items' (which we don't use, but we do have a list of 
work items in our specs template) tracked as tasks - which would also be 
nice since you can track tasks like documentation, CLIs (nova and OSC) 
and tempest testing (if required). One thing people always commit to in 
their spec is adding support for the feature in client libraries, 
tempest and docs, but once the nova server side change is merged those 
commitments end up getting dropped (not always, but more often than I'd 
like).

-- 

Thanks,

Matt