Do you have a channel like this? How do you manage it’s use? Does it make more sense to remove it and force all bug-related conversation to occur via the ticketing system?
We had a defects channel at one time and the problem is it becomes noise and starts getting ignored and issues just get dropped/hidden for a lack of proper documentation. So we forced all defects into a tracking system (zendesk in our case), which really cleaned up slack and made it more usable. We then had an engineering channel in case anyone needed a question answered that wasn't necessarily a support issue etc. That was working great until someone put in a bot for every zendesk ticket to get dropped into the engineering channel which now means that channel became a useless space for engineering. Essentially the channel is used by customer service and ops people at this point and it has nothing to do with engineering and we ignore it for the most part unless we are tagged personally. I really need to rename it because it has become not what it was intended.
The only slack "defects" type channels I like personally are the software/systems we run sending in predictive notices that an engineer needs to deal with quickly. For example, a production system that is about to run out of space, a production system that is running at 90% capacity for X time or whatever. Having a devops type channel like that is super helpful because it lets you be proactive vs reactive on things, and it prevents a lot of support tickets from ever being created. I also like new services that get deployed to drop daily/weekly stats in a slack channel for a time period while we get all the kinks worked out. That can be helpful to track things down timely, but it is a channel we create for that purpose and then gets deleted later.