Another option for playing around things- I am happy to do a test migration and populate our storyboard-dev instance with your real data from lp. The last half a dozen teams we have migrated have been handled this way.
Playing around with StoryBoard ahead of time is a really good idea because it does work differently from lp. I don't think its more complicated, it just takes some getting used to. It forces a lot less on its users in terms of constructs and gives users a lot more flexibility to use it in a way that is most effective for them. For a lot of people this involves a mental re-frame of task management and organization of work but its not a herculean effort. -Kendall (diablo_rojo) On Mon, Jun 11, 2018 at 1:31 PM Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +0000: > > Jeremy Stanley <fu...@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 > > __________________________________________________________________________ > 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
