StoryBoard/Task Lists

This is a strawman to check the validity of using task lists and abandoning the concept of task priorities.

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 / Random thoughts

• 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.
• It might actually make sense to always manipulate stories rather than tasks. I suspect if someone adds a feature to his list, he wants all the tasks from that story related to his project to show up, including the ones that may be added later.
• For a global release view (or an Oslo-wide view) we'll need to be able to "see" the release tracking dashboard at projectgroup level, which might make for a busy or confusing view

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.