Sample output from the dry run:

Code owner activity report

Period: 2026-01-12 – 2026-02-11

Each code owner (individuals only) must have reviewed or replied to at least 80% of the PRs and issues where they were the code owner for the component.

Components in scope: processor/filter, processor/k8sattributes, processor/resourcedetection, processor/transform, receiver/filelog, receiver/hostmetrics, receiver/prometheus (and processor/resourcedetection/* sub-labels).

@mx-psi here is an attempt to count reviews per codeowner of the specific components that are targeting stability. I suggest that we focus on those only for now so as to avoid extra noise by checking the vast list of Contrib's components :).

I wonder if 80% target is quite high though specially when we timeframe in a monthly period. Happy to tune the targets/checks accordingly.

Also I only have the report for PRs but we can expand to report issues' stats as well if we find this useful either now or enable it on a later iteration.

Should the report measure the PRs created by the codeowner itself ? Looking into my values, most of the PRs was created by me and I cannot review it 😅

Should the report measure the PRs created by the codeowner itself ? Looking into my values, most of the PRs was created by me and I cannot review it 😅

Yeap, that's correct :) . I updated the logic and sample output: fb9e0e1#diff-3005a22a150a86354b703948d26e08bbf1654ac09b994e6ae7124114580740b3R255

Updated output sample:

Code owner activity report

Period: 2026-01-13 – 2026-02-12

Each code owner (individuals only) must have reviewed or replied to at least 80% of the PRs and issues where they were the code owner for the component.

Components in scope: processor/filter, processor/k8sattributes, processor/resourcedetection, processor/transform, receiver/filelog, receiver/hostmetrics, receiver/prometheus (and processor/resourcedetection/* sub-labels).

@mx-psi here is an attempt to count reviews per codeowner of the specific components that are targeting stability.

Thanks for working on this!

I suggest that we focus on those only for now so as to avoid extra noise by checking the vast list of Contrib's components :).

Yeah that makes sense to me

I wonder if 80% target is quite high though specially when we timeframe in a monthly period. Happy to tune the targets/checks accordingly.

I agree it is quite high, we can start with something lower (maybe to start smaller we could do 50%). Also, the target was meant to be per component and not specifically per codeowner. We could lower the percentage do something like target%/num_of_codeowners (so, e.g., if we go with 50% and there are two codeowners, we check if each has replied to at least 25% of issues?)

Also I only have the report for PRs but we can expand to report issues' stats as well if we find this useful either now or enable it on a later iteration.

Let's start with PRs for now to keep this small and add issues later?

I agree it is quite high, we can start with something lower (maybe to start smaller we could do 50%). Also, the target was meant to be per component and not specifically per codeowner. We could lower the percentage do something like target%/num_of_codeowners (so, e.g., if we go with 50% and there are two codeowners, we check if each has replied to at least 25% of issues?)

We require at least 3 codeowners for components that aim to become stable, so maybe we can set the summary goal of the component to 75% and ask for 25% from each codeowner?

Otherwise we require that: 75% of PRs per component get reviewed at least by one code-owner and that codeowners contribute at least 75%/number_of_codeowners of reviews to the component.

New Sample output:

Code owner activity report

Period: 2026-01-13 – 2026-02-12

We target at least 75% of each component's PRs to be reviewed by a code owner, and each code owner to respond to at least 75% / n of their requested PRs (n = number of code owners for that component) (at least 3 code owners for components aiming for stable).

Components in scope: processor/filter, processor/k8sattributes, processor/resourcedetection, processor/transform, receiver/filelog, receiver/hostmetrics, receiver/prometheus (and processor/resourcedetection/* sub-labels).

Component PR review rate (75% target)

Hmmm, I feel like we're trying to do two things at once here. Identify inactive codeowners and assess how responsive a codeowners group is to their components.

I'm looking at Prometheus receiver stats since that's where I keep a constant eye. If we look at Krajo, David, Anthony, and my responsiveness individually, none of us reaches the 80% threshold. In reality, if I see that other codeowners have already responded to an issue and I have nothing to add, I won't comment.

To get this right, I think we need to split the concerns here. Use something different to identify inactive individuals, count codeowners as a group of people, and check how responsive the whole group is together.

We don't target 80%, that was the initial plan :)
Latest state is the following:

We target at least 75% of each component's PRs to be reviewed by at least a code owner, and each code owner to respond to at least 75% / n of their requested PRs (n = number of code owners for that component) (at least 3 code owners for components aiming for stable).

See the sample output at #46015 (comment).

The idea here is that we first focus on the components (first table) ensuring that at least 75% of them are reviewed by at least one person. This ensures that people submitting PRs are getting reviews.

Then we have the additional table as a reference to drill down more if needed and check if something can be fixed for a specific component to improve its stats and "health". Imagine that a component has 70% of reviews which is only coming from one or two codeowners. Having a look into the secondary table will provide the insight that an active third codeowner is required.

Would that be reasonable @ArthurSens ?

Ah gotcha, I think I was misinterpreting the tables.