Open Stack

On 11/12/2015 12:48 PM, Steve Gordon wrote:
> ----- 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?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