Difference between revisions of "StoryBoard/Task Lists"
(→Q&A) |
|||
| Line 36: | Line 36: | ||
A: there are other ways to triage bugs than setting a priority. With a project the size of OpenStack, only ''Critical'' level bugs actually get any attention anyway, so what's the point of differentiating between ''wishlist'', ''low'' or ''medium'' ? Using official tags, in particular, is a much more efficient way to triage bugs. You can differentiate between low-hanging-fruit, regressions, gate-blocking, legal-issues, data-loss, security... All relevant, but to different people. That is much more helpful triaging than setting everything to ''Critical'' in a desperate attempt to make it appear on the top of an infinite pile. | A: there are other ways to triage bugs than setting a priority. With a project the size of OpenStack, only ''Critical'' level bugs actually get any attention anyway, so what's the point of differentiating between ''wishlist'', ''low'' or ''medium'' ? Using official tags, in particular, is a much more efficient way to triage bugs. You can differentiate between low-hanging-fruit, regressions, gate-blocking, legal-issues, data-loss, security... All relevant, but to different people. That is much more helpful triaging than setting everything to ''Critical'' in a desperate attempt to make it appear on the top of an infinite pile. | ||
| + | |||
| + | ''Q: Who is responsible for assigning those tags, and can I have a kind of a private tag, not visible to anybody else?" | ||
| + | |||
| + | ''Q: Where can the tags be applied to? Stories, tasks, or both?" | ||
== Notes == | == Notes == | ||
* Shall we have a way to put stories in lists as well ? Sometimes (like feature prioritization) it might make sense to manipulate at the story level rather than move a collection of tasks around. | * Shall we have a way to put stories in lists as well ? Sometimes (like feature prioritization) it might make sense to manipulate at the story level rather than move a collection of tasks around. | ||
Revision as of 08:04, 21 February 2014
This is a strawman to check the validity of using task lists and abandoning the concept of task priorities.
User stories
- PTL/Drivers want to communicate top release goals, and use that to prioritize review effort
- Release managers want to communicate expected features in the upcoming release, based on how likely they are to land
- Developers want to list tasks they care about and order them, to organize their work and prioritize their reviews
Straw man
In this proposed implementation, we take the radical view of not using classic task priorities to handle work prioritization. The drawback with classic task priorities is that (1) they suppose priorities are shared by everyone and (2) they suppose everything will always have a priority set. Unless you meet those two goals, they are practically useless and still extremely costly to half-maintain.
Implementation
The idea here is to use a simple concept of ordered task lists and let people / teams flexibly use them to express their work prioritization.
You would have:
- Personal task lists that developers may use to build their own TODO lists (or that might be autocreated from changes you proposed / reviewed)
- Shared task lists that teams can use to express their team priorities in complex ways (gate fixes, regression bugs, MVP goals...)
- Release/project task lists that would be used to describe a given development milestone goals
Depending on the task list, the order in which the tasks are ranked may or may not have a meaning. The goal is to give users a flexible way to list tasks and let them express their workflows and things they care about with it.
Visual implementation
Task lists would actually be grouped in dashboards that show them in parallel columns. The dashboard itself would be personal, shared or release-related (rather than the task list itself). The proposed visual implementation is a Kanban view, like Trello boards. This allows to support true linear workflow Kanbans if someone has a need for that.
Might be able to reuse [1] (or not).
Q&A
Q: but all bug trackers out there have priorities. You must be doing something wrong
A: we are not building a bug tracker. We are building a task tracker. A tool developers will want to use, rather than wish it never existed. This approach puts the user in control of his task prioritization and lets him express complex priorities (and pick the next action based on context, which is very GTD)
Q: but but but... we still need to triage incoming bug reports ! And encourage people to work on critical bugs !
A: there are other ways to triage bugs than setting a priority. With a project the size of OpenStack, only Critical level bugs actually get any attention anyway, so what's the point of differentiating between wishlist, low or medium ? Using official tags, in particular, is a much more efficient way to triage bugs. You can differentiate between low-hanging-fruit, regressions, gate-blocking, legal-issues, data-loss, security... All relevant, but to different people. That is much more helpful triaging than setting everything to Critical in a desperate attempt to make it appear on the top of an infinite pile.
Q: Who is responsible for assigning those tags, and can I have a kind of a private tag, not visible to anybody else?"
Q: Where can the tags be applied to? Stories, tasks, or both?"
Notes
- Shall we have a way to put stories in lists as well ? Sometimes (like feature prioritization) it might make sense to manipulate at the story level rather than move a collection of tasks around.
