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.

I am just wondering about the best way to communicate the revisiting
of all the priorities at the beginning of every milestone.

I want a way of saying:
* reviewers only sign up for a single milestone
* if you slip, you (the blueprint developer) need to go make your case
again (to raise the prioirty above low)
* in most cases the original reviewers will still have bandwidth to
help, so ask them first
* in many cases the reviewers may have already signed up for the next
milestone and re-priortiesed the blueprint for you
* but understand you are likely to have a lower priority after the
slip, and they could all say no, leaving you as low priority

I picked low rather than "none" because there is no reason to
re-approve the blueprint. If it was sane before, its probably still
OK, in most cases.

> 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.

I agree. I am just wondering about the best way to communicate the
"cost" of slipping.

John