Adam Coldrick <a...@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 __________________________________________________________________________ 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
