-
Notifications
You must be signed in to change notification settings - Fork 25
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
Limiting team/repository access for users inactive for 60 months #193
Conversation
The following access changes will be introduced as a result of applying the plan: Access Changes
|
Before merge, verify that all the following plans are correct. They will be applied as-is after the merge. Terraform plansTerraform plans are too long to post as a comment. Please inspect Plan > Comment > Show terraform plans instead. |
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.
Thank you, I eyeballed and nothing controversial stands out. We have a bunch of repos where the original creator still had admin but was not contributing for years. I think it makes sense to remove admin in these cases as a security precaution (can be restored if they need it back or want to transfer repo – example: ipfs-inactive/stargate#7).
Some comments inline.
- Wondertan | ||
- yrliou | ||
- yunigraham | ||
- zeckli | ||
privacy: closed | ||
IPFS HTTP Client Maintainers: |
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.
@galargh should we remove teams which end up with no members?
There is a bunch of them below (Repos - Python
, Repos - Rust
, Repos - Scala
etc).
It does not have to be as part of this cleanup, ideally would be separate PR, and also follow # KEEP:
convention.
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.
Yes, let's remove the empty teams but I'd prefer doing it after this round of user changes is complete if you don't mind.
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 - #193 (comment) Thank you, and let me know if you have any questions 💁 Tagging all the people whose access changes (#193 (comment)) as a result of this PR (no one is being removed from the org):
1/3 |
Continuation of #193 (comment) 3/3 |
Is this for ipfs only? |
For you, as per #193 (comment), this will result in the following change:
|
ah, ok. Thanks. |
Understood, no objections from my side. Thanks for the heads-up! |
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.
No objections regarding changes affecting me
@@ -340,9 +340,6 @@ repositories: | |||
advanced_security: false |
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.
@galargh feel free to drop the entire 2022.ipfs.camp
key, it was an empty repo that I've since removed. ty
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.
Noted, thanks. I'll clean up teams I was told are no longer relevant after this one's merged.
Nice, will this help prevent recent spam? |
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-03-04: notify affected parties with @mention:
2024-03-08: merge this change after incorporating feedback
2024-03-08: clean up empty teams and past IPFS Camp teams