> From: Matt Riedemann <mrie...@linux.vnet.ibm.com>
> To: openstack-operators@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" <mzoel...@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@lists.openstack.org
> >>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
