<div dir="ltr">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.<br><br>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.  <div><br></div><div>-Kendall (diablo_rojo)<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 11, 2018 at 1:31 PM Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +0000:<br>
> Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> wrote:<br>
> <br>
> >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?<br>
> <br>
> 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.<br>
> <br>
> So, are you saying the information shown in the examples I gave is not useful?<br>
> <br>
> 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?<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
<br>
This thread isn't going in a very productive direction. Please<br>
consider your tone as you reply.<br>
<br>
The release team used to (help) manage the launchpad series data.<br>
We stopped doing that a long time ago, as Jeremy pointed out, because<br>
it was not useful to *the release team* in the way we were managing<br>
the releases. We stopped tracking blueprints and bug fixes to try<br>
to predict which release they would land in and built tools to make<br>
it easier for teams to declare what they had completed through<br>
release notes instead.<br>
<br>
OpenStack does not have a bunch of project managers signed up to<br>
help this kind of information, so it was left up to each project<br>
team to track any planning information *they decided was useful*<br>
to do their work.  If that tracking information happens to be useful<br>
to anyone other than contributors, I consider that a bonus.<br>
<br>
As we shift teams over to Storyboard, we have another opportunity<br>
to review the processes and to decide how to use the new tool. Some<br>
teams with lightweight processes will be able to move directly with<br>
little impact. Other teams who are doing more tracking and planning<br>
will need to think about how to do that. The new tool provides some<br>
flexibility, and as with any other big change in our community,<br>
we're likely to see a bit of divergence before we collectively<br>
discover what works and teams converge back to a more consistent<br>
approach.  That's normal, expected, and desirable.<br>
<br>
I recommend that people spend a little time experimenting on their<br>
own before passing judgement or trying to set standards.<br>
<br>
Start by looking at the features of the tool itself.  Set up a work<br>
list and add some stories to it. Set up a board and see how the<br>
automatic work lists help keep it up to date as the story or task<br>
states change. Do the same with a manually managed board. If you<br>
need a project to assign a task to because yours hasn't migrated<br>
yet, use openstack/release-test.<br>
<br>
Then think about the workflows you actually use -- not just the<br>
ones you've been doing because that's the way the project has always<br>
been managed. Think about how those workflows might translate over<br>
to the new tool, based on its features. If you're not sure, ask and<br>
we can see what other teams are doing or what people more familiar<br>
with the tool suggest trying.<br>
<br>
Doug<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>