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

[Emmet Hikory]

Doug Hellmann wrote:

> If an epic is just a list of stories, doesn't that make it a worklist?


    Worklists are one way to do epics.  In prior discussion about epics, a 
number of people have raised the idea that an epic contains more than just a 
list of stories, but also connective narrative (think about all the “I’ll kill 
you in the morning” parts of Arabian Nights, for example).  In that case, a 
wiki page may be a better solution, where the wiki page has the connective 
narrative, perhaps a list of personae, or whatever is appropriate for the 
specific requirements analysis procedure being used, and links to individual 
stories that together will enable the epic (but may also appear in different 
epics with different personae, etc.).  Such a textual document with links could 
also be implemented using the specs infrastructure, rather than a wiki page.  I 
suspect there are other ways that I do not recall at the moment, or I have not 
heard proposed.

    At a high level, I think epics are important, but I think that more 
experimentation with ways to connect collections of stories is necessary before 
we can collectively understand what would make sense.  We should try several 
things (likely adoptions from the various ways we are doing similar tracking 
now), and I expect us to slowly converge on two or three solutions that are 
known to work well for our teams, depending on the individual characteristics 
of the teams.

—
Emmet HIKORY

__
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

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

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2018-06-11 18:00:12 -0500:
> On 6/11/2018 3:31 PM, Doug Hellmann wrote:
> > 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.
> 
> I'm reminded of something we talked about in IRC last week wrt tracking 
> blueprint-type changes over a given series / release in storyboard. It 
> was mentioned that storyboard has a not-yet-implemented epics feature 
> which is really how we'd probably do this (nested stories is another way 
> of thinking about this). So nova could, for example, have an epic for 
> Stein and then track a story for each blueprint, with the old launchpad 
> blueprint 'work items' (which we don't use, but we do have a list of 
> work items in our specs template) tracked as tasks - which would also be 
> nice since you can track tasks like documentation, CLIs (nova and OSC) 
> and tempest testing (if required). One thing people always commit to in 
> their spec is adding support for the feature in client libraries, 
> tempest and docs, but once the nova server side change is merged those 
> commitments end up getting dropped (not always, but more often than I'd 
> like).
> 

If an epic is just a list of stories, doesn't that make it a worklist?

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

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

[Jay S Bryant]

On 6/11/2018 6:00 PM, Matt Riedemann wrote:

On 6/11/2018 3:31 PM, Doug Hellmann wrote:

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.


I'm reminded of something we talked about in IRC last week wrt 
tracking blueprint-type changes over a given series / release in 
storyboard. It was mentioned that storyboard has a not-yet-implemented 
epics feature which is really how we'd probably do this (nested 
stories is another way of thinking about this). So nova could, for 
example, have an epic for Stein and then track a story for each 
blueprint, with the old launchpad blueprint 'work items' (which we 
don't use, but we do have a list of work items in our specs template) 
tracked as tasks - which would also be nice since you can track tasks 
like documentation, CLIs (nova and OSC) and tempest testing (if 
required). One thing people always commit to in their spec is adding 
support for the feature in client libraries, tempest and docs, but 
once the nova server side change is merged those commitments end up 
getting dropped (not always, but more often than I'd like).


Being able to use epics to organize the stories would be very helpful.  
Maybe it is something that can be done with tags but if Storyboard has 
something more purposefully created to track epics like Jira has that 
would help make Storyboard a bit more useful.


__
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

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

[Tom Barron]

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,  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 
wrote:
>
>> Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +:
>> > Jeremy Stanley  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 

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

[Kendall Nelson]

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)

On Tue, 12 Jun 2018, 2:53 pm Tom Barron,  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 
> wrote:
> >
> >> Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +:
> >> > Jeremy Stanley  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 

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

[Tom Barron]

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


Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +:
> Jeremy Stanley  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 

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

[Jeremy Stanley]

On 2018-06-11 17:55:24 -0500 (-0500), Matt Riedemann wrote:
> On 6/11/2018 3:23 PM, Jeremy Stanley wrote:
> > If you recall the "specs" experiment years
> > ago, a few teams tried mildly different solutions for moving from LP
> > blueprints with random wiki page links to tracking specifications in
> > Git repositories, and over time they learned successful patterns
> > from each other and mostly converged on similar solutions. There
> > were similar cries back then about "how will users/operators find
> > out what is being planned?" but I think the end result was far
> > better than what it replaced.
> 
> The specs thing was mentioned last week in IRC when talking about blueprints
> in launchpad and I just want to reiterate the specs are more about high
> level designs and reviewing those designs in Gerrit which was / is a major
> drawback in the 'whiteboard' in launchpad for working on blueprints - old
> blueprints that had a design (if they had a design at all) were usually
> linked from a wiki page.
> 
> Anyway, specs are design documents per release. Blueprints in launchpad, at
> least for nova, are the project management tracking tool for that release.
> Not all blueprints require a spec, but all specs require a blueprint since
> specs are generally for API changes or other major design changes or
> features. Just FYI.

I agree, that highlights what I see as one of the four predominant
patterns we have going on at present:

* teams using a combination of blueprints with specs
* teams just using blueprints
* teams just using specs
* teams using neither blueprints nor specs

Some teams who dropped use of blueprints, or who never used them to
begin with, may end up having a bug report or story they use like a
blueprint to track tasks associated with their specs. Case in point:
the Infra team has a story for each spec, and the idea is that you
can populate that story with tasks corresponding to the
implementation steps outlined in the spec itself, then reference
those tasks in your commit messages so you get automatic tracking of
progress for the spec, though we tended to not be very diligent with
that because we're sort of laid back about our particular specs
process. In our case, those spec stories can go in automatic lanes
in a board so that you can see which are active vs merged and, if
we followed release cycles, could have those lanes further specified
by story tag for the targeted release.

There's a lot of flexibility here and, much like the specs
experiments of a few years ago, I expect to see teams coming up with
effective patterns and then sharing those with each other allowing
us to converge as a community toward some loose consistency.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

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

[Kendall Nelson]

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

> Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +:
> > Jeremy Stanley  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
>

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

[Thierry Carrez]

Doug Hellmann wrote:

[...]
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.
[...]


A bit more historical context around that.

Launchpad has a design flaw in how it uses milestones and series. Those 
are used both for pre-milestone planning (what you planned to do) and 
post-milestone reporting (what actually landed). Since what you plan to 
do never ends up being what you actually do, using the same fields to 
track both creates subtle issues. Trust me, I spent my early OpenStack 
years fighting that discrepancy and trying to provide a "release 
manager" view of OpenStack with it. As OpenStack grew, the amount of 
work needed went up and the quality of the result went down.


The solution is to use separate tools. Git history and reno are the only 
accurate way to track what landed. The task tracker should only do 
pre-milestone planning.


Then, what's the best way to track progress toward a milestone ? 
Launchpad was clearly not the best tool, otherwise we would not have 
random etherpads with lists of Launchpad links around release candidate 
time, or people tracking progress in external Trellos. A lot of people 
wanted more than just binary indicators like tags and milestone targeting.


Storyboard is designed to let you use tags, or lists, or boards, 
whatever the team finds convenient to organize the work. Don't get me 
wrong, it's not perfect, and it still has much more rough edges than I'd 
like. But at least it has the potential to become what we need. It 
doesn't try to do more than it should.


It's also worth repeating it is a task tracker, not a product management 
tool. So yes, you are missing the consistent views of "progress" and 
"what's landed" across all of OpenStack. But as Jeremy and Doug 
mentioned, the reality is that we bailed on providing that view through 
Launchpad a long time ago.


--
Thierry Carrez (ttx)

__
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

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

[CARVER, PAUL]

Matt Riedemann   wrote:

>The specs thing was mentioned last week in IRC when talking about blueprints 
>in launchpad and I just want to reiterate the specs are
>more about high level designs and reviewing those designs in Gerrit which was 
>/ is a major drawback in the 'whiteboard' in launchpad for 
>working on blueprints - old blueprints that had a design (if they had a design 
>at all) were usually linked from a wiki page.

>Anyway, specs are design documents per release. Blueprints in launchpad, at 
>least for nova, are the project management tracking tool for 
>that release. Not all blueprints require a spec, but all specs require a 
>blueprint since specs are generally for API changes or other major 
>design changes or features. Just FYI.

Matt is saying exactly what I've been saying in OpenContrail/Tungsten Fabric 
TSC meetings for a year. Launchpad Blueprints are very valuable for identifying 
what's likely to be in a given release, unambiguously indicating when the team 
has determined that something is going to miss a release (and therefore get 
bumped out to the future) and capturing the history of what was in a release. 
But they're lousy for reviewing and collaborating on technical details of what 
the thing actually is and how it is planned to work.

On the other hand, spec documents in Gerrit are pretty good for iteratively 
refining a design document and ultimately agreeing to a finalized version, but 
not really all that good at reflecting status and progress to people who are 
not down in the weeds of discussing the implementation details of the feature.

If Storyboard can find a way to improve on one or both of these activities, 
that's great. But abandoning Launchpad series and milestones functionality 
without a good replacement isn't a good idea for projects that are using them 
effectively. And for projects that aren't using them, I have to ask whether 
it's because they have a better way of communicating release plans to their 
user/operator communities or if it's because they simply aren't communicating 
release plans.

Generally somebody somewhere is paying for almost all development, so most 
likely somebody wants to know if and when it is/will-be/was done. The simpler 
and more consistent the tooling for communicating that, the less time everyone 
has to spend answering questions from the people who just want to know if 
whatever thing they're waiting on is in progress, on the backlog, or already 
complete.

__
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

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

[Matt Riedemann]

On 6/11/2018 3:31 PM, Doug Hellmann wrote:

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.


I'm reminded of something we talked about in IRC last week wrt tracking 
blueprint-type changes over a given series / release in storyboard. It 
was mentioned that storyboard has a not-yet-implemented epics feature 
which is really how we'd probably do this (nested stories is another way 
of thinking about this). So nova could, for example, have an epic for 
Stein and then track a story for each blueprint, with the old launchpad 
blueprint 'work items' (which we don't use, but we do have a list of 
work items in our specs template) tracked as tasks - which would also be 
nice since you can track tasks like documentation, CLIs (nova and OSC) 
and tempest testing (if required). One thing people always commit to in 
their spec is adding support for the feature in client libraries, 
tempest and docs, but once the nova server side change is merged those 
commitments end up getting dropped (not always, but more often than I'd 
like).


--

Thanks,

Matt

__
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

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

[Matt Riedemann]

On 6/11/2018 3:23 PM, Jeremy Stanley wrote:

If you recall the "specs" experiment years
ago, a few teams tried mildly different solutions for moving from LP
blueprints with random wiki page links to tracking specifications in
Git repositories, and over time they learned successful patterns
from each other and mostly converged on similar solutions. There
were similar cries back then about "how will users/operators find
out what is being planned?" but I think the end result was far
better than what it replaced.


The specs thing was mentioned last week in IRC when talking about 
blueprints in launchpad and I just want to reiterate the specs are more 
about high level designs and reviewing those designs in Gerrit which was 
/ is a major drawback in the 'whiteboard' in launchpad for working on 
blueprints - old blueprints that had a design (if they had a design at 
all) were usually linked from a wiki page.


Anyway, specs are design documents per release. Blueprints in launchpad, 
at least for nova, are the project management tracking tool for that 
release. Not all blueprints require a spec, but all specs require a 
blueprint since specs are generally for API changes or other major 
design changes or features. Just FYI.


--

Thanks,

Matt

__
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

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

[Jeremy Stanley]

On 2018-06-11 15:09:55 -0500 (-0500), Jay S Bryant wrote:
[...]
> Fair enough. It would help if we had buy-in from all of the
> projects but you are right that nothing prevents us from achieving
> consensus from those are are willing to participate.
[...]

Yes, we started out thinking that was going to be the way forward
and eventually learned from that mistake. It's debilitatingly
depressing to work on a project whose intended users keep saying
they want it to be identical to the also-questionably-designed thing
they're currently using because any change in process is some amount
of effort they can avoid by deferring. Refusing to let anyone use SB
year after year because it's wasn't quite ready enough for everybody
(even if it was plenty useful for somebody) resulted in the people
who had been assigned to work on it rage-quit from the endless
negativity being heaped on them.

It was only when it found other potential users outside the
OpenStack ecosystem entirely that new life was breathed into the
project, because it was getting used by somebody who couldn't be
told they weren't allowed. We resolved soon after that to discard
our prior fear of different projects relying on different tools,
realizing that no progress would ever be made if we required
everyone to agree to use it first.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

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

[Doug Hellmann]

Excerpts from CARVER, PAUL's message of 2018-06-11 19:53:47 +:
> Jeremy Stanley  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

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

[Jeremy Stanley]

On 2018-06-11 19:53:47 + (+), CARVER, PAUL wrote:
[...]
> Well, that's a bit rude
[...]

Apologies for the strong language; I did not intend any offense, and
it was indeed unnecessary for purposes of my point.

> So, are you saying the information shown in the examples I gave is
> not useful?

I'm saying as far as OpenStack is concerned, it's not a "standard"
(which was your original claim). A minority of the 40 official
services (so named by the project navigator anyway) are relying on
it and I'd wager far fewer still of the >800 deliverable
repositories maintained by official OpenStack project teams are
either.

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

I think you likely care proportionally more about projects which
have been in the OpenStack ecosystem for longer (this is
unsurprising) and of those quite a few are tracking series/milestone
info in LP because it was integrated with release management once
upon a time (up until a couple years ago) so there was a lot of
pressure, perhaps even a requirement, to do so and old habits die
hard.

Matt R. notes in his reply that as PTL he found using it for
tracking cycle work independent of whether the Release Management
team was still expecting/relying on it, so I don't doubt the
usefulness of having some means of continuing to do that (and with
StoryBoard there are a few ways you could do it but we didn't want
to be proscriptive). Some other teams have found that they prefer a
kanban style tool for this sort of effort instead, but have
unfortunately turned to proprietary services like Trello as a
result.

I also don't think that lack of using the series/milestone tracker
in LP is an indication that a project is doing a worse job of
managing releases. We have a lot more useful automation now around
release notes, highlights, release processes scraping references
from commit logs, and so on.

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

https://docs.openstack.org/infra/storyboard/gui/theory.html#worklists-and-boards

As I said, we didn't want to start out telling teams how
they should be doing their release tracking so that we could see
what patterns emerged. If you recall the "specs" experiment years
ago, a few teams tried mildly different solutions for moving from LP
blueprints with random wiki page links to tracking specifications in
Git repositories, and over time they learned successful patterns
from each other and mostly converged on similar solutions. There
were similar cries back then about "how will users/operators find
out what is being planned?" but I think the end result was far
better than what it replaced.

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

I'm not saying anything should be thrown out. I personally don't
even feel that teams should be forced to use StoryBoard (or any
particular tool for that matter), but just want to focus on making
sure we provide useful, free and open tools through which and on
which we can collectively collaborate.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

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

[Jay S Bryant]

On 6/11/2018 11:54 AM, Doug Hellmann wrote:

Excerpts from Jay S Bryant's message of 2018-06-11 11:42:52 -0500:

On 6/11/2018 11:17 AM, CARVER, PAUL wrote:

Jumping into the general Storyboard topic, but distinct from the previous 
questions about searching, is there any equivalent in Storyboard to the 
Launchpad series and milestones diagrams? e.g.:

https://launchpad.net/nova/+series
https://launchpad.net/neutron/+series
https://launchpad.net/cinder/+series
https://launchpad.net/networking-sfc/+series
https://launchpad.net/bgpvpn/+series

As I understand from what I've read and seen on summit talk recordings, anyone can create 
any view of the data they please and they can share their personalized view with whomever 
they want, but that is basically the complete opposite of standardization. Does 
Storyboard have any plans to provide any standard views that are consistent across 
projects? Or is it focused solely on the "in club" who know what dashboard 
views are custom to each project?

Paul, this is actually one of the big concerns I have with the move to
Storyboard is the fact that there is no longer standardization across
projects.  When I asked about this it was noted that it would be
important for Cinder to document how we use Storyboard so people can
refer to the documentation and know how to use it.  This, however, seems
needlessly complicated. Would have expected how to use Storyboard was
going to be used to be documented/recommended before hand.

I'm not sure what sort of project-specific documentation we think we
need.

Each project team can set up its own board or worklist for a given
series. The "documentation" just needs to point to that thing, right?

Each team may also decide to use a set of tags, and those would need to
be documented, but that's no different from launchpad.
As I understood it, there is no required way to use Storyboard for 
tracking what used to be 'Blueprints'.  So each time will need to 
document how they use Storyboard to record such things.  If I am 
incorrect about this I apologize.

For anyone trying to follow multiple projects at a strategic level (i.e. not 
down in the weeds day to day, but checking in weekly or monthly) to see what's 
planned, what's deferred, and what's completed for either upcoming milestones 
or looking back to see if something did or did not get finished, a consistent 
cross-project UI of some kind is essential.

Agreed.  Wonder if at the next midcycle it would be worth having a cross
project discussion to try and create some consistency.  That, however,
would require buy-in from at least the core projects.

Why? If we have a large number of projects who agree to use the tool a
certain way, that seems good, regardless of whether any specific teams
are included in the group. Let the outliers document their processes, if
they end up being significantly different.
Fair enough.  It would help if we had buy-in from all of the projects 
but you are right that nothing prevents us from achieving consensus from 
those are are willing to participate.

For example, with virtually no insider involvement with Nova, I was able to 
locate this view of what's going on for the Rocky series: 
https://launchpad.net/nova/rocky
How would I locate that same information for a project in Storyboard without 
constructing my own custom worklist or finding an insider to share their 
worklist with me?


__
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

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

[CARVER, PAUL]

Jeremy Stanley  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.


__
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

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

[Matt Riedemann]

On 6/11/2018 1:57 PM, Jeremy Stanley wrote:

So... of the_minority_  of projects (from that arbitrarily-chosen
but presumably "important" sample) who are actually using that
feature, how many of them are simply doing it because they thought
the release team was still making use of that information? (Hint:
they stopped as of mitaka.)


I never used the series/release/milestone stuff for tracking nova 
blueprint deliverables because of the release team, I did it purely for 
project management reasons while I was PTL since it was a clean and easy 
way to track that information, and allowed me to easily gather stats for 
blueprint levels across nova releases.


Otherwise what you said is correct about that totally being per-project 
and dependent on the level of OCD of the release liaison / PTL of that 
project.


--

Thanks,

Matt

__
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

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

[Jeremy Stanley]

Others likely have more detailed answers to some of your other
points, but as for the ones I happen to know off the top of my
head...

On 2018-06-11 12:39:36 -0400 (-0400), Zane Bitter wrote:
[...]
> * There's no help link anywhere. (This appears to be because there's nothing
> to link to.)

It's https://storyboard.openstack.org/#!/page/about (linked as
"About" in the left sidebar of every page on the site) but maybe it
should be renamed and/or given an icon? It's also the default page
view if you go to the site root while not authenticated. It should
probably also link to https://docs.openstack.org/infra/storyboard/ I
guess.

> * There's no way to mark a story as a duplicate of another.

In a twist of irony, this is being tracked in:

https://storyboard.openstack.org/#!/story/2000552
https://storyboard.openstack.org/#!/story/2002136

> * Numeric IDs in URLs instead of project names are a serious barrier to
> usability.
[...]

The change series ending in https://review.openstack.org/548343
implements this, and is basically ready to merge any time now.

> * You can't even use Google to search it, I suspect because only issues that
> are linked to from other sites are visible to the crawler due to there being
> no sitemap.xml.
[...]

There's in-progress work to update storyboard-webclient to newer
AngularJS and as a result the situation related to Web search
engines will get significantly better. Adding a sitemap or similar
index for the benefit of search engines should likely come with or
shortly after that.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

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

[Jeremy Stanley]

On 2018-06-11 17:17:23 + (+), CARVER, PAUL wrote:
[...]
> Perhaps none if there is a standard, but is there a standard? Can
> you give me examples in Storyboard of "standard" views that
> present information even vaguely similar to
> https://launchpad.net/nova/+series and
> https://launchpad.net/nova/rocky ? Or is every project on their
> own to invent the views that they will use, independent of what
> any other project is doing?
[...]

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?

Picking through just the set of 40 "services" listed at
https://www.openstack.org/software/project-navigator I see that:

  * swift seems to stop in mitaka
  * murano in pike
  * freezer in queens
  * solum in liberty
  * aodh in newton
  * senlin in pike
  * ironic in queens (but not really as the series just exist with
no releases after newton)
  * octavia in pike
  * karbor in queens (but not really any detail even then)
  * searchlight in pike
  * barbican in queens (but not really since they stopped showing
releases in pike)
  * panko never used it at all
  * ceilometer stopped in mitaka
  * monasca never used it
  * rally has nonstandard series names but stopped sometime in 2017
  * congress stopped in queens
  * watcher in queens
  * vitrage in queens (but actually stopped milestoning in ocata)
  * cloudkitty has nonstandard series names ending in 2017
  * tricircle stopped using milestones in pike
  * openstack-ansible ended in newton
  * kuryr never used it

So... of the _minority_ of projects (from that arbitrarily-chosen
but presumably "important" sample) who are actually using that
feature, how many of them are simply doing it because they thought
the release team was still making use of that information? (Hint:
they stopped as of mitaka.)
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

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

[CARVER, PAUL]

Doug Hellmann   wrote:


>I'm not sure what sort of project-specific documentation we think we need.
Perhaps none if there is a standard, but is there a standard? Can you give me 
examples in Storyboard of "standard" views that present information even 
vaguely similar to https://launchpad.net/nova/+series and 
https://launchpad.net/nova/rocky ? Or is every project on their own to invent 
the views that they will use, independent of what any other project is doing?

>Each project team can set up its own board or worklist for a given series. The 
>"documentation" just needs to point to that thing, right?
If we're relying on each team to set up its own board or worklist then it 
sounds like there is not a standard. In which case, we're back to the need for 
each project to document (at a minimum) where to find its view and perhaps also 
how to interpret it.

>Each team may also decide to use a set of tags, and those would need to be 
>documented, but that's no different from launchpad.
I agree, use of tags is likely to be team specific, but where can someone find 
those tags without mind-melding with an experienced member of the project?

E.g. If I navigate to the fairly obvious URL: 
https://bugs.launchpad.net/neutron I can see a list of tags on the right side 
of the page, sorted in descending order by frequency of use. On the other hand, 
if I follow the intuitive process of going to https://storyboard.openstack.org 
and clicking on "Project Groups" and then clicking "heat" and then clicking 
"openstack/heat" I reach the somewhat less obvious URL 
https://storyboard.openstack.org/#!/project/989 and no indication at all of 
what tags might be useful in this project.


__
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

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

[Doug Hellmann]

Excerpts from Jay S Bryant's message of 2018-06-11 11:42:52 -0500:
> 
> On 6/11/2018 11:17 AM, CARVER, PAUL wrote:
> > Jumping into the general Storyboard topic, but distinct from the previous 
> > questions about searching, is there any equivalent in Storyboard to the 
> > Launchpad series and milestones diagrams? e.g.:
> >
> > https://launchpad.net/nova/+series
> > https://launchpad.net/neutron/+series
> > https://launchpad.net/cinder/+series
> > https://launchpad.net/networking-sfc/+series
> > https://launchpad.net/bgpvpn/+series
> >
> > As I understand from what I've read and seen on summit talk recordings, 
> > anyone can create any view of the data they please and they can share their 
> > personalized view with whomever they want, but that is basically the 
> > complete opposite of standardization. Does Storyboard have any plans to 
> > provide any standard views that are consistent across projects? Or is it 
> > focused solely on the "in club" who know what dashboard views are custom to 
> > each project?
> Paul, this is actually one of the big concerns I have with the move to 
> Storyboard is the fact that there is no longer standardization across 
> projects.  When I asked about this it was noted that it would be 
> important for Cinder to document how we use Storyboard so people can 
> refer to the documentation and know how to use it.  This, however, seems 
> needlessly complicated. Would have expected how to use Storyboard was 
> going to be used to be documented/recommended before hand.

I'm not sure what sort of project-specific documentation we think we
need.

Each project team can set up its own board or worklist for a given
series. The "documentation" just needs to point to that thing, right?

Each team may also decide to use a set of tags, and those would need to
be documented, but that's no different from launchpad.

> > For anyone trying to follow multiple projects at a strategic level (i.e. 
> > not down in the weeds day to day, but checking in weekly or monthly) to see 
> > what's planned, what's deferred, and what's completed for either upcoming 
> > milestones or looking back to see if something did or did not get finished, 
> > a consistent cross-project UI of some kind is essential.
> Agreed.  Wonder if at the next midcycle it would be worth having a cross 
> project discussion to try and create some consistency.  That, however, 
> would require buy-in from at least the core projects.

Why? If we have a large number of projects who agree to use the tool a
certain way, that seems good, regardless of whether any specific teams
are included in the group. Let the outliers document their processes, if
they end up being significantly different.

> > For example, with virtually no insider involvement with Nova, I was able to 
> > locate this view of what's going on for the Rocky series: 
> > https://launchpad.net/nova/rocky
> > How would I locate that same information for a project in Storyboard 
> > without constructing my own custom worklist or finding an insider to share 
> > their worklist with me?
> >
> 

__
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

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

[Jay S Bryant]

On 6/11/2018 11:17 AM, CARVER, PAUL wrote:

Jumping into the general Storyboard topic, but distinct from the previous 
questions about searching, is there any equivalent in Storyboard to the 
Launchpad series and milestones diagrams? e.g.:

https://launchpad.net/nova/+series
https://launchpad.net/neutron/+series
https://launchpad.net/cinder/+series
https://launchpad.net/networking-sfc/+series
https://launchpad.net/bgpvpn/+series

As I understand from what I've read and seen on summit talk recordings, anyone can create 
any view of the data they please and they can share their personalized view with whomever 
they want, but that is basically the complete opposite of standardization. Does 
Storyboard have any plans to provide any standard views that are consistent across 
projects? Or is it focused solely on the "in club" who know what dashboard 
views are custom to each project?
Paul, this is actually one of the big concerns I have with the move to 
Storyboard is the fact that there is no longer standardization across 
projects.  When I asked about this it was noted that it would be 
important for Cinder to document how we use Storyboard so people can 
refer to the documentation and know how to use it.  This, however, seems 
needlessly complicated. Would have expected how to use Storyboard was 
going to be used to be documented/recommended before hand.

For anyone trying to follow multiple projects at a strategic level (i.e. not 
down in the weeds day to day, but checking in weekly or monthly) to see what's 
planned, what's deferred, and what's completed for either upcoming milestones 
or looking back to see if something did or did not get finished, a consistent 
cross-project UI of some kind is essential.
Agreed.  Wonder if at the next midcycle it would be worth having a cross 
project discussion to try and create some consistency.  That, however, 
would require buy-in from at least the core projects.

For example, with virtually no insider involvement with Nova, I was able to 
locate this view of what's going on for the Rocky series: 
https://launchpad.net/nova/rocky
How would I locate that same information for a project in Storyboard without 
constructing my own custom worklist or finding an insider to share their 
worklist with me?




__
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

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

[Zane Bitter]

On 11/06/18 10:23, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2018-06-11 16:00:41 +0200:

Hi,

On 06/11/2018 03:53 PM, Ruby Loo wrote:

Hi,

I don't want to hijack the initial thread, but am now feeling somewhat guilty
about not being vocal wrt Storyboard. Yes, ironic migrated to Storyboard in the
beginning of this cycle. To date, I have not been pleased with replacing
Launchpad with Storyboard. I believe that Storyboard is somewhat
still-in-progress, and that there were/are some features (stories) that are
outstanding that would make its use better.

  From my point of view (as a developer and core, not a project manager or PTL)
using Storyboard has made my day-to-day work worse. Granted, any migration is
without headaches. But some of the main things, like searching for our RFEs
(that we had tagged in Launchpad) wasn't possible. I haven't yet figured out how
to limit a search to only the 'ironic' project using that 'search' like GUI, so
I have been frustrated trying to find particular bugs that I *knew* existed but
had not memorized the bug number.


Yeah, I cannot fully understand the search. I would expect something explicit
like Launchpad or better something command-based like "project:openstack/ironic
pxe". This does not seem to work, so I also wonder how to filter all stories
affecting a project.



Searching tripped me up for the first couple of weeks, too.
Storyboard's search field is a lot "smarter" than expected. Or maybe
you'd call it "magic". Either way, it was confusing, but you don't have
to use any special syntax in the UI.

To search for a project, type the name of the project in the search
field and then *wait* for the list of drop-down options to appear.
The first item in the list will be a "raw" search for the term. The
others will have little icons indicating their type. The project
icon looks like a little cube, for example.  If I go to
https://storyboard.openstack.org/#!/search and type "openstack/ironic"
I get a list that includes openstack/ironic, openstack/ironic-inspector,
etc.

Select the project you want from the list and hit enter, and you'll
get a list of all of the stories with tasks attached to the project.


Yeah, it's actually pretty powerful, but the UX is a pain. For a 
workflow as common as searching within a project, there should never be 
a step that involves *waiting*. This could be easily fixed: if the user 
is on the page for a project (or project group) and clicks on the search 
tab, the search field should be autopopulated with the project so they 
only have to opt out when they want to search something else, rather 
than opt in every time by typing the project's name again... waiting... 
clicking on one of the inscrutable icons. (Prepopulating in this way 
would also help teach people how the search field works and what the 
little icons mean, so that it wouldn't take weeks to figure out how to 
search within a project even when you have to start from scratch.)


There are a lot of rough edges like this. An issue tracker is an 
incredibly complicated class of application, and projects like Launchpad 
have literally millions of issues tracked, so basically everything that 
could come up has. Storyboard is not at that stage yet.


Some other bugbears:

* There's no help link anywhere. (This appears to be because there's 
nothing to link to.)


* There's no way to mark a story as a duplicate of another.

* Numeric IDs in URLs instead of project names are a serious barrier to 
usability.


* Default query size of 10 unless you (a) are logged in, and (b) 
increased it to something sane in your Profile (pro tip: do this now!) 
makes it really painful to use, especially since the full text search is 
not very accurate, the prev/next arrows appear to be part of a 
competition to make UI elements as tiny as possible(4 pixels wide, and 
even the click target is only 16), and moving between pages is kinda 
slow. Also I changed the setting in my profile the other day, and when I 
logged in again today it had been reset to 10.


* Actually, I just tried scrolling through the project list after 
setting the query size back to 100, and the ranges I got were:

  - 1 to 100 of 344 ok so far
  - 101 to 200 of 344 good good
  - 100101 to 344 of 344 wat

* Actually, *is* there any full-text search? The search page says only 
that you can search for "Keyword in a story or task title". That would 
explain why it's impossible to find most things you're looking for.


* You can't even use Google to search it, I suspect because only issues 
that are linked to from other sites are visible to the crawler due to 
there being no sitemap.xml.


* Showing project groups in reverse chronological order of their 
creation instead of alphabetical order is bizarre.


* Launchpad fields always display in fixed-width fonts with linebreaks 
preserved. Storyboard uses Markdown. The migration process makes no 
attempt to preserve the formatting, so a lot of the 

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

[CARVER, PAUL]

Jumping into the general Storyboard topic, but distinct from the previous 
questions about searching, is there any equivalent in Storyboard to the 
Launchpad series and milestones diagrams? e.g.:

https://launchpad.net/nova/+series
https://launchpad.net/neutron/+series
https://launchpad.net/cinder/+series
https://launchpad.net/networking-sfc/+series
https://launchpad.net/bgpvpn/+series

As I understand from what I've read and seen on summit talk recordings, anyone 
can create any view of the data they please and they can share their 
personalized view with whomever they want, but that is basically the complete 
opposite of standardization. Does Storyboard have any plans to provide any 
standard views that are consistent across projects? Or is it focused solely on 
the "in club" who know what dashboard views are custom to each project?

For anyone trying to follow multiple projects at a strategic level (i.e. not 
down in the weeds day to day, but checking in weekly or monthly) to see what's 
planned, what's deferred, and what's completed for either upcoming milestones 
or looking back to see if something did or did not get finished, a consistent 
cross-project UI of some kind is essential.

For example, with virtually no insider involvement with Nova, I was able to 
locate this view of what's going on for the Rocky series: 
https://launchpad.net/nova/rocky
How would I locate that same information for a project in Storyboard without 
constructing my own custom worklist or finding an insider to share their 
worklist with me?

-- 
Paul Carver
VoIP: 732-545-7377
Cell: 908-803-1656
E: pcar...@att.com
Q Instant Message
If you look closely enough at the present you can find loose bits of the future 
just lying around.



__
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

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

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2018-06-11 16:00:41 +0200:
> Hi,
> 
> On 06/11/2018 03:53 PM, Ruby Loo wrote:
> > Hi,
> > 
> > I don't want to hijack the initial thread, but am now feeling somewhat 
> > guilty 
> > about not being vocal wrt Storyboard. Yes, ironic migrated to Storyboard in 
> > the 
> > beginning of this cycle. To date, I have not been pleased with replacing 
> > Launchpad with Storyboard. I believe that Storyboard is somewhat 
> > still-in-progress, and that there were/are some features (stories) that are 
> > outstanding that would make its use better.
> > 
> >  From my point of view (as a developer and core, not a project manager or 
> > PTL) 
> > using Storyboard has made my day-to-day work worse. Granted, any migration 
> > is 
> > without headaches. But some of the main things, like searching for our RFEs 
> > (that we had tagged in Launchpad) wasn't possible. I haven't yet figured 
> > out how 
> > to limit a search to only the 'ironic' project using that 'search' like 
> > GUI, so 
> > I have been frustrated trying to find particular bugs that I *knew* existed 
> > but 
> > had not memorized the bug number.
> 
> Yeah, I cannot fully understand the search. I would expect something explicit 
> like Launchpad or better something command-based like 
> "project:openstack/ironic 
> pxe". This does not seem to work, so I also wonder how to filter all stories 
> affecting a project.
> 

Searching tripped me up for the first couple of weeks, too.
Storyboard's search field is a lot "smarter" than expected. Or maybe
you'd call it "magic". Either way, it was confusing, but you don't have
to use any special syntax in the UI.

To search for a project, type the name of the project in the search
field and then *wait* for the list of drop-down options to appear.
The first item in the list will be a "raw" search for the term. The
others will have little icons indicating their type. The project
icon looks like a little cube, for example.  If I go to
https://storyboard.openstack.org/#!/search and type "openstack/ironic"
I get a list that includes openstack/ironic, openstack/ironic-inspector,
etc.

Select the project you want from the list and hit enter, and you'll
get a list of all of the stories with tasks attached to the project.

To search based on words in the title or body of the story or task,
just type those and then select the item with the magnifying glass
icon for the "raw" search.

It's not necessary to use search to get a list of open items, though.
You can also navigate directly to a project or group of projects.
For example, by clicking the "Project Groups" icon on the left you
end up at https://storyboard.openstack.org/#!/project_group/list
and by entering "ironic" in the search field there you'll see that
there are 23 projects in the ironic group (wow!). Clicking the name
of the project group will take you to a view showing the current
open items.

I strongly encourage teams to set up worklists or dashboards with
saved searches or manually curated lists of stories or tasks. For
example, the release team uses
https://storyboard.openstack.org/#!/board/64 to keep track of our work
within the cycle.

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

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

[Dmitry Tantsur]

Hi,

On 06/11/2018 03:53 PM, Ruby Loo wrote:

Hi,

I don't want to hijack the initial thread, but am now feeling somewhat guilty 
about not being vocal wrt Storyboard. Yes, ironic migrated to Storyboard in the 
beginning of this cycle. To date, I have not been pleased with replacing 
Launchpad with Storyboard. I believe that Storyboard is somewhat 
still-in-progress, and that there were/are some features (stories) that are 
outstanding that would make its use better.


 From my point of view (as a developer and core, not a project manager or PTL) 
using Storyboard has made my day-to-day work worse. Granted, any migration is 
without headaches. But some of the main things, like searching for our RFEs 
(that we had tagged in Launchpad) wasn't possible. I haven't yet figured out how 
to limit a search to only the 'ironic' project using that 'search' like GUI, so 
I have been frustrated trying to find particular bugs that I *knew* existed but 
had not memorized the bug number.


Yeah, I cannot fully understand the search. I would expect something explicit 
like Launchpad or better something command-based like "project:openstack/ironic 
pxe". This does not seem to work, so I also wonder how to filter all stories 
affecting a project.


Bonus point for giving stories names. They don't even have to be unique, but I 
have something like


 https://storyboard.openstack.org/#!/story/100500-some-readable-slug/

(where 100500 is an actual story ID) it would help my browser locate them in my 
history.




I haven't been as involved upstream this cycle, so perhaps I have missed other 
emails that have mentioned how to get around or do things with Storyboard. I 
would caution folks that are thinking about migrating; I wish we had delayed it 
until there was better support/features/stories implemented with Storyboard. At 
the time, I was also negligent about actually trying out Storyboard before we 
pushed the button (because I assumed it would be ok, others were using it, why 
wouldn't it suffice?) Perhaps Storyboard can address most of my issues now? 
Maybe updated documentation would help? (I believe the last time I tried to use 
Storyboard was 2 weeks ago, when I was 'search'ing for an old bug in Storyboard. 
I gave up.)


I apologize for not writing a detailed email with specific examples of what is 
lacking (for me) and in hindsight should have sent out email at the time I 
encountered issues/had questions. I guess I am hoping that others can 
fill-in-the-blanks and ask for things that would make Storyboard (more) usable.


No, I didn't watch any videos about using Storyboard, just like I've never 
watched any video about using Launchpad, Trello, jira, . I did try 
looking for documentation at some point though and I don't recall finding what I 
was looking for.


--ruby


On Thu, Jun 7, 2018 at 4:25 PM, Kendall Nelson > wrote:


Hello :)

I think that these two goals definitely fit the criteria we discussed in
Vancouver during the S Release Goal Forum Session. I know Storyboard
Migration was also mentioned after I had to dip out to another session so I
wanted to follow up on that.

I know it doesn't fit the shiny user facing docket that was discussed at the
Forum, but I do think its time we make migration official in some capacity
as a release goal or some other way. Having migrated Ironic and having
TripleO on the schedule for migration (as requested during the last goal
discussion) in addition to having migrated Heat, Barbican and several others
in the last few months we have reached the point that I think migration of
the rest of the projects is attainable by the end of Stein.

Thoughts?

-Kendall (diablo_rojo)



__
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

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

[Ruby Loo]

Hi,

I don't want to hijack the initial thread, but am now feeling somewhat
guilty about not being vocal wrt Storyboard. Yes, ironic migrated to
Storyboard in the beginning of this cycle. To date, I have not been pleased
with replacing Launchpad with Storyboard. I believe that Storyboard is
somewhat still-in-progress, and that there were/are some features (stories)
that are outstanding that would make its use better.

>From my point of view (as a developer and core, not a project manager or
PTL) using Storyboard has made my day-to-day work worse. Granted, any
migration is without headaches. But some of the main things, like searching
for our RFEs (that we had tagged in Launchpad) wasn't possible. I haven't
yet figured out how to limit a search to only the 'ironic' project using
that 'search' like GUI, so I have been frustrated trying to find particular
bugs that I *knew* existed but had not memorized the bug number.

I haven't been as involved upstream this cycle, so perhaps I have missed
other emails that have mentioned how to get around or do things with
Storyboard. I would caution folks that are thinking about migrating; I wish
we had delayed it until there was better support/features/stories
implemented with Storyboard. At the time, I was also negligent about
actually trying out Storyboard before we pushed the button (because I
assumed it would be ok, others were using it, why wouldn't it suffice?)
Perhaps Storyboard can address most of my issues now? Maybe updated
documentation would help? (I believe the last time I tried to use
Storyboard was 2 weeks ago, when I was 'search'ing for an old bug in
Storyboard. I gave up.)

I apologize for not writing a detailed email with specific examples of what
is lacking (for me) and in hindsight should have sent out email at the time
I encountered issues/had questions. I guess I am hoping that others can
fill-in-the-blanks and ask for things that would make Storyboard (more)
usable.

No, I didn't watch any videos about using Storyboard, just like I've never
watched any video about using Launchpad, Trello, jira, . I did
try looking for documentation at some point though and I don't recall
finding what I was looking for.

--ruby


On Thu, Jun 7, 2018 at 4:25 PM, Kendall Nelson 
wrote:

> Hello :)
>
> I think that these two goals definitely fit the criteria we discussed in
> Vancouver during the S Release Goal Forum Session. I know Storyboard
> Migration was also mentioned after I had to dip out to another session so I
> wanted to follow up on that.
>
> I know it doesn't fit the shiny user facing docket that was discussed at
> the Forum, but I do think its time we make migration official in some
> capacity as a release goal or some other way. Having migrated Ironic and
> having TripleO on the schedule for migration (as requested during the last
> goal discussion) in addition to having migrated Heat, Barbican and several
> others in the last few months we have reached the point that I think
> migration of the rest of the projects is attainable by the end of Stein.
>
> Thoughts?
>
> -Kendall (diablo_rojo)
>
>
__
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