Kathey Marsden wrote:
Rick Hillegas wrote:
This is what I intend to do during the triage:
1) Sanity check the Issue Type field.
2) Sanity check and mark all applicable check boxes.
Those fields plus the user votes will give me the information I need
to guide my bug fixing.
I guess that would bring me back to Urgency then. Dag said:
"Doc: This is the field used for dynamically reflecting scheduling
opinions and decisions; when a release manager is appointed, typically
a release manager will "own" this field to reflect how she sees how
issues should be prioritized for fixing prior to a release
("releasability"). Presumably, no release will be made if there is a
"blocker" left. This field also takes likelihood of users hitting a
bug into account; Priority a.k.a. Severity does not. After triage, no
bug should have the "none" urgency.
"
It seems reasonable that the release manager would be able to use this
field to mark issues as Blocker or maybe even Urgent, but it seems it
would be a bit cumbersome to rank all of the issues with his/her
personal opinion and as you say individuals will use whatever method
they like to prioritize their bug fixing for non-blocker issues.
You're the next release manager. If you want to publish some
easy-to-evaluate rules for filling-in this field, I'm happy to
sanity-check this field too when I triage my lump of JIRAs. Something,
for instance, which mapped check boxes to Urgency values, like this:
Data Corruption => Blocker
Crash = > Blocker
Wrong query result + Seen in production + has no workaround => Blocker
Performance + Seen in production + has no workaround => Urgent
Security + Seen in production + has no workaround => Urgent
Everything else => Normal
An enterprising soul might even be able to write a script which updates
the Urgency field given a set of rules like those above.
Thanks,
-Rick
Kathey
