-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing users inactive for 60 months from teams and repositories #75
Conversation
Before merge, verify that all the following plans are correct. They will be applied as-is after the merge. Terraform plansipld
|
The following access changes will be introduced as a result of applying the plan: Access Changes
|
@@ -332,13 +332,6 @@ repositories: | |||
advanced_security: false | |||
allow_update_branch: false | |||
archived: false | |||
collaborators: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one's interesting because it's for a private repository that was used for security release coordination with other teams. The people here don't contribute to the org but would have been added for visibility.
I think it makes sense to have them pruned in a process like this. Ideally we'd just be using private forks off advisory drafts but sometimes it doesn't make sense, like for this one. The repo in question here is less than 60 months old and they're always going to be deleted regardless of how short you make it. If you run it too often then we're going to hit snags because they'd be added to a private repo and then removed as soon as the next run happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, one option to preserve access through and permanently opt out of the automated cleanup would be to add KEEP
comments. It would look something like that:
pull:
# KEEP: Because ...
- alvin-reyes
# KEEP: Because ...
- jennijuju
# KEEP: Because ...
- TippyFlitsUK
push:
# KEEP: Because ...
- hsanjuan
Do you think it'd make sense to allow opting out entire repositories out of the automated cleanup?
Two other interesting things to note - two people, Hannah and Alex, are being removed from repos they created, leaving nobody but admin. Might be fair because they're pretty stale and maybe even archived now, I wonder if people will object to pruning like that though. Otherwise seems fine to me to move on to general feedback. |
That's a great point. I think in these cases we should treat a PR like that as a invitation to discussion whether the repository in question should be archived or, if not, we should add a |
Yes, that's all reasonable, having an escape hatch is the key here. I can see now that you've mentioned in the original post so maybe that's all this needs. Nothing from me to KEEP, but nice to know it can be done in future if required. Will be interesting to see if anyone impacted by this asks for a KEEP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@web3-bot should be added back to new repositories.
Hi! We're ready to open up the PR for general review 🥳 I'd like to ask you to review the changes affecting you and flag any that should be reverted, are wrong, or need more explanation. You can find the detailed explanation of this PR, the reasoning for introducing the changes and the process itself in the description - #75 (comment) Thank you, and let me know if you have any questions 💁 Tagging all the people whose access changes (#75 (comment)) as a result of this PR:
|
I would love to be added to an Alumni organization for IPLD and Multiformats. It makes me sad to leave this org - these were interesting days for me. Having an alumni org or team with no permissions also helps, considering how GitHub is increasingly the CV of the future. |
100% remove me. |
We're not removing anyone from the organization here, we're only updating direct repository collaborator access and team memberships. There's also a special This all means that everyone will remain part of the organization and it will be really simple to restore access wherever and whenever needed. |
Okay to remove me! |
Summary
This PR cleans up user access by removing users who have been inactive for over 60 months (5 years) from teams and repositories.
A user is deemed inactive if they haven't performed any of the following actions in the past 60 months in a repository in question or in any of the repositories the team in question grants access to:
Any user who, after the introduction of the above changes, isn't a direct collaborator in any of the repositories and isn't a member of any teams is assigned to the
Alumni
team.If a user's access to a repository or team should be restored, the appropriate line change should be reverted, and a comment starting with
KEEP:
(followed by a reason) should be added directly above that line.This pertains to the "'archive' inactive users and teams" in ipfs/ipfs#511.
Who is this targeting?
The current PR is what results from a script to identify inactive users in an org.
Why is this being done?
See "Why do we care about periodically cleaning up permissions across the orgs?" in ipfs/ipfs#511
Is this set in stone?
No. This PR was created and being left open for some days to give awareness and incorporate feedback. We're not taking a "ask for permission" approach, as that would require way too much wrangling. Instead, we're giving visibility to what's proposed and inviting folks to comment and influence. A saving grace here is that none of this is a "one-way door". If something got messed up or missed, a follow-up PR can be done to correct it.
Is anyone being removed from the organization?
No. All existing members of the org are staying members. In the most reduced/scoped-down case, someone will still be part of an "Alumni" team in the org to signal their past involvement. Thank you for your past contributions, and we certainly welcome you to play a more active role in the future.
Timeline
2024-02-26: public PR
2024-02-28: notify affected parties with @mention:
2024-03-04: merge this change after incorporating feedback