<div dir="ltr"><div dir="ltr"><div>On Wed, Mar 27, 2019 at 3:47 PM Eric Fried <openstack@fried.cc> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All-<br>
<br>
It seems like we don't have a great way of looking at a blueprint and<br>
saying, "this looks like a good idea, and yes we want to do it, but<br>
we're not going to be able to prioritize it for this release." Sometimes<br>
we just leave those blueprints "unspecified" and their specs stay open<br>
in limbo. And some blueprints we'll approve for the current series, and<br>
merge the spec under $current_cycle/approved, but not really intend to<br>
get the work completed. And at the end of the release, those pieces<br>
muddy our completion stats. It would be nice if those stats reflected<br>
only work we got done that we *intended* to get done.<br>
<br>
I'm not bringing this up just for the sake of making numbers pretty; it<br>
would just be nice to have a crisp picture of the work slated for the<br>
current release. And also a way for contributors to propose specs they<br>
*don't* intend for the current series, but still want to start<br>
discussing (I happen to know of at least one example of this for Train).<br>
And also a way to keep track of work we know we want to do eventually,<br>
just not now.<br>
<br>
=== TL;DR >>><br>
So I'd like to propose that we set up a "future" series in Launchpad,<br>
and a corresponding subdirectory in the specs repo.<br>
=== TL;DR <<<<br>
<br>
The process would be pretty much as you would expect, including (but not<br>
limited to):<br>
<br>
- If we decide (e.g. at the PTG) that we like a spec that's proposed<br>
under $current/approved, but won't have time for it in the current<br>
series, we'll ask the author to move it to future/ and make sure the<br>
History section includes "$current: proposed and approved for 'future'".<br>
- If we decide in mid-release that we want to defer a blueprint, we can<br>
propose a patch to move it from $current/approved to future/ (including<br>
a redirect).<br>
- If a contributor wants to start work on a spec for a future release,<br>
they can propose it directly to the future/ path.<br>
- Every cycle when setting goals we can skim through the 'future' items<br>
to see if any should be pulled in. In which case we propose a patch to<br>
move the file from future/ to $current/approved (including a redirect)<br>
which we can fast-approve.<br>
- If we decide to flush a spec from 'future', we can move it to a<br>
'rejected' (or 'abandoned'? bikeshed away) folder - but we can sort this<br>
part of the process out later.<br>
<br>
How do folks feel about this idea?<br></blockquote><div class="gmail_quote"><br></div>Isn't this what the backlog directory[0] is for?</div><div class="gmail_quote"><div><br></div><div>[0] <a href="http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/backlog/approved">http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/backlog/approved</a></div><div> </div><div>// jim</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-efried<br>
.<br>
<br>
</blockquote></div></div>