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 __________________________________________________________________________ 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
