[.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
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.
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#
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad) http://blogs.gnome.org/aklapper/
Wikitech-l mailing list