Open Stack

On 05/08/14 12:33 -0700, Devananda van der Veen wrote:
>Hi all!
>
>The following idea came out of last week's midcycle for how to improve our
>spec process and tracking on launchpad. I think most of us liked it, but of
>course, not everyone was there, so I'll attempt to write out what I recall.
>
>This would apply to new specs proposed for Kilo (since the new spec
>proposal deadline has already passed for Juno).
>
>
>First, create a blueprint in launchpad and populate it with your spec's
>heading. Then, propose a spec with just the heading (containing a link to
>the BP), Problem Description, and first paragraph outlining your Proposed
>change.
>
>This will be given an initial, high-level review to determine whether it is
>in scope and in alignment with project direction, which will be reflected
>on the review comments, and, if affirmed, by setting the blueprint's
>"Direction" field to "Approved".
>
>At this point, if affirmed, you should proceed with filling out the entire
>spec, and the remainder of the process will continue as it was during Juno.
>Once the spec is approved, update launchpad to set the specification URL to
>the spec's location on https://specs.openstack.org/openstack/ironic-specs/
>and a member of the team (probably me) will update the release target,
>priority, and status.
>
>
>I believe this provides two benefits. First, it should give quicker initial
>feedback to proposer if their change is going to be in/out of scope, which
>can save considerable time if the proposal is out of scope. Second, it
>allows us to track well-aligned specs on Launchpad before they are
>completely approved. We observed that several specs were approved at nearly
>the same time as the code was approved. Due to the way we were using LP
>this cycle, it meant that LP did not reflect the project's direction in
>advance of landing code, which is not what we intended. This may have been
>confusing, and I think this will help next cycle. FWIW, several other
>projects have observed a similar problem with spec<->launchpad interaction,
>and are adopting similar practices for Kilo.
>
>
>Comments/discussion welcome!

As someone who has proposed a lengthy spec that was deemed to be
out-of-scope (mea culpa!), a big +1 to this idea! :)

I think this will also be a good way to catch instances where several
people propose similar, overlapping specs.

I think we're still in 'laboratories of democracy' status with this,
but long-term I hope the various projects can converge on a single
protocol for proposing specs.

-- Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/85568a93/attachment.pgp>