Yes! I can definitely set Manila up in storyboard-dev. I'll get the imports done before the end of the week :)<div><br></div><div>-Kendall (diablo_rojo)<br><br><div class="gmail_quote"><div dir="ltr">On Tue, 12 Jun 2018, 2:53 pm Tom Barron, <<a href="mailto:tpb@dyncloud.net">tpb@dyncloud.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/06/18 10:57 +0200, Kendall Nelson wrote:<br>
>Another option for playing around things- I am happy to do a test migration<br>
>and populate our storyboard-dev instance with your real data from lp. The<br>
>last half a dozen teams we have migrated have been handled this way.<br>
><br>
<br>
Can we do this for manila?  I believe you did a test migration already <br>
but not to a sandbox that we could play with?  Or maybe you did the <br>
sandbox as well but I missed that and didn't play with it?<br>
<br>
Before we cutover I want to:<br>
 * add some new sample bugs and blueprints<br>
 * set up worklists for our release milestones<br>
 * set up some useful worklists and boards and search queries for<br>
   stuff that we track only ad-hoc today<br>
 * figure a place to document these publicly<br>
<br>
-- Tom<br>
<br>
>Playing around with StoryBoard ahead of time is a really good idea <br>
>because<br>
>it does work differently from lp. I don't think its more complicated, it<br>
>just takes some getting used to. It forces a lot less on its users in terms<br>
>of constructs and gives users a lot more flexibility to use it in a way<br>
>that is most effective for them. For a lot of people this involves a mental<br>
>re-frame of task management and organization of work but its not a<br>
>herculean effort.<br>
><br>
>-Kendall (diablo_rojo)<br>
><br>
>On Mon, Jun 11, 2018 at 1:31 PM Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>> wrote:<br>
><br>
>> 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<br>
>> the >800 official OpenStack deliverable repos have a view like that with<br>
>> any actual relevant detail? If it's "standard" then certainly more than<br>
>> half, right?<br>
>> ><br>
>> > Well, that's a bit rude, so I'm not going to get in a swearing contest<br>
>> over whether Nova, Neutron and Cinder are more "important" than 800+ other<br>
>> projects. I picked a handful of projects that I'm most interested in and<br>
>> which also happened to have really clear, accessible and easy to understand<br>
>> information on what they have delivered in the past and are planning to<br>
>> 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<br>
>> useful?<br>
>> ><br>
>> > Or just that I've been lucky in the past that the projects I'm most<br>
>> interested in do a better than typical job of managing releases but the<br>
>> future is all downhill?<br>
>> ><br>
>> > If you're saying it's not useful info and we're better off without it<br>
>> then I'll just have to disagree. If you're saying that it has been replaced<br>
>> with something better, please share the URLs.<br>
>> ><br>
>> > I'm all for improvements, but saying "only a few people were doing<br>
>> something useful so we should throw it out and nobody do it" isn't a path<br>
>> to improvement. How about we discuss alternate (e.g.<br>
>> 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>
>><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>
<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>