🌱 New check: Inactive Maintainers #4893
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Fixes #2027.
New feature
This PR adds a new check for inactive maintainers. At a high level, the check does two things in the following order:
The check 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 activity data that the GitHub and Gitlab handlers can fetch are documented in the check documentation. 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).
This check should probably be part of the Maintenance check, but before I place it there, I will let folks chime in on thoughts and suggestions.
Some activity types require higher token permissions. If the check runs without those permissions, it will not consider those activity types.
Special notes for your reviewer
This can be tested with:
SCORECARD_DEBUG_MAINTAINERS=1 \ GITHUB_AUTH_TOKEN=$TOKEN \ go run main.go --repo=github.com/owner/repo \ --checks=Inactive-MaintainersSCORECARD_DEBUG_MAINTAINERS=1will print out the active and inactive maintainers.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.)