community
community copied to clipboard
Automate removal of inactive Slack users
Describe the issue
Kubernetes Slack is running into some problems with total number of accounts. We would like to deactivate accounts which were inactive (no logins) for some period of time, probably 1 year.
There do not appear to be any existing tools which implement this, either via Slack or third parties. So this task would require writing scripts to use the Slack API in order to deactivate batches of users. Requirements of this task include:
- Learning or knowing the Slack API, both documented and undocumented features
- Working in SIG-Contribex to set parameters of deactivation
- Writing a repeatable script in which can deactivate batches of users based on their date of last activity. Golang is preferred, can discuss other languages
- Testing and troubleshooting the script
If someone finds an existing 3rd-party tool which does implement the goal, that's also acceptable.
As nobody on our Slack team currently has advanced working knowledge of the Slack API, anyone working on this task would need to be self-guided; mentorship on the Slack API is not available. Members of SIG-Contribex can mentor other parts of the task.
/sig contributor-experience /area slack-management /help
@jberkus: This request has been marked as needing help from a contributor.
Guidelines
Please ensure that the issue body includes answers to the following questions:
- Why are we solving this issue?
- To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
- Does this issue have zero to low barrier of entry?
- How can the assignee reach out to you for help?
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
Describe the issue
Kubernetes Slack is running into some problems with total number of accounts. We would like to deactivate accounts which were inactive (no logins) for some period of time, probably 1 year.
There do not appear to be any existing tools which implement this, either via Slack or third parties. So this task would require writing scripts to use the Slack API in order to deactivate batches of users. Requirements of this task include:
- Learning or knowing the Slack API, both documented and undocumented features
- Working in SIG-Contribex to set parameters of deactivation
- Writing a repeatable script in Go or Python which can deactivate batches of users based on their date of last activity.
- Testing and troubleshooting the script
As nobody on our Slack team currently has advanced working knowledge of the Slack API, anyone working on this task would need to be self-guided; mentorship on the Slack API is not available. Members of SIG-Contribex can mentor other parts of the task.
/sig contributor-experience /area slack-management /help
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
One worthy addition to the requirements: The removal process should account for a step which allows inactive users to explain if they want to stay. (similar to how GitHub org pruning happens)
When we have an implementation, SIG K8s Infra can assist with deploying it as a long running process.
I would suggest that we aim for this to make the process non manual.
One worthy addition to the requirements: The removal process should account for a step which allows inactive users to explain if they want to stay. (similar to how GitHub org pruning happens)
Users could get a DM first, and then removal after say a week beyond that. The problem is then you have to track this state. I'm not sure how reasonable this is to implement even if this sounds like a good idea.
alternatively the script could only suggest accounts to exist, but then the process will require more human labor ...
One worthy addition to the requirements: The removal process should account for a step which allows inactive users to explain if they want to stay. (similar to how GitHub org pruning happens)
I don't think you quite understand the scale of this. I'd estimate that we're looking at removing on the order of 100,000 inactive users. No course of action that requires a human in the middle is feasible.
Users could get a DM first, and then removal after say a week beyond that. The problem is then you have to track this state. I'm not sure how reasonable this is to implement even if this sounds like a good idea.
Since we're talking about removing users who haven't logged in in over a year, how would they see the DMs?
We don't actually need to track state. We could simply DM all the inactive users, and then remove any which are still inactive a week later. Anyone who read their DMs wouldn't still be inactive.
However, this makes the scripting significantly more complex, and I'm not clear on the benefit.
I don't think you quite understand the scale of this. I'd estimate that we're looking at removing on the order of 100,000 inactive users. No course of action that requires a human in the middle is feasible.
!!!!
How many users do we have now?
207,752
Since we're talking about removing users who haven't logged in in over a year, how would they see the DMs?
Devil's advocate: By default slack will email you if you've been inactive and someone mentions you or DMs you, IIRC.
We don't actually need to track state. We could simply DM all the inactive users, and then remove any which are still inactive a week later. Anyone who read their DMs wouldn't still be inactive.
I mean that we would either have to store state about this or we have to "store it" by pulling it from slack DMs and finding the responses or lack of response, which seems likely to be complex, fragile, and not performant.
... Or having humans do it, which seems wholly unreasonable.
However, this makes the scripting significantly more complex, and I'm not clear on the benefit.
Yes.
I utterly failed to convey that ... I'm agreeing that I'm not sure that this is a reasonable thing to do. This seems painful and probably unnecessary. I meant more of a straw-man to illustrate the mess. I don't think this is going to be reasonable.
It's not really the same as removing from the github org anyhow. The slack is self-service open-invite and by pruning the mass of inactive users we unbreak rejoining for everyone.
Writing a repeatable script in Go or Python which can deactivate batches of users based on their date of last activity.
If possible I would request Go, we have more experience as a community with reliably shipping Go and we should probably turn this into a continuous service at some point, to avoid even needing to manually invoke the tool.
We also have a repo with slack tools written in Go currently, which would be a good home for the implementation: https://github.com/kubernetes-sigs/slack-infra
@BenTheElder updated with "Golang is preferred".
We do have some code to deactivate users (undocumented API):
https://github.com/kubernetes-sigs/slack-infra/blob/main/slack-moderator/users.go#L57-L75
Is "deactivating" synonymous with "removal"? If the reactivation process is straightforward and does not result in the loss of any messages (including previous conversations), we could opt to deactivate the account and offer a method for reactivation.
@pacoxu The reactivation process is annoying; basically, the user will need to file an issue in k/community, or email community@. Slack doesn't provide another avenue.
This does mean that before doing the deactivation we'll need to make sure that the info on how to reactivate is present on several community resources. It's also why, in the ContribEx meeting on Wednesday, we think we'd start with accounts that have been inactive for 3 years or more.
Hi @jberkus ,
Sry for jumping in abruptly into this discussion. While I went through the threads, an strategy came to my mind to achieve it, here's how we could do it,
Please do read through the docs and let me know if you have any further queries I would be eager to take them up...
I have attached the golang file as .txt file as .go files were not upload supported
@devatbosch hey, thanks for pitching in! This is a promising start.
In the future, please just share stuff as text blocks in your post? I'd have looked at your comment earlier if it hadn't been a PDF.
Questions about the go module:
-
Your module uses slack-go instead of Kubernetes' slack module. Both modules are unmaintained. Do you have experience with slack-go? Is it in better shape than our tooling?
-
Your current workflow pulls all the inactive users. Since we're talking about up to 100,000 users, we need to batch this; any code that tries to retrieve all the inactive users at once will run into memory/execution time issues.
Thanks for your help. Lemme know what else you need -- you can also chat in #contribex on Kubernetes Slack.
Hi @jberkus ,
Thanks for replying.
About your questions;
-
Do not really have much experience on the slack-go module since I've just started working with it so have a beginner friendly touch to it.
-
This point can be addressed by doing necessary modifications in the GO code.
Do let me know, in case of further queries. I believe with the support from the community we can have this implementation done on the first place...
#kubernetes-users now have ~200k users in the channel and I cannot join it due to limitation. It may be a good time to start the cleanup.
@pacoxu that's the reason for this issue. But we need automation, doing it manually will not scale. There are way too many inactive accounts.