andre_klapper at gmx
Aug 6, 2012, 4:24 AM
Post #5 of 5
On Thu, 2012-08-02 at 21:35 -0400, Al Snow wrote:
> Appears CLOSED status is not used much - do we stop at RESOLVED or
> VERIFIED status?
In short: CLOSED has been removed from the default workflow in Bugzilla
4.x, see https://bugzilla.mozilla.org/show_bug.cgi?id=486292
In a traditional (idealistic) workflow a patch gets committed to the
code repository and the developer / committer closes the corresponding
bug report as RESOLVED FIXED (if there are no extensions in place that
do this job for you, e.g. a bot that parses code commit messages for bug
Afterwards QA or bug reporter try out the "new version" that includes
the fix, try to reproduce the bug again, and either change status to
REOPENED (if still reproducible) or VERIFIED. For the latter case,
product or project management afterwards set the status to CLOSED (which
in my opinion is mostly a waste of time).
In case of other resolutions like e.g. RESOLVED WONTFIX, a product
maintainer / developer can set this status and theoretically the bug
reporter acknowledges / accepts the decision by setting VERIFIED status.
Especially in projects with a high involvement of volunteers / community
members with differing technical background knowledge and no direct
availability of a newer version that includes the fix, a bug reporter
cannot be expected to verify the fix in a timely manner (e.g. because
distributions do not immediately ship updated packages to the end user,
end user might miss skills to compile an unstable software version from
the code repository on her/his own, end users to not have spare time to
also verify, etc.).
> How about PRIORITY? See lots of UNPRIORITIZED that have a active
> (ACTIVE, RESOLVED) status.
If things are RESOLVED already I wouldn't care about priority, as it's
all past anyway. :)
The use of "Priority" is covered under
https://www.mediawiki.org/wiki/Bug_management/Bugzilla_usage (should be
merged with http://www.mediawiki.org/wiki/Bugzilla/Fields by a future
> Will double-check docs, but unclear how DUPLICATE tickets are set to
DUPLICATE is just another resolution, just like FIXED or WONTFIX, to
mark duplicate reports. It helps to keep discussions in one place and
can also provide statistics on how often users run into a certain issue,
making it potentially more important to fix the underlying problem.
> How long does a ticket stay in one status before we need to flag it?
Not sure what you mean. "Flag" in which way?
(To avoid potential confusion just a warning that in the Bugzilla
universe the term "flag" might have a different meaning. As far as I
know Bugzilla "flags" are currently not used in Wikimedia Bugzilla.)
> Created a couple of personal Bugzilla monitors (whiners), but any help
> with bug triage dashboard/graphs/reports/wizards/extensions would be
As usual it depends on what exactly you want to find out (the "Reports"
section and the "Advanced Search" might help), but Bugzilla does not
provide many statistics on changes *over time* unfortunately, apart from
[Product Ã— Reports per Status] charts like
> Semi-automatic detection of duplicates (see Bugzilla e-group)
Not sure what you mean by "Bugzilla e-group" here. :)
Bugzilla has a "&format=guided" format for enter_bug.cgi (just attach it
to the URL) which lists the most popular reports, but does not analyze
and compare strings or such.
The guided format in Wikimedia Bugzilla needs some cleanup and polish
first (cf. bug 36762) before it could theoretically be used.
There are a few scientific papers out there about Natural Language
Processing in bugtrackers but I'm not aware (yet) of an existing useful
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
Wikitech-l mailing list
Wikitech-l [at] lists