> John Garbutt wrote: >> On 25 October 2013 11:52, Nikola Đipanov <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
