Open Stack

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, <tpb at dyncloud.net> 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 <doug at doughellmann.com>
> wrote:
> >
> >> 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
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180612/a05c6783/attachment.html>