[Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

Steve Gordon sgordon at redhat.com
Thu Nov 12 18:48:16 UTC 2015


----- Original Message -----
> From: "John Garbutt" <john at johngarbutt.com>
> To: maishsk+openstack at maishsk.com

[SNIP]

> 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

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



More information about the OpenStack-operators mailing list