--- Comment #10 from Andre Klapper <aklap...@wikimedia.org> ---
Concentrating on "Time to ... by Priority/Severity" in this comment. Need to
understand better, hence dropping some late night beer comments + thoughts.
== Bug report priority changes vs. data gathering/representation in graph
"Time to fix (TTF)"-related expectations per priority are covered in
http://www.mediawiki.org/wiki/Bugzilla/Fields#Priority - an "Immediate
priority" report should have a shorter TTF median than a "Low prio" report.
In my opinion, TTF entirely depends to the moment a report receives priority
triaging - either an initial triage or a retriage. Retriage means that Priority
(and less often Severity, though from default "Normal" to "Enhancement" might
be the one big exception here) of a report can change.
If I interpret comment 4 directly, one bug report remains in one line (color)
in the current model, based on gathering its *current* priority value?
An open report that was low priority for three years and then suddenly became
highest priority (e.g. due to other infrastructure changes creating the side
effect that the bug is way more visible) and two weeks later closed as RESOLVED
FIXED with priority still set to "highest" should probably not be shown as
"highest priority bug that took three years and two weeks to get closed" as
So: Could the framework query changes to the "Priority" value of one report
(via the "bugs_activity" database table in Bugzilla) and could one report be
broken into/represented in several lines, each line showing for how long the
report had that specific priority set? I think this would make the lines more
meaningful. (Same might apply to Severity).
== (Neglectable?) data artefacts on bug report metadata
Can I assume that *all* bug reports are used as data source, hence also all
resolutions (including WONTFIX, INVALID)?
This might be a rather neglectable artefact, but correcting report metadata
(priority, component, etc) after resolving a report (e.g. as WONTFIX, INVALID
etc) often does not happen:
"Of course, the developer could change the issue category after resolution -
but this happens rarely. In many cases there exists no real motivation to
change the issue category once the cause for a problem is found and fixed."
(Herzig, Just, and Zeller: "It's not a bug, it's a feature: how
misclassification impacts bug prediction", 2013, page 396, at
when the server is not down.)
== Time to change "Unprioritized" to different priority (likely ignorable)
As the default priority of a report is always "Unprioritized", I wonder whether
median time between creation of a bug report and changing the priority from
"Unprioritized" to a different value would be any helpful.
I am not convinced myself though: This is likely covered by "Time to first
action by Priority" which might be enough for us.
Anyway, just in case, two potentially problematic aspects for data gathering:
* Not all teams use Priority in Bugzilla. Some use Mingle etc. instead.
* Some tickets get closed so quickly that they remain "Unprioritized".
You are receiving this mail because:
You are on the CC list for the bug.
Wikibugs-l mailing list