Open Stack

John,


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.


Feature requests are the same process as specs. And I fully agree
that bug reports are not good idea for this.

The only difference is template. I believe you won't find end users
that would like to spend time to read all this steps:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html
and provide required info.

As an end users I would like to spend maximum 5 minutes to provide info
about:
- use case
- problem description
- possible solution [optional]


What about making nova template simpler?
And actually doing this across all projects?


Best regards,
Boris Pavlovic


On Fri, May 15, 2015 at 11:46 AM, John Garbutt <john at johngarbutt.com> wrote:

> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150515/22565201/attachment.html>