Open Stack

Thanks all for the feedback, refinements, suggestions. Please keep them
coming!

> If each core only commits to "care about" the
> implementation of 2 bps, then we already have a limit for the number of
> approved bps.

I'd like to not try to prescribe this level of detail. [all blueprints
are not created equal] x [all cores are not created equal] = [too many
variables]. Different cores will have different amounts of time, effort,
and willingness to be liaisons.

> I support the ide that we limit our scope. But it is pretty hard to 
> select which 25 (or whathever amount we agree on) bp we approve out of 
> possible ~50ish. What will be the method of selection?

Basically have a meeting and decide what should fall above or below the
line, like you would in a corporate setting. It's not vastly different
than how we already decide whether to approve a blueprint; it's just
based on resource rather than technical criteria.

(It's a hard thing to have to tell somebody their feature is denied
despite having technical merit, but my main driver here is that they
would rather know that up front than it be basically a coin toss whose
result they don't know until feature freeze.)

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

Yup, your math makes sense. It pains me to phrase it this way, but it's
more realistic:

(A) Let's aim to complete 25 blueprints in Ussuri; so we'll approve 30,
expecting 5 to fail.

And the goal of this manifesto is to ensure that ~zero of the 5
incompletes are due to (A) overcommitment and (B) cultural disconnects.

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

Yeah, that's a legit suggestion, but I really didn't want to go there
[1]. I want to try to keep this conceptually as simple as possible, at
least the first time around. (I also really don't see the team trying to
subvert the process by e.g. making sure we pick the 30 biggest blueprints.)

efried

[1] I have long-lasting scars from my experiences with "story points"
and other "agile" planning techniques.