<div dir="ltr">John,<div><br></div><div><br style="font-size:12.8000001907349px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">So, you can have all details in the spec, or you can have only the<br></span><span style="font-size:12.8000001907349px">problem statement complete. Its up to you as a submitter how much<br></span><span style="font-size:12.8000001907349px">detail you want to provide. I would recommend adding rough ideas into<br></span><span style="font-size:12.8000001907349px">the alternatives section, and leaving everything else blank except the<br></span><span style="font-size:12.8000001907349px">problem statement.</span></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <span style="font-size:12.8000001907349px">We are trying to use a single process for "parked" developer ideas and<br></span><span style="font-size:12.8000001907349px">operator ideas, so they are on an equal footing.</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">The reason its not just a "bug" or similar, is so we are able to<br></span><span style="font-size:12.8000001907349px">review the idea with the submitter, to ensure we have a good enough<br></span><span style="font-size:12.8000001907349px">problem description, so a developer can pick up and run with the idea,<br></span><span style="font-size:12.8000001907349px">and turn it into a more complete spec targeted at a specific release.<br></span><span style="font-size:12.8000001907349px">In addition, we are ensuring that the problem description is in scope.</span></blockquote><div><br></div><div>Feature requests are the same process as specs. And I fully agree </div><div>that bug reports are not good idea for this. </div><div><br></div><div>The only difference is template. I believe you won't find end users</div></div><div>that would like to spend time to read all this steps:</div><div><a href="http://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html">http://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html</a> </div><div>and provide required info. </div><div><br></div><div>As an end users I would like to spend maximum 5 minutes to provide info about:</div><div>- use case</div><div>- problem description </div><div>- possible solution [optional]</div><div><br></div><div><br></div><div>What about making nova template simpler? </div><div>And actually doing this across all projects? </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 15, 2015 at 11:46 AM, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On 05/14/15 21:04, Boris Pavlovic wrote:<br>
</span><span class="">> I believe that backlog should be different much simpler then specs.<br>
<br>
</span>Agreed. And they are.<br>
<span class=""><br>
> Imho Operators don't have time / don't want to write long long specs and<br>
> analyze how they are aligned with specs<br>
> or moreover how they should be implemented and how they impact<br>
> performance/security/scalability. They want<br>
> just to provide feedback and someday get it implemented/fixed.<br>
<br>
</span>Working for an operator myself, I agree, thats the idea.<br>
<br>
Bugs still go into a bug report.<br>
<br>
These backlog specs are for feature requests, like additional APIs, or<br>
additional configurability, etc. Where you need to have a conversation<br>
between the operator and the developer communities.<br>
<span class=""><br>
> In Rally we chose different way called "feature request".<br>
> The process is the same as for specs, but template is much simpler.<br>
<br>
</span>I think this is similar.<br>
<span class=""><br>
On 14 May 2015 at 19:52, Maish Saidel-Keesing <<a href="mailto:maishsk@maishsk.com">maishsk@maishsk.com</a>> wrote:<br>
> Can we please have this as a default template and the default way to allow<br>
> Operators to submit a feature request for EVERY and ALL the OpenStack<br>
> projects ??<br>
<br>
</span>+1<br>
<br>
Thats exactly how backlog specs came about.<br>
<br>
I ran a cross project session at the last summit to try and<br>
standardise how all the different projects deal with specs.<br>
<a href="https://etherpad.openstack.org/p/kilo-crossproject-specs" target="_blank">https://etherpad.openstack.org/p/kilo-crossproject-specs</a><br>
<br>
>From that, we agreed to introduce "Backlog" specs to hold ideas and<br>
problem statements, and un-targeted or un-assigned specs. We intended<br>
to roughly match what keystone was already doing, although our intent<br>
appears to have diverged a little.<br>
<br>
This is the first design summit where we have the "concept" in place,<br>
and I would love your help road testing this.<br>
<br>
If an operator working session agreed on a problem statement, or set<br>
of problem statements, putting those up as backlog specs reviews would<br>
be a great way to get feedback from the developer community.<br>
<span class=""><br>
>> On Thu, May 14, 2015 at 8:47 PM, John Garbutt <<a href="mailto:john@johngarbutt.com">john@johngarbutt.com</a>><br>
</span><span class="">>>> You can read more about Nova's backlog specs here:<br>
>>> <a href="http://specs.openstack.org/openstack/nova-specs/specs/backlog/" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/backlog/</a><br>
<br>
</span>Let me give more detail. To quote the above page:<br>
<br>
"<br>
If you have a problem that needs solving, but you are not currently<br>
planning on implementing it, this is the place we can store your<br>
ideas.<br>
These specifications have the problem description completed, but all<br>
other sections are optional.<br>
"<br>
<br>
So, you can have all details in the spec, or you can have only the<br>
problem statement complete. Its up to you as a submitter how much<br>
detail you want to provide. I would recommend adding rough ideas into<br>
the alternatives section, and leaving everything else blank except the<br>
problem statement.<br>
<br>
We are trying to use a single process for "parked" developer ideas and<br>
operator ideas, so they are on an equal footing.<br>
<br>
The reason its not just a "bug" or similar, is so we are able to<br>
review the idea with the submitter, to ensure we have a good enough<br>
problem description, so a developer can pick up and run with the idea,<br>
and turn it into a more complete spec targeted at a specific release.<br>
In addition, we are ensuring that the problem description is in scope.<br>
<br>
With that extra detail, do you think this could work?<br>
<br>
Thanks,<br>
John<br>
</blockquote></div><br></div>