jberkus
commented
4 years ago /sig contributor-experience /area slack /kind cleanup
attn: @Katharine @castrojo @mrbobbytables
Closed jberkus closed 4 years ago
jberkus
commented
4 years ago /sig contributor-experience /area slack /kind cleanup
attn: @Katharine @castrojo @mrbobbytables
k8s-ci-robot
commented
4 years ago @jberkus: The label(s) area/slack cannot be applied, because the repository doesn't have them
Katharine
commented
4 years ago I am going to argue against all three of these tasks:
Check to see if there is a purpose, pinned documents like agendas, and other best practices being used in the channel.
Channels don't need agendas, because they aren't required to have meetings. Indeed, as far as I recall, none of these things are requirements of channels. I think are only hard requirement is that channel members follow the code of conduct (which we now automatically pin at channel creation), and that the topic of the channel itself is Kubernetes-related (which will have been determined at channel creation and does not really need subsequent auditing).
Prune old abandoned users
This isn't really meaningfully possible — we can deactivate them, which prevents them from logging in, but we cannot remove their accounts or any information about them. I'm not sure we gain much by doing this beyond making it harder for attackers to use compromised accounts (and given how easy it is to make one, this feels like an implausible route of attack).
The downside would be confused users if they returned later, which we know to happen at least sometimes. They would both be unable to log in (because their account is deactivated) and unable to create a new account (because it already exists). We might be able to handle this by changing their email addresses when deactivating them, but we can't really automate that.
Close unused channels
My most controversial opinion, I imagine: I don't think there is a significant cost to low/no-traffic channels. We have attempted to minimise the bar to clear to create channels, which I would naturally expect to lead to more unused channels.
Moderators are not expected to actively moderate all channels, which is supported by the report tooling we now have. Slack itself does not impose a channel count limit. As such, I don't think the number of channels imposes any burden on Slack administration.
The other concern with unused channels is that users could join them, send a message, and be disappointed when they don't get a response. I think this is not a huge concern: almost all of these channels have some members, often dozens or hundreds. If someone does post a message there, those members are likely to see the message.
As such, I don't think closing channels is worth the effort expended either on the action of doing so, or the disgruntled users/projects when their channel is deemed to be defunct.
jberkus
commented
4 years ago Katharine,
The main reason I can see for closing inactive channels is to reduce new member confusion when trying to find a channel for a specific purpose. Whether or not that benefit offsets the effort required to actually do it is another question, though.
mrbobbytables
commented
4 years ago Prune old abandoned users - I think we can strike this task off completely; auditing the current user base just isn't worth it. I agree with Katharine, we'll likely just get a higher rate of confused users if/when they come back.
Close unused channels - I don't think it's worth the effort to audit these at this point. Most of the channels do have SOME users in them, even if quiet. At most I'd probably consider the ones that have been around for 6 months + with no messages posted, but even then it doesn't seem like they're doing much harm. From some cursory digging, most of our channels that have been closed down in the recent past have been by the original person requesting the channel or when a project is being shutdown. (ref: https://github.com/kubernetes/community/pull/4425).
Channel purpose - From a quick look at the channels most of the ones that are missing a purpose are from other open source projects. The ones I would like to have a purpose is any official kubernetes channels - ones that are owned by a sig, wg, subproject etc -- even if its just a link to the subproject itself.
Below are the Slack Audit requirements from https://github.com/kubernetes/community/blob/master/sig-contributor-experience/community-maintenance.md Due to discussion and issues on Slack, I'd like to revisit these before putting serious effort into fulfilling them.
One major roadblock is that we've determined that the statistics from Slack Analytics are not trustworthy, which will make it a challenge to perform certain tasks like pruning unused channels and accounts.
Channels
Users
Prune old abandoned users - we are approaching 100K users, the vast majority of which have not posted in months, some not for years. Do we want to consider purging old user accounts with no activity? This would need to be automated somehow. Obviously suffers from the issue with untrustworthy stats.
General