Open Stack

Hi everyone,

What follows is mostly of interest to PTLs and other $PROJECT-drivers
that help them maintain Launchpad blueprints in order.

Launchpad has a concept of "series goal" and "priority" (controlled by
drivers), while most other fields (including "target milestone") can be
modified by blueprint assignees.

Currently we use "series goal" to bless a subset of blueprints and make
them part of our "roadmap" for the cycle. This has several drawbacks:

* It's difficult to find out about "proposed" blueprints
* "Series goal" can get out of sync with "target milestone"
* Stuff that is not "approved" for the series goal still appears in
LP "milestone" view
* Stuff that is not "approved" for the series goal does NOT appear on
LP "series" view
* Series-goal-accepted blueprints should have a "priority" set, but
sometimes one is set without the other.

To work around those drawbacks, we spend more and more time in release
meeting to fix inconsistencies between those fields, which is clearly
not the best use of our precious time.

My proposal would be to simplify this by dropping the use of "series
goal" altogether and just use a single field: "priority".

Blueprint authors would indicate that they intend to land their stuff
for a given milestone using the "target milestone" field.

Drivers would see those appear in milestone/series views as "undefined"
priority. They would triage them by setting one of those priorities:

- Essential: Would prefer not to release without that feature
- High: Important feature that we should have in the release
- Medium: Optional feature that should still be part of the roadmap
- Low: Optional feature that we should not follow on the release radar

And that's it. Triaging incoming blueprints is just about setting this
field.

A script will automatically and regularly align "series goal" with
"target milestone", so that the series and milestone views are
consistent (if someone sets target milestone to "havana-3" then the
series goal will be set to "havana").

During the release meeting we'll only look into Medium/High/Essential
blueprints, and the release status page should probably only list those
as well.

This also encourages people to set a target milestone, which is pretty
essential in communicating out when a given feature is likely to land.

So this simplifies a lot, but we lose /some/ granularity:

* You won't have blueprints on your roadmap that are not targeted to a
specific milestone, so it's more difficult to do a list of "would be
great to have in this release if only someone wanted to take them"
blueprints.

* Blueprints that don't have a target milestone should probably also not
have a priority, so that they are effectively "untriaged" (the automatic
script might even check for that and remove priority when the target
milestone is unset). That makes it more difficult to have a prioritized
backlog (though we could use a "next" milestone to do that if people
want it).

Thoughts ?

-- 
Thierry Carrez (ttx)