Re: [openstack-dev] [storyboard] Prioritization?

2018-09-27 Thread Ben Nemec



On 9/27/18 4:17 AM, Thierry Carrez wrote:

Ben Nemec wrote:

On 9/25/18 3:29 AM, Thierry Carrez wrote:
Absence of priorities was an initial design choice[1] based on the 
fact that in an open collaboration every group, team, organization 
has their own views on what the priority of a story is, so worklist 
and tags are better ways to capture that. Also they don't really work 
unless you triage everything. And then nobody really looks at them to 
prioritize their work, so they are high cost for little benefit.


So was the storyboard implementation based on the rant section then? 
Because I don't know that I agree with/understand some of the 
assertions there.


First, don't we _need_ to triage everything? At least on some minimal 
level? Not looking at new bugs at all seems like the way you end up 
with a security bug open for two years *ahem*. Not that I would know 
anything about that (it's been fixed now, FTR).


StoryBoard's initial design is definitely tainted by an environment that 
has changed since. Back in 2014, most teams did not triage every bug, 
and were basically using Launchpad as a task tracker (you created the 
bugs that you worked on) rather than a bug tracker (you triage incoming 
requests and prioritize them).


I'm not sure that has actually changed much. Stemming from this thread I 
had an offline discussion around bug management and the gist was that we 
don't actually spend much time looking at the bug list for something to 
work on. I tend to pick up a bug when I hit it in my own environments or 
if I'm doing bug triage and it's something I think I can fix quickly. I 
would like to think that others are more proactive, but I suspect that's 
wishful thinking. I had vague thoughts that I might actually start 
tackling bugs that way this cycle since I spent a lot of last cycle 
getting Oslo bugs triaged so I might be able to repurpose that time, but 
until it actually happens it's just hopes and dreams. :-)


Unfortunately, even if bug triage is a "write once, read never" process 
I think we still need to do it to avoid the case I mentioned above where 
something important falls through the cracks. :-/




Storyboard is therefore designed primarily a task tracker (a way to 
organize work within teams), so it's not great as an issue tracker (a 
way for users to report issues). The tension between the two concepts 
was explored in [1], with the key argument that trying to do both at the 
same time is bound to create frustration one way or another. In PM 
literature you will even find suggestions that the only way to solve the 
diverging requirements is to use two completely different tools (with 
ways to convert a reported issue into a development story). But that 
"solution" works a lot better in environments where the users and the 
developers are completely separated (proprietary software).


[1] https://wiki.openstack.org/wiki/StoryBoard/Vision


[...]
Also, like it or not there is technical debt we're carrying over here. 
All of our bug triage up to this point has been based on launchpad 
priorities, and as I think I noted elsewhere it would be a big step 
backward to completely throw that out. Whatever model for 
prioritization and triage that we choose, I feel like there needs to 
be a reasonable migration path for the thousands of existing triaged 
lp bugs in OpenStack.


I agree, which is why I'm saying that the "right" answer might not be 
the "best" answer.




Yeah, I was mostly just +1'ing your point here. :-)

__
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] [storyboard] Prioritization?

2018-09-27 Thread Thierry Carrez

Ben Nemec wrote:

On 9/25/18 3:29 AM, Thierry Carrez wrote:
Absence of priorities was an initial design choice[1] based on the 
fact that in an open collaboration every group, team, organization has 
their own views on what the priority of a story is, so worklist and 
tags are better ways to capture that. Also they don't really work 
unless you triage everything. And then nobody really looks at them to 
prioritize their work, so they are high cost for little benefit.


So was the storyboard implementation based on the rant section then? 
Because I don't know that I agree with/understand some of the assertions 
there.


First, don't we _need_ to triage everything? At least on some minimal 
level? Not looking at new bugs at all seems like the way you end up with 
a security bug open for two years *ahem*. Not that I would know anything 
about that (it's been fixed now, FTR).


StoryBoard's initial design is definitely tainted by an environment that 
has changed since. Back in 2014, most teams did not triage every bug, 
and were basically using Launchpad as a task tracker (you created the 
bugs that you worked on) rather than a bug tracker (you triage incoming 
requests and prioritize them).


Storyboard is therefore designed primarily a task tracker (a way to 
organize work within teams), so it's not great as an issue tracker (a 
way for users to report issues). The tension between the two concepts 
was explored in [1], with the key argument that trying to do both at the 
same time is bound to create frustration one way or another. In PM 
literature you will even find suggestions that the only way to solve the 
diverging requirements is to use two completely different tools (with 
ways to convert a reported issue into a development story). But that 
"solution" works a lot better in environments where the users and the 
developers are completely separated (proprietary software).


[1] https://wiki.openstack.org/wiki/StoryBoard/Vision


[...]
Also, like it or not there is technical debt we're carrying over here. 
All of our bug triage up to this point has been based on launchpad 
priorities, and as I think I noted elsewhere it would be a big step 
backward to completely throw that out. Whatever model for prioritization 
and triage that we choose, I feel like there needs to be a reasonable 
migration path for the thousands of existing triaged lp bugs in OpenStack.


I agree, which is why I'm saying that the "right" answer might not be 
the "best" answer.


--
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] [storyboard] Prioritization?

2018-09-26 Thread Kendall Nelson
On Wed, Sep 26, 2018 at 9:50 AM Ben Nemec  wrote:

>
>
> On 9/25/18 3:29 AM, Thierry Carrez wrote:
> > Doug Hellmann wrote:
> >> I think we need to reconsider that position if it's going to block
> >> adoption. I think Ben's case is an excellent second example of where
> >> having a field to hold some sort of priority value would be useful.
> >
> > Absence of priorities was an initial design choice[1] based on the fact
> > that in an open collaboration every group, team, organization has their
> > own views on what the priority of a story is, so worklist and tags are
> > better ways to capture that. Also they don't really work unless you
> > triage everything. And then nobody really looks at them to prioritize
> > their work, so they are high cost for little benefit.
>
> So was the storyboard implementation based on the rant section then?
> Because I don't know that I agree with/understand some of the assertions
> there.
>
> First, don't we _need_ to triage everything? At least on some minimal
> level? Not looking at new bugs at all seems like the way you end up with
> a security bug open for two years *ahem*. Not that I would know anything
> about that (it's been fixed now, FTR).
>
> I'm also not sure I agree with the statement that setting a priority for
> a blueprint is useless. Prioritizing feature work is something everyone
> needs to do these days since no team has enough people to implement
> every proposed feature. Maybe the proposal is for everyone to adopt
> Nova-style runways, but I'm not sure how well that works for smaller
> projects where many of the developers are only able to devote part of
> their time to it. Setting a time window for a feature to merge or get
> kicked to the back of line would be problematic for me.
>
> That section also ends with an unanswered question regarding how to do
> bug triage in this model, which I guess is the thing we're trying to
> address with this discussion.
>
> >
> > That said, it definitely creates friction, because alternatives are less
> > convenient / visible, and it's not how other tools work... so the
> > "right" answer here may not be the "best" answer.
> >
> > [1] https://wiki.openstack.org/wiki/StoryBoard/Priority
> >
>
> Also, like it or not there is technical debt we're carrying over here.
> All of our bug triage up to this point has been based on launchpad
> priorities, and as I think I noted elsewhere it would be a big step
> backward to completely throw that out. Whatever model for prioritization
> and triage that we choose, I feel like there needs to be a reasonable
> migration path for the thousands of existing triaged lp bugs in OpenStack.
>

The information is being migrated[1], we just don't expose it in the
webclient. You could still access the info via the API.


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



-Kendall (diablo_rojo)

[1]
https://github.com/openstack-infra/storyboard/blob/master/storyboard/migrate/launchpad/writer.py#L183
__
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] [storyboard] Prioritization?

2018-09-26 Thread Ben Nemec



On 9/25/18 3:29 AM, Thierry Carrez wrote:

Doug Hellmann wrote:

I think we need to reconsider that position if it's going to block
adoption. I think Ben's case is an excellent second example of where
having a field to hold some sort of priority value would be useful.


Absence of priorities was an initial design choice[1] based on the fact 
that in an open collaboration every group, team, organization has their 
own views on what the priority of a story is, so worklist and tags are 
better ways to capture that. Also they don't really work unless you 
triage everything. And then nobody really looks at them to prioritize 
their work, so they are high cost for little benefit.


So was the storyboard implementation based on the rant section then? 
Because I don't know that I agree with/understand some of the assertions 
there.


First, don't we _need_ to triage everything? At least on some minimal 
level? Not looking at new bugs at all seems like the way you end up with 
a security bug open for two years *ahem*. Not that I would know anything 
about that (it's been fixed now, FTR).


I'm also not sure I agree with the statement that setting a priority for 
a blueprint is useless. Prioritizing feature work is something everyone 
needs to do these days since no team has enough people to implement 
every proposed feature. Maybe the proposal is for everyone to adopt 
Nova-style runways, but I'm not sure how well that works for smaller 
projects where many of the developers are only able to devote part of 
their time to it. Setting a time window for a feature to merge or get 
kicked to the back of line would be problematic for me.


That section also ends with an unanswered question regarding how to do 
bug triage in this model, which I guess is the thing we're trying to 
address with this discussion.




That said, it definitely creates friction, because alternatives are less 
convenient / visible, and it's not how other tools work... so the 
"right" answer here may not be the "best" answer.


[1] https://wiki.openstack.org/wiki/StoryBoard/Priority



Also, like it or not there is technical debt we're carrying over here. 
All of our bug triage up to this point has been based on launchpad 
priorities, and as I think I noted elsewhere it would be a big step 
backward to completely throw that out. Whatever model for prioritization 
and triage that we choose, I feel like there needs to be a reasonable 
migration path for the thousands of existing triaged lp bugs in OpenStack.


__
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] [storyboard] Prioritization?

2018-09-26 Thread Jim Rollenhagen
On Wed, Sep 26, 2018 at 8:17 AM Adam Coldrick  wrote:

> On Tue, 2018-09-25 at 18:40 +, CARVER, PAUL wrote:
> [...]
> > There is certainly room for additional means of juggling and
> > discussing/negotiating priorities in the stages before work really gets
> > under way, but if it doesn't eventually become clear
> >
> > 1) who's doing the work
> > 2) when are they targeting completion
> > 3) what (if anything) is higher up on their todo list
>
> Its entirely possible to track these three things in StoryBoard today, and
> for other people to view that information.
>
> 1) Task assignee, though this should be set when someone actually starts
> doing the work rather than being used to indicate "$person intends to do
> this at some point"
> 2) Due date on a card in a board
> 3) Lanes in that board ordered by priority
>

I, for one, would not want to scroll through every lane on a large
project's bug board to find the priority or target date for a given bug.
For example, Nova has 819 open bugs right now.

It would be a much better user experience to be able to open a specific bug
and see the priority or target date.

// jim
__
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] [storyboard] Prioritization?

2018-09-26 Thread Adam Coldrick
On Tue, 2018-09-25 at 18:40 +, CARVER, PAUL wrote:
[...]
> There is certainly room for additional means of juggling and
> discussing/negotiating priorities in the stages before work really gets
> under way, but if it doesn't eventually become clear
> 
> 1) who's doing the work
> 2) when are they targeting completion
> 3) what (if anything) is higher up on their todo list

Its entirely possible to track these three things in StoryBoard today, and
for other people to view that information.

1) Task assignee, though this should be set when someone actually starts
doing the work rather than being used to indicate "$person intends to do
this at some point"
2) Due date on a card in a board
3) Lanes in that board ordered by priority

The latter two assume that the person doing the work is using a board to
track what they're doing, which is probably sensible behaviour we should
encourage.

Its admittedly difficult for downstream consumers to quickly find the
board-related information, but I think that is a discoverability bug (it
doesn't currently become clear where exactly these things can be found)
rather than a fundamental issue which means we should just abandon the
multi-dimensional approach.

> then it's impossible for anyone else to make any sort of plans that
> depend on that work. Plans could include figuring out how to add more
> resources or contingency plans. It's also possible that people or
> projects may develop a reputation for not delivering on their stated top
> priorities, but that's at least better than having no idea what the
> priorities are because every person and project is making up their own
> system for tracking it.

I would argue that someone who wants to make plans based on upstream work
that may or may not get done should be taking the time (which should at
worst be something like "reading the docs to find a link to a
worklist/board" even with the current implementation) to understand how
upstream are expressing the state of their work, though I can understand
why they might not always want to. I definitely think that defining an
"official"-ish approach is something that should probably be done, to
reduce the cognitive load on newcomers.

- Adam

__
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] [storyboard] Prioritization?

2018-09-26 Thread Adam Coldrick
On Tue, 2018-09-25 at 13:41 -0400, Doug Hellmann wrote:
> Adam Coldrick  writes:
> > For tasks I am less concerned in that aspect since cross-project
> > support
> > isn't hurt, but remain of the opinion that a global field is the wrong
> > approach since it means that only one person (or group of people) gets
> > to
> > visibly express their opinion on the priority of the task.
> 
> While I agree that not everyone attaches the same priority to a given
> task, and it's important for everyone to be able to have their own say
> in the relative importance of tasks/stories, I think it's more important
> than you're crediting for downstream consumers to have a consistent way
> to understand the priority attached by the person(s) doing the
> implementation work.

I think you're right. The existing implementation hasn't really considered
the case of a downstream consumer unused to the differences in StoryBoard
just turning up at the task tracker to find out something like "what are
the priorities of the oslo team?", and it shows in how undiscoverable to
an outsider that is no matter which of the workflows we suggest is being
used.

> > Allowing multiple groups to express opinions on the priority of the
> > same
> > tasks allows situations where (to use a real world example I saw
> > recently,
> > but not in OpenStack) an upstream project marks a bug as medium
> > priority
> > for whatever reason, but a downstream user of that project is
> > completely
> > broken by that bug, meaning either providing a fix to it or persuading
> > someone else to is of critical importance to them.
> 
> This example is excellent, and I think it supports my position.

I can see that, but I also don't think our positions are entirely
incompatible. In the example, the downstream user was one of the main
users of the upstream project and there was some contributor overlap.

In my ideal world the downstream project would've expressed the priority
in a worklist or board that upstream people were subscribed (or otherwise
paying attention) to. Then, the upstream project would've set their
priority in a board or worklist which the downstream folk also pay
attention to somehow (since they are interested in how upstream are
prioritising work). This way a contributor interested in the priorities of
both projects could see the overlap, and perhaps use that to decide what
to work on next. Also, since downstream have a way to pay attention to
upstream's priority, they can see the low "official" priority and go and
have any discussions needed.

> An important area where using boards or worklists falls short of my own
> needs is that, as far as I know, it is not possible to subscribe to
> notifications for when a story or task is added to a list or board. So
> as a person who submits a story, I have no way of knowing when the
> team(s) working on it add it to (or remove it from) a priority list or
> change its priority by moving it to a different lane in a board.
> Communicating about what we're doing is as important as gathering and
> tracking the list of tasks in the first place. Without a notification
> that the priority of a story or task has been lowered, how would I know
> that I need to go try to persuade the team responsible to raise it back
> up?

It is indeed not possible for the scenario I describe above to work neatly
in StoryBoard today, because boards and worklists don't give
notifications. That's because we've not got round to finishing that part
of the implementation yet, rather than by design.

Worklists do currently generate history of changes made to them, there is
just no good way to see it anywhere and no notifications sent based on it.

> Even if we add (or there is) some way for me to receive a notification
> based on board or list membership, without a real priority field we have
> several different ways to express priority (different tag names, a
> single worklist that's kept in order, a board with separate columns for
> each status, etc.). That means each team could potentially use a
> different way, which in turn means downstream consumers have to
> discover, understand, and subscribe to all of those various ways, and
> use them correctly, for every team they are tracking. I think that's an
> unreasonable burden to place on someone who is not working in the
> community constantly, as is the case for many of our operators who
> report bugs.

This is the part I've not really considered before for StoryBoard. Perhaps
we should've been defining an "official" prioritisation workflow and
trying to make that discoverable.

> > With global priority there is a trade-off, either the bug tracker
> > displays
> > priorities with no reference as to who they are important to,
> > downstream
> > duplicate the issue elsewhere to track their priority, or their
> > expression
> > of how important the issue is is lost in a comment in order to
> > maintain
> > the state of "all priorities are determined by the core team".
> 
> I suppose that 

Re: [openstack-dev] [storyboard] Prioritization?

2018-09-25 Thread CARVER, PAUL


Doug Hellmann   wrote:

>If we're just throwing data into it without trying to use it to communicate, 
>then I can see us having lots of different views of priority with
>the same level of "official-ness". I don't think that's what we're doing 
>though. I think we're trying to help teams track what they've 
>committed to do and *communicate* those commitments to folks outside of the 
>team. And from that perspective, the most important 
>definition of "priority" is the one attached by the person(s) doing the work. 
>That's not the same as saying no one else's opinion about 
>priority matters, but it does ultimately come down someone actually doing one 
>task before another. And I would like to be able to follow 
>along when those people prioritize work on the bugs I file.

I agree. Different people certainly may prioritize the same thing differently, 
but there are far more consumers of software than there are producers and the 
most important thing a consumer wants to know (about a feature that they're 
eagerly awaiting) is what is the priority of that feature to whoever is doing 
the work of implementing it.

There is certainly room for additional means of juggling and 
discussing/negotiating priorities in the stages before work really gets under 
way, but if it doesn't eventually become clear

1) who's doing the work
2) when are they targeting completion
3) what (if anything) is higher up on their todo list

then it's impossible for anyone else to make any sort of plans that depend on 
that work. Plans could include figuring out how to add more resources or 
contingency plans. It's also possible that people or projects may develop a 
reputation for not delivering on their stated top priorities, but that's at 
least better than having no idea what the priorities are because every person 
and project is making up their own system for tracking it.
__
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] [storyboard] Prioritization?

2018-09-25 Thread Doug Hellmann
Adam Coldrick  writes:

> On Mon, 2018-09-24 at 22:47 +, Jeremy Stanley wrote:
>> On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
>> [...]
>> > At the PTG there was feedback from at least one team that
>> > consumers of the data in storyboard want a priority setting on
>> > each story. Historically the response to that has been that
>> > different users will have different priorities, so each of them
>> > using worklists is the best way to support those differences of
>> > opinion.
>> > 
>> > I think we need to reconsider that position if it's going to block
>> > adoption. I think Ben's case is an excellent second example of
>> > where having a field to hold some sort of priority value would be
>> > useful.
>
> I'm strongly against reverting to having a single global priority value
> for things in StoryBoard, especially so for stories as opposed to tasks.
> Having a single global priority field for stories at best implies that a
> cross-project story has the same priority in each project, and at worst
> means cross-project discussions need to occur to find an agreement on an
> acceptable priority (or one affected project's opinion overrules the
> others, with the others' priorities becoming harder to understand at a
> glance or just completely lost).

I would be fine with 1 field per task.

> For tasks I am less concerned in that aspect since cross-project support
> isn't hurt, but remain of the opinion that a global field is the wrong
> approach since it means that only one person (or group of people) gets to
> visibly express their opinion on the priority of the task.

While I agree that not everyone attaches the same priority to a given
task, and it's important for everyone to be able to have their own say
in the relative importance of tasks/stories, I think it's more important
than you're crediting for downstream consumers to have a consistent way
to understand the priority attached by the person(s) doing the
implementation work.

> Allowing multiple groups to express opinions on the priority of the same
> tasks allows situations where (to use a real world example I saw recently,
> but not in OpenStack) an upstream project marks a bug as medium priority
> for whatever reason, but a downstream user of that project is completely
> broken by that bug, meaning either providing a fix to it or persuading
> someone else to is of critical importance to them.

This example is excellent, and I think it supports my position.

An important area where using boards or worklists falls short of my own
needs is that, as far as I know, it is not possible to subscribe to
notifications for when a story or task is added to a list or board. So
as a person who submits a story, I have no way of knowing when the
team(s) working on it add it to (or remove it from) a priority list or
change its priority by moving it to a different lane in a board.
Communicating about what we're doing is as important as gathering and
tracking the list of tasks in the first place. Without a notification
that the priority of a story or task has been lowered, how would I know
that I need to go try to persuade the team responsible to raise it back
up?

Even if we add (or there is) some way for me to receive a notification
based on board or list membership, without a real priority field we have
several different ways to express priority (different tag names, a
single worklist that's kept in order, a board with separate columns for
each status, etc.). That means each team could potentially use a
different way, which in turn means downstream consumers have to
discover, understand, and subscribe to all of those various ways, and
use them correctly, for every team they are tracking. I think that's an
unreasonable burden to place on someone who is not working in the
community constantly, as is the case for many of our operators who
report bugs.

> With global priority there is a trade-off, either the bug tracker displays
> priorities with no reference as to who they are important to, downstream
> duplicate the issue elsewhere to track their priority, or their expression
> of how important the issue is is lost in a comment in order to maintain
> the state of "all priorities are determined by the core team".

I suppose that depends on the reason we're using the task tracker.

If we're just throwing data into it without trying to use it to
communicate, then I can see us having lots of different views of
priority with the same level of "official-ness". I don't think that's
what we're doing though. I think we're trying to help teams track what
they've committed to do and *communicate* those commitments to folks
outside of the team. And from that perspective, the most important
definition of "priority" is the one attached by the person(s) doing the
work. That's not the same as saying no one else's opinion about priority
matters, but it does ultimately come down someone actually doing one
task before another. And I would like to be able to follow 

Re: [openstack-dev] [storyboard] Prioritization?

2018-09-25 Thread Adam Coldrick
On Mon, 2018-09-24 at 22:47 +, Jeremy Stanley wrote:
> On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > At the PTG there was feedback from at least one team that
> > consumers of the data in storyboard want a priority setting on
> > each story. Historically the response to that has been that
> > different users will have different priorities, so each of them
> > using worklists is the best way to support those differences of
> > opinion.
> > 
> > I think we need to reconsider that position if it's going to block
> > adoption. I think Ben's case is an excellent second example of
> > where having a field to hold some sort of priority value would be
> > useful.

I'm strongly against reverting to having a single global priority value
for things in StoryBoard, especially so for stories as opposed to tasks.
Having a single global priority field for stories at best implies that a
cross-project story has the same priority in each project, and at worst
means cross-project discussions need to occur to find an agreement on an
acceptable priority (or one affected project's opinion overrules the
others, with the others' priorities becoming harder to understand at a
glance or just completely lost).

For tasks I am less concerned in that aspect since cross-project support
isn't hurt, but remain of the opinion that a global field is the wrong
approach since it means that only one person (or group of people) gets to
visibly express their opinion on the priority of the task.

Allowing multiple groups to express opinions on the priority of the same
tasks allows situations where (to use a real world example I saw recently,
but not in OpenStack) an upstream project marks a bug as medium priority
for whatever reason, but a downstream user of that project is completely
broken by that bug, meaning either providing a fix to it or persuading
someone else to is of critical importance to them.

With global priority there is a trade-off, either the bug tracker displays
priorities with no reference as to who they are important to, downstream
duplicate the issue elsewhere to track their priority, or their expression
of how important the issue is is lost in a comment in order to maintain
the state of "all priorities are determined by the core team".

> The alternative suggestion, for teams who want to be able to flag
> some sort of bucketed priorities, is to use story tags. We could
> even improve the import tool to accept some sort of
> priority-to-tag-name mapping so that, say, when we import bugs for
> Oslo their oslo-critical tag is applied to any with a critical
> bugtask, oslo-medium to any with medium priority tasks, and so on.
> Not all teams using StoryBoard will want to have a bucketed priority
> scheme, and those who do won't necessarily want to use the same
> number or kinds of priorities.

This approach will work fine, but as far as I can tell the only benefit of
this rather than just creating say a board with a lane for each priority
bucket is better discoverability when browsing stories. In my opinion that
is a bug in our browse/search implementation, and the story list should be
able to be filtered by worklist or board. Using this as a workaround is
sensible, but I think I'd rather encourage the recommended workflow of
tracking priority in ordered worklists or boards.

In my eyes the correct solution to Ben's issue of losing all the priority
information is to cause the migration scripts to create (or allow an
existing board to be specified) a board with lanes representing the
different Launchpad priorities used, and populate it accordingly.

Its probably also worth noting that the database still tracks the
deprecated task-level global priority, and the migration script imports
priority data into that field, so it would be possible to write a script
to interrogate the API and build such a board post-migration. See [0],
[1], and [2] for example. I would strongly advise against actively using
the existing global priority field for tracking priority though, since it
is deprecated and the intent is for it to go away at some point.

In general I think most of the complaints about complex priority vs global
priority that I've seen can be reduced to issues with how the complex
priority approach as implemented in StoryBoard makes it somewhat harder to
actually discover what people think about the priority of things, and the
inability to order search results by priority. I believe that can be
solved by improving our implementation, rather than falling back to a
flawed global priority approach.

- Adam


[0]: https://storyboard-dev.openstack.org/api/v1/tasks?project_id=574
rity=high
[1]: https://storyboard-dev.openstack.org/api/v1/tasks?project_id=574
rity=medium
[2]: https://storyboard-dev.openstack.org/api/v1/tasks?project_id=574
rity=low

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [storyboard] Prioritization?

2018-09-25 Thread Thierry Carrez

Doug Hellmann wrote:

I think we need to reconsider that position if it's going to block
adoption. I think Ben's case is an excellent second example of where
having a field to hold some sort of priority value would be useful.


Absence of priorities was an initial design choice[1] based on the fact 
that in an open collaboration every group, team, organization has their 
own views on what the priority of a story is, so worklist and tags are 
better ways to capture that. Also they don't really work unless you 
triage everything. And then nobody really looks at them to prioritize 
their work, so they are high cost for little benefit.


That said, it definitely creates friction, because alternatives are less 
convenient / visible, and it's not how other tools work... so the 
"right" answer here may not be the "best" answer.


[1] https://wiki.openstack.org/wiki/StoryBoard/Priority

--
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] [storyboard] Prioritization?

2018-09-24 Thread Jeremy Stanley
On 2018-09-24 19:31:17 -0400 (-0400), Doug Hellmann wrote:
> That came up as a suggestion, too. The challenge there is that we
> cannot (as far as I know) sort on tags. So even if we have tags,
> we can't create a list of stories that is ordered automatically
> based on the priority. Maybe there's a solution to that?

A board with automatic lanes for each priority tag? That way you can
also have a lane for "stories with incomplete tasks for projects in
my project-group but which haven't been prioritized yet" and be able
to act on/triage them accordingly.
-- 
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] [storyboard] Prioritization?

2018-09-24 Thread Doug Hellmann
Jeremy Stanley  writes:

> On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> At the PTG there was feedback from at least one team that
>> consumers of the data in storyboard want a priority setting on
>> each story. Historically the response to that has been that
>> different users will have different priorities, so each of them
>> using worklists is the best way to support those differences of
>> opinion.
>> 
>> I think we need to reconsider that position if it's going to block
>> adoption. I think Ben's case is an excellent second example of
>> where having a field to hold some sort of priority value would be
>> useful.
>
> The alternative suggestion, for teams who want to be able to flag
> some sort of bucketed priorities, is to use story tags. We could
> even improve the import tool to accept some sort of
> priority-to-tag-name mapping so that, say, when we import bugs for
> Oslo their oslo-critical tag is applied to any with a critical
> bugtask, oslo-medium to any with medium priority tasks, and so on.
> Not all teams using StoryBoard will want to have a bucketed priority
> scheme, and those who do won't necessarily want to use the same
> number or kinds of priorities.

That came up as a suggestion, too. The challenge there is that we cannot
(as far as I know) sort on tags. So even if we have tags, we can't
create a list of stories that is ordered automatically based on the
priority. Maybe there's a solution to that?

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] [storyboard] Prioritization?

2018-09-24 Thread Jeremy Stanley
On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote:
[...]
> At the PTG there was feedback from at least one team that
> consumers of the data in storyboard want a priority setting on
> each story. Historically the response to that has been that
> different users will have different priorities, so each of them
> using worklists is the best way to support those differences of
> opinion.
> 
> I think we need to reconsider that position if it's going to block
> adoption. I think Ben's case is an excellent second example of
> where having a field to hold some sort of priority value would be
> useful.

The alternative suggestion, for teams who want to be able to flag
some sort of bucketed priorities, is to use story tags. We could
even improve the import tool to accept some sort of
priority-to-tag-name mapping so that, say, when we import bugs for
Oslo their oslo-critical tag is applied to any with a critical
bugtask, oslo-medium to any with medium priority tasks, and so on.
Not all teams using StoryBoard will want to have a bucketed priority
scheme, and those who do won't necessarily want to use the same
number or kinds of priorities.
-- 
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] [storyboard] Prioritization?

2018-09-24 Thread Doug Hellmann
Ben Nemec  writes:

> Hi,
>
> This came up in the Oslo meeting as a result of my initial look at the 
> test Storyboard import. It appears all of the priority data from 
> launchpad gets lost in the migration, which is going to make organizing 
> hundreds of bugs somewhat difficult. I'm particularly not fond of it 
> after spending last cycle whittling down our untriaged bug list. :-)
>
> Work lists and tags were mentioned as possible priority management tools 
> in Storyboard, so is there some way to migrate launchpad priorities into 
> one of those automatically? If not, are there any plans to add that?
>
> It sounded like a similar conversation is happening with a few other 
> teams so we wanted to bring the discussion to the mailing list for 
> visibility.
>
> Thanks.
>
> -Ben

At the PTG there was feedback from at least one team that consumers of
the data in storyboard want a priority setting on each
story. Historically the response to that has been that different users
will have different priorities, so each of them using worklists is the
best way to support those differences of opinion.

I think we need to reconsider that position if it's going to block
adoption. I think Ben's case is an excellent second example of where
having a field to hold some sort of priority value would be useful.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [storyboard] Prioritization?

2018-09-24 Thread Ben Nemec

Hi,

This came up in the Oslo meeting as a result of my initial look at the 
test Storyboard import. It appears all of the priority data from 
launchpad gets lost in the migration, which is going to make organizing 
hundreds of bugs somewhat difficult. I'm particularly not fond of it 
after spending last cycle whittling down our untriaged bug list. :-)


Work lists and tags were mentioned as possible priority management tools 
in Storyboard, so is there some way to migrate launchpad priorities into 
one of those automatically? If not, are there any plans to add that?


It sounded like a similar conversation is happening with a few other 
teams so we wanted to bring the discussion to the mailing list for 
visibility.


Thanks.

-Ben

__
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