Wikimedia Bugzilla is closed!

The main problems discussed so far:

* We need to scan only the Bugzilla products and components corresponding to https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects . Andre, did you have a list somewhere mapping these?

* The graphs miss a legend describing what is being calculated. Documentation in the wiki page linked above would be useful too.

* The data calculated is the average, but the median is preferred.

* The graphs start in Jan 2002 but there is no data until Jul 2004.

* Proper labels.

I still must put more time to dive into these graphs and see whether they provide the answers we are looking for, or they could be improved. Andre, you are the main stakeholder of this page.

(In reply to Quim Gil from comment #1)
> * We need to scan only the Bugzilla products and components corresponding to
> https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects . Andre,
> did you have a list somewhere mapping these?

Last list I made was bug 54469 comment 6.

> Andre, you are the main stakeholder of this page.

Noted.

One data issue in the graphs:
http://korma.wmflabs.org/browser/bugzilla_response_time.html shows "avg_fa_Immediate:788.7567" for Feb 2011. That is impossible as the "Immediate" priority was only introduced on Nov 30, 2012: http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064746.html
I have not investigated other peaks yet (also because I don't have data handy when which priority and severity was introduced in this Bugzilla).

The main problem I have with these graphs is that they show plenty of lines going up and down, but no clear message. 

When answering "Time to closed by Priority", I think we should actually answer "Median time of open bugs". This would provide more stable lines without huge jumps between months, where we can see

* whether we are increasing or decreasing the median time for open bugs
* the differences of time response for higher and lower priority bugs

I think this change will make all the graphs a lot more useful.

Then we can organize better those six graphs:

Time to closed by Priority
Time to closed by Severity

Then time to first action, then time to first comment.

It would be good to have also a line for the median of the total of bugs, regardless of priority/severity, to see how good are we doing overall.

One more thing, since we are considering "Lowest" almost as an equivalent of WONTFIX-for-maintainers (we assign Lowest priority when nobody is planning to act on a report), we might need to consider them as resolved-wontfix if they distort too much the results. We will see.

(In reply to Andre Klapper from comment #2)
> (In reply to Quim Gil from comment #1)
> > * We need to scan only the Bugzilla products and components corresponding to
> > https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects . Andre,
> > did you have a list somewhere mapping these?
> 
> Last list I made was bug 54469 comment 6.
> 
> > Andre, you are the main stakeholder of this page.
> 
> Noted.
> 
> One data issue in the graphs:
> http://korma.wmflabs.org/browser/bugzilla_response_time.html shows
> "avg_fa_Immediate:788.7567" for Feb 2011. That is impossible as the
> "Immediate" priority was only introduced on Nov 30, 2012:
> http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064746.html
> I have not investigated other peaks yet (also because I don't have data
> handy when which priority and severity was introduced in this Bugzilla).

It is shown that way because we take the current/final priority of a bug to classify them into group due to the priority can change during the life of bug.

In this case, the peak is from bug 27320.

https://bugzilla.wikimedia.org/show_bug.cgi?id=27320.

It was submitted on Feb 2011 (that's why it is shown at that point in the chart) but its first action was made two years later (April 2013). Its current priority is Immediate.

Another possibility is to select the initial state but most of the bugs (aroung 90%) fall in Unprioritize or Normal priorities. Selecting intermediate states doesn't make any sense because we would need infinite charts to show the data.

(In reply to Quim Gil from comment #3)
> The main problem I have with these graphs is that they show plenty of lines
> going up and down, but no clear message. 
> 
> When answering "Time to closed by Priority", I think we should actually
> answer "Median time of open bugs". This would provide more stable lines
> without huge jumps between months, where we can see
> 
> * whether we are increasing or decreasing the median time for open bugs
> * the differences of time response for higher and lower priority bugs
> 
> I think this change will make all the graphs a lot more useful.
> 
> Then we can organize better those six graphs:
> 
> Time to closed by Priority
> Time to closed by Severity
> 
> Then time to first action, then time to first comment.
> 

I think you are right.

Please have a look at the new charts that I've just uploaded. Instead of "Time to close" now we show "Time opened" by median and average. I've also included the median for first action and first comment.

The main problem here is with those big peaks in median charts. The useful data is lost at the bottom of the chart and you can only see flat lines. We have to think about how to manage these cases.

Average charts are still there for comparing with the median ones. We can remove them whenever you want.

> It would be good to have also a line for the median of the total of bugs,
> regardless of priority/severity, to see how good are we doing overall.
> 

Good point. I'm going to add it.

> One more thing, since we are considering "Lowest" almost as an equivalent of
> WONTFIX-for-maintainers (we assign Lowest priority when nobody is planning
> to act on a report), we might need to consider them as resolved-wontfix if
> they distort too much the results. We will see.

I had it into account for top issues and "Time opened" so these data is already filtered.

(In reply to Santiago Dueñas from comment #5)
> The main problem here is with those big peaks in median charts. The useful
> data is lost at the bottom of the chart and you can only see flat lines. We
> have to think about how to manage these cases.

Scale in log base 10?

Let's focus first on these graphs:

(In reply to Santiago Dueñas from comment #5)
> now we show "Time opened" by median and average.

There is still something odd here. See for instance "Time opened by Priority (average)"

In August 2004, apparently one month after opening the Bugzilla instance, we have about Low and Lowest bugs with a median of 1000 days. How can this be? I expect a graph that says that after 30 days of Bugzilla a bug can be 30 days old at most.


> The main problem here is with those big peaks in median charts.

Before trying to address the visualization problems of those high peaks, I still must understand the algorithm that generates them. You say...  

(In reply to Santiago Dueñas from comment #4)
> In this case, the peak is from bug 27320.

> It was submitted on Feb 2011 (that's why it is shown at that point in the
> chart) but its first action was made two years later (April 2013). Its
> current priority is Immediate.

I think we have a problem of perspective. Your perspective seems to be data-centric: "how old were the bugs created at this point of time when they received their first action?" We actually care about our own perspective as bugtriagers (yes, we are so self-centered people)  :) : "how old are today the open bugs that haven't received any action yet"? And last month? And a year ago?

We want to see whether we are processing those bugs faster or slower than before, whether we succeed addressing more important bugs faster or not. In this sense, I wouldn't expect high peaks emerging, since the highest increase from month to month can only be 31 days (unless you reopen hundreds of very old bugs, an unlikely scenario that would reflect a legitimate higher peak).

Let's agree on these points before tying to solve anything else, please.

(In reply to Andre Klapper from comment #2)
> (In reply to Quim Gil from comment #1)
> > * We need to scan only the Bugzilla products and components corresponding to
> > https://wikitech.wikimedia.org/wiki/Key_Wikimedia_software_projects . Andre,
> > did you have a list somewhere mapping these?
> 
> Last list I made was bug 54469 comment 6.

Interesting, but... you could have updated [[wikitech:Key_Wikimedia_software_projects]] instead, which is the canonical place to track changes to the key Wikimedia projects.

Maybe we can simplify things a bit? (but still document them in the wiki page)

Entire products:

Analytics
Commons App
Cortado (???)
Datasets
MediaWiki
MediaWiki‑Vagrant
MobileFrontend
OOjs
OOjs UI
openZIM
Parsoid
Pywikibot
QRpedia
Security (can we extract anything from here anyway?)
Tools (???)
VisualEditor
Wiki Loves Monuments
Wikimedia
Wikimedia Labs
Wikipedia App 

Then someone should map the components under "MediaWiki extensions" with [[wikitech:Key_Wikimedia_software_projects]]. Maybe it is easier to have the full list of components under "MediaWiki extensions" in Bugzilla and then remove those extensions not deployed here. It's not a big deal if there is a bit of mismatch. We can always fine tune.

Andre, can you help Santi with this?

For my better understanding (and maybe others who might have the same problem):
"Time to first action by Priority" - How is an "action" defined? Is "Time to first comment" a subset, or disjunct? Would changing the status from REOPENED to NEW count as an action already?

Smaller issue in all graphs but only on this page:  After "Feb 2013", the month name header in the overlay popup becomes "undefined" (instead of "Mar 2013" etc).

> The main problem here is with those big peaks in median charts. The 
> useful data is lost at the bottom of the chart and you can only see
> flat lines. We have to think about how to manage these cases.

Does the rendering allow a cut-off parameter, e.g. "only render lowest 40% of y axis"? Could images have double the height? Is there a way to zoom the x and/or y axis (also see bug 61810)?
Not convinced by these ideas, but still some thoughts.

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".

(In reply to Quim Gil from comment #8)
> > Last list I made was bug 54469 comment 6.
> 
> Interesting, but... you could have updated
> [[wikitech:Key_Wikimedia_software_projects]] instead, which is the canonical
> place to track changes to the key Wikimedia projects.

Uhm. I cannot remember exactly, but I guess I was worried about the format I should use but did not ask explicitly. :(
Should I make [[wikitech:Key_Wikimedia_software_projects]] a table and add the corresponding Bugzilla product/component in the second column? 
Or what's the prefered format to parse it in a machine-readable way? :-/

(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.

(In reply to Andre Klapper from comment #11)
> Should I make [[wikitech:Key_Wikimedia_software_projects]] a table and add
> the corresponding Bugzilla product/component in the second column? 
> Or what's the prefered format to parse it in a machine-readable way? :-/

Santi: Could you answer this please?

(In reply to Andre Klapper from comment #13)
> (In reply to Andre Klapper from comment #11)
> > Should I make [[wikitech:Key_Wikimedia_software_projects]] a table and add
> > the corresponding Bugzilla product/component in the second column? 
> > Or what's the prefered format to parse it in a machine-readable way? :-/
> 
> Santi: Could you answer this please?

A table sounds good. They're easy to parse and edit. But if I can suggest something, I prefer to have product/component in separated columns, in order to pass them as parameters to our tool.

(In reply to Quim Gil from comment #12)
> (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.)
> 

Action means changes + comments done by someone, but not by the reporter. In this context, "Time to first action" means how long it took that someone (not the submitter or reporter) for the first time, made a change on any the bug's parameters or posted a first comment. 

This is the definition that Alvaro gime me but we can change it to "Time to first change", if you prefer.

> > Is "Time to
> > first comment" a subset, or disjunct?

"Time to first comment" is a subset of "Time to first action".

> > 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.
>

Definitely. I can try something but I prefer to close the definition and meaning of the current charts before moving to new ones.

> (In reply to Santiago Dueñas from comment #4)
> > In this case, the peak is from bug 27320.
> 
> > It was submitted on Feb 2011 (that's why it is shown at that point in the
> > chart) but its first action was made two years later (April 2013). Its
> > current priority is Immediate.
> 
> I think we have a problem of perspective. Your perspective seems to be
> data-centric: "how old were the bugs created at this point of time when they
> received their first action?" We actually care about our own perspective as
> bugtriagers (yes, we are so self-centered people)  :) : "how old are today
> the open bugs that haven't received any action yet"? And last month? And a
> year ago?
> 
> We want to see whether we are processing those bugs faster or slower than
> before, whether we succeed addressing more important bugs faster or not. In
> this sense, I wouldn't expect high peaks emerging, since the highest
> increase from month to month can only be 31 days (unless you reopen hundreds
> of very old bugs, an unlikely scenario that would reflect a legitimate
> higher peak).
> 
> Let's agree on these points before tying to solve anything else, please.

I've added some new charts that try to show this.

These new ones are in top of the page and are "Time opened by Priority (median)/(average)". Former "Time opened" charts are now "Time to close by Priodity (median)/(average). If you go down, you will see same charts but by Severity.

Let's focus on "Time opened by Priority (median)". It shows how old your opened bugs were at a certain point in time, in median.

If you select the first point with data, Aug 2004, it means that those bugs that remained open at the end of August were submitted (opened) in median around 15 days ago for most of the priorities. If you go to the next point, Sep 2004, it means the bugs that remain open (those from August that are not closed yet and those from September) were opened X days ago by priority, an so on.

These charts have some problems:

- A peak that goes down doesn't implies you are closing the oldest bugs. It can means that there are more bugs that were open recently, decreasing the median. You can see this behaviour in Feb 2011. The median of Unprioritized bugs is 530 days because there's only one bug that were opened 530 days ago. The next month, the median goes down to 282 days because another bug was opened in Mar 2011 and at the end of that month none of them were closed.

- High lines can hide or shadow your work on new bugs. If you are closing new bugs very fast and you also have old opened bugs, you won't see any change in the lines.

- Take into account that we are using the current priority of a bug. I think that for these kind of charts, it makes more sense to take the priority of the bug at that time, but it raises another problem: changes in lines might be produced by changes in the priority. If you change the priority of a bug, the old priority line will decrease while the new one will increase.

One possible solution to these problems is combine these with historgrams or distribution charts.

(In reply to Santiago Dueñas from comment #16)
> I've added some new charts that try to show this.

Thanks! They feel more helpful than the "Time to close by..." charts.

> These charts have some problems:
> 
> - A peak that goes down doesn't implies you are closing the oldest bugs. It
> can means that there are more bugs that were open recently, decreasing the
> median. You can see this behaviour in Feb 2011. The median of Unprioritized
> bugs is 530 days because there's only one bug that were opened 530 days ago.
> The next month, the median goes down to 282 days because another bug was
> opened in Mar 2011 and at the end of that month none of them were closed.

Probably overhead and not a good idea, but could the overlay also display on how many items the calculated value is based on?

> - Take into account that we are using the current priority of a bug. I think
> that for these kind of charts, it makes more sense to take the priority of
> the bug at that time, but it raises another problem: changes in lines might
> be produced by changes in the priority. If you change the priority of a bug,
> the old priority line will decrease while the new one will increase.

Yeah, that's what I meant in comment 10 - but let's revisit the "when to query the priority/severity value of a report" aspect later.

(In reply to Santiago Dueñas from comment #14)
> > > Should I make [[wikitech:Key_Wikimedia_software_projects]] a table and add
> > > the corresponding Bugzilla product/component in the second column? 
> 
> A table sounds good. They're easy to parse and edit. But if I can suggest
> something, I prefer to have product/component in separated columns

Done: https://wikitech.wikimedia.org/w/index.php?title=Key_Wikimedia_software_projects&diff=101721&oldid=90993

I hope I'll remember to update when I change Bugzilla's taxonomy. :)

(And as a side-effect of (re-)investigating Bugzilla taxomony of Fundraising I found & filed bug 62002.)

After a conversation with Santi, we agreed on these changes:

* focus on severity, removing all the graphs about priority and keeping the page sane; the former is more objective and stable, the latter is more subjective and changeable

* Santi will try to draw the graphs calculating the severity of the reports at a given time; it seems to be easy but we'll see

* the "median age of open reports" graphs will go at the beginning: reports without any action, reports without any comment, reports unresolved

* the "media age of reports acted upon" will follow with a clear explanation: median age of reports when they get a first action, when they get a first comment, when they get a resolution

* the number of bugs will be also displayed in the dialog with data.

Then the canonical list of products / reports that Andre just posted must be implemented.

Then we will see whether we still get those high peaks converting the rest in planes or not.

Also, Andre was asking about the possibility to zoom graphs to visualize only a certain period. I *believe* I have seen this functionality in VizGrimoire but I'm not sure. In any case, it is something that we would consider only when we have the points above solve, if we still need it.

Santi, yesterday Andre and me agreed that the information provided by the "Time to close" graphs isn't very useful to us. Not only the very high peaks make the rest impossible to analyze. The main problem is that those reports don't tell us much about the trends, what should we do better, what is the call to action.

The graphs about the age of reports open without action do show trends and where should we improve. In fact Andre is missing already the ones based on priority. 

For all these reasons we propose to have these graphs, in this order:

Age of reports without any action by priority & severity

Age of reports without any comment by priority & severity

Age of reports unresolved by priority & severity


If you still think it makes sense to have graphs of the age of closed/actioned/commented reports let's discuss, but after we leave this KPI ready for this iteration. It's already March and there is still a lot to do. Thank you!

(In reply to Quim Gil from comment #20)
> Santi, yesterday Andre and me agreed that the information provided by the
> "Time to close" graphs isn't very useful to us. Not only the very high peaks
> make the rest impossible to analyze. The main problem is that those reports
> don't tell us much about the trends, what should we do better, what is the
> call to action.
> 

The other day Jesus and I were discussing about it and we find that these charts are not useful if we do not include bugs that are still opened, unattended or uncommented. Tomorrow we can talk about it during the confcall.

> The graphs about the age of reports open without action do show trends and
> where should we improve. In fact Andre is missing already the ones based on
> priority. 
> 
> For all these reasons we propose to have these graphs, in this order:
> 
> Age of reports without any action by priority & severity
> 
> Age of reports without any comment by priority & severity
> 
> Age of reports unresolved by priority & severity
> 
> 

Added.

I've also include some help messages to clarify what the charts mean. Please have a look to the message and let me know whether you understand them or not, or if you want to change some terms, for instance, tickets to bugs/reports, etc.

I still have to add the number of bugs in the info boxes and filter those components that are not key projects.

> If you still think it makes sense to have graphs of the age of
> closed/actioned/commented reports let's discuss, but after we leave this KPI
> ready for this iteration. It's already March and there is still a lot to do.
> Thank you!

Ok!

BTW, sorry with the delay with this. To get the "age" data from actions and comments was tricker than I thought.

Remaining tasks:

(In reply to Quim Gil from comment #19)
> * the number of bugs will be also displayed in the dialog with data.
> 
> Then the canonical list of products / reports that Andre just posted must be
> implemented.

We also agreed to add a black line t each graph showing the absolute median, regardless of severity/priority, excluding "Lowest" as the graphs do now.

We left this for later:

> Also, Andre was asking about the possibility to zoom graphs to visualize
> only a certain period. I *believe* I have seen this functionality in
> VizGrimoire but I'm not sure. In any case, it is something that we would
> consider only when we have the points above solve, if we still need it.

(In reply to Quim Gil from comment #22)
> Remaining tasks:
> 
> (In reply to Quim Gil from comment #19)
> > * the number of bugs will be also displayed in the dialog with data.
> > 
> > Then the canonical list of products / reports that Andre just posted must be
> > implemented.
> 
> We also agreed to add a black line t each graph showing the absolute median,
> regardless of severity/priority, excluding "Lowest" as the graphs do now.

Added but I still have to check how to change the colors of the charts.

> 
> We left this for later:
> 
> > Also, Andre was asking about the possibility to zoom graphs to visualize
> > only a certain period. I *believe* I have seen this functionality in
> > VizGrimoire but I'm not sure. In any case, it is something that we would
> > consider only when we have the points above solve, if we still need it.

Looks good to me; thanks!

(In reply to Santiago Dueñas from comment #21)
> I've also include some help messages to clarify what the charts mean. Please
> have a look to the message and let me know whether you understand them or
> not, or if you want to change some terms, for instance, tickets to
> bugs/reports, etc.

* Typo: "Unnatended Tickets"
* Typo: "had no actions by ohters than the reporter."
* Clicking on the explanation button (qm_15.png icon; "?" in a square) in the
  four last of the six graphs scrolls up to the top of the page in FF27.
* Unattended vs uncommented: I'd still love to see an explanation of the
  difference to make sure that everybody understands, maybe in the header in 
  brackets, like "Unattended tickets (no activity by anybody else than 
  reporter)" and "Uncommented tickets" (no comments by anybody else than
  reporter)" or so?

> I still have to add the number of bugs in the info boxes and filter those 
> components that are not key projects.

I think I'll reevaluate after we have this functionality in place (plus zooming, maybe).

Santi, thank you! The "Total" line is already useful now. I hope the fact of scanning only key Wikimedia projects will reduce the very high peaks, making the rest more readable.

One option to make the Total line more visible could also be to make it thicker than the rest (just in case this is easier than changing the color).

Andre, we agreed to Bitergia that they would focus on the graphs and we will focus on the content. Most of it can be "edited" indirectly via pull requests at https://github.com/Bitergia/mediawiki-dashboard/blob/master/browser/bugzilla_response_time.html

Santi, only fyi: on the topic of removing tracking bugs, there is bug 2007, where all of them are identified.

This is our first approach to the zoom feature. There are some bugs to fix, though. 

http://korma.wmflabs.org/browser/zoom_test.html

The graphs are now considered ready:

http://korma.wmflabs.org/browser/bugzilla_response_time.html

We are still missing better strings, but this is a task for me. I'm taking the bug. Help / patches welcome.

https://www.mediawiki.org/wiki/Community_metrics#Global_Pending_List still mentions "Zoom feature for graphs" a a nice-to-have improvement. If this item is still open when we close this bug, we will open a new bug report for it.

(In reply to Andre Klapper from comment #9)
> Is there a way to zoom the x and/or y axis (also see bug 61810)?

Now you can zoom. What is you try without me explaining you how, so we test how usable is this?  :)

(In reply to Quim Gil from comment #29)
> What if you try without me explaining you how, so we test how usable is this?

I like!

My first guess: Click on a canvas and use Ctrl key && mouse scroll wheel. But the standard zoom behavior of browser takes over. That idea probably came from using PDF viewers too much.

Second guess: I mark a timeframe by clicking the left mouse button, dragging it horizontally while keeping it clicked, like in an audio editor.

Bingo.

I also highly appreciate that the y axis zoom is adjusted automatically!
And clicking for a bit longer on the canvas seems to reset the zoom.

Big kudos!