Open Stack

On 07/29/2014 11:48 AM, Russell Bryant wrote:
> On 07/29/2014 11:43 AM, Tracy Jones wrote:
>> 3.  We have bugs that are really not bugs but features, or performance
>> issues.  They really should be a BP not a bug, but we don’t want these
>> things to fall off the radar so they are bugs… But we don’t really know
>> what to do with them.  Should they be closed?  Should they have a
>> different category – like feature request??  Perhaps they should just be
>> wish list??
>
> I don't think blueprint are appropriate for tracking requests.  They
> should only be created when someone is proposing actually doing the work.
>
> I think Wishlist is fine for keeping a list of requests.  That's what
> I've been using it for.

There's a metric crap-ton of bugs that are *not* in Wishlist and are 
instead in High or Medium importance, but they are not necessarily bugs 
that either have a specific solution -- see: performance-related bugs -- 
or are things that frankly can never be "fixed".

We don't want to keep these things as bugs, because they aren't really 
bugs, but the blueprint/spec stuff isn't appropriate for "epics" that 
are like super-specs to be used to track general themes. We think that a 
separate category of thing is needed for tracking these themes. In 
Agile, these things are called "epics".

>> In generate we need to tighten up the definition of triaged and
>> confirmed.  Bugs should move from New -> Confirmed -> Triaged -> In
>> Progress.  JayPipes has updated the wiki to clarify this.
>>
>>    * Confirmed means someone has looked at the bug, saw there was enough
>>      into to start to diagnose, and agreed it sounds like a bug.
>>    * Triaged means someone has analyzed the bug and can propose a
>>      solution (not necessarily a patch).  If the person is not going to
>>      fix it, they should update the bug with the proposal and move the
>>      bug into Triaged.
>
> We should be careful not to conflict with the guidelines set for all
> OpenStack projects here:
>
>     https://wiki.openstack.org/wiki/BugTriage
>
> For example, that page says when a bug should be set to Confirmed or
> Triaged.  In most cases, it's Confirmed.  Triage is when there is a
> known solution.

So, yeah, we went back and forth on this. One thing that was mentioned 
is that by setting something to Wishlist from, say, High, we downplay 
the importance of the particular "bug", which, for performance and 
scalability "epics" tends to annoy both the bug submitter and the bug owner.

However, setting the bug to New, which triggers a re-verification and/or 
re-triaging of the issue, puts the onus and responsibility on the bug 
triaging team and allows the bug to be taken off of the "In progress but 
Abandoned" list and not lost into the general swamp of "In progress but 
not assigned".

Anyway, just food for thought.
-jay