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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev