Open Stack

> On 05/14/15 21:04, Boris Pavlovic wrote:
> I believe that backlog should be different much simpler then specs.

Agreed. And they are.

> Imho Operators don't have time / don't want to write long long specs and
> analyze how they are aligned with specs
> or moreover how they should be implemented and how they impact
> performance/security/scalability. They want
> just to provide feedback and someday get it implemented/fixed.

Working for an operator myself, I agree, thats the idea.

Bugs still go into a bug report.

These backlog specs are for feature requests, like additional APIs, or
additional configurability, etc. Where you need to have a conversation
between the operator and the developer communities.

> In Rally we chose different way called "feature request".
> The process is the same as for specs, but template is much simpler.

I think this is similar.

On 14 May 2015 at 19:52, Maish Saidel-Keesing <maishsk at maishsk.com> wrote:
> Can we please have this as a default template and the default way to allow
> Operators to submit a feature request for EVERY and ALL the OpenStack
> projects ??

+1

Thats exactly how backlog specs came about.

I ran a cross project session at the last summit to try and
standardise how all the different projects deal with specs.
https://etherpad.openstack.org/p/kilo-crossproject-specs

>From that, we agreed to introduce "Backlog" specs to hold ideas and
problem statements, and un-targeted or un-assigned specs. We intended
to roughly match what keystone was already doing, although our intent
appears to have diverged a little.

This is the first design summit where we have the "concept" in place,
and I would love your help road testing this.

If an operator working session agreed on a problem statement, or set
of problem statements, putting those up as backlog specs reviews would
be a great way to get feedback from the developer community.

>> On Thu, May 14, 2015 at 8:47 PM, John Garbutt <john at johngarbutt.com>
>>> You can read more about Nova's backlog specs here:
>>> http://specs.openstack.org/openstack/nova-specs/specs/backlog/

Let me give more detail. To quote the above page:

"
If you have a problem that needs solving, but you are not currently
planning on implementing it, this is the place we can store your
ideas.
These specifications have the problem description completed, but all
other sections are optional.
"

So, you can have all details in the spec, or you can have only the
problem statement complete. Its up to you as a submitter how much
detail you want to provide. I would recommend adding rough ideas into
the alternatives section, and leaving everything else blank except the
problem statement.

We are trying to use a single process for "parked" developer ideas and
operator ideas, so they are on an equal footing.

The reason its not just a "bug" or similar, is so we are able to
review the idea with the submitter, to ensure we have a good enough
problem description, so a developer can pick up and run with the idea,
and turn it into a more complete spec targeted at a specific release.
In addition, we are ensuring that the problem description is in scope.

With that extra detail, do you think this could work?

Thanks,
John