If you count the situations that lead to "No" you'll realize that all the "No" cases can be easily checked for, and if you're not in a "No" case then you're in a "Yes" case.
Can probably be implemented in a regular function with about 30 lines of code?
Software development in a nutshell.
I think you might be under-counting the "No" cases.
I counted at least 30 (and then stopped, with plenty still to go) so I don't think you'll get it in 30 lines of code unless you have some very long lines with rather impenetrable logic.
I counted 9.
- channel is muted and message not in a thread the user is subscribed to
- user in dnd-mode and there's no dnd-override
- this is a @channel mention but @channel mentions are suppressed
- message is for a thread user is subscribed to but channel notification perf is nothing
- notification preference for device is set to "never"
- @here mention but user is not active (not here)
- highlighted word in a thread message the user is not subscribed to
- channel notification preference is set to nothing
- I couldn't understand this condition (@mention in a comment on a file not owned by user?)
You can check these conditions sequentially and if any of them match, return false.
The last statement in the function would just `return true`.
The function needs a struct representing user preferences and a struct representing what's being currently parsed as inputs.
It's really not that complicated.
Counting paths from the first node to the "NO" node rather than just counting total edges leading to the "NO" node.
Many of the conditions you mentioned are themselves determined based on various other conditions, and/or only triggered if certain paths (but not others) are followed.
> You can check these conditions sequentially and if any of them match, return false.
Not so.
For example, you could have the 'notification preference for device set to "never"', but there are paths through the flow diagram that evaluate to "YES" without ever going through the path that checks for the global device notification preferences.
Therefore if you are just sequentially checking each of the conditions you mentioned, then you'd be returning false (because that one statement matched) instead of true (because the flow should never go down that path).
But, this is not the kind of thing that justifies, for example, having 20 engineers to work on this one problem for three weeks.
It's still a simple thing for one person to handle in a couple of days.
I don't get why people use feature lists as an excuse for why things take a long time and require many many engineers.
I don't disagree, I just think it's more effort than the 'regular function with about 30 lines of code' you first mentioned.