On Wed, Jun 19, 2013 at 6:51 AM, Thierry Carrez <[email protected]>wrote:
> 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 ? > 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).
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
