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