Default Resolution set

[Gervase Markham]

On 09/12/10 11:30, Max Kanat-Alexander wrote:
> On 12/09/2010 07:53 AM, Gervase Markham wrote:
>> There is interest in the Mozilla community in revisitng the question for
>> b.m.o. Would it be good to do the same process as we did for statuses -
>> drawing together the experience and use cases from lots of different
>> Bugzillas to see if our current set is optimal?
>
> Ah, I don't think I'd have too much interest in that--I haven't seen any
> problem being caused by the current set of resolutions on any of the
> numerous installations I've worked with,

Well, there are certainly people adding different resolutions.

> and I don't want to solve
> problems unless we have evidence that proves they exist (see
> http://www.codesimplicity.com/post/if-it-aint-broken/ ).

Here's one example of a thought-through objection. This discussion is 
going on in mozilla.dev.planning; I have just noticed a good post from 
dveditz too.

Gerv

-------- Original Message --------
Subject: Re: Bug resolutions
Date: Wed, 8 Dec 2010 05:36:05 -0800 (PST)
From: Henri Sivonen <hsivonen at iki.fi>
To: dev-planning at lists.mozilla.org
Newsgroups: mozilla.dev.planning

Gervase Markham wrote:
 > On 08/11/10 08:41, Henri Sivonen wrote:
 > > Considering that the status discussion seems to have come to an end,
 > > would now be an appropriate time to have the other discussion about
 > > the resolution field?
 >
 > I'm away for a week from Wednesday; let's look at it when I get back
 > :-)

Let's get back to this topic.

The INVALID/WONTFIX/WORKSFORME taxonomy bothers me. There have been bugs 
filed against the HTML5 parser where the allegation made in the bug 
report has been accurate, but since the described behavior is correct 
per spec and the spec is not going to be changed (e.g. a choice either 
way breaks some pages), the bug won't be FIXED. Now, the general 
semantic of WORKSFORME is that the allegation made about product 
behavior can't be reproduced. This is not the right resolution, since 
the allegation was accurate. Many times INVALID is used as the 
resolution when the product behaves per spec and INVALID indeed means 
"not a bug" per documentation. However, to a bug reporter who hasn't 
read the documentation may well interpret INVALID as a statement of the 
bug report being inaccurate. To communicate that I see the alleged 
problem but that the product nonetheless isn't going to be changed since 
the product is correct per spec, I've used WONTFIX a lot in ways that 
strictly per documentation probably should have been INVALID.

Put the other way, I think the semantics of INVALID aren't sufficiently 
obvious from the UI string without reading the definition from 
documentation. However, I think it's not really worthwhile to have a 
fine-grained taxonomy for categorizing reports that resulted in no 
change to the product. I think it would be sufficient to have two 
resolutions that indicate no change to the product:
  1) The allegation made in the bug report was accurate but the product 
isn't going to be changed.
  2) The allegation made in the bug report could not be verified to 
accurate to a degree to make the report actionable.

#1 would replace WONTFIX and the use of INVALID as documented.
#2 would replace WORKSFORME and the use of INVALID against the 
documentation to mean bogus reports.

I don't have a strong opinion of what these two resolutions should be 
called. On bugzilla.validator.nu, I called them INTENTIONAL and 
NOTREPRODUCIBLE. bugzilla.redhat.com calls #1 NOTABUG.

It might make sense to fold the INCOMPLETE resolution into #2 as well. 
However, I observe that INCOMPLETE was created after WORKSFORME already 
existed, so perhaps having INCOMPLETE as a distinction is indeed 
considered to add value.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla