I worked for a telecom marketing software service for seven years. My old boss was obsessed with notifications and mobile apps because he was a marketing “guru” and indirectly showed me how broken by design most services are in this respect. One day at work a serious bug was discovered and I suggested we do the responsible thing and notify users affected and my boss said it wasn’t a priority. Where, we as developers, draw the line in the sand seems to be whatever we feel is convenient for us at the moment.
Personally I feel that most users are already drowning in notifications, emails, badges, slack messages, ads, calls, etc that even if you did do an opt-in for notifications that most users would just ignore them since their attention is already too divided.
One thing to consider is not what your software should do but how it will really be used. The software I wrote was designed for sales teams to do marketing and communication but one day I discovered a bug that crippled the service, disabling most calls, while trying to fix an unrelated bug. This bug had been active for months, yet no users had reported it because they weren’t really using the software, in their minds they would rather not work at all and file false reports in the software to make it appear they had done their sales calls to meet their quotas. The bug was fixed but no measures were ever taken to fix the real bug which was the loop hole users were using to commit wage theft. The lesson here is that most users don’t want to use your software, their boss is making them and they hate their jobs. So why not focus on the real problem which is figuring out why your users hate their work and then fix that problem.
Every service is crazy about being “realtime” these days but imagine if git was realtime...cringy...yet more people do “real” collaboration with it than any other technology given the proposition that communication software such as slack isn’t really about collaboration at all. I’ve come to feel that if a software service feels they need notifications in order for it to work then they haven’t truly automated the problem they are solving. It’s like try/catch statements: 80% of the time the catch statements in practice are just //todo comments or log to an error table no one will ever read. So my last piece of advice is to think about notifications like catch clauses, meaning that if you do your job right then notifications shouldn’t be necessary at all.