Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#580 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
github, github-actions
Área
authorization, devops, security

Línea de trabajo

No se han identificado archivos ni pruebas. Empieza por resolver las cuestiones de políticas y, después, diseña el flujo de trabajo programado en torno a las GitHub APIs, el team-membership endpoint y el organization audit log. Se considerará completado cuando se hayan realizado dos ciclos mensuales en modo report-only, se gestionen de forma segura los resultados incompletos y los fallos de notificación, se mantengan registros privados y se admita la eliminación aprobada con soporte para la reincorporación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

question sysadmin

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.

Lenguaje dominante
Python
Estrellas
14
Forks
32
Merge medio
15 h 40 min
PR fusionados (30 d)
5

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de kernelci/kernelci-project

Todos los issues de kernelci/kernelci-project

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.