Remove Inactive Users #1030

Activity

1. bjohansebas commented on Jan 9, 2026

   

   bjohansebas

   on Jan 9, 2026

   Last edited by bjohansebas

   Member

   More actions

   The https://github.com/pkgjs organization contains 28 inactive13 users. That's 70% of the organization4.

   In pkgjs we’re going to have an emeritus team, and anyone who is not included in the list in nodejs/package-maintenance#642 will be moved there, unless they are a TSC member or part of the moderation team.

   aslo see #1020
2. richardlau commented on Jan 9, 2026

   

   richardlau

   on Jan 9, 2026

   Member

   More actions

   Currently, the @nodejs organization contains 69 inactive1 users. That's roughly a fifth of the entire organization2.

   Footnotes

   1. A user who has not interacted (commenting, committing, etc) on a repository in the organization in the past 12 months. [↩](#user-content-fnref-1-861f13ae9ab3acaf96c3a793855368f5) [↩2](#user-content-fnref-1-2-861f13ae9ab3acaf96c3a793855368f5)
   
   2. As of writing, there are 346 members of the [@nodejs](https://github.com/nodejs) organization. [↩](#user-content-fnref-2-861f13ae9ab3acaf96c3a793855368f5)
   

   For the nodejs list:

   node-forward-build is owned by the Build WG and is still in use today. Things will break if it is removed from the org.

   Some of the identified users are members of the organization for notification purposes.

   For example (since these are IBMers who I know are still involved with Node.js):

   • @john-yan is a member of platform-aix, platform-ppc and platform-s390. He's in the same IBM team that I am in, although mainly focused on V8 work with @miladfarca.
   • @zsw007 is a member of platform-zos.

   (FWIW nodejs/node#61308 was opened specifically for the IBM platform teams but the above names were not suggested for removal/clean up.)
3. avivkeller commented on Jan 9, 2026

   

   avivkeller

   on Jan 9, 2026

   MemberAuthor

   More actions

   Some of the identified users are members of the organization for notification purposes.

   Noted. I identified the users with a basic script to fetch members -> check interactions -> log usernames. I know the list likely has false positives.
4. ljharb commented on Jan 11, 2026

   

   ljharb

   on Jan 11, 2026

   SponsorMember

   More actions

   Inactive users merely being in the org is immaterial - the only thing that matters is if inactive users have permissions that are dangerous to hold, namely, Write or higher on repos (and in some repos, Write might not even matter). Can you filter down to only those users who have such access?
5. mcollina commented on Jan 11, 2026

   

   mcollina

   on Jan 11, 2026

   SponsorMember

   More actions

   Our most important assets (nodejs/node) has already a script that does this check.

   👍React with 👍4Reacted by Jordan Harband, Beth Griggs, Rafael Gonzaga and Sebastian Beltran
6. avivkeller commented on Jan 12, 2026

   

   avivkeller

   on Jan 12, 2026

   MemberAuthor

   More actions

   Inactive users merely being in the org is immaterial - the only thing that matters is if inactive users have permissions that are dangerous to hold, namely, Write or higher on repos (and in some repos, Write might not even matter). Can you filter down to only those users who have such access?

   It's not. There are several things that every member of the organization has access to:

   1. https://github.com/nodejs/moderation (Private Repo; Triage Access)
   2. https://github.com/nodejs/collaborators-public-votes (Write Access)
   3. https://github.com/nodejs/nodejs-ambassadors (Private Repo; Read Access)
   4. Ability to run pull_request workflows without authorization.
   5. Seeing all organization members (although I'm not sure this is a problem)
   6. The ability to create/transfer repositories in the organization ("organization members have a number of permissions, including the ability to create repositories and projects.")

   etc
7. ljharb commented on Jan 12, 2026

   

   ljharb

   on Jan 12, 2026

   SponsorMember

   More actions

   Then the permissions changes I'd recommend is making mere org membership not automatically grant any permissions. (although 4, 5, and 6 imo aren't really a risk for known actors) 2, for example - only collaborators should have write access.