(In reply to Nemo from comment #0)

The solution is simple: reverse your query, calculate the median time that
it took for *merged* patches to be merged.

This is what Metrics Grimoire offered at the beginning, and I guess providing that data is fairly simple. Álvaro, what do you say?

However, we want to put our attention first on the work that still needs to be done. You can be pretty fast closing the bugs that matter to you (say median 1,7 days) while absolutely ignoring all the rest. Does this make you a good maintainer? I don't think so. Good maintainers are the ones capable of keeping the house clean.

In today's ECT querterly review, Erik pointed out that the current stats include WIP patches. I knew this, but I underestimated the amount of such patches. I will file a bug to discard them.

(In reply to Quim Gil from comment #1)

However, we want to put our attention first on the work that still needs to
be done. You can be pretty fast closing the bugs that matter to you (say
median 1,7 days) while absolutely ignoring all the rest. Does this make you
a good maintainer? I don't think so. Good maintainers are the ones capable
of keeping the house clean.

I'm only talking of the graph by affiliation, the graphs by extension I don't know; for the general situation we have three graphs above on open patches.

We could have a fourth: what I often look at (because it's easy and IMHO reasonably meaningful) is the *number* of open patches by affiliation. Typically I see something like 70 % merged patches by WMF and 70 % open patches by volunteers.

I think our current approach of measuring median age of open changesets is good, because it shows the dimensions of the problem we have.

A team might have a great performance crunching new patches as they come (therefore having a great statistic resolving code review), but look at these scenarios:

• A team processes quickly new patches while ignoring a huge bag of old changesets.
• A team processes quickly half of the open patches they receive, but ignores the other half.

If the same team is measured by the media age of their open changesets, that age will grow as long as they keep ignoring a percentage of the patches they have received. On the other hand. teams keeping their media age of open changesets low are very likely to be reviewing new changesets fast.

Based on this, I propose to decline this task.

You almost convinced me. ;-) But this report is about the graph "Are Wikimedia's staff and non-staff contributions processed equally?", rather than the others. The scenario "A team processes quickly half of the open patches they receive, but ignores the other half" can still produce sensible answers to that question in realistic situations.

Both your worst-case scenarios are IMHO extreme and about as realistic as this:

• A team processes quickly half of the patches and speedy-abandons the other half.