Le 03/08/12 03:35, Al Snow a écrit : With svn, we would mark the bug as resolved once it got sent in the repository. With git that is done when the change is merged. I use the verified status for Wikimedia server configuration where I usually ask the bug opener to confirm the issue got solved. I also set some random bugs verified when I have actually checked the patch / correction, eventually wrote test for it and I am 100% sure it is fine. We have bugs unpriorized by default. Hexmode, our previous bugmeister, was using that field as a frequency check. Highest priority would receive daily attention, higher once a week, normal once a month via bug triage (dont quote me on the actual frequency though). For the MediaWiki core team, paid staff in charge of maintaining Mediawiki, we have a weekly review of highest priority bug. The easy change are usually done on the fly, more tricky issues are reviewed via that process. So we use that field to mark it as being urgent and needing attention from the team. I use the closed state when I want to end a bug report, making it clear to the people participating in the bug that either: - we dont want that feature / it is not a bug. - they are talking about a different bug and must open a new bug. There is nothing set. Unconfirmed remain as such till we get a way to actually reproduce the issue, have more user input or something. That let us focus on the actually confirmed bugs. Lot of trivial changes are resolved on sight and never reach the New status :-D Meanwhile, would you mind using paragraphs in your next emails? :-D -- Antoine "hashar" Musso

Hi Al, On Thu, 2012-08-02 at 21:35 -0400, Al Snow wrote: 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.). 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). 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. 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.) 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=U… 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 -- Andre Klapper (maemo.org bugmaster & GNOME Bugsquad) http://blogs.gnome.org/aklapper/