Open Stack

John Garbutt wrote:
> On 25 October 2013 11:52, Nikola Đipanov <ndipanov at 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)