Hi!

I think this is a nice idea indeed. Do you plan to use this process starting 
from Juno or as soon as possible?


- Roman


On Aug 5, 2014, at 22:33, Devananda van der Veen <devananda....@gmail.com> 
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!
> 
> -Deva
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to