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 <j...@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 <mais...@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 <j...@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 >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators