Automate removal of inactive Slack users

[jberkus]

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

[k8s-ci-robot]

@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.

[palnabarun]

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)

[BenTheElder]

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 ...

[jberkus]

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.

[jberkus]

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.

[palnabarun]

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?

[jberkus]

207,752

[BenTheElder]

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.

[BenTheElder]

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

[jberkus]

@BenTheElder updated with "Golang is preferred".

[dims]

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

[pacoxu]

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.

[jberkus]

@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.