Difference between revisions of "StoryBoard/Task Lists"

Revision as of 18:24, 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

Flow: login->select project dashboard view->filter for project->reorder/prioritize tasks based on goals/needs.

• Release managers want to communicate expected features in the upcoming release, based on how likely they are to land

Flow: login->select release view->??

• Developers want to list tasks they care about and order them, to organize their work and prioritize their reviews

Flow: login->select personal dashboard view->reorder/prioritize tasks based on goals/needs What would the flow be for *adding* a new task to the personal view? Potentially: login->select project dashboard view->filter for project->select tasks to add to personal view->select 'add to personal tasks' option->select personal view->see tasks at bottom of personal view list, reorder as necessary (?)

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).

• Developer/User wants to report a bug and wants to put it in specific dashboard view

Flow: login->one-click-to-add-story-button->fill in name/description and 'add to view: project'->view shared dashboard->filter project->task should appear at bottom of list and is available for prioritization

• Developer/User wants to add a feature story and wants affiliated task to go into specific dashboard view

Flow: login->one-click-to-add-story-button->fill in name/description and 'add to view: project'; label with affiliated project->view shared dashboard->filter project->task should appear at bottom of list and is available for prioritization

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 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?"

A: 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?"

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.