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@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 <thie...@openstack.org> wrote on 03/16/2016 11:26:14 AM: > > > From: Thierry Carrez <thie...@openstack.org> > > To: openstack-dev@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev