[nova][ptg] Ussuri scope containment
thierry at openstack.org
Tue Oct 1 11:18:29 UTC 2019
Eric Fried wrote:
> There's nothing new or surprising about the above. We've tried to
> address these issues in various ways in the past, with varying degrees
> of effectiveness.
> I'd like to try a couple more.
> (A) Constrain scope, drastically. We marked 25 blueprints complete in
> Train . Since there has been no change to the core team, let's limit
> Ussuri to 25 blueprints . If this turns out to be too few, what's the
> worst thing that happens? We finish everything, early, and wish we had
> done more. If that happens, drinks are on me, and we can bump the number
> for V.
> (B) Require a core to commit to "caring about" a spec before we approve
> it. The point of this "core liaison" is to act as a mentor to mitigate
> the cultural issues noted above , and to be a first point of contact
> for reviews. I've proposed this to the spec template here .
Setting expectations more reasonably is key to grow a healthy long-term
environment, so I completely support your efforts here. However I
suspect there will always be blueprints that fail to be completed. If it
were purely a question of reviewer resources, then I agree that capping
the number of blueprints to the reviewer team's throughput is the right
approach. But as you noted, incomplete blueprints come from a few
different reasons, sometimes not related to reviewers efforts at all.
So if out of 50 blueprints, say 5 are incomplete due to lack of
reviewers attention, 5 due to lack of developer attention, and 15 fail
due to reviewers also being developers and having to make a hard
choice... Targeting 30-35 might be better (expecting 5-10 of them to
fail anyway, and not due to constrained resources).
The other comment I have is that I suspect all blueprints do not have
the same weight, so assigning them complexity points could help avoid
Thierry Carrez (ttx)
More information about the openstack-discuss