Open Stack

The Neutron RFE process [1] demands time-committment from various groups 
which I cannot give. A face-to-face discussion could be benefitial to 
come to a conclusion, so I proposed a session for the Newton summit 
at [2] (see section "RFEs: communication channel and process"). 
There won't be a big difference on the bug list in 4 weeks when the 
summit starts, which means (with my "bug czar" hat on) I can handle 
this.

I'm going to clean up the existing whislist bugs which are older
than 12 months, which is a common cleanup task as described in [3]
and should surprise no one. Help is appreciated [4]. It makes the list
significantly less cluttered and helps the nova bugs team immediately. 
The next 4 weeks until the summit, new bug reports which are RFEs will 
be set to "wishlist" again, to keep a consistent state which is then
the starting point for future actions we decide on the summit.

I'm going to forward this thread to the ops ML, as it affects them also
a lot and they should have the chance to say their opinions. I still 
prefer the "discuss RFEs on the ML (-dev/-ops)" idea, Matt already 
pointed out the potential benefits.

With a "requirements engineering hat" on, without any Nova "flavor":
Maybe an extra list "https://bugs.launchpad.net/openstack-rfe" would
make sense, as, I assume, the other projects face the same challenges.
But I'd rather not discuss this in this thread.

Thanks for your input so far. Let's see what the ops say on their ML
and what the Newton summit will bring.

References:
[1] 
http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
[2] https://etherpad.openstack.org/p/newton-nova-summit-ideas
[3] 
https://wiki.openstack.org/wiki/BugTriage#Task_9:_Deprecate_old_wishlist_bugs_.28bug_supervisors.29
[4] http://45.55.105.55:8082/bugs-dashboard.html#tabWishlist

Regards, Markus Zoeller (markus_z)

Rochelle Grober <rochelle.grober at huawei.com> wrote on 03/18/2016 12:45:38 
AM:

> From: Rochelle Grober <rochelle.grober at huawei.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 03/18/2016 12:46 AM
> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) 
blueprint?
> 
> (Inline because the mail formatted friendly this time)
> 
> From: Tim Bell March 17, 2016 11:26 AM:
> On 17/03/16 18:29, "Sean Dague" <sean at dague.net> wrote:
> 
> >On 03/17/2016 11:57 AM, Markus Zoeller wrote:
> ><snip>
> >> Suggested action items:
> >> 
> >> 1. I close the open wish list items older than 6 months (=138 
reports)
> >>    and explain in the closing comment that they are outdated and the 
> >>    ML should be used for future RFEs (as described above).
> >> 2. I post on the openstack-ops ML to explain why we do this
> >> 3. I change the Nova bug report template to explain this to avoid 
more
> >>    RFEs in the bug report list in the future.
> 
> Please take a look at how Neutron is doing this.  [1] is their list of
> RFEs. [2] is the ML post Kyle provided to document how Ops and other 
> users can submit RFEs without needing to know how to submit specs or 
> code OpenStack Neutron. I'll let Kyle post on how successful the 
> process is, if he wants to.
> 
> The point here is that Neutron uses wishlist combined with [RFE] in 
> the title to identify Ops and user requests.  This identifies items as
> Ops/user asks that these comuunities consider important.  Also, the 
> point is that Yes, post the RFE on the ops list, but open the RFE bug 
> and allow comments, voting there.  The bug system does much better 
> keeping track of the request and Ops votes once it exists.  Plus, once
> Ops and others know about the lightweight process, they'll know where 
> to go looking so they can vote/add comments.  Please don't restrict 
> RFEs to mailing list.  It's a great way to lose them.  So my suggestion 
here is:
> 
> 1.  Close the wishlist (all of it???) and post in each that if it's a 
> new feature the submitter thinks is useful to himself and others, 
> resubmit with [RFE] in title, priority wishlist, pointer to the Neutron 
docs.
> 2.  Post to openstack-ops and usercommittee why, and ask them to 
> discuss on the ML and review all [RFE]s that they submit (before or 
> after, but if the bug number is on ML, they can vote on it and add 
> comments, etc.)
> 3. Change the template to highlight/require the information needed to 
> move forward with *any* submitted bug by dev.
> 
> >> 4. In 6 months I double-check the rest of the open wishlist bugs
> >>    if they found developers, if not I'll close them too.
> >> 5. Continously double-check if wishlist bug reports get created
> >>
> >> Doubts? Thoughts? Concerns? Agreements?
> >
> >This sounds like a very reasonable plan to me. Thanks for summarizing
> >all the concerns and coming up with a pretty balanced plan here. +1.
> >
> >   -Sean
> 
> I?d recommend running it by the -ops* list along with the RFE 
> proposal. I think many of the cases
> had been raised since people did not have the skills/know how to 
proceed.
> 
> Engaging with the ops list would also bring in the product working 
> group who could potentially
> help out on the next step (i.e. identifying the best places to invest 
> for RFEs) and the other
> topical working groups (e.g. Telco, scientific) who could help with 
> prioritisation/triage.
> 
> I don?t think that a launchpad account on its own is a big problem. 
> Thus, I could also see an approach
> where a blueprint was created in launchpad with some reasonably 
> structured set of chapters. My
> personal experience was that the challenges came more later on trying 
> to get the review matched up and
> the right bp directories.
> 
> There is a big benefit to good visibility in the -ops community for 
> RFEs though. Quite often, the
> features are implemented but people did not know how to find them in 
> the doc (or maybe its a doc bug).
> Equally, the OSops scripts repo can give people workarounds while the 
> requested feature is in the
> priority queue.
> 
> It would be a very interesting topic to kick off in the ops list and 
> then have a further review in
> Austin to agree how to proceed.
> 
> Tim 
> 
> You can review how the [RFE] experiment is going in six weeks or more.
> We can also get an Ops session specifically for reviewing/commenting 
> on RFEs and/or hot Nova bugs. I think you'd get good attendance.  I'd 
> be happy to moderate, or be the secretary for that session.
> 
> I really think if we can get Ops to use the RFE system that Neutron 
> already employs, you'll see fewer duplicates, more participation and 
> better feedback across all bugs from Ops (and others).  The Ops folks 
> will participate enthusiastically as long as they get feedback from 
> devs and/or see progress in getting their needs addressed.  If you 
> post the mail and the process (and an example of what a good RFE might
> look like) to the ops list soon, there can be a good list of RFEs by 
> the summit to get Ops to discuss and start the conversation on just 
> what they need and Nova can provide along those lines in Newton, 
> taking into account Nova's other Newton priorities.  Plus, you will 
> have a differentiator of what folks need as new features as they are 
> discovered during Ops' rollout to the newer releases.
> 
> --Rocky
> 
> 
> [1] https://bugs.launchpad.net/neutron/?
> field.searchtext=RFE&search=Search&field.status%
> 3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%
> 3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%
> 3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%
> 3Alist=INPROGRESS&field.status%
> 
3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
> [2] 
http://lists.openstack.org/pipermail/openstack-dev/2015-June/066217.html
> 
> 
> 
> >
> >-- 
> >Sean Dague
> >http://dague.net
> >
> 
>__________________________________________________________________________
> >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
> 
__________________________________________________________________________
> 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
> 
__________________________________________________________________________
> 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