For clarification, quoting from the internal ticket:

One changeset can have several patchsets (the last one overwrites the previous ones, afaik). The time we track is for changeset, based on its status. That means we track the time from the moment the changeset is created to the point in which it is resolved or abandoned.

Adding some more background, the more I think about this:
I do realize that a changeset marked as CR-1 (means: needs improvement) might simply remain open forever if nobody ever picks it up and fixes it. And that could make the stats more noisy and less useful.
I'm more interested in the time values per affiliation for changesets that are CR+0 (no review has happened yet) and CR+1 (someone has given positive feedback but someone else must approve the changeset via a CR+2 to get merged, which can sometimes be a bottleneck because the person giving a CR+2 is kind of responsible if the changeset gets merged and then breaks something).
So I'm back to wanting also to be able to filter this on code-review labels, as requested in T224755 and I hope that this is going to be combinable.

As this is a bit related: Thanks to the Status widget on the Gerrit-Timing dashboard, we already know that the review rate (percentage) of Gerrit changesets is different per affiliation, by filtering on the Organization. However, these stats only reflect the status of patches created in the last 90 days as of right now; they include no information about the timing. Comparison for the last 90 days of Wikimedia Foundation vs Individual:

We're running into inconsistencies in Gerrit data in this task which distort the results:

• Looking at https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/245854/ there is no "Patchset 1" and no "Uploaded patch set 1." entry. Not sure what happened here. Same for e.g. https://gerrit.wikimedia.org/r/22679 where also the order of comments is not linear in time.
• Looking at other items like https://gerrit.wikimedia.org/r/107279/ where there is a Patchset 1, I have no idea and can only wonder about timezone setting differences, or pushing way later after creating locally, or incorrect local system dates on computers. All not convincing though.

Full list of the 43 problematic changesets can be seen at https://wikimedia.biterg.io/goto/87013a17063b675738cd841d8fb49c6b

Wondering if we could simply use the created_on value instead of the opened value to calculate the painless_delay value (and as there is a patchset_created_on), but need to check with Bitergia who know what they are doing, unlike me.

We also need to provide input on how to visualize this. Input very welcome.
Currently the visualization proposal can be seen in https://wikimedia.biterg.io/goto/d813c19b886e7015c587014af443b2b0 , adding a screenshot here:

Note that this is still a draft and work in progress.

Also wondering about medium vs average here.

Copying internal comment here:

The painless_delay is calculated only for changeset items and we use last_update field as changeset closing date (of course for merged or abandoned changesets, for the open ones we calculate the time from creation to the present).

https://wikimedia.biterg.io/goto/c9663782f8c9d893f94434c0135ffd13 is an example for the operations/puppet repository.
The search query could also be filtered for CR status, for example (repository:"operations/puppet") AND status_value:"-1", see T224755: Allow to filter by Gerrit label 'code review' (on the latest patchset) in the frontend for that.

TODO: Still need to find out how to save this visualization and add it to a dashboard (probably Gerrit Timing?) and not get that overwritten when Bitergia deploys a new software version with its dashboard item defaults.

Hmm, given its topic it would probably fit best on https://wikimedia.biterg.io/app/kibana#/dashboard/Gerrit-Timing but don't want to replace that with C_Gerrit-Timing, so it would be another dashboard. We'd need to ask Bitergia to get the link into the top bar.

Documented in https://www.mediawiki.org/w/index.php?title=Community_metrics&type=revision&diff=3568518&oldid=3568108

Note that by default, this entirely ignores any Gerrit change set status (whether NEW, MERGED, ABANDONED) and any CR label status, but this covers any and every Gerrit patch within the given time frame in the upper right corner, also closed ones.

It is possible to pass values like status:"NEW" AND status_value:"1" AND/OR !_exists_:status_value (for CR0) in order to filter accordingly.