Difference between revisions of "StoryBoard/Task Lists"
m |
|||
| Line 2: | Line 2: | ||
== User stories == | == User stories == | ||
| − | * PTL/Drivers | + | * PTL/Drivers/ReleaseManagers set top release goals, and use that to prioritize review effort |
| − | + | * Developers use project release goals to prioritize review efforts | |
| − | * | + | * Downstream consumers want to get an idea of the upcoming features |
| − | + | * Developers want to track tasks they care about and order them, to organize their work | |
| − | * Developers want to | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Straw man == | == Straw man == | ||
| Line 37: | Line 26: | ||
== Visual implementation == | == 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 | + | 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 rts boards. This allows to support true linear workflow Kanbans if someone has a need for that. |
Might be able to reuse [https://github.com/onepiecejs/nodejs-cantas] (or not). | Might be able to reuse [https://github.com/onepiecejs/nodejs-cantas] (or not). | ||
| + | |||
| + | == How this maps to our defined user stories == | ||
| + | '''PTL/Drivers/ReleaseManagers set top release goals, and use that to prioritize review effort''' | ||
| + | |||
| + | Flow: login->select project->select release goals dashboard->reorder/prioritize tasks based on goals/needs | ||
| + | |||
| + | '''Developers use project release goals to prioritize review efforts''' | ||
| + | |||
| + | Developers access the release goals dashboard and prioritize accordingly. Or they write tools to access the information in the dashboard through the API and present them in a review priority list | ||
| + | |||
| + | '''Downstream consumers want to get an idea of the upcoming features''' | ||
| + | |||
| + | Flow: login->select project->select release goals dashboard->read | ||
| + | |||
| + | '''Developers want to track tasks they care about and order them, to organize their work''' | ||
| + | |||
| + | Flow: login->select personal dashboard view->reorder/prioritize tasks based on goals/needs | ||
| + | They should be able to search for tasks to add at the dashboard level (pane ? modal window ?). However we would also support adding tasks to a dashboard directly from any story you visit, or as an option at story creation time. To keep the UI simple, by default tasks could go to some "default" column in the selected dashboards (that they would then visit to rearrange). | ||
| + | |||
| + | == Unsolved issues == | ||
| + | * 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. | ||
| + | |||
== Q&A == | == Q&A == | ||
| Line 53: | Line 64: | ||
''Q: Who is responsible for assigning those tags, and can I have a kind of a private tag, not visible to anybody else?" | ''Q: Who is responsible for assigning those tags, and can I have a kind of a private tag, not visible to anybody else?" | ||
| − | A: I think we could have "protected" tags that only a team can set. That could let us implement task status using tags. | + | A: We should discuss tags elsewhere, but I think we could have "protected" tags that only a team can set. That could let us implement task status using tags. |
''Q: Where can the tags be applied to? Stories, tasks, or both?" | ''Q: Where can the tags be applied to? Stories, tasks, or both?" | ||
| − | A: | + | A: Tags should be applied at story-level. |
| + | |||
| + | ''Q: Would a Kanban-view of a project dashboard (let's say) allow for customizable column names/orders within it?'' | ||
| + | |||
| + | A: The release dashboard would probably be strict (a milestone view). The team dashboards would very much be customizable. | ||
| + | |||
| + | |||
| + | == Removed text == | ||
| + | Need to support these as well: | ||
| + | *Developer/User wants to report a bug and doesn't necessarily know a lot about it | ||
| + | Flow: login->one-click-to-add-story-button->fill in name/description only, no 'add to view: ' option selected (defaults to 'untriaged')->task generated under story automatically with story info, flows into 'untriaged' view (may or may not have a project affiliated with it, though untriaged view can be filtered per project if project is affiliated with task). | ||
| − | |||
| − | + | That all sounds slightly orthogonal from the task list concept. | |
| − | |||
Revision as of 13:48, 26 February 2014
This is a strawman to check the validity of using task lists and abandoning the concept of task priorities.
Contents
User stories
- PTL/Drivers/ReleaseManagers set top release goals, and use that to prioritize review effort
- Developers use project release goals to prioritize review efforts
- Downstream consumers want to get an idea of the upcoming features
- Developers want to track tasks they care about and order them, to organize their work
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.
Note: task lists should probably only contain open tasks. Once completed the task should disappear from the list.
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 rts boards. This allows to support true linear workflow Kanbans if someone has a need for that.
Might be able to reuse [1] (or not).
How this maps to our defined user stories
PTL/Drivers/ReleaseManagers set top release goals, and use that to prioritize review effort
Flow: login->select project->select release goals dashboard->reorder/prioritize tasks based on goals/needs
Developers use project release goals to prioritize review efforts
Developers access the release goals dashboard and prioritize accordingly. Or they write tools to access the information in the dashboard through the API and present them in a review priority list
Downstream consumers want to get an idea of the upcoming features
Flow: login->select project->select release goals dashboard->read
Developers want to track tasks they care about and order them, to organize their work
Flow: login->select personal dashboard view->reorder/prioritize tasks based on goals/needs They should be able to search for tasks to add at the dashboard level (pane ? modal window ?). However we would also support adding tasks to a dashboard directly from any story you visit, or as an option at story creation time. To keep the UI simple, by default tasks could go to some "default" column in the selected dashboards (that they would then visit to rearrange).
Unsolved issues
- 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.
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?"
A: We should discuss tags elsewhere, but I think we could have "protected" tags that only a team can set. That could let us implement task status using tags.
Q: Where can the tags be applied to? Stories, tasks, or both?"
A: Tags should be applied at story-level.
Q: Would a Kanban-view of a project dashboard (let's say) allow for customizable column names/orders within it?
A: The release dashboard would probably be strict (a milestone view). The team dashboards would very much be customizable.
Removed text
Need to support these as well:
- Developer/User wants to report a bug and doesn't necessarily know a lot about it
Flow: login->one-click-to-add-story-button->fill in name/description only, no 'add to view: ' option selected (defaults to 'untriaged')->task generated under story automatically with story info, flows into 'untriaged' view (may or may not have a project affiliated with it, though untriaged view can be filtered per project if project is affiliated with task).
That all sounds slightly orthogonal from the task list concept.
