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

Tom Barron tpb at dyncloud.net
Tue Jun 12 12:52:46 UTC 2018


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




More information about the OpenStack-dev mailing list