Policy for managing inactive CODEOWNERS

[stefano-garzarella]

Many CODEOWNERS files across the organization are outdated, listing maintainers who are no longer active. This situation slows down the PR review process, provides a misleading view of repository health, and makes it difficult to identify when new maintainers are needed.

Proposed Policy

• A CODEOWNER is considered inactive after X months without any review activity (comments, approvals, etc.) in a repository.
• Inactive members will be gracefully removed from the CODEOWNERS file after a notification period (we would contact them and, if they are no longer active, remove them from the CODEOWNERS file).
• Anyone removed can easily be re-added as a maintainer whenever they wish to become active again.
• The required number of approvals per PR should be adjusted to align with the current number of active maintainers.

TODO

• Add documentation about this policy in https://github.com/rust-vmm/community (maybe in MAINTAINERS.md) if we reach an agreement
  • Should we also cover gatekeepers ?
    • Postponed after monorepo switching (Agreed during BoF @ KVM Forum 2025)
• Decide a fair timeframe for inactivity (X)? (e.g., 6 months, 12 months?)
  • 1 year inactivity window (Agreed during BoF @ KVM Forum 2025)
• Decide how should we handle the process
  • A periodic manual audit
  • A script to run manually
  • A script to put in our CI

Looking forward to hearing everyone's thoughts.

[epilys]

    * Decide a fair timeframe for inactivity (**X**)? (e.g., 6 months, 12 months?)

I think 6 months might be too short (someone might get get occupied with a temporary work project or have personal issues outside of work). One year aligns with corporations reevaluating budgets and priorities.

• Decide how should we handle the process

    * [ ]  A periodic manual audit* [ ]  A script to run manually* [ ]  A script to put in our CI
  

All of the above, start manually first and then see if it works as a process. For script etc, we could incorporate it in my https://github.com/epilys/rust-vmm-helper-cli that has already functionality for Github API automation.

For CI: Github Action docs for running an action on schedule: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule

[roypat]

We talked about this at a BoF session at KVM forum in Milan, and decided on a 1 year inactivity window, where activity counts as leaving a comment on an issue or PR. Being removed from codeowners doesnt mean that someone isn't wanted as a maintainer anymore, but rather just so that we can keep track of how many active maintainers we have (and adjust approval rules and monitor project health). If someone wants to come back to maintaining a crate after removal, they are welcome to just ping us and ask to be readded as a codeowner (or just open a PR against the codeowner file to readd themself).

We'll do the checks regularly (monthly?) and open an issue in the community repository tagging everyone who hasn't been active in a year, and then wait a month before going ahead with removals.

[roypat]

For gatekeepers, we deferred having a process until we have a monorepo, because then gatekeepers will just be "codeowners for the repo root" and can be handled by this policy as well automatically.

[stefano-garzarella]

@epilys @roypat @RuoqingHe my next steps for this will be:

• Add documentation about this policy in https://github.com/rust-vmm/community
• Prepare a script/query to do the manual audit (if you have any idea where to start, feel free to suggest)
• Discuss in the next upstream call when send notifications (with @roypat we thought about starting by the end/mid of October, so we can complete this by the end of November and use December for the migration to the monorepo

WDYT?

[roypat]

my next steps for this will be:

sounds good!

Prepare a script/query to do the manual audit (if you have any idea where to start, feel free to suggest)

A python version of (see also https://docs.github.com/en/rest/activity/events?apiVersion=2022-11-28#list-public-events-for-a-user)

github_user=roypat
curl -L   -H "Accept: application/vnd.github+json"   -H "X-GitHub-Api-Version: 2022-11-28"   https://api.github.com/users/$github_user/events/public?per_page=100 | jq '.[] | select(.org.login == "rust-vmm")'

that iterates over the pages until it processed all entries less than 1 year old should probably do the trick, although might not be too nice on github's API (but probably fine if we only run it one every few months?). We can grab $github_user by parsing the CODEOWNER files.