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
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
