Open Stack

> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: openstack-operators at lists.openstack.org
> Date: 03/22/2016 12:06 AM
> Subject: Re: [Openstack-operators] [nova] RFEs: communication channel 
> and process
> 
> 
> 
> 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.

How about that flow:
* RFE got discussed, got stakeholders and were approved on the ops ML
* Forward the mail to the dev ML
    * keep [RFE][nova] in the subject line
    * use the backlog spec template text for the conclusion post
* Nova folks pick that up
    * make a backlog spec or real spec out of it
    * discuss it for the next cycle during the summit

As the use cases got discussed on the ML and stakeholders are known, 
I assume it's more likely to draw attention to them.

> > 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...

A simple thing would be an etherpad which serves as backlog where
the interested parties make their +1 and add a contact person for
questions which could arise later in time. These are then also the
stakeholders which should be in the position to say that a feature
is implemented in a way their use cases are covered and the feature
is considered done.
That etherpad could then be used during the summit. A mockup:
https://etherpad.openstack.org/p/nova-ops-rfe

> 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.
> 

I think they could participate in the prioritization effort. It all
comes down to not having enough resources in Nova to 
* write fixes for all bugs
* write changes for features
* review(!) all the changes
without losing the stability and scope of the project. Therefore
the prioritization is needed. 

Regards, Markus Zoeller (markus_z)

> >
> > 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
> 
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>