[openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
Long story short, I'm in favor of abandoning the use of "wishlist" as an importance in bug reports to track requests for enhancements. The reason I bring this up is [1] which I closed as invalid because I saw it as a RFE. jichenjc disagreed with my approach there. I'm asking here on the ML to check what the common understanding is. My reasons to *not* use "wishlist" are: * the absence of a feature is not a bug * a bug report describes a faulty behavior of existing features * we don't have a process to transform wishlist bugs to blueprints * wishlist bugs could be used to sneak in features after the feature freeze * using a bug report bypasses the blueprint approval process * using "wishlist" as an importance below "low" is a granularity which doesn't help We have ~160 bug reports which are set to "wishlist" and are in an open state. 2/3 of them are older than 1 year and would need a new assessment if they are still valid. As we have enough valid bugs open I'm not sure which benefit we have to keep them open and who would do the new assessment. Alternative: mriedem used a combination of "wishlist" + "opinion" (a closed state) in [2], which does also make sense to me, as it is easy to query. Not sure who would do that though. References: [1] https://bugs.launchpad.net/nova/+bug/1556756 [2] https://bugs.launchpad.net/nova/+bug/1552786 Regards, Markus Zoeller (markus_z) __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On Tue, 15 Mar 2016, Markus Zoeller wrote: Long story short, I'm in favor of abandoning the use of "wishlist" as an importance in bug reports to track requests for enhancements. While I'm very much in favor of limiting the amount of time issues (of any sort) linger in launchpad[1] I worry that if we stop making "wishlist" available as an option then people who are not well informed about the complex system for achieving features in Nova will have no medium to get their ideas into the system. We want users to sometime be able to walk up, drop an idea and move on without having to be responsible for actually doing that work. If we insist that such ideas must go through the blueprint process then most ideas will be left unstated. What I think we need to do instead is fix this problem: * we don't have a process to transform wishlist bugs to blueprints such that we do have a process of some kind where a wishlist idea either gets an owner who starts the blueprint process (because it is just that cool) or dies from lack of attention. It's clear, though, that we already have a huge debt in bug/issue management so adding yet another task is hard to contemplate. I think we can address some of that by more quickly expiring bugs that have had no recent activity or attention, on the assumption that: * They will come back up again if they are good ideas or real bugs. * Lack of attention is a truthy signal of either lack of resources or lack of importance. What needs to happen is that fewer things which are not actionable or nobody is interested in show up when traversing the bugs looking for something to work on. I'm happy to help some of this become true, in part because of [1] below. [1] I've recently spent a bit of time chasing bugs tagged "scheduler" and far too many of them are so old that it's impossible to tell whether they matter any more, and many of them are confused by patches and people who have gone in and out of existence. It's challenging to tease out what can be done and the information has very little archival value. It should go off the radar. Having a bunch of stuff that looks like it needs to be done but never actually is is stop energy and depressing. -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent tw: @anticdent__ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 3/15/2016 8:37 AM, Chris Dent wrote: On Tue, 15 Mar 2016, Markus Zoeller wrote: Long story short, I'm in favor of abandoning the use of "wishlist" as an importance in bug reports to track requests for enhancements. While I'm very much in favor of limiting the amount of time issues (of any sort) linger in launchpad[1] I worry that if we stop making "wishlist" available as an option then people who are not well informed about the complex system for achieving features in Nova will have no medium to get their ideas into the system. We want users to sometime be able to walk up, drop an idea and move on without having to be responsible for actually doing that work. If we insist that such ideas must go through the blueprint process then most ideas will be left unstated. We do have a way for people to drop off RFEs/ideas for features without actually providing design details, which is the backlog specs: https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html What I think we need to do instead is fix this problem: * we don't have a process to transform wishlist bugs to blueprints such that we do have a process of some kind where a wishlist idea either gets an owner who starts the blueprint process (because it is just that cool) or dies from lack of attention. It's clear, though, that we already have a huge debt in bug/issue management so adding yet another task is hard to contemplate. I think we can address some of that by more quickly expiring bugs that have had no recent activity or attention, on the assumption that: * They will come back up again if they are good ideas or real bugs. * Lack of attention is a truthy signal of either lack of resources or lack of importance. What needs to happen is that fewer things which are not actionable or nobody is interested in show up when traversing the bugs looking for something to work on. I'm happy to help some of this become true, in part because of [1] below. [1] I've recently spent a bit of time chasing bugs tagged "scheduler" and far too many of them are so old that it's impossible to tell whether they matter any more, and many of them are confused by patches and people who have gone in and out of existence. It's challenging to tease out what can be done and the information has very little archival value. It should go off the radar. Having a bunch of stuff that looks like it needs to be done but never actually is is stop energy and depressing. __ 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 We need to shrink the nova bug backlog. I'd say any wishlist bugs that are open for over a year (maybe even 6 months) should be marked Invalid with a comment saying to file a blueprint or a backlog spec (with links on how to do that). -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 03/15/2016 09:37 AM, Chris Dent wrote: > On Tue, 15 Mar 2016, Markus Zoeller wrote: > >> Long story short, I'm in favor of abandoning the use of "wishlist" >> as an importance in bug reports to track requests for enhancements. > > While I'm very much in favor of limiting the amount of time issues > (of any sort) linger in launchpad[1] I worry that if we stop making > "wishlist" available as an option then people who are not well > informed about the complex system for achieving features in Nova > will have no medium to get their ideas into the system. We want > users to sometime be able to walk up, drop an idea and move on without > having to be responsible for actually doing that work. If we insist > that such ideas must go through the blueprint process then most > ideas will be left unstated. I believe that 0% of such drive by wishlist items ever get implemented. I also think they mostly don't even get ACKed until 6 or 12 months after submission. So It's not really a useful feedback channel. So I'm pro just closing Wishlist items as Opinion and moving on. Probably with some boiler plate around it about submission guidelines for making a lightweight blueprint. > What I think we need to do instead is fix this problem: > >> * we don't have a process to transform wishlist bugs to blueprints > > such that we do have a process of some kind where a wishlist idea > either gets an owner who starts the blueprint process (because it is > just that cool) or dies from lack of attention. > > It's clear, though, that we already have a huge debt in bug/issue > management so adding yet another task is hard to contemplate. > > I think we can address some of that by more quickly expiring bugs > that have had no recent activity or attention, on the assumption > that: > > * They will come back up again if they are good ideas or real bugs. > * Lack of attention is a truthy signal of either lack of resources or lack > of importance. > > What needs to happen is that fewer things which are not actionable > or nobody is interested in show up when traversing the bugs looking > for something to work on. > > I'm happy to help some of this become true, in part because of [1] > below. > > [1] I've recently spent a bit of time chasing bugs tagged > "scheduler" and far too many of them are so old that it's impossible > to tell whether they matter any more, and many of them are confused > by patches and people who have gone in and out of existence. It's > challenging to tease out what can be done and the information has > very little archival value. It should go off the radar. Having a > bunch of stuff that looks like it needs to be done but never > actually is is stop energy and depressing. Agreed. At 1000 open artifacts (many of them bad), you can't keep enough context in your head at once to know things are really issues or not, and once they get old enough they are lost to the mists of time. Having a smaller high quality bug list would make it more of a todo list, which would be nice for both experienced folks in the project, and new people looking to contribute something off the bat. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
Le 15/03/2016 14:48, Matt Riedemann a écrit : On 3/15/2016 8:37 AM, Chris Dent wrote: On Tue, 15 Mar 2016, Markus Zoeller wrote: Long story short, I'm in favor of abandoning the use of "wishlist" as an importance in bug reports to track requests for enhancements. While I'm very much in favor of limiting the amount of time issues (of any sort) linger in launchpad[1] I worry that if we stop making "wishlist" available as an option then people who are not well informed about the complex system for achieving features in Nova will have no medium to get their ideas into the system. We want users to sometime be able to walk up, drop an idea and move on without having to be responsible for actually doing that work. If we insist that such ideas must go through the blueprint process then most ideas will be left unstated. We do have a way for people to drop off RFEs/ideas for features without actually providing design details, which is the backlog specs: https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html I tend to agree, we could just put either opinion/wishlist or invalid/wishlist and gently ask the bug reporter to open at least a blueprint. I'm not sure a backlog spec for a tiny RFE is worthwhile, because it would generate a lot of changes up to nova-specs tho, but in case we see some Launchpad blueprint needing a backlog spec, we could then invalid the blueprint and ask for a backlog spec instead. -Sylvain What I think we need to do instead is fix this problem: * we don't have a process to transform wishlist bugs to blueprints such that we do have a process of some kind where a wishlist idea either gets an owner who starts the blueprint process (because it is just that cool) or dies from lack of attention. It's clear, though, that we already have a huge debt in bug/issue management so adding yet another task is hard to contemplate. I think we can address some of that by more quickly expiring bugs that have had no recent activity or attention, on the assumption that: * They will come back up again if they are good ideas or real bugs. * Lack of attention is a truthy signal of either lack of resources or lack of importance. What needs to happen is that fewer things which are not actionable or nobody is interested in show up when traversing the bugs looking for something to work on. I'm happy to help some of this become true, in part because of [1] below. [1] I've recently spent a bit of time chasing bugs tagged "scheduler" and far too many of them are so old that it's impossible to tell whether they matter any more, and many of them are confused by patches and people who have gone in and out of existence. It's challenging to tease out what can be done and the information has very little archival value. It should go off the radar. Having a bunch of stuff that looks like it needs to be done but never actually is is stop energy and depressing. __ 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 We need to shrink the nova bug backlog. I'd say any wishlist bugs that are open for over a year (maybe even 6 months) should be marked Invalid with a comment saying to file a blueprint or a backlog spec (with links on how to do that). __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On Tue, 15 Mar 2016, Matt Riedemann wrote: We do have a way for people to drop off RFEs/ideas for features without actually providing design details, which is the backlog specs: https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html In what universe is writing a backlog spec walking up and dropping an idea? It's not necessarily a bad thing to have that level of friction, but it is something we should be aware of. My take is that if we do have that level of friction then influence, in its many forms, will solely be mediated by the vendors that consume the upstream OpenStack community, or people who have the wherewithal to become embedded in the community. Is that fully healthy? Sean said: I believe that 0% of such drive by wishlist items ever get implemented. I also think they mostly don't even get ACKed until 6 or 12 months after submission. So It's not really a useful feedback channel. That's a shame. [snip] Matt said: We need to shrink the nova bug backlog. I'd say any wishlist bugs that are open for over a year (maybe even 6 months) should be marked Invalid with a comment saying to file a blueprint or a backlog spec (with links on how to do that). Sean said: Agreed. At 1000 open artifacts (many of them bad), you can't keep enough context in your head at once to know things are really issues or not, and once they get old enough they are lost to the mists of time. Having a smaller high quality bug list would make it more of a todo list, which would be nice for both experienced folks in the project, and new people looking to contribute something off the bat. I think whatever timegap we use for expiring stuff it should _not_ be on anything resembling the length of a cycle. It should be a bit shorter so as to keep the ebb and flow of the bug handling on its own flow: something that anybody can do in the gaps of whatever else they are doing without regard to the cycle's handling of features. But yes, some kind of expiration of the backlog would be great. I'll start doing what I can when I see it. -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent tw: @anticdent__ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
Chris Dent wrote on 03/15/2016 02:37:45 PM: > From: Chris Dent > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 03/15/2016 02:38 PM > Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint? > > On Tue, 15 Mar 2016, Markus Zoeller wrote: > > > Long story short, I'm in favor of abandoning the use of "wishlist" > > as an importance in bug reports to track requests for enhancements. > > While I'm very much in favor of limiting the amount of time issues > (of any sort) linger in launchpad[1] I worry that if we stop making > "wishlist" available as an option then people who are not well > informed about the complex system for achieving features in Nova > will have no medium to get their ideas into the system. We want > users to sometime be able to walk up, drop an idea and move on without > having to be responsible for actually doing that work. If we insist > that such ideas must go through the blueprint process then most > ideas will be left unstated. > > What I think we need to do instead is fix this problem: > > > * we don't have a process to transform wishlist bugs to blueprints > > such that we do have a process of some kind where a wishlist idea > either gets an owner who starts the blueprint process (because it is > just that cool) or dies from lack of attention. > > It's clear, though, that we already have a huge debt in bug/issue > management so adding yet another task is hard to contemplate. > > I think we can address some of that by more quickly expiring bugs > that have had no recent activity or attention, on the assumption > that: > > * They will come back up again if they are good ideas or real bugs. > * Lack of attention is a truthy signal of either lack of resources or lack >of importance. > > What needs to happen is that fewer things which are not actionable > or nobody is interested in show up when traversing the bugs looking > for something to work on. Regarding the expiration of bug reports, I have [1] in the pipeline which had a proposal there at the end. It's something I'd like to discuss at the summit. Right now I'm focusing on the "wishlist" ones. > [...] References: [1] https://review.openstack.org/#/c/266453/2/doc/source/bug_process.rst Regards, Markus Zoeller (markus_z) __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
Sean Dague wrote on 03/15/2016 02:52:47 PM: > From: Sean Dague > To: openstack-dev@lists.openstack.org > Date: 03/15/2016 02:53 PM > Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint? > > On 03/15/2016 09:37 AM, Chris Dent wrote: > > On Tue, 15 Mar 2016, Markus Zoeller wrote: > > > >> Long story short, I'm in favor of abandoning the use of "wishlist" > >> as an importance in bug reports to track requests for enhancements. > > > > While I'm very much in favor of limiting the amount of time issues > > (of any sort) linger in launchpad[1] I worry that if we stop making > > "wishlist" available as an option then people who are not well > > informed about the complex system for achieving features in Nova > > will have no medium to get their ideas into the system. We want > > users to sometime be able to walk up, drop an idea and move on without > > having to be responsible for actually doing that work. If we insist > > that such ideas must go through the blueprint process then most > > ideas will be left unstated. > > I believe that 0% of such drive by wishlist items ever get implemented. > I also think they mostly don't even get ACKed until 6 or 12 months after > submission. So It's not really a useful feedback channel. > > So I'm pro just closing Wishlist items as Opinion and moving on. > Probably with some boiler plate around it about submission guidelines > for making a lightweight blueprint. A few more specific numbers which could help to make a decission. Open wishlist bug reports older than: > now: 146 > 6 months: 141 > 12 months: 122 Wishlist bug reports in progress: 9 Wishlist bug reports implemented: 46 (last 24 months) 25 (last 18 months) 19 (last 12 months) 5 (last 6 months) Based on that it seems to me that it is not a very successful channel to get ideas implemented(!). The dropping is easy though. Based on that I'm very much in favor of the agressive choice to close the remaining 146 wishlist bugs with a comment which explains how to go on from there (using backlog specs). > > What I think we need to do instead is fix this problem: > > > >> * we don't have a process to transform wishlist bugs to blueprints > > > > such that we do have a process of some kind where a wishlist idea > > either gets an owner who starts the blueprint process (because it is > > just that cool) or dies from lack of attention. > > > > It's clear, though, that we already have a huge debt in bug/issue > > management so adding yet another task is hard to contemplate. > > > > I think we can address some of that by more quickly expiring bugs > > that have had no recent activity or attention, on the assumption > > that: > > > > * They will come back up again if they are good ideas or real bugs. > > * Lack of attention is a truthy signal of either lack of resources or lack > > of importance. > > > > What needs to happen is that fewer things which are not actionable > > or nobody is interested in show up when traversing the bugs looking > > for something to work on. > > > > I'm happy to help some of this become true, in part because of [1] > > below. > > > > [1] I've recently spent a bit of time chasing bugs tagged > > "scheduler" and far too many of them are so old that it's impossible > > to tell whether they matter any more, and many of them are confused > > by patches and people who have gone in and out of existence. It's > > challenging to tease out what can be done and the information has > > very little archival value. It should go off the radar. Having a > > bunch of stuff that looks like it needs to be done but never > > actually is is stop energy and depressing. > > Agreed. At 1000 open artifacts (many of them bad), you can't keep enough > context in your head at once to know things are really issues or not, > and once they get old enough they are lost to the mists of time. Having > a smaller high quality bug list would make it more of a todo list, which > would be nice for both experienced folks in the project, and new people > looking to contribute something off the bat. > >-Sean True, that's a goal we should aim for. The old bug reports bind unnecessarily resources. Regards, Markus Zoeller (markus_z) __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
Chris Dent wrote on 03/15/2016 03:23:42 PM: > From: Chris Dent > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 03/15/2016 03:24 PM > Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint? > > On Tue, 15 Mar 2016, Matt Riedemann wrote: > > > We do have a way for people to drop off RFEs/ideas for features without > > actually providing design details, which is the backlog specs: > > > > https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html > > In what universe is writing a backlog spec walking up and dropping > an idea? > > It's not necessarily a bad thing to have that level of friction, but > it is something we should be aware of. Having 2 channels to communicate an idea, both with different levels of friction, the easier one will be used. And that's the bug list. Instantly closing new "wishlist" bugs in the future leaves one channel open. The friction of that channel is fine IMO. > My take is that if we do have that level of friction then influence, in > its many forms, will solely be mediated by the vendors that consume the > upstream OpenStack community, or people who have the wherewithal to > become embedded in the community. Is that fully healthy? I don't understand this, could you rephrase it please? > [...] > > -- > Chris Dent (�s°□°)�s�喋擤ォ� http://anticdent.org/ > freenode: cdent tw: > @anticdent__ > 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 Regards, Markus Zoeller (markus_z) __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On Tue, 15 Mar 2016, Markus Zoeller wrote:
Chris Dent wrote on 03/15/2016 03:23:42 PM:
My take is that if we do have that level of friction then influence, in
its many forms, will solely be mediated by the vendors that consume the
upstream OpenStack community, or people who have the wherewithal to
become embedded in the community. Is that fully healthy?
I don't understand this, could you rephrase it please?
Just for an example:
Say I'm a hobbyist in the basement who has just installed openstack
using whatever combination of packages, puppet, chef, ansible,
trunk, sheer grit, whatever on my spare hardware because I want to
know how it all works. After some effort I get it working, start
using it, and find some issues. Those issues come in two forms:
* What would be described by reasonable folk as a bug ("I do some api
request and get a 500, really I should get a 4xx"). I report that
to launchpad with a replication scenario, eventually somebody comes
along, sees an actionable bug and fixes it, thanks me for the
clear MTC.
* I get used to using things and realize that for a particular use
case it would be useful to be able to express it more clearly. I
report that to launchpad with a description of the idea and how it
fits in to the world. It gets closed as wishlist with a bump to
the backlog specs. I'm just a guy in the basement, I can't be
bothered with going to the trouble of making a commit, I guess my
ideas aren't that important.
Meanwhile, fortune 500 company chrisshoe, inc.[2] has contracted with
Hbirahat, the new consolidated enterprise OpenStack company, for a few
millions dollars worth of help on their new private cloud. While
working on that the professionals involved have realized they need a
particular feature. Hbirahat has a lot of people involved in
OpenStack[1], so no problem, we'll just get one of the cores in the
related project to write a spec, massage it through.
Turns out that idea from chrisshoe, inc. was in the same area as the one
that me in the basement had, except mine was several months earlier. And
while the chrisshoe solution is oriented towards easing private clouds
for enterprises, mine was for easing experimental clouds for people in
the basement. I could have spent the day not just writing up the backlog
spec, but also first of all figuring out _how_ to write a backlog spec.
Instead I just went about my original goal because meh.
You could argue that I (in the basement) just didn't care enough
and if I did I would have scratched my itch. That would be entirely
fair in many open source projects and may even be in this one. But
there's an extent to which the leverage that a monied corporation
can exercise in the OpenStack environment is a bit ... disconcerting.
It makes it seem like that for individual contributors we may want
to grease the pathways of contribution to compensate for the
advantages that the corporate behemoths have. I, unfortunately, don't
have any immediate ideas on how that might be done in the face our
pre-existing situation.
[1] All of them, pretty much, because of the industry consolidation.
[2] Makers of comfy shoes for comfy folk.
--
Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 15/03/16 16:21, "Markus Zoeller" wrote: >Sean Dague wrote on 03/15/2016 02:52:47 PM: > >> From: Sean Dague >> To: openstack-dev@lists.openstack.org >> Date: 03/15/2016 02:53 PM >> Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) >blueprint? >> >> On 03/15/2016 09:37 AM, Chris Dent wrote: >> > On Tue, 15 Mar 2016, Markus Zoeller wrote: >> > >> >> Long story short, I'm in favor of abandoning the use of "wishlist" >> >> as an importance in bug reports to track requests for enhancements. >> > >> > While I'm very much in favor of limiting the amount of time issues >> > (of any sort) linger in launchpad[1] I worry that if we stop making >> > "wishlist" available as an option then people who are not well >> > informed about the complex system for achieving features in Nova >> > will have no medium to get their ideas into the system. We want >> > users to sometime be able to walk up, drop an idea and move on without >> > having to be responsible for actually doing that work. If we insist >> > that such ideas must go through the blueprint process then most >> > ideas will be left unstated. >> >> I believe that 0% of such drive by wishlist items ever get implemented. >> I also think they mostly don't even get ACKed until 6 or 12 months after >> submission. So It's not really a useful feedback channel. >> >> So I'm pro just closing Wishlist items as Opinion and moving on. >> Probably with some boiler plate around it about submission guidelines >> for making a lightweight blueprint. > >A few more specific numbers which could help to make a decission. >Open wishlist bug reports older than: >> now: 146 >> 6 months: 141 >> 12 months: 122 > >Wishlist bug reports in progress: 9 >Wishlist bug reports implemented: >46 (last 24 months) >25 (last 18 months) >19 (last 12 months) > 5 (last 6 months) > >Based on that it seems to me that it is not a very successful >channel to get ideas implemented(!). The dropping is easy though. > >Based on that I'm very much in favor of the agressive choice to close >the remaining 146 wishlist bugs with a comment which explains how to >go on from there (using backlog specs). The bug process was very light weight for an operator who found something they would like enhanced. It could be done through the web and did not require git/gerrit knowledge. I went through the process for a change: - Reported a bug for the need to add an L2 cache size option for QEMU (https://bugs.launchpad.net/nova/+bug/1509304) closed as invalid since this was a feature request - When this was closed, I followed the process and submitted a spec (https://blueprints.launchpad.net/nova/+spec/qcow2-l2-cache-size-configuration) It was not clear how to proceed from here for me. The risk I see is that we are missing input to the development process in view of the complexity of submitting those requirements. Clearly, setting the bar too low means that there is no clear requirement statement etc. However, I think the combination of tools and assumption of knowledge of the process means that we are missing the opportunity for good quality input. Many of these are low hanging fruit improvements which could be used to bring developers into the community if we can find a good way to get the input and match it with the resource to implement. Tim > >> > What I think we need to do instead is fix this problem: >> > >> >> * we don't have a process to transform wishlist bugs to blueprints >> > >> > such that we do have a process of some kind where a wishlist idea >> > either gets an owner who starts the blueprint process (because it is >> > just that cool) or dies from lack of attention. >> > >> > It's clear, though, that we already have a huge debt in bug/issue >> > management so adding yet another task is hard to contemplate. >> > >> > I think we can address some of that by more quickly expiring bugs >> > that have had no recent activity or attention, on the assumption >> > that: >> > >> > * They will come back up again if they are good ideas or real bugs. >> > * Lack of attention is a truthy signal of either lack of resources or >lack >> > of importance. >> > >> > What needs to happen is that fewer things which are not actionable >> > or nobody is interested in show up when traversing the bugs looking >> > for something to work on. >> > >> > I'm happy to help some of
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
agree we can ask people to submit their requirement through backlog spec but not sure it might have too much process sometimes the bug opener is not a developer, it might be some operatoror openstack user, they just want to get it done but they don't know more detailso we can keep the wishlist and cleanup it and mark it invalid as you suggestedlike 6 month or 1 year, but mark the bug which may contains valid request Invalid like [1] right afterwe found it's not current supported seems too rush[1]https://bugs.launchpad.net/bugs/1556756-Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote: -To: openstack-dev@lists.openstack.orgFrom: Matt Riedemann <mrie...@linux.vnet.ibm.com>Date: 03/15/2016 02:50PMSubject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?On 3/15/2016 8:37 AM, Chris Dent wrote:> On Tue, 15 Mar 2016, Markus Zoeller wrote:>>> Long story short, I'm in favor of abandoning the use of "wishlist">> as an importance in bug reports to track requests for enhancements.>> While I'm very much in favor of limiting the amount of time issues> (of any sort) linger in launchpad[1] I worry that if we stop making> "wishlist" available as an option then people who are not well> informed about the complex system for achieving features in Nova> will have no medium to get their ideas into the system. We want> users to sometime be able to walk up, drop an idea and move on without> having to be responsible for actually doing that work. If we insist> that such ideas must go through the blueprint process then most> ideas will be left unstated.We do have a way for people to drop off RFEs/ideas for features without actually providing design details, which is the backlog specs:https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html>> What I think we need to do instead is fix this problem:>>> * we don't have a process to transform wishlist bugs to blueprints>> such that we do have a process of some kind where a wishlist idea> either gets an owner who starts the blueprint process (because it is> just that cool) or dies from lack of attention.>> It's clear, though, that we already have a huge debt in bug/issue> management so adding yet another task is hard to contemplate.>> I think we can address some of that by more quickly expiring bugs> that have had no recent activity or attention, on the assumption> that:>> * They will come back up again if they are good ideas or real bugs.> * Lack of attention is a truthy signal of either lack of resources or lack> of importance.>> What needs to happen is that fewer things which are not actionable> or nobody is interested in show up when traversing the bugs looking> for something to work on.>> I'm happy to help some of this become true, in part because of [1]> below.>> [1] I've recently spent a bit of time chasing bugs tagged> "scheduler" and far too many of them are so old that it's impossible> to tell whether they matter any more, and many of them are confused> by patches and people who have gone in and out of existence. It's> challenging to tease out what can be done and the information has> very little archival value. It should go off the radar. Having a> bunch of stuff that looks like it needs to be done but never> actually is is stop energy and depressing.>>>> __> 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>We need to shrink the nova bug backlog. I'd say any wishlist bugs that are open for over a year (maybe even 6 months) should be marked Invalid with a comment saying to file a blueprint or a backlog spec (with links on how to do that).-- Thanks,Matt Riedemann__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On Mar 15, 2016, at 10:59, Tim Bell wrote: > The risk I see is that we are missing input to the development process in > view of the complexity of submitting those requirements. Clearly, setting the > bar too low means that there is no clear requirement statement etc. However, > I think the combination of tools and assumption of knowledge of the process > means that we are missing the opportunity for good quality input. > > Many of these are low hanging fruit improvements which could be used to bring > developers into the community if we can find a good way to get the input and > match it with the resource to implement. Agreed. I think Wishlist bugs have had value but I'll admit the value is small compared to the total number of Wishlist bugs. The thing I like about them is that they're easy for anyone to open and people can pile on and say "me too" so we get some indication of how much interest there is in a feature/idea (the launchpad bug heat increases). I have seen this work well in a couple of cases where I don't think we could have found out people were interested in something otherwise. Digging up examples: * Several novaclient users would like it if tenant ids were validated against keystone [1] (Look how many duplicates and the bug heat!). It has since evolved into a spec [2] and blueprint [3]. I didn't think this would be as popular as it is, but I know it from the number of bugs people have opened that I have marked as duplicates of a Wishlist bug. * Several nova users are interested in the capability to detach the root device volume of an instance, when in shutoff state [4]. This one, I had no idea about until I saw the bug. I think the spec process is heavy for a person who just wants to communicate a feature ask and it requires that other people be able to find that spec to +1 it before it potentially goes into the abandoned state once spec freeze happens. I can't imagine users finding a spec being that they're not searchable. I feel like you have to "be in the know" to vote on a spec. With the Wishlist bugs, users can search to find things they're interested in and add comments. Triagers can see duplicates and mark them as such, which bubbles up popular asks via bug heat. It's a lot of manual work, though. -melanie [1] https://bugs.launchpad.net/nova/+bug/1118066 [2] https://review.openstack.org/#/c/92507/ [3] https://blueprints.launchpad.net/nova/+spec/validate-project-with-keystone [4] https://bugs.launchpad.net/nova/+bug/1396965 signature.asc Description: Message signed with OpenPGP using GPGMail __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 03/15/2016 04:09 PM, melanie witt wrote: > On Mar 15, 2016, at 10:59, Tim Bell wrote: > >> The risk I see is that we are missing input to the development process in >> view of the complexity of submitting those requirements. Clearly, setting >> the bar too low means that there is no clear requirement statement etc. >> However, I think the combination of tools and assumption of knowledge of the >> process means that we are missing the opportunity for good quality input. >> >> Many of these are low hanging fruit improvements which could be used to >> bring developers into the community if we can find a good way to get the >> input and match it with the resource to implement. > > Agreed. I think Wishlist bugs have had value but I'll admit the value is > small compared to the total number of Wishlist bugs. > > The thing I like about them is that they're easy for anyone to open and > people can pile on and say "me too" so we get some indication of how much > interest there is in a feature/idea (the launchpad bug heat increases). I > have seen this work well in a couple of cases where I don't think we could > have found out people were interested in something otherwise. > > Digging up examples: > > * Several novaclient users would like it if tenant ids were validated against > keystone [1] (Look how many duplicates and the bug heat!). It has since > evolved into a spec [2] and blueprint [3]. I didn't think this would be as > popular as it is, but I know it from the number of bugs people have opened > that I have marked as duplicates of a Wishlist bug. > > * Several nova users are interested in the capability to detach the root > device volume of an instance, when in shutoff state [4]. This one, I had no > idea about until I saw the bug. > > > I think the spec process is heavy for a person who just wants to communicate > a feature ask and it requires that other people be able to find that spec to > +1 it before it potentially goes into the abandoned state once spec freeze > happens. I can't imagine users finding a spec being that they're not > searchable. I feel like you have to "be in the know" to vote on a spec. With > the Wishlist bugs, users can search to find things they're interested in and > add comments. Triagers can see duplicates and mark them as such, which > bubbles up popular asks via bug heat. It's a lot of manual work, though. I think this is the key issue. It is so much manual and noise in most of the cases that it actually slows down the fixing of real bugs. And burns out all the triagers. Markus has been lasting in this role longer than most, so I want to defer to his judgment about being able to stay in it and stay sane. 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. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On Tue, Mar 15, 2016 at 05:59:32PM +, Tim Bell wrote: [...] > The bug process was very light weight for an operator who found > something they would like enhanced. It could be done through the web > and did not require git/gerrit knowledge. I went through the process > for a change: > > - Reported a bug for the need to add an L2 cache size option for QEMU > (https://bugs.launchpad.net/nova/+bug/1509304) closed as invalid since > this was a feature request - When this was closed, I followed the > process and submitted a spec > (https://blueprints.launchpad.net/nova/+spec/qcow2-l2-cache-size-configuration) > > It was not clear how to proceed from here for me. Given the feature request is fairly self-contained (so, it wouldn't warrant a specification), the next step would be someone feeling motivated enough to submit a patch to implement it. > The risk I see is that we are missing input to the development process > in view of the complexity of submitting those requirements. Clearly, > setting the bar too low means that there is no clear requirement > statement etc. However, I think the combination of tools and > assumption of knowledge of the process means that we are missing the > opportunity for good quality input. >From an Operator's perspective, I think your concern seems reasonable: having a friction-free way to provide input (like an RFE bug) vs. having the process knowledge (Spec-less Blueprint vs. Blueprint with Spec). But, given Markus' stats about 'Wishlist' implementation, that category doesn't seem to be quite effective. [...] -- /kashyap __ 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
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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
How do other teams capture feature requests outside of the blueprint/spec process? I'm inclined to agree with the others about the bug queue not being the right place for it, as someone who has been assisting with bug queue maintenance. I also agree with the other points brought up that we need an easy way for folks to submit such requests as the "Wishlist" bug option clearly fills a role (and was failing at it). We definitely need to make sure we stay accessible to our user community. --- Augustina Ragwitz Sr System Software Engineer, HPE Cloud Hewlett Packard Enterprise --- irc: auggy __ 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
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 wrote on 03/16/2016 11:26:14 AM: > From: Thierry Carrez > To: openstack-dev@lists.openstack.org > Date: 03/16/2016 11:27 AM > Subject: Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint? >
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 17/03/16 18:29, "Sean Dague" wrote: >On 03/17/2016 11:57 AM, Markus Zoeller wrote: > >> 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? > >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 > >-- >Sean Dague >http://dague.net > >__ >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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 03/17/2016 11:57 AM, Markus Zoeller wrote: > 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? 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 -- Sean Dague http://dague.net __ 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
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" wrote: >On 03/17/2016 11:57 AM, Markus Zoeller wrote: > >> 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
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\)" > > 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 rep
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
On 3/17/2016 1:26 PM, Tim Bell wrote: On 17/03/16 18:29, "Sean Dague" wrote: On 03/17/2016 11:57 AM, Markus Zoeller wrote: 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? 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 -- Sean Dague http://dague.net __ 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 I agree with Tim and Sean. As noted in my PTL candidacy email, I want an ops CPL for the nova team, someone that can attend the ops meeting(s?) and bring back issues. I try to add known ops people that are involved in nova to specs for their input when possible, but a lot of the time this ends up being Chet Burgess for everything (Mr Nova Ops!). But we need to get a better communication channel going with the ops list/channel/meetings and RFE bugs aren't cutting it. I like the idea of starting in the ML (dev or ops) since, as noted, if it's already done, or someone has already implemented it out of tree and just haven't had the time to push it to nova (which is more common than you'd think), it can be noted quickly. It would also foster early discussion on the idea before it shows up in gerrit as a spec review where only a small handful of spec reviewers are going to see it (which is also a reason things move slowly). If something was a bad idea, or just didn't get much enthusiasm, then it kind of dies on the vine naturally in the ML rather than a bitrot spec review in gerrit that we just end up abandoning every 6 months. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?
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 wrote on 03/18/2016 12:45:38 AM: > From: Rochelle Grober > To: "OpenStack Development Mailing List (not for usage questions)" > > 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" wrote: > > >On 03/17/2016 11:57 AM, Markus Zoeller wrote: > > > >> 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
