Open Stack

On Mon, 2018-09-24 at 22:47 +0000, 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&prio
rity=high
[1]: https://storyboard-dev.openstack.org/api/v1/tasks?project_id=574&prio
rity=medium
[2]: https://storyboard-dev.openstack.org/api/v1/tasks?project_id=574&prio
rity=low