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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev