Hi Al,
[Expectations, workflows and manpower among FOSS projects differ so
please take my comments with a grain of salt as I don't follow the
Wikimedia project that closely.]
On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
> c. Accept
non-fix resolution
> * Accepting all non-fixed resolution.
> * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5
non-"FIXED" RESOLUTION values)
Sorry but I don't know what you mean by
"accepting" here. :/
When I look at the non-"FIXED" RESOLUTIONs
that I know about (INVALID,
WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN
it or accept the resolution and change status to VERIFIED.
...or to just leave a report as it is? :)
REOPENing normally happens if the reporter, developer or another party
interested in fixing the issue realizes that a committed fix did not fix
the issue, or to signal disagreement. I'm not convinced if triagers can
help here to save any of those persons some time.
Also I don't really see who it helps to verify RESOLVED DUPLICATE.
Personally I rather consider it a waste of time (anybody is free to
disagree of course) as efforts are better spent on general triaging like
identifying duplicates etc. which seems to be a bigger help for users
and developers.
For the other four options I normally leave it to the reporter. For
example verifying a WONTFIX (=stating for a second time that the request
will not receive a fix) might make a reporter feel less acknowledged for
spending time on reporting a bug or request.
andre
PS: For anybody _really_ interested in discussing the use of the
VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla
dev-platform/dev-quality mailing lists at
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9…
--
Andre Klapper (
maemo.org bugmaster & GNOME Bugsquad)
http://blogs.gnome.org/aklapper/