---- On Wed, 27 Mar 2019 14:45:02 -0500 Eric Fried <openstack@fried.cc> wrote ----
All-
It seems like we don't have a great way of looking at a blueprint and saying, "this looks like a good idea, and yes we want to do it, but we're not going to be able to prioritize it for this release." Sometimes we just leave those blueprints "unspecified" and their specs stay open in limbo. And some blueprints we'll approve for the current series, and merge the spec under $current_cycle/approved, but not really intend to get the work completed. And at the end of the release, those pieces muddy our completion stats. It would be nice if those stats reflected only work we got done that we *intended* to get done.
I'm not bringing this up just for the sake of making numbers pretty; it would just be nice to have a crisp picture of the work slated for the current release. And also a way for contributors to propose specs they *don't* intend for the current series, but still want to start discussing (I happen to know of at least one example of this for Train). And also a way to keep track of work we know we want to do eventually, just not now.
=== TL;DR >>> So I'd like to propose that we set up a "future" series in Launchpad, and a corresponding subdirectory in the specs repo. === TL;DR <<<
The process would be pretty much as you would expect, including (but not limited to):
- If we decide (e.g. at the PTG) that we like a spec that's proposed under $current/approved, but won't have time for it in the current series, we'll ask the author to move it to future/ and make sure the History section includes "$current: proposed and approved for 'future'". - If we decide in mid-release that we want to defer a blueprint, we can propose a patch to move it from $current/approved to future/ (including a redirect).
Thanks for bringing this up. What will be the conditions or criteria of the above two scenarios? - Review bandwidth? - Author (contributors) wish not to complete the code in the cycle when he/she is proposing the spec for? I mean do we have any scenario where spec author says "please approve my spec in this cycle but I will not start the code in this cycle so consider this a future spec" - Technical scope etc ? - Anything else ? IMO, the first two scenarios should not be the reason to ask people to propose your spec in future/ dir. For other scenarios, we should clearly say "NO: as of now due to xyz reason so rejected or suggestion for repropose" etc. future/ dir idea is good but main challenge it can face is "how many people going to review the future/ items' because I feel everyone is so busy with their current assignments.
- If a contributor wants to start work on a spec for a future release, they can propose it directly to the future/ path.
+1, this is a nice idea to start the early discussion/feedback etc. -gmann
- Every cycle when setting goals we can skim through the 'future' items to see if any should be pulled in. In which case we propose a patch to move the file from future/ to $current/approved (including a redirect) which we can fast-approve. - If we decide to flush a spec from 'future', we can move it to a 'rejected' (or 'abandoned'? bikeshed away) folder - but we can sort this part of the process out later.
How do folks feel about this idea?
-efried .