On Tue, 2018-09-25 at 13:41 -0400, Doug Hellmann wrote:
> Adam Coldrick <a...@sotk.co.uk> 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 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.

I agree that the actual most important opinion is the one held by the
person actually doing the work. Historically we've avoided any ACLs on the
story/task side of things to make things like "Alice sees a low-hanging-
fruit task she can do that some people care about, assigns herself, and
does the work".

Its totally possible to just also add a priority field with a similar lack
of ACLs, but if that priority is assumed to represent the core team's
opinion then someone like Alice being paid to do a bunch of things
upstream needs to track the priorities of the work she is doing elsewhere,
even though she is the one actually doing the work.

There are other benefits to complex/multi-dimensional priority over global
priority fields too, e.g. it forces the person(s) doing the prioritisation
to give consideration to the relative priority of tasks, by nature of
being a collection of ordered lists. I've often seen projects using global
priority end up with every single task marked "Important", to the point
where new priority levels have been introduced once a clearly more
important task was created.

It feels to me like the real issue here is that StoryBoard doesn't
communicate priority well at best, and not at all to a complete outsider.
I feel that we can better solve that by improving how StoryBoard
communicates the priorities people have expressed, than by adding a
special priority field that only certain people are allowed to click on.

To throw out some ideas, it seems to me that although we've avoided ACLs
for things on the whole, we could utilise Teams better to reach some kind
of solution here. I'm envisioning being able to link a Project to a Team,
and then allowing the Team to define a Board which represents the
"official" priorities. Those priorities could then be shown against Tasks
which are in that Project.

This approach keeps the benefits of using multi-dimensional priorities
whilst also solving the problem that priority isn't easily visible to
downstream consumers. It also retains the ability for contributors who are
interested in the priorities expressed by other people/groups to pay
attention to those lists too.

It will enforce a more strictly defined workflow for priority too, I was
imagining something along the lines of using boards with lanes to
represent broad priority categories, with the cards in those lanes
arranged in rough priority order.

- 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

Reply via email to