Slack plugin: automatically subscribe a channel to updates on a topic when link is shared

In our company, Slack channels proliferate with wild abandon. This is a topic of discussion in of itself, but it will likely be a challenge to work towards having a more curated set of Slack channels… some folks have worked on aspects of this problem, but even with automatic cleanup, I expect the number of channels to continue growing.

So in Slack, it is culturally expected at this point that channels will be frequently created and often represent niche interests. Out of a few thousand people, some channels may be very active, but only have ~ 10 active people in them.

This is one of the reasons that I’ve advocated for tag support in the official slack plugin. We don’t want to see the same proliferation of categories in our Discourse setup, but we don’t mind tags enjoying the same kind of freedom that Slack channels have. So the thinking is, if Slack channel users are able to self-subscribe to tags of interest to that channel, then relevant Discourse discussions can feed into the appropriate channel.

But here’s another thought I had around the same problem:

What if, any time a link to a Discourse topic is posted in Slack, the channel could auto-subscribe to updates for that topic? This would eliminate the need to remember to tag things appropriately, or which tags map to which channel.

(The tag support thing would still be valuable, I think, but this could complement it pretty well).

1 Like

Is this possible within the constraints of the current design @vinothkannans?

2 Likes

Yes both are possible. I can add these to my current to-do list.

5 Likes

As per your request I started working on tag support. My idea is if someone run the below command in a slack channel X then X itself will be subscribed to the tag support.

subscribe:tag support

Here every clients should configure outgoing webhook on slack with URL(s), Token and Trigger Word(s) fields. Trigger Word(s) should be configured as subscribe:, unsubscribe: etc., or we can give common name like discourse:.

Now what is your opinion @mcwumbly?

I was thinking it would follow the design established already for categories, using the /slash-command

So it’d be something like:

/discourse [watch|follow|mute|help|status] [category|tag|all]

Whether tags need to be namespaced or not is something I don’t personally feel too strongly about. On the one hand, the plugin could just infer it for the user, saving them from having to specify things explicitly. There would be the edge-case of a tag that also exists as a category, in which case, a simple “category wins” rule could be put in place. Alternatively, we could require something like this:

/discourse [watch|follow|mute|help|status] [category|tag:name|all]

So to subscribe to the “teapot” category, I would do:

/discourse watch teapot

And to subscribe to the “teapot” tag, I would do this instead:

/discourse watch tag:teapot
1 Like

Yes. Slack commands are far better option comparing to outgoing webhooks. But it needs a dedicated slack app for Discourse. And also needs a microservice bridge to connect all client installs with slack app. I am already discussing with Discourse team to create it.

I think this one is better.

Thanks for your valuable suggestions.

3 Likes

I think there may be a middle ground just to get tag support added. The existing slack command works well for the category subscriptions and doesn’t yet require the additional complexity you discuss, I don’t think.

Once we start talking about the idea in the OP for automatic “topic” subscriptions when a link is pasted anywhere in the message, then it will be necessary to do something fancier, though.

1 Like

Thank you @mcwumbly. Somehow I totally missed this topic :stuck_out_tongue:. It’s right place to start the tag support.

But I am still thinking dedicated Discourse slack app is needed. It will reduce manual configuration work for clients on slack. Also it will be easy to develop new features. Like automatic topic subscription which you suggested.

3 Likes

No. We are not going down this path. It was discussed at length earlier and it requires a lot of pain and suffering on our side.

1 Like