Hi Al,
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 long: 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 numbers). 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 Bugwrangler).
Will double-check docs, but unclear how DUPLICATE tickets are set to CLOSED.
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 appreciated.
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 https://bugzilla.wikimedia.org/reports.cgi?product=Wikimedia&datasets=UN...
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 implementation (extension).
andre