Open Stack

Top post as I summarize below what was said. At the end is a proposal 
of actions.

TL;DR: Use the openstack-dev ML and discuss the most wanted RFEs at 
       the summit?


The two diametral points are:

* The ops like to have a frictionless way for RFEs which need to be
  resolved explicitely (accepted|declined instead of 'starving to death')
* The nova-bugs team wants to focus on faulty behavior of existing 
  features only without the "noise" of RFEs.


Just to make myself clear about my motivation and the conditions:

* We have (almost) no volunteers for the "bug skimming duty" [1] to do
  a pre-sorting of reports (except auggy, she did/does an awesome job!)
* We have (almost) no bug tag owners which do a deeper analysis of the
  incoming valid reports [2]
* We have ~ 1000 bug reports open, a lot are (very) old and need 
  re-assessment
* Some RFEs are not written like RFEs and the nova bugs team needs 
  to figure out if this is a bug or an RFE. As I don't know every detail
  and have to research these details, it distracts a lot from real bugs
* Some of the RFEs *need* a spec as they need a REST API change. Some
  need involvement of other projects like Cinder and Neutron.
* I'm convinced that a low number of high quality features will help 
  the ops in a better way than more features which work most of the time.
  This is not a criticism on the skill of the developers, bugs are a
  normal part of SW development and need to be fixed.
* The resource restrictions described above force me (and others) to
  focus on the important things. I don't have the intention to exclude 
  people's ideas.
* I sometimes hear "Is OpenStack even Enterprise ready?". There is
  a lot ongoing with the project navigator and clear deprecation 
  policies but without focusing on the quality aspect I have a hard 
  time to say "yes, it is ready".
* I don't care a lot about the overall number of bug reports. But it's
  not comprehensible anymore and setting a focus on bugs to fix first
  is not possible this way. Bringing the list back to a comprehensible
  size is the first step in adjusting the (fixes, reviews) pipeline.
  Finishing less items is more helpful than a lot of "in progress" items
* I *do* want the ops feedback. I have the hope that ttx's proposal
  of the summit split [3] (which I support) will become *the* input 
  channel for us.


Alternative to wishlist bugs:

I'm also subscribed to the "openstack-ops" mailing list (I assume most
of us are). Posting a RFE on that list would have the following 
advantages: 
* It's the most easy way to post an idea (no Launchpad account needed)
* Other ops can chime in if they want that or not. All without querying
  Launchpad for multiple projects.
* You see RFE's for other projects too and can make conclusions if
  they maybe depend on or contradict each other.
* The triaging effort for the bugs team for RFEs is none
* The ML is (somewhat) queryable (just use [nova][RFE] in the subject)
* The ops community can filter the top priority missing features by 
  themselves before they reach out for implementation. Some ideas die 
  naturally as other ops explain how they do it (=> share knowledge)

The design summit can then have a session which goes through that list
of pre-filtered most wanted ops features and take that into account
when the priorization for the next cycle is done. This doesn't solve 
the challenge to find developers who implement that, but as these items
will have more focus there could be more volunteers.

This way could also be a good transition or supplement of the way
we would do the requirements engineering after the (hopefully coming)
split of the design summit. I'm not up-to-date how this is planned.


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


References:
[1] 
https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty
[2] https://wiki.openstack.org/wiki/Nova/BugTriage#Tags
[3] 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/087161.html

Regards, Markus Zoeller (markus_z)


Thierry Carrez <thierry at openstack.org> wrote on 03/16/2016 11:26:14 AM:

> From: Thierry Carrez <thierry at openstack.org>
> To: openstack-dev at lists.openstack.org
> Date: 03/16/2016 11:27 AM
> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) 
blueprint?
> 
> Sean Dague wrote:
> > It's a trade off. Would you rather keep Wishlist mechanism and have 
~30
> > extra bugs in every release, and have to hunt for a new bug lead twice
> > as often? That's my gut feel on the break down here.
> >
> > To get the bug backlog under control, we have to make hard calls here.
> > This is one of them. Once we're working with < 400 open issues, 
deciding
> > to reopen the Wishlist mechanism is a thing we can and should revisit.
> 
> You're right that as soon as a project is resource-constrained (be it 
> patch authors, core reviewers bandwidth or spec reviewers) and you can't 

> get everything on your own list done anyway, you're likely to gradually 
> stop looking at extra sources of inspiration. You start by ignoring the 
> unqualified "wishlist bugs", then if you still can't get your own things 

> done you'll likely ignore the more qualified "backlog specs" and if all 
> else fails you'll start ignoring the bug reports altogether.
> 
> In an ideal world you'd either grow the resources / bandwidth, or get to 

> the bottom of what you absolutely need to get done, and then start 
> paying attention to those feedback channels again. Those feedback 
> channels are essential to keep the pulse on the users problems and 
> needs, and avoid echo chamber effects. But then if you just can't give 
> them any attention, having them existing and ignored is worse than not 
> having them at all.
> 
> So if Nova currently is in that resource-constrained situation (and I 
> think it is), it's better to clearly set expectations and close the 
> wishlist bugs feedback mechanism, rather than keeping it open and 
> completely ignore it.
> 
> -- 
> Thierry Carrez (ttx)
> 
> 
__________________________________________________________________________
> 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
>