Default Resolution set
gerv at mozilla.org
Fri Dec 10 20:45:25 UTC 2010
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
-------- 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
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.
hsivonen at iki.fi
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
More information about the developers