Excerpts from Matt Riedemann's message of 2018-06-11 18:00:12 -0500: > 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). >
If an epic is just a list of stories, doesn't that make it a worklist? Doug __________________________________________________________________________ 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