Re: [Wikitech-l] Several Bug Triage Questions
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=Wikimediadatasets=UNCONFIRMEDdatasets=NEWdatasets=ASSIGNEDdatasets=NEEDINFOdatasets=REOPENEDbanner=1 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 -- Andre Klapper (maemo.org bugmaster GNOME Bugsquad) http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Several Bug Triage Questions
Le 03/08/12 03:35, Al Snow a écrit : Also did some archaeology on Bugzilla and have some questions. Appears CLOSED status is not used much - do we stop at RESOLVED or VERIFIED status? 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. How about PRIORITY? See lots of UNPRIORITIZED that have a active (ACTIVE, RESOLVED) status. Will double-check docs, but unclear how DUPLICATE tickets are set to CLOSED. 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. How long does a ticket stay in one status before we need to flag it? 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Several Bug Triage Questions
Le 03/08/12 03:35, Al Snow a écrit : any help with bug triage dashboard/graphs/reports/wizards/extensions would be appreciated. I am only aware about the weekly bug summary at: https://bugzilla.wikimedia.org/weekly-bug-summary.cgi?tops=10days=7 Bugzilla as an XMLRpc interface which might be used to build a dashboard. Or we could involve the analytic team to generate us nice reports out of a full Bugzilla dump, they are already working on such a tool for our Gerrit tool. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Several Bug Triage Questions
Hi - I'm Al Snow. Applied for the Bug Wrangler position a week ago. Started today setting up accounts and reading about the internals. Also did some archaeology on Bugzilla and have some questions.Appears CLOSED status is not used much - do we stop at RESOLVED or VERIFIED status? How about PRIORITY? See lots of UNPRIORITIZED that have a active (ACTIVE, RESOLVED) status. Will double-check docs, but unclear how DUPLICATE tickets are set to CLOSED.How long does a ticket stay in one status before we need to flag it? Created a couple of personal Bugzilla monitors (whiners), but any help with bug triage dashboard/graphs/reports/wizards/extensions would be appreciated. Also saw reference to Bug Squad in 2012-2013 Goals. (Thanks - Julian) ..My bug triage ideas, beside the Bug Squad, include looking into:Semi-automatic detection of duplicates (see Bugzilla e-group)Semi-automatic assignment of Assignee (saw some external references)Create wizard to improve bug creation (similar to Google's BITE project ;) Wrestle that bug to the ground!Al PS. Today's notes - if you have questions about what I found in the last several days. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Several Bug Triage Questions
I don't know much about why we stop at RESOLVED, but what is most likely the preferred path would be to have some sort of QA team that goes through all RESOLVED bugs, tests them, and marks them as VERIFIED accordingly. Then finally it can be closed. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Thu, Aug 2, 2012 at 9:35 PM, Al Snow jas...@hotmail.com wrote: Hi - I'm Al Snow. Applied for the Bug Wrangler position a week ago. Started today setting up accounts and reading about the internals. Also did some archaeology on Bugzilla and have some questions.Appears CLOSED status is not used much - do we stop at RESOLVED or VERIFIED status? How about PRIORITY? See lots of UNPRIORITIZED that have a active (ACTIVE, RESOLVED) status. Will double-check docs, but unclear how DUPLICATE tickets are set to CLOSED.How long does a ticket stay in one status before we need to flag it? Created a couple of personal Bugzilla monitors (whiners), but any help with bug triage dashboard/graphs/reports/wizards/extensions would be appreciated. Also saw reference to Bug Squad in 2012-2013 Goals. (Thanks - Julian) ..My bug triage ideas, beside the Bug Squad, include looking into:Semi-automatic detection of duplicates (see Bugzilla e-group)Semi-automatic assignment of Assignee (saw some external references)Create wizard to improve bug creation (similar to Google's BITE project ;) Wrestle that bug to the ground!Al PS. Today's notes - if you have questions about what I found in the last several days. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
