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