Open Stack

The correct tldr:

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

Markus Zoeller/Germany/IBM wrote on 03/17/2016 04:57:27 PM:

> From: Markus Zoeller/Germany/IBM
> To: "OpenStack Development Mailing List \(not for usage questions\)" 
> <openstack-dev at lists.openstack.org>
> Date: 03/17/2016 04:57 PM
> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) 
blueprint?
> 
> 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
> >