<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 6:51 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
What follows is mostly of interest to PTLs and other $PROJECT-drivers<br>
that help them maintain Launchpad blueprints in order.<br>
<br>
Launchpad has a concept of "series goal" and "priority" (controlled by<br>
drivers), while most other fields (including "target milestone") can be<br>
modified by blueprint assignees.<br>
<br>
Currently we use "series goal" to bless a subset of blueprints and make<br>
them part of our "roadmap" for the cycle. This has several drawbacks:<br>
<br>
* It's difficult to find out about "proposed" blueprints<br>
* "Series goal" can get out of sync with "target milestone"<br>
* Stuff that is not "approved" for the series goal still appears in<br>
LP "milestone" view<br>
* Stuff that is not "approved" for the series goal does NOT appear on<br>
LP "series" view<br>
* Series-goal-accepted blueprints should have a "priority" set, but<br>
sometimes one is set without the other.<br>
<br>
To work around those drawbacks, we spend more and more time in release<br>
meeting to fix inconsistencies between those fields, which is clearly<br>
not the best use of our precious time.<br>
<br>
My proposal would be to simplify this by dropping the use of "series<br>
goal" altogether and just use a single field: "priority".<br>
<br>
Blueprint authors would indicate that they intend to land their stuff<br>
for a given milestone using the "target milestone" field.<br>
<br>
Drivers would see those appear in milestone/series views as "undefined"<br>
priority. They would triage them by setting one of those priorities:<br>
<br>
- Essential: Would prefer not to release without that feature<br>
- High: Important feature that we should have in the release<br>
- Medium: Optional feature that should still be part of the roadmap<br>
- Low: Optional feature that we should not follow on the release radar<br>
<br>
And that's it. Triaging incoming blueprints is just about setting this<br>
field.<br>
<br>
A script will automatically and regularly align "series goal" with<br>
"target milestone", so that the series and milestone views are<br>
consistent (if someone sets target milestone to "havana-3" then the<br>
series goal will be set to "havana").<br>
<br>
During the release meeting we'll only look into Medium/High/Essential<br>
blueprints, and the release status page should probably only list those<br>
as well.<br>
<br>
This also encourages people to set a target milestone, which is pretty<br>
essential in communicating out when a given feature is likely to land.<br>
<br>
So this simplifies a lot, but we lose /some/ granularity:<br>
<br>
* You won't have blueprints on your roadmap that are not targeted to a<br>
specific milestone, so it's more difficult to do a list of "would be<br>
great to have in this release if only someone wanted to take them"<br>
blueprints.<br>
<br>
* Blueprints that don't have a target milestone should probably also not<br>
have a priority, so that they are effectively "untriaged" (the automatic<br>
script might even check for that and remove priority when the target<br>
milestone is unset). That makes it more difficult to have a prioritized<br>
backlog (though we could use a "next" milestone to do that if people<br>
want it).<br>
<br>
Thoughts ?<br></blockquote><div><br></div><div><br></div><div style>This sounds like a fantastic improvement. I'd really like to have a "next" milestone as well as an "Ongoing" milestone, for tracking the kinds of long, drawn out refactorings / code improvements that cannot fit in a single milestone but still need to be communicated to developers (though not necessarily to the project update coordinators).</div>
</div></div></div>