Re: [openstack-dev] [storyboard] Prioritization?
On 9/27/18 4:17 AM, Thierry Carrez wrote: Ben Nemec wrote: On 9/25/18 3:29 AM, Thierry Carrez wrote: Absence of priorities was an initial design choice[1] based on the fact that in an open collaboration every group, team, organization has their own views on what the priority of a story is, so worklist and tags are better ways to capture that. Also they don't really work unless you triage everything. And then nobody really looks at them to prioritize their work, so they are high cost for little benefit. So was the storyboard implementation based on the rant section then? Because I don't know that I agree with/understand some of the assertions there. First, don't we _need_ to triage everything? At least on some minimal level? Not looking at new bugs at all seems like the way you end up with a security bug open for two years *ahem*. Not that I would know anything about that (it's been fixed now, FTR). StoryBoard's initial design is definitely tainted by an environment that has changed since. Back in 2014, most teams did not triage every bug, and were basically using Launchpad as a task tracker (you created the bugs that you worked on) rather than a bug tracker (you triage incoming requests and prioritize them). I'm not sure that has actually changed much. Stemming from this thread I had an offline discussion around bug management and the gist was that we don't actually spend much time looking at the bug list for something to work on. I tend to pick up a bug when I hit it in my own environments or if I'm doing bug triage and it's something I think I can fix quickly. I would like to think that others are more proactive, but I suspect that's wishful thinking. I had vague thoughts that I might actually start tackling bugs that way this cycle since I spent a lot of last cycle getting Oslo bugs triaged so I might be able to repurpose that time, but until it actually happens it's just hopes and dreams. :-) Unfortunately, even if bug triage is a "write once, read never" process I think we still need to do it to avoid the case I mentioned above where something important falls through the cracks. :-/ Storyboard is therefore designed primarily a task tracker (a way to organize work within teams), so it's not great as an issue tracker (a way for users to report issues). The tension between the two concepts was explored in [1], with the key argument that trying to do both at the same time is bound to create frustration one way or another. In PM literature you will even find suggestions that the only way to solve the diverging requirements is to use two completely different tools (with ways to convert a reported issue into a development story). But that "solution" works a lot better in environments where the users and the developers are completely separated (proprietary software). [1] https://wiki.openstack.org/wiki/StoryBoard/Vision [...] Also, like it or not there is technical debt we're carrying over here. All of our bug triage up to this point has been based on launchpad priorities, and as I think I noted elsewhere it would be a big step backward to completely throw that out. Whatever model for prioritization and triage that we choose, I feel like there needs to be a reasonable migration path for the thousands of existing triaged lp bugs in OpenStack. I agree, which is why I'm saying that the "right" answer might not be the "best" answer. Yeah, I was mostly just +1'ing your point here. :-) __ 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
Re: [openstack-dev] [storyboard] Prioritization?
Ben Nemec wrote: On 9/25/18 3:29 AM, Thierry Carrez wrote: Absence of priorities was an initial design choice[1] based on the fact that in an open collaboration every group, team, organization has their own views on what the priority of a story is, so worklist and tags are better ways to capture that. Also they don't really work unless you triage everything. And then nobody really looks at them to prioritize their work, so they are high cost for little benefit. So was the storyboard implementation based on the rant section then? Because I don't know that I agree with/understand some of the assertions there. First, don't we _need_ to triage everything? At least on some minimal level? Not looking at new bugs at all seems like the way you end up with a security bug open for two years *ahem*. Not that I would know anything about that (it's been fixed now, FTR). StoryBoard's initial design is definitely tainted by an environment that has changed since. Back in 2014, most teams did not triage every bug, and were basically using Launchpad as a task tracker (you created the bugs that you worked on) rather than a bug tracker (you triage incoming requests and prioritize them). Storyboard is therefore designed primarily a task tracker (a way to organize work within teams), so it's not great as an issue tracker (a way for users to report issues). The tension between the two concepts was explored in [1], with the key argument that trying to do both at the same time is bound to create frustration one way or another. In PM literature you will even find suggestions that the only way to solve the diverging requirements is to use two completely different tools (with ways to convert a reported issue into a development story). But that "solution" works a lot better in environments where the users and the developers are completely separated (proprietary software). [1] https://wiki.openstack.org/wiki/StoryBoard/Vision [...] Also, like it or not there is technical debt we're carrying over here. All of our bug triage up to this point has been based on launchpad priorities, and as I think I noted elsewhere it would be a big step backward to completely throw that out. Whatever model for prioritization and triage that we choose, I feel like there needs to be a reasonable migration path for the thousands of existing triaged lp bugs in OpenStack. I agree, which is why I'm saying that the "right" answer might not be the "best" answer. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [storyboard] Prioritization?
On Wed, Sep 26, 2018 at 9:50 AM Ben Nemec wrote: > > > On 9/25/18 3:29 AM, Thierry Carrez wrote: > > Doug Hellmann wrote: > >> 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. > > > > Absence of priorities was an initial design choice[1] based on the fact > > that in an open collaboration every group, team, organization has their > > own views on what the priority of a story is, so worklist and tags are > > better ways to capture that. Also they don't really work unless you > > triage everything. And then nobody really looks at them to prioritize > > their work, so they are high cost for little benefit. > > So was the storyboard implementation based on the rant section then? > Because I don't know that I agree with/understand some of the assertions > there. > > First, don't we _need_ to triage everything? At least on some minimal > level? Not looking at new bugs at all seems like the way you end up with > a security bug open for two years *ahem*. Not that I would know anything > about that (it's been fixed now, FTR). > > I'm also not sure I agree with the statement that setting a priority for > a blueprint is useless. Prioritizing feature work is something everyone > needs to do these days since no team has enough people to implement > every proposed feature. Maybe the proposal is for everyone to adopt > Nova-style runways, but I'm not sure how well that works for smaller > projects where many of the developers are only able to devote part of > their time to it. Setting a time window for a feature to merge or get > kicked to the back of line would be problematic for me. > > That section also ends with an unanswered question regarding how to do > bug triage in this model, which I guess is the thing we're trying to > address with this discussion. > > > > > That said, it definitely creates friction, because alternatives are less > > convenient / visible, and it's not how other tools work... so the > > "right" answer here may not be the "best" answer. > > > > [1] https://wiki.openstack.org/wiki/StoryBoard/Priority > > > > Also, like it or not there is technical debt we're carrying over here. > All of our bug triage up to this point has been based on launchpad > priorities, and as I think I noted elsewhere it would be a big step > backward to completely throw that out. Whatever model for prioritization > and triage that we choose, I feel like there needs to be a reasonable > migration path for the thousands of existing triaged lp bugs in OpenStack. > The information is being migrated[1], we just don't expose it in the webclient. You could still access the info via the API. > __ > 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 -Kendall (diablo_rojo) [1] https://github.com/openstack-infra/storyboard/blob/master/storyboard/migrate/launchpad/writer.py#L183 __ 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
Re: [openstack-dev] [storyboard] Prioritization?
On 9/25/18 3:29 AM, Thierry Carrez wrote: Doug Hellmann wrote: 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. Absence of priorities was an initial design choice[1] based on the fact that in an open collaboration every group, team, organization has their own views on what the priority of a story is, so worklist and tags are better ways to capture that. Also they don't really work unless you triage everything. And then nobody really looks at them to prioritize their work, so they are high cost for little benefit. So was the storyboard implementation based on the rant section then? Because I don't know that I agree with/understand some of the assertions there. First, don't we _need_ to triage everything? At least on some minimal level? Not looking at new bugs at all seems like the way you end up with a security bug open for two years *ahem*. Not that I would know anything about that (it's been fixed now, FTR). I'm also not sure I agree with the statement that setting a priority for a blueprint is useless. Prioritizing feature work is something everyone needs to do these days since no team has enough people to implement every proposed feature. Maybe the proposal is for everyone to adopt Nova-style runways, but I'm not sure how well that works for smaller projects where many of the developers are only able to devote part of their time to it. Setting a time window for a feature to merge or get kicked to the back of line would be problematic for me. That section also ends with an unanswered question regarding how to do bug triage in this model, which I guess is the thing we're trying to address with this discussion. That said, it definitely creates friction, because alternatives are less convenient / visible, and it's not how other tools work... so the "right" answer here may not be the "best" answer. [1] https://wiki.openstack.org/wiki/StoryBoard/Priority Also, like it or not there is technical debt we're carrying over here. All of our bug triage up to this point has been based on launchpad priorities, and as I think I noted elsewhere it would be a big step backward to completely throw that out. Whatever model for prioritization and triage that we choose, I feel like there needs to be a reasonable migration path for the thousands of existing triaged lp bugs in OpenStack. __ 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
Re: [openstack-dev] [storyboard] Prioritization?
On Wed, Sep 26, 2018 at 8:17 AM Adam Coldrick wrote: > On Tue, 2018-09-25 at 18:40 +, CARVER, PAUL wrote: > [...] > > There is certainly room for additional means of juggling and > > discussing/negotiating priorities in the stages before work really gets > > under way, but if it doesn't eventually become clear > > > > 1) who's doing the work > > 2) when are they targeting completion > > 3) what (if anything) is higher up on their todo list > > Its entirely possible to track these three things in StoryBoard today, and > for other people to view that information. > > 1) Task assignee, though this should be set when someone actually starts > doing the work rather than being used to indicate "$person intends to do > this at some point" > 2) Due date on a card in a board > 3) Lanes in that board ordered by priority > I, for one, would not want to scroll through every lane on a large project's bug board to find the priority or target date for a given bug. For example, Nova has 819 open bugs right now. It would be a much better user experience to be able to open a specific bug and see the priority or target date. // jim __ 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
Re: [openstack-dev] [storyboard] Prioritization?
On Tue, 2018-09-25 at 18:40 +, CARVER, PAUL wrote: [...] > There is certainly room for additional means of juggling and > discussing/negotiating priorities in the stages before work really gets > under way, but if it doesn't eventually become clear > > 1) who's doing the work > 2) when are they targeting completion > 3) what (if anything) is higher up on their todo list Its entirely possible to track these three things in StoryBoard today, and for other people to view that information. 1) Task assignee, though this should be set when someone actually starts doing the work rather than being used to indicate "$person intends to do this at some point" 2) Due date on a card in a board 3) Lanes in that board ordered by priority The latter two assume that the person doing the work is using a board to track what they're doing, which is probably sensible behaviour we should encourage. Its admittedly difficult for downstream consumers to quickly find the board-related information, but I think that is a discoverability bug (it doesn't currently become clear where exactly these things can be found) rather than a fundamental issue which means we should just abandon the multi-dimensional approach. > then it's impossible for anyone else to make any sort of plans that > depend on that work. Plans could include figuring out how to add more > resources or contingency plans. It's also possible that people or > projects may develop a reputation for not delivering on their stated top > priorities, but that's at least better than having no idea what the > priorities are because every person and project is making up their own > system for tracking it. I would argue that someone who wants to make plans based on upstream work that may or may not get done should be taking the time (which should at worst be something like "reading the docs to find a link to a worklist/board" even with the current implementation) to understand how upstream are expressing the state of their work, though I can understand why they might not always want to. I definitely think that defining an "official"-ish approach is something that should probably be done, to reduce the cognitive load on newcomers. - 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
Re: [openstack-dev] [storyboard] Prioritization?
On Tue, 2018-09-25 at 13:41 -0400, Doug Hellmann wrote: > Adam Coldrick 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
Re: [openstack-dev] [storyboard] Prioritization?
Doug Hellmann wrote: >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. Different people certainly may prioritize the same thing differently, but there are far more consumers of software than there are producers and the most important thing a consumer wants to know (about a feature that they're eagerly awaiting) is what is the priority of that feature to whoever is doing the work of implementing it. There is certainly room for additional means of juggling and discussing/negotiating priorities in the stages before work really gets under way, but if it doesn't eventually become clear 1) who's doing the work 2) when are they targeting completion 3) what (if anything) is higher up on their todo list then it's impossible for anyone else to make any sort of plans that depend on that work. Plans could include figuring out how to add more resources or contingency plans. It's also possible that people or projects may develop a reputation for not delivering on their stated top priorities, but that's at least better than having no idea what the priorities are because every person and project is making up their own system for tracking it. __ 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
Re: [openstack-dev] [storyboard] Prioritization?
Adam Coldrick writes: > On Mon, 2018-09-24 at 22:47 +, 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 a
Re: [openstack-dev] [storyboard] Prioritization?
On Mon, 2018-09-24 at 22:47 +, 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: open
Re: [openstack-dev] [storyboard] Prioritization?
Doug Hellmann wrote: 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. Absence of priorities was an initial design choice[1] based on the fact that in an open collaboration every group, team, organization has their own views on what the priority of a story is, so worklist and tags are better ways to capture that. Also they don't really work unless you triage everything. And then nobody really looks at them to prioritize their work, so they are high cost for little benefit. That said, it definitely creates friction, because alternatives are less convenient / visible, and it's not how other tools work... so the "right" answer here may not be the "best" answer. [1] https://wiki.openstack.org/wiki/StoryBoard/Priority -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [storyboard] Prioritization?
On 2018-09-24 19:31:17 -0400 (-0400), Doug Hellmann wrote: > That came up as a suggestion, too. The challenge there is that we > cannot (as far as I know) sort on tags. So even if we have tags, > we can't create a list of stories that is ordered automatically > based on the priority. Maybe there's a solution to that? A board with automatic lanes for each priority tag? That way you can also have a lane for "stories with incomplete tasks for projects in my project-group but which haven't been prioritized yet" and be able to act on/triage them accordingly. -- Jeremy Stanley signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [storyboard] Prioritization?
Jeremy Stanley writes: > 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. > > 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. That came up as a suggestion, too. The challenge there is that we cannot (as far as I know) sort on tags. So even if we have tags, we can't create a list of stories that is ordered automatically based on the priority. Maybe there's a solution to that? 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
Re: [openstack-dev] [storyboard] Prioritization?
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. 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. -- Jeremy Stanley signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [storyboard] Prioritization?
Ben Nemec writes: > Hi, > > This came up in the Oslo meeting as a result of my initial look at the > test Storyboard import. It appears all of the priority data from > launchpad gets lost in the migration, which is going to make organizing > hundreds of bugs somewhat difficult. I'm particularly not fond of it > after spending last cycle whittling down our untriaged bug list. :-) > > Work lists and tags were mentioned as possible priority management tools > in Storyboard, so is there some way to migrate launchpad priorities into > one of those automatically? If not, are there any plans to add that? > > It sounded like a similar conversation is happening with a few other > teams so we wanted to bring the discussion to the mailing list for > visibility. > > Thanks. > > -Ben 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. 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
[openstack-dev] [storyboard] Prioritization?
Hi, This came up in the Oslo meeting as a result of my initial look at the test Storyboard import. It appears all of the priority data from launchpad gets lost in the migration, which is going to make organizing hundreds of bugs somewhat difficult. I'm particularly not fond of it after spending last cycle whittling down our untriaged bug list. :-) Work lists and tags were mentioned as possible priority management tools in Storyboard, so is there some way to migrate launchpad priorities into one of those automatically? If not, are there any plans to add that? It sounded like a similar conversation is happening with a few other teams so we wanted to bring the discussion to the mailing list for visibility. Thanks. -Ben __ 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
