On 03/15/2016 04:09 PM, melanie witt wrote:
> On Mar 15, 2016, at 10:59, Tim Bell <tim.b...@cern.ch> 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
