<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"> <span>agree we can ask people to submit their requirement through backlog spec but not sure it might <br>have too much process sometimes the bug opener is not a developer, it might be some operator<br>or openstack user, they just want to get it done but they don't know more detail<br><br>so we can keep the wishlist and cleanup it and mark it invalid as you suggested<br>like 6 month or 1 year, but mark the bug which may contains valid request Invalid like [1] right after<br>we found it's not current supported seems too rush<br><br></span><font size="2"><font face="Default Monospace,Courier New,Courier,monospace">[1]</font></font><font face="Default Monospace,Courier New,Courier,monospace" size="2"><a target="_blank" href="https://bugs.launchpad.net/bugs/1556756">https://bugs.launchpad.net/bugs/1556756</a></font><br><br><font color="#990099">-----Matt Riedemann <<a target="_blank" href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote: -----</font><div class="iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">To: <a target="_blank" href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>From: Matt Riedemann <<a target="_blank" href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>><br>Date: 03/15/2016 02:50PM<br>Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?<br><br><div><font face="Courier New,Courier,monospace" size="2"><br>On 3/15/2016 8:37 AM, Chris Dent wrote:<br>> On Tue, 15 Mar 2016, Markus Zoeller wrote:<br>><br>>> Long story short, I'm in favor of abandoning the use of "wishlist"<br>>> as an importance in bug reports to track requests for enhancements.<br>><br>> While I'm very much in favor of limiting the amount of time issues<br>> (of any sort) linger in launchpad[1] I worry that if we stop making<br>> "wishlist" available as an option then people who are not well<br>> informed about the complex system for achieving features in Nova<br>> will have no medium to get their ideas into the system. We want<br>> users to sometime be able to walk up, drop an idea and move on without<br>> having to be responsible for actually doing that work. If we insist<br>> that such ideas must go through the blueprint process then most<br>> ideas will be left unstated.<br><br>We do have a way for people to drop off RFEs/ideas for features without <br>actually providing design details, which is the backlog specs:<br><br><a href="https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html">https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html</a><br><br>><br>> What I think we need to do instead is fix this problem:<br>><br>>> * we don't have a process to transform wishlist bugs to blueprints<br>><br>> such that we do have a process of some kind where a wishlist idea<br>> either gets an owner who starts the blueprint process (because it is<br>> just that cool) or dies from lack of attention.<br>><br>> It's clear, though, that we already have a huge debt in bug/issue<br>> management so adding yet another task is hard to contemplate.<br>><br>> I think we can address some of that by more quickly expiring bugs<br>> that have had no recent activity or attention, on the assumption<br>> that:<br>><br>> * They will come back up again if they are good ideas or real bugs.<br>> * Lack of attention is a truthy signal of either lack of resources or lack<br>>    of importance.<br>><br>> What needs to happen is that fewer things which are not actionable<br>> or nobody is interested in show up when traversing the bugs looking<br>> for something to work on.<br>><br>> I'm happy to help some of this become true, in part because of [1]<br>> below.<br>><br>> [1] I've recently spent a bit of time chasing bugs tagged<br>> "scheduler" and far too many of them are so old that it's impossible<br>> to tell whether they matter any more, and many of them are confused<br>> by patches and people who have gone in and out of existence. It's<br>> challenging to tease out what can be done and the information has<br>> very little archival value. It should go off the radar. Having a<br>> bunch of stuff that looks like it needs to be done but never<br>> actually is is stop energy and depressing.<br>><br>><br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: <a target="_blank" href="mailto:OpenStack-dev-request@lists.openstack.org?subject">OpenStack-dev-request@lists.openstack.org?subject</a>:unsubscribe<br>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>><br><br>We need to shrink the nova bug backlog. I'd say any wishlist bugs that <br>are open for over a year (maybe even 6 months) should be marked Invalid <br>with a comment saying to file a blueprint or a backlog spec (with links <br>on how to do that).<br><br>-- <br><br>Thanks,<br><br>Matt Riedemann<br><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a target="_blank" href="mailto:OpenStack-dev-request@lists.openstack.org?subject">OpenStack-dev-request@lists.openstack.org?subject</a>:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br></font></div></div></div></font><BR>