Open Stack

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 [3]. Since there has been no change to the core team, let's limit
> Ussuri to 25 blueprints [4]. 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 [5], and to be a first point of contact
> for reviews. I've proposed this to the spec template here [6].
> 
> Thoughts?

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
under/overshooting.

-- 
Thierry Carrez (ttx)