[openstack-dev] use of storyboard (was [TC] Stein Goal Selection)

Tom Barron tpb at dyncloud.net
Tue Jun 12 13:44:34 UTC 2018


On 12/06/18 15:25 +0200, Kendall Nelson wrote:
>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)

Thanks much!

>
>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
>>

>__________________________________________________________________________
>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




More information about the OpenStack-dev mailing list