feat(meta): require collaborators to be active

[avivkeller]

Fixes #7767

The wording can be changed as needed.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	May 28, 2025 4:57pm

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.36%. Comparing base (39e3ae1) to head (bf73db8).
Report is 8 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7775      +/-   ##
==========================================
+ Coverage   75.31%   75.36%   +0.04%     
==========================================
  Files          96       96              
  Lines        7856     7862       +6     
  Branches      192      192              
==========================================
+ Hits         5917     5925       +8     
+ Misses       1938     1936       -2     
  Partials        1        1              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull Request Overview

Adds automation to identify and report inactive collaborators, updates documentation to clarify collaborator maintenance, and schedules a periodic workflow.

• Introduces a script that searches for collaborator activity over a configurable timeframe and files or updates an issue listing inactive members
• Provides comprehensive tests for all new utilities and workflows
• Extends CONTRIBUTING.md with a “Maintaining Collaborator Status” section and adds a GitHub Actions workflow to run the script weekly

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
apps/site/scripts/find-inactive-collaborators/index.mjs	New script to detect inactive collaborators and create/update an issue
apps/site/scripts/find-inactive-collaborators/tests/index.test.mjs	Tests covering date utilities, activity checks, issue creation/update, and full workflow
CONTRIBUTING.md	Added “Maintaining Collaborator Status” section and fixed link case
.github/workflows/find-inactive-collaborators.yml	Scheduled GitHub Actions workflow to invoke the script weekly

Comments suppressed due to low confidence (1)

CONTRIBUTING.md:6

• There’s an extra hyphen and inconsistent indentation before the 'Becoming a collaborator' entry, which breaks the list structure; remove the redundant '-' to fix formatting.

-  - [Becoming a collaborator]

[MattIPv4]

This feels very odd to put inside the site app when it is an entirely meta thing to the repo/organisation, nothing to do with the production site?

[avivkeller]

I just figured I'd put it in the same directory as lighthouse, but I can move it.

[ovflowd]

This feels very odd to put inside the site app when it is an entirely meta thing to the repo/organisation, nothing to do with the production site?

I agree. But at the same time, there's no such... hmm.. meta repo for the website team or web-infra team, so no idea where this should live. @bmuenzenmeyer we could create a repo on nodejs/web-team as a meta space for the website and web-infra teams.

[avivkeller]

WDYT about storing a list of the current members in the GOVERNANCE file?

That would eliminate the need to use a custom token, and we could just use the default actions token?

(This is what is done in core)

[MattIPv4]

Fwiw, I'm fine with this living in .github/scripts -- I think this repo is still canonically the right place, and that directory seems like a logical location to me 👍

[MattIPv4]

WDYT about storing a list of the current members in the GOVERNANCE file?

This does seem easier than needing a custom token. I do wonder if something should be done more centrally to have all the (public) teams in code somewhere.

[bmuenzenmeyer]

We have a monorepo now. It would be easy to make a module here that only serves as a tooling/scripts location.

Heck, api-docs-tooling could even migrate.
The more we add to the monorepo the more value it (theoretically) provides

[ovflowd]

We have a monorepo now. It would be easy to make a module here that only serves as a tooling/scripts location.

Heck, api-docs-tooling could even migrate. The more we add to the monorepo the more value it (theoretically) provides

I don't think the website repo should be a "fit everything" in one repository. There should be separation of concerns IMO. And I do prefer having a meta-repo for the administrative side of things of the web teams.

[ovflowd]

I'd like to formally block this PR (the PR itself is fine) -- I just want to have the @nodejs/nodejs-website and @nodejs/web-infra team to give a 👍 or 👎 if this should live here or within a meta repository.

• 👍 if you want this script on the WEBSITE repository
• 👎 if you want this script on a meta management repository for the WEBSITE TEAM

[avivkeller]

Also, currently, this only checks commits, since there isn't a decent way to check the timestamp of a PR contribution.

We can check if they've commented on a PR/issue that's been updated in the past twelve months, or we can leave it as it (leaving it as is matches node core).

As is matching: 8 inactive
w/ additional check: 1 inactive

[avivkeller]

@ovflowd Are you satisfied with the outcome of the vote?

Personally, I think we should land this here, setup a common repository to store all of our re-used actions (i.e. dependency-review and scorecard, etc). Once that's all setup, we can migrate this there (although, since it's not really re-used, it might not belong there).

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🟢 100	🟢 100	🟢 100	🟢 91	🔗
/en/about	🟢 100	🟢 100	🟢 100	🟠 82	🔗
/en/about/previous-releases	🟢 100	🟢 100	🟢 100	🟠 83	🔗
/en/download	🟢 96	🟢 100	🟢 100	🟢 91	🔗
/en/blog	🟢 100	🟢 100	🟢 96	🟢 92	🔗

[ovflowd]

@ovflowd Are you satisfied with the outcome of the vote?

Personally, I think we should land this here, setup a common repository to store all of our re-used actions (i.e. dependency-review and scorecard, etc). Once that's all setup, we can migrate this there.

There wasn't even enough time yet. Not everyone has voted. Let's wait 48 more hours.

[bmuenzenmeyer]

non blocking comments but perhaps worth adding

[ovflowd]

Alrighty, vote passed. @avivkeller feel free to merge :)