Open Stack

On 3/21/2016 12:58 PM, Tim Bell wrote:
>
> On 21/03/16 17:24, "Markus Zoeller" <mzoeller at de.ibm.com> wrote:
>
>> Hello dear ops,
>>
>> I'd like to make you aware of discussion [1] on the openstack-dev ML.
>> I'm in the role of maintaining the bug list in Nova and was looking
>> for a way to gain an overview again over our ~950 open bug reports.
>> My idea was to redirect the RFEs away from the Nova bug list, to make
>> that a list of reports which describe only faulty behaviors in existing
>> features [2] (see section "Alternative to wishlist bugs").
>>
>> Long story short, what are your opinions/ideas of RFE handling?
>
> Pleased to see this discussion is underway to encourage the feedback loop and lower the barrier for improvement suggestions.
>
> To check I understand the proposal,
>
> - We stop raising wishlist bugs
> - We send an e-mail to the ops list with [RFE] for discussion and review of alternatives

Specifically, tag with [RFE][nova] so it's filtered properly as a nova RFE.

>
> My only concerns are
>
> 1. How to get from the [RFE] agreed stage to a blueprint with implementation proposal ?

Markus might have other ideas, but I guess it depends on if the person 
proposing the RFE in the ML is also going to write the spec. If they 
don't want to write the implementation proposal (full spec), then they 
can propose a backlog spec. Backlog specs are high-level ideas with some 
rough design but not a full spec that someone can later pick up and 
flesh out with proposed changes. Alternatively, if some developer is 
interested in the RFE they can propose a spec. I'd expect that person to 
signal their interest in the RFE ML thread saying they'd like to work on 
it and be the assignee for the spec.

Like all things that are new, this will take some trial and error to see 
what works.

> 2. In the current blueprint process, I can +1 a spec to support the proposal. How can we identify the RFEs with the strongest community support ?

This is a tricky one. With wishlist bugs we can gauge interest with the 
heat meter, duplicate bugs, etc. And in launchpad you can link bug 
reports to blueprints (great example here [1]). I don't think anyone is 
actually using those right now to drive that interest back into nova though.

So thinking out loud, we do make a list of priorities at each design 
summit, it might be the case that we'd take one of these types of specs 
as a priority, keeping in mind not everything can be a priority else we 
don't have any priorities - if that makes sense...

I'd also like to get a Nova/Ops cross-project liaison in Newton. In my 
mind, that person would attend the ops meeting(s), monitor the list, be 
in the #openstack-operators channel and be a point person for bringing 
issues from the operators community back to nova - via nova meetings, 
-dev ML, whatever. That person could help raise the flag on important 
items though.

> 3. How can the various Ops working groups (https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee) which could help with this process ?

I'm not sure I understand this question but I'm guessing it ties back 
into #2.

>
> Tim
>
>>
>> References:
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html
>> [2]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-March/089673.html
>>
>> Regards, Markus Zoeller (markus_z)
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

[1] 
https://blueprints.launchpad.net/nova/+spec/validate-project-with-keystone

-- 

Thanks,

Matt Riedemann