Open Stack

Adam Coldrick <adam at sotk.co.uk> writes:

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

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 along when
those people prioritize work on the bugs I file.

Doug