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 it's misleading.

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 http://www.st.cs.uni-saarland.de/softevo/bugclassify/paper/icse2013-bugclassify.pdf 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".