Open Stack

Apologies for top-posting, etc etc

I'd like to mention something the Swift team introduced back in 2016 and has been using quite successfully ever since. After trying both blueprints and specs, we have settled on our ideas wiki page. Basically, if you've got an idea, write it down and link to it. I'll let the original email do more of the explaining: http://lists.openstack.org/pipermail/openstack-dev/2016-May/094026.html

Swift's ideas page is at https://wiki.openstack.org/wiki/Swift/ideas


--John





On 27 Mar 2019, at 12:45, Eric Fried 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).
> - 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
> .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 850 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190331/74450273/attachment.sig>