Jump to: navigation, search

StoryBoard/Story Status

< StoryBoard
Revision as of 15:58, 12 February 2014 by ThierryCarrez (talk | contribs) (Created page with "This page tracks the need for story-level statuses. == User stories == * Drivers (PTL and delegates) need to approve features before changes that are part of the feature are...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This page tracks the need for story-level statuses.

User stories

  • Drivers (PTL and delegates) need to approve features before changes that are part of the feature are allowed to land
  • Bugs could use some confirmation state to determine that the bug is valid

Implementation

Features

Glance/Drivers proposes the following states:

  • New
  • InfoWait
  • Targeted (approved)
  • Abandoned
  • Wishlist
  • Rejected

Glance Blueprint Process.svg

Bugs

Bugs could use the following statuses:

  • New
  • InfoWait
  • Targeted
  • Wishlist
  • Rejected (Invalid)

Issues

The main issue with adding statuses is that humans must set them. At some point when their statuses are not kept up to date with reality, you can't rely on those statuses and they end up costing a lot for little benefit. With Launchpad bugs were hopelessly left untriaged. Blueprints were only in a slightly better shape.

The other question is: would status be set at story or at task level ? For features it makes sense at story-level, but then, for multi-project features, who would end up setting the "targeted" state ?

Alternate approaches

Could we leverage other concepts to achieve the same results ? Like priority or tags ? You could approve a feature by moving it to the "approved" column in the PTL/Driver priority view.