On 11/12/2015 12:48 PM, Steve Gordon wrote:
----- Original Message -----
From: "John Garbutt" <[email protected]>
To: [email protected]
[SNIP]
On 14 May 2015 at 19:52, Maish Saidel-Keesing <[email protected]> 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 <[email protected]>
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I don't expect a backlog spec to have a detailed technical solution to
the problem, but I would expect a clear use case, and if there are high
level ideas on possible solutions those could be stated, with known
pros/cons if there are any.
If we aren't going to have backlog specs, what are other teams doing? I
think Neutron is doing something like bug reports with RFE in the title
or tag? Do those get acted on?
Another reason backlog specs came about was because back at the Intel
meetup we were looking at really old bugs (over a year or two) which
were more like performance or other large functional issues, that
couldn't just be resolved with a simple bug fix. So the problem was
leaving those sit around forever with no one working on them, but not
wanting to close them because they were valid issues. The backlog specs
came out in part from that because we could at least record these in
tree as a place for people to see, OK, I have this same issue and I
actually have an idea of how to solve it, so I'll turn this into a spec
and work it via the normal spec process.
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
