John Garbutt wrote: > On 25 October 2013 11:52, Nikola Đipanov <ndipa...@redhat.com> wrote: >> I don't have the numbers but I have a feeling that what happened in >> Havana was that a lot of blueprints slipped until the time for feature >> freeze. Reviewers thought it was a worthwile feature at that point (this >> was, I feel, when *actual* blueprint reviews are done - whatever the >> process says. It's natural too - once the code is there so much more is >> clear) and wanted to get it in - but it was late in the cycle so we >> ended up accepting things that could have been done better. > > Maybe we need a clarification around the priority, something like: > * the priority applies only to the target milestone when the priority was > agreed > * should the blueprint move to a new milestone, the priority should be > reset to low priority
We should definitely revise priority when a blueprint slips, I'm just not sure there is value in automatically resetting those to Low. Priorities are used to convey how critical a feature is to a given development cycle / release. When people look at our roadmap, they can assume that Essential stuff is more likely to make it than Low stuff. This is in turn reflected in weekly release status meetings where I nag about Essential/High stuff a lot, and I happily ignore Low stuff. We can't just reset Essential stuff to Low if it slips. It will likely stay Essential, it may drop to High, it could go to Low (but that sounds unlikely), it may be deferred. In the (hopefully rare) latter case, we should communicate that and why we did it to our community, so that they can recalibrate their expectations about what will probably be in the release. Regards, -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev