[Proposal] Automate inactivity review and access cleanup for the hackers team

[nuclearcat]

Summary

I propose adding a scheduled access-hygiene review for the hackers GitHub team. Accounts with no qualifying KernelCI activity for a rolling six-month period would be subject to the agreed notification and exemption policy, then automatically removed from the team when appropriate.

This would remove stale access without removing anyone from the GitHub organization or erasing any contribution history. Rejoining the team should remain straightforward when someone becomes active again.

Why this is needed

Stale access increases the impact of an abandoned or compromised account. This matters for the hackers team because it currently has 46 members and access to 30 public repositories, including:

• 7 repositories with write access
• 6 repositories with triage access
• 17 repositories with read access

A preliminary snapshot for 2026-03-01 through 2026-09-01 found:

• 10 of 46 members had recorded KernelCI contribution-calendar activity;
• 36 had no recorded KernelCI contribution-calendar activity in that window;
• 6 had no visible contribution-calendar activity anywhere on GitHub in that window; and
• 4 currently have 2FA disabled.

The detailed account list should remain private to organization owners/team maintainers. These figures are an initial signal, not a removal list: GitHub contribution calendars do not capture every useful activity, such as all issue comments, work on non-default branches, meetings, mailing-list work, infrastructure work outside GitHub, or private activity that is not visible to the audit account.

The organization-level GitHub setting to require 2FA is currently disabled. GitHub provides a native organization policy that can block non-compliant members from organization resources, so this should be considered alongside inactivity cleanup: Requiring two-factor authentication in your organization.

Proposed policy

Qualifying activity

Any of the following in a kernelci repository should reset the six-month timer:

• commits;
• pull requests;
• pull-request reviews;
• issues;
• issue or pull-request comments; or
• another verifiable KernelCI contribution recorded by a maintainer.

General GitHub activity should be reported as context during review, but activity in unrelated organizations should not by itself justify retaining KernelCI access.

Review and removal flow

Run the check monthly:

1. Generate a private report for organization owners/team maintainers.
2. Exclude organization owners, service accounts, explicitly designated maintainers, and time-limited documented exceptions.
3. Apply the agreed notification policy: either privately warn each candidate and allow a 7-day grace period, or remove access without advance notice and optionally send a low-pressure informational note afterward. The latter may avoid bothering contributors who are simply taking a break, and removal is low-impact because team membership is easy to restore.
4. If advance warning is used, recheck activity at the end of the grace period.
5. Remove only the hackers team membership if the account remains inactive and no exception was approved.
6. Record the decision in an administrator-visible audit log and provide a simple reinstatement path.

The automation should fail safely: incomplete API results, rate limits, or notification failures must prevent removal. It should run in report-only mode for at least two monthly cycles before automatic removals are enabled.

2FA

In parallel, notify the four affected team members privately and discuss enabling GitHub's organization-wide Require two-factor authentication setting after an announced enrollment period. 2FA status should not be published per account.

Implementation outline

• Use a scheduled workflow with a least-privilege, organization-owned GitHub App rather than a maintainer's personal token.
• Read team membership and contribution/activity signals through the GitHub APIs.
• Keep an allowlist with an owner, reason, and expiration date for each exception.
• Store detailed candidate and notification records privately; publish only aggregate metrics.
• Use GitHub's team-membership API for the final removal: REST API endpoints for team members.
• Verify removals through the organization audit log (team.remove_member): Audit log events for your organization.

Questions for discussion

1. Does the activity definition above cover the ways KernelCI contributors work?
2. Which roles or accounts need automatic or time-limited exemptions?
3. Do inactive members need to be notified privately before removal at all? A warning may surface unrecorded work or needed exceptions, but it may also unnecessarily bother contributors who are taking a break, while adding someone back to hackers is straightforward.
4. If notification is desired, should it happen before or after removal, through which private channel, and is a 7-day grace period sufficient?
5. Should the initial rollout require an owner to approve every removal after the dry-run period?
6. Should organization-wide required 2FA be adopted as part of the same access-hygiene work?

If there is agreement on the policy, the next step would be to document it, implement a report-only job, and review two reports before enabling removal.