(In reply to Andre Klapper from comment #9)
> For my better understanding (and maybe others who might have the same
> problem):
> "Time to first action by Priority" - How is an "action" defined?

It means that someone (else, not the reporter) has changed priority, severity, etc. That the bug has some history of changes, although afaik a first comment is not counted (Santi must confirm). See Bug 13162, which tops the list, it hasn't seen any change since it was submitted in 2008.

(It belongs to the MultiBoilerplate extension which afaik is not part of the Key Wikimedia projects, a way to fine tune the list of products/components we scan is to remove those that show up in the top results.)

> Is "Time to
> first comment" a subset, or disjunct? Would changing the status from
> REOPENED to NEW count as an action already?

A bug REOPENED has been RESOLVED before, therefore it was acted upon already.

(In reply to Andre Klapper from comment #10)
> 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?

Yes, this is not optimal but, unless it is easy to fix, I would leave it as such for the current iteration. We want to complete this KPI (well, the 5 KPIs) in this quarter, and Marc is already around the corner.
 
> 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).

Following on Comment 7, this would be translated as

"How old are today the open bugs that haven't received any action yet, organized by their priority/severity today"? And last month (based on the priority/severity they had last month)? And a year ago (based on the priority/severity they had last year)?

As said, if Santi sees a quick way to fix this let's do it. Otherwise let's open an enhancement request for the next iteration.

I bet the current way of counting is still useful: for instance, if many urgent bugs were unnoticed for a long time, this will affect the time to address urgent issues, and it will show that we are slow addressing issues that were potentially urgent before we looked at them.

I'm leaving the rest to Santi, but let's not deviate on the current focus es defined in Comment 7. We need to deliver a good iteration soon, and we have still many fonts open here.