I don't really think this is worth implementing -- we haven't seen any other requests for it, and I don't think GitHub's behavior is very good (I end up with a lot of duplicate unread notifications). Do you think it's worth pursuing, @chad?

Oh, I see some discussion in T1403. We can let this sit and see if there's more interest in it, but I think we're unlikely to ever pursue this.

Top level I'd have to ask what problem are we solving. What prompted you to come and ask for this feature, maybe something already exists in Phabricator that could solve that? If you feel you're missing information, I'd rather start there.

In general our notifications are pretty spammy, in fact there probably a handful of tasks on that topic. I don't think it's a good user experience to both overly notify and do it twice (which they have to manually clear both out). We operate under the assumption that teams live in Phabricator for hours a day and that given the volume, it'd be overly distracting to have to manage everything twice.

We also have Dashboards, so anything personally assigned to you or requiring your input, or even slightly of interest to you, is pulled out separately.

Github's model is: Pull request comes in, everyone is notified everywhere. Task comes in, everyone is notified everywhere. We feel this model gets unscalable pretty quickly for companies, but is understandable for small Open Source projects.

What prompted me to look for this feature is that I thought there was an issue with my installation that prevented notifications from being highlighted then I thought it was Phabricator issue till I knew it was by design.

I have a different use-case with Phabricator, I'm not planning for my team to use it hours a day, I'll just use it for code reviews (post-commit audits) which might be done once or twice a week, so I want new notifications to be always highlighted as the user might see the email today but decides to come back and resolve the concern a day or two later.

The dashboards are pretty good, I didn't know they exist, they'll solve the problem partially as I'll show the notifications list and the tasks assigned to each user with updates related to them but still the user won't be able to differentiate what's new (unread) unless he kept track of the last notification he handled.

To restate @PeteA from T9384, the use case we have is "web interface whenever available, emails otherwise."

Our Phabricator installation is available in the local company network, there are VPN tunnels in place for external access too, but there are still many occasions where our users would like to act on a task while not being able to access either the local network or the tunnel - from home during the weekend, on the go etc.

Emails are great for that, but enabling emails means when the user is back in the office / on the tunnel, they will not start getting unread notifications - and having a list of unread notifications is a much more convenient way of tracking what to do.

One solution would be to always remember to switch all notification options to "email" each time before going home / on vacation / on a business trip and put them back to "notify" when back to office, but a) it's too easy to forget to do it and b) there is a gazillion dropdowns to flip.

An "email + unread notifications" option would solve this problem.
When the user is in the office, they use the helpful notification list and they ignore the emails they receive (the emails just go to a special folder in their inbox and are marked as "read").
When the user is on the go, they stop ignoring the emails. And when back to office, they ignore them again.

See also T7004, although I'm generally not hopeful about being able to build a version of that which feels like it works well.

If we did plan to pursue it, it might point at a user-selectable mode (e.g., "Online" = notifications, "Offline" = email + notifications, "Automatic" = guess from activity) but I don't think this avenue is especially promising.