----- Original Message ----- > From: "John Garbutt" <j...@johngarbutt.com> > To: maishsk+openst...@maishsk.com
[SNIP] > 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 Hi all, I get the impression from the feedback on a recently submitted item [1] and also a read of a clarification that was made to the backlog page [2] that this is no longer the way the backlog works? Specifically, a proposed or desired solution is now required and the page now talks about it being a place for the project team to record decisions only (originally it seemed more focused on recording ideas). >From an NFV/Telco working group perspective we have been trying to convince >folks for some time to stop leading with pre-defined solutions and focus more >- at least in the first instance - on documenting their use cases in a way >that they could be shared with the relevant OpenStack project teams via their >respective RFE/backlog processes. It seems to me though based on my >experiences having actually tried to submit one of these ideas as a dry run >there is not in fact a working process for recording these as originally >advertised [3][4][5]? Am I misinterpreting the intent of the change here? Thanks, Steve [1] https://review.openstack.org/#/c/224325/ [2] http://git.openstack.org/cgit/openstack/nova-specs/commit/doc/source/specs/backlog/index.rst?id=525af38a5ce27bed70d950234e94a48584820943 [3] http://git.openstack.org/cgit/openstack/nova-specs/tree/doc/source/specs/backlog/index.rst?id=41bf5302e7ff2b9305b0e8a459e9fe715fba0c38 [4] http://lists.openstack.org/pipermail/openstack-dev/2015-May/064284.html [5] http://lists.openstack.org/pipermail/openstack-dev/2015-May/064180.html __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev