Open Stack

 ---- On Wed, 27 Mar 2019 14:45:02 -0500 Eric Fried <openstack at 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 
 > . 
 >  
 >