🌱 Maintained check: New probe: Inactive Maintainers

[AdamKorcz]

What kind of change does this PR introduce?

Fixes #2027.

New feature

• PR title follows the guidelines defined in our pull request documentation

This PR adds a new probe to the Maintained check that assesses whether the project has any inactive maintainers. At a high level, the probe does two things in the following order:

1. First, it fetches the data about users with elevated privileges in the repository. These are the Maintainers of the project.
2. Next, it fetches and analyzes events in the repository for signals about the maintainers' activity going 6 months back. If a maintainer has had any activity in those 6 months, they have been active, otherwise the probe considers them inactive.

The probe scores proportionally based on the proportion between active and inactive maintainers.

The client handlers pull in as many activity signals as the API allows. The Gitlab client that Scorecard uses had some bugs with some signal types, so the Gitlab client handler uses raw requests instead of client methods. The GitHub client does not use graphql; I couldn't get it to be as efficient in getting the same details and batching the calls efficiently.

At a bit of a lower level, the client handlers will go through all activity data they have fetched and will mark a maintainer active as soon as they see any activity by that maintainer. Once all maintainers are active, the handlers will not process anymore activity records. This is for efficiency.

The clients pull in a fairly comprehensive set of activity data from the repository. They do not include some GitHub enterprise-only activity types, manual job triggers (GitHub) and Direct PR/MR reviews (Gitlab does not make the timestamp for these available in the API response).

Some activity types require higher token permissions. If the check runs without those permissions, it will not consider those activity types.

How this probe differs from existing Maintained probes

Currently, the Maintained check has four probes:

1. one that checks whether a project is archived
2. one that checks whether there has been recent commits
3. one that checks for activities on issues by project members
4. one that checks whether the repo was created recently.

The existing probes focus on any activity by the maintainers as a group: Whether any maintainer/project member has recent activity in issues for example. The probe in this PR analyzes whether any of the maintainers have had no activity in a long time.

Does this PR introduce a user-facing change?

For user-facing changes, please add a concise, human-readable release note to
the release-note

(In particular, describe what changes users might need to make in their
application as a result of this pull request.)

Add new check for inactive maintainers.

[codecov]

Codecov Report

❌ Patch coverage is 68.28971% with 521 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.57%. Comparing base (353ed60) to head (5714856).
⚠️ Report is 314 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4893      +/-   ##
==========================================
+ Coverage   66.80%   69.57%   +2.76%     
==========================================
  Files         230      254      +24     
  Lines       16602    17264     +662     
==========================================
+ Hits        11091    12011     +920     
+ Misses       4808     4236     -572     
- Partials      703     1017     +314     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

This pull request has been marked stale because it has been open for 10 days with no activity

[spencerschrock]

Some activity types require higher token permissions. If the check runs without those permissions, it will not consider those activity types.

Wouldn't you need an admin token to enumerate the maintainers? So none of the check would run without admin?

I could see this working as a probe in Maintained, which would only be enabled when running with an admin token.

In terms of data collection, did you consider using the existing client methods to look for maintainer activity, instead of just putting them in a new GetMaintainerActivity method?

[github-actions]

This pull request has been marked stale because it has been open for 10 days with no activity

[github-actions]

This pull request has been marked stale because it has been open for 10 days with no activity

[AdamKorcz]

In terms of data collection, did you consider using the existing client methods to look for maintainer activity, instead of just putting them in a new GetMaintainerActivity method?

Yes, but I found it unfeasible: The probe in this PR pulls in more data than the existing client handlers allow.