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). - If a contributor wants to start work on a spec for a future release, they can propose it directly to the future/ path. - 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 .