Jump to: navigation, search

Difference between revisions of "Task Tracker Requirements"

(Objectives tracking)
(Open questions)
Line 74: Line 74:
* Dependencies between stories ?
* Dependencies between stories ?
* Should we have a 1:1 relationship between tasks  and code changes ? Would allow to track task completion more directly
* Should we have a 1:1 relationship between tasks  and code changes ? Would allow to track task completion more directly
* Can features span multiple series ?

Revision as of 07:31, 1 May 2013


Why yet another bug tracker ? Why not keep Launchpad ? Why not use X ?

Bug and feature tracking, or more generally task tracking, is closely linked to your workflow. Each tool out there enforces their own view on how to track bugs and/or features. You generally choose a tool that enforces a workflow that is acceptable to your project. But if the tool you use is not specifically tailored to your workflow, then it will do extra things and be confusing, or require you to do extra things to keep it consistent with your workflow. For example, suppose your bug triaging activity is about setting a priority to a bug. If you have a status that has "confirmed" and "triaged", which one should you set ? And if you can set priority independently of that triaging status, you end up with bugs that are triaged without priority, or bugs that are untriaged but with a priority set. At the other end of the spectrum, there are tools that don't enforce any workflow (think github issues) -- keeping those consistent is also a daunting task, and they generally don't handle a collection of related projects that well (each project is generally seen as independent).

We originally based our workflow on Launchpad, which is tailored to Ubuntu distribution workflows. It served us well, but OpenStack grew to the point where the small differences in workflows are getting more annoying, once multiplied by the number of persons involved in the project. At the same time, Launchpad development stalled, leaving us with little chances to improve the tool to suit our needs.

To help us in evaluating future options, this document will detail our requirements for a task tracking tool (features and bugs) and propose a reference implementation.

Basic principles

The main principle is that a single story (bug or feature) is broken down on multiple tasks. This is one thing that Launchpad Bugs really did right. Tasks are units of work that affect a specific project and a specific branch. They can be affected to different people. But tasks are always presented as part of a story, which is where the discussion happens. Tasks let you have bugs or features that affect multiple projects and branches, which is critical for OpenStack, and track them much more conveniently than just by using a single table and dependencies between single-dimensional items.

The second principle is that bugs and features are fundamentally different. Bugs can have tasks for stable branches, while features only have tasks for the version under development. Features and bugs show up in separate lists in release summary pages. Features are not a "wishlist" priority bug.

The third principle is that while bugs and features are different, they can be tracked with the same tools, because they have a lot in common. There is no need in maintaining them completely separately.

Ideal implementation

Data model

  • Projects
  • Series
    • Milestones (1:n, ordered by date)
  • Stories
    • Reporter/proposer
    • Title
    • Type: Feature or Bug
    • Importance ([Untriaged, Invalid, must have, should have, could have, wishlist] for features, [Untriaged, Invalid, Critical, High, Medium, Low] for bugs)
    • Tasks (1:n, ordered?) -- can have multiple tasks for the same project/series combination
      • Title (by default "series backport" for a bug, a number for a feature)
      • Project (or "other")
      • Series
      • Assignee
      • Status (Todo, under development (?), in review, landed in branch, blocked(?))
      • Target milestone (+ landed milestone ?)
      • Release tracking flag (set by drivers)
      • Proposed change link(s ?)
    • Description
    • Whiteboard (?)
    • Subscribers
    • Visibility: Security bug or Public
    • Tags
    • CVE references
    • Comments (1:n, ordered by date)
    • Attachments (or just enable links in description and comments ?)

Supported activities


tbd + duplicates ?

Release tracking

Summary pages show tasks with filters:

  • Tasks or just stories
  • features and/or bugs (on separate lists)
  • specific series
  • specific milestone
  • all projects or just one project
  • Included completed tasks/stories or not
  • Only release-tracking-flagged, or all

Release pages


Automatic status updating


Open questions

  • Dependencies between tasks or just linear lists ?
  • Dependencies between stories ?
  • Should we have a 1:1 relationship between tasks and code changes ? Would allow to track task completion more directly
  • Can features span multiple series ?