Design: Fine Grained Slack Notifications
Problem to solve
Today, Slack notifications are a fairly blunt instrument. This feature lets you send notifications to a specific channel based on the type of event that triggered it, but there is a lot of variability in those events, and leads to users considering the notifications somewhat spammy.
Current State
The current available triggers are:
Trigger | Description |
---|---|
Push | Event will be triggered by a push to the repository |
Issue | Event will be triggered when an issue is created/updated/closed |
Confidential Issue | Event will be triggered when a confidential issue is created/updated/closed |
Merge Request | Event will be triggered when a merge request is created/updated/merged |
Note | Event will be triggered when someone adds a comment |
Confidential Note | Event will be triggered when someone adds a comment on a confidential issue |
Tag Push | Event will be triggered when a new tag is pushed to the repository |
Pipeline | Event will be triggered when a pipeline status changes |
Wiki Page | Event will be triggered when a wiki page is created/updated |
Deployment | Event will be triggered when a deployment starts or finishes |
Alert | Event will be triggered when a new, unique alert is recorded |
Proposal
We should review the current customer requests (collected in this epic) and prioritize those, but we should design a future state vision for what this configuration page could look like, identifying what the ideal state would be. From there we can iterate towards it as necessary, but considering the complexity of the configuration here, it makes the most sense to think as far out as possible to ensure we're not simply adding more technical debt by making iterative changes.