Fork me on GitHub
#community-development
<
2022-08-15
>
skylize19:08:09

It's pretty cool that anyone can just create a channel at will. But an unfortunate side effect is a slew of channels to choose from. Many of these channels died, or failed to take off to begin with. Example: #composition has only ~15 posts, all in late 2016. This does not really add meaningful value, but does create a lot of noise. It is quite cumbersome to cull through all the channels in search of relevant discussions. It is also disheartening if you find a channel you think you want to join (for example if you think #composition is an interesting topic and want to hear other's thoughts on it), only to discover an abandoned empty space. It is untenable to think you could use "View Channel" to periodically check in on some channels without joining them, because you must dig through the paginated list each time to find them. Seems to me it would be really nice if we could find some way to begin removing dead channels. The vision in my head would probably include something like the following: • One-off event channels should be archived after some reasonable time period post-event. So Clojure Days can have an ongoing channel if they want. But specifically Clojure Days 2019 is a one-off. So #dcd19, being clearly outdated, should be archived. • Library support channels should be occasionally scanned for likely, ... shall we just say, deprecation. If a library seems to have no recent maintenance updates, and nobody is asking questions about it, we can contact the author and ask "Is this still supported?" No sense having a channel for an unsupported lib, so archive or maybe even delete in some cases. • Add a channel for #other-library-support. After attempting to contact authors for permission, merge low-traffic library channels into this channel. Hopefully we could find a way to tag where they came from, while copying them over? Delete such channels after they are merged. Encourage authors expecting low traction to use this channel for support instead of creating a new one, until such time their project surprisingly takes off. • Gather up any other remaining obviously dead channels, and merge them into some sort of #dead-channels archive. I would not expect any of these suggestions to be hard rules that need "enforcement". Instead they are intended as guidelines for trimming the fat over time. And I have no idea who would be expected to do the work involved (particularly since I believe merging must be done manually?). But if this could somehow be accomplished, the Channel List would be much more welcoming; and it would be way easier to find active channels and/or channels directly relevant to a specific question.

seancorfield20:08:01

I don't believe Slack offers any way to "merge" content from one channel to another (unless that's something they added recently and I missed notification of it?). The burden of this curation would very likely fall on the Admin/Moderator team and although I do something along these lines, in cooperation with half a dozen moderators, on one of the much smaller Slacks I run, I'm not sure how much time we would want to spend doing a similar curation here given that it is about an order of magnitude larger than that one. I believe that archived channels no longer have their content searchable (unless you specifically search within that channel?) so one caveat about archiving "deprecated" channels is that their history becomes mostly "lost" -- and searchable history was the main thing folks were asking for before we managed to get Slack to sponsor us for the Pro plan we're on now (we were on the free plan previously -- and sponsorship is a per-year thing so we have to re-apply each year).

seancorfield20:08:35

That said, there definitely are a lot of channels with only one or two members and no traffic for months that could be archived by the Admin team without much concern.

skylize20:08:58

I think you are right about no merging feature, though not certain since I don't manage any Slack workspaces. But a quick goog search indicates merging can be accomplished manually by exporting the data from one channel and then importing it into another.

seancorfield20:08:52

Via the APIs I suspect? So someone would have to write and maintain such a script...

skylize20:08:31

Assuming the manual process is not an unbearable burden (maybe it is?), merging could be a workaround to mostly keep searchability. Gather archives into an #archive channel, instead of actually archiving the channels. The big catch, of course being that the overlapping timelines between channels get interwoven.

skylize20:08:50

If a script could somehow tag the origin channel while merging, that could help a lot with that.

skylize20:08:14

You could even keep the original channel but in archived state.

skylize20:08:23

> That said, there definitely are a lot of channels with only one or two members and no traffic for months that could be archived by the Admin team without much concern. I realize that even if my suggestion is feasible, there would still be a high probability that simply nobody gets around to it. So if this cannot be worked out, a little bit of curating by archiving would be a fair consolation prize.

eggsyntax15:08:51

I would lean against any unnecessary channel archiving if that means we lose searchability. I don't see any significant cost to having lots of channels since, as Alex pointed out, it's easy to see them sorted by traffic. It seems natural to me in a slack of our size and length of existence that there are too many channels for reading through the complete list of channel names to be a good method for finding channels you're interested in.

eggsyntax16:08:21

Although I'm definitely :thumbsup: on archiving the channels that no one's ever posted in 😆

👍 1
Alex Miller (Clojure team)20:08:31

you may find it helpful to use https://clojurians.slack.com/stats#channels and sort by total membership to find more active channels

Alex Miller (Clojure team)20:08:46

I've found it to be good to establish naming strategies in other slacks I've admin'ed, like geo-LOCATION, seems like similar with lib- conf- whatever could theoretically help, although maybe we're too far down the road :)

👍 1