Open Stack

On 2018-06-11 17:55:24 -0500 (-0500), Matt Riedemann wrote:
> On 6/11/2018 3:23 PM, Jeremy Stanley wrote:
> > If you recall the "specs" experiment years
> > ago, a few teams tried mildly different solutions for moving from LP
> > blueprints with random wiki page links to tracking specifications in
> > Git repositories, and over time they learned successful patterns
> > from each other and mostly converged on similar solutions. There
> > were similar cries back then about "how will users/operators find
> > out what is being planned?" but I think the end result was far
> > better than what it replaced.
> 
> The specs thing was mentioned last week in IRC when talking about blueprints
> in launchpad and I just want to reiterate the specs are more about high
> level designs and reviewing those designs in Gerrit which was / is a major
> drawback in the 'whiteboard' in launchpad for working on blueprints - old
> blueprints that had a design (if they had a design at all) were usually
> linked from a wiki page.
> 
> Anyway, specs are design documents per release. Blueprints in launchpad, at
> least for nova, are the project management tracking tool for that release.
> Not all blueprints require a spec, but all specs require a blueprint since
> specs are generally for API changes or other major design changes or
> features. Just FYI.

I agree, that highlights what I see as one of the four predominant
patterns we have going on at present:

    * teams using a combination of blueprints with specs
    * teams just using blueprints
    * teams just using specs
    * teams using neither blueprints nor specs

Some teams who dropped use of blueprints, or who never used them to
begin with, may end up having a bug report or story they use like a
blueprint to track tasks associated with their specs. Case in point:
the Infra team has a story for each spec, and the idea is that you
can populate that story with tasks corresponding to the
implementation steps outlined in the spec itself, then reference
those tasks in your commit messages so you get automatic tracking of
progress for the spec, though we tended to not be very diligent with
that because we're sort of laid back about our particular specs
process. In our case, those spec stories can go in automatic lanes
in a board so that you can see which are active vs merged and, if
we followed release cycles, could have those lanes further specified
by story tag for the targeted release.

There's a lot of flexibility here and, much like the specs
experiments of a few years ago, I expect to see teams coming up with
effective patterns and then sharing those with each other allowing
us to converge as a community toward some loose consistency.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180612/af0b142f/attachment.sig>