Open Stack

Daniel P. Berrange wrote:
> In this thread about code review:
> 
>   http://lists.openstack.org/pipermail/openstack-dev/2013-August/013701.html
> 
> I mentioned that I thought there were too many blueprints created without
> sufficient supporting design information and were being used for "tickbox"
> process compliance only. I based this assertion on a gut feeling I have
> from experiance in reviewing.
> [...]

Nice analysis, Daniel.

One side of this issue is that the blueprints tool no longer matches our
needs (can't have a blueprint that affects multiple projects, can't
discuss in blueprints the same way we do with bugs...).

So I suspect part of the "tickbox" effect is due to people not getting
enough value from blueprints. They are essential for project management
types (think PTLs or me), but feel like a process tickbox for everyone
else. I hope that StoryBoard will one day fix that for us.

> I do think we have scope for being more rigourous in our review of
> blueprints, asking people to expand on the design info associated with
> a blueprint. Perhaps also require that a blueprint is actually approved
> by the core team before we go to the trouble of reviewing & approving
> the code implementing a blueprint in Gerrit.

The approval process has been simplified lately: if a blueprint is
targeted to a milestone and has a priority set (not "Undefined") then it
is considered approved. I agree you could require that the blueprint was
reviewed/prioritized before landing a feature associated with it.

Note that in some cases, some "improvements" that do not clearly fall
into the "bug" category are landed without a blueprint link (or a bug
link). So a first step could be to require that a review always
references a bug or a blueprint before it's landed. Then, improve the
quality of the information present in said bug/blueprint.

-- 
Thierry Carrez (ttx)