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

Reply via email to