Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#580 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
github, github-actions
Lĩnh vực
authorization, devops, security

Hướng nghiên cứu

Chưa xác định được tệp hoặc bài kiểm thử nào. Trước tiên, hãy giải quyết các vấn đề về chính sách, sau đó thiết kế workflow được lập lịch dựa trên GitHub APIs, team-membership endpoint và organization audit log. Hoàn thành có nghĩa là thực hiện hai chu kỳ hằng tháng ở chế độ report-only, xử lý an toàn các kết quả chưa đầy đủ và lỗi thông báo, bảo đảm các bản ghi ở chế độ riêng tư, cũng như hỗ trợ việc xóa đã được phê duyệt và khôi phục tư cách thành viên.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Python
Star
14
Fork
32
Merge trung bình
15 giờ 40 phút
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của kernelci/kernelci-project

Tất cả issue của kernelci/kernelci-project

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.