Yes! I can definitely set Manila up in storyboard-dev. I'll get the imports done before the end of the week :)
-Kendall (diablo_rojo) On Tue, 12 Jun 2018, 2:53 pm Tom Barron, <[email protected]> wrote: > On 12/06/18 10:57 +0200, Kendall Nelson wrote: > >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. > > > > Can we do this for manila? I believe you did a test migration already > but not to a sandbox that we could play with? Or maybe you did the > sandbox as well but I missed that and didn't play with it? > > Before we cutover I want to: > * add some new sample bugs and blueprints > * set up worklists for our release milestones > * set up some useful worklists and boards and search queries for > stuff that we track only ad-hoc today > * figure a place to document these publicly > > -- Tom > > >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 <[email protected]> > wrote: > > > >> 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 > >> > > >__________________________________________________________________________ > >OpenStack Development Mailing List (not for usage questions) > >Unsubscribe: > [email protected]?subject:unsubscribe > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
