Page MenuHomePhabricator

Refinements for "Mute Notifications"
Open, LowPublic


See T13053 for earlier work. See PHI126. D19033 introduces a "Mute Notifications" action for subscribable objects.

The current implementation is a little rough. I'd like to see if anyone actually uses it before investing more time into it. If it sees use, some reasonable followups might include:

  • Support !mute via email replies (and via comment commands in the future, see T11934).
  • When users are @mentioned on an object, render their name in a disabled style if they've been muted. Otherwise, Alice may be trying to get Bob's attention with @bob but not realize that he has the object muted and her efforts are fruitless. (Muting is stronger than mentions.) This could also be: "Bob has muted this discussion, mention him anyway?".
  • Muting is currently weaker than "Send me an email" in Herald. I think this is right, but maybe not.
  • Provide some way to review stuff you've muted, maybe in a dedicated UI or by continuing to deliver you notifications to a separate "Muted Threads" section of your notifications UI.

Event Timeline

epriestley created this task.

If this feature doesn't see much use, I'd like to remove or deemphasize it (for example, by moving it to a keystroke or removing the UI and just providing access via !mute) at some point since I think UI space in the curtain is premium real estate. This doesn't need to be 200 mutes per user per day, but I could imagine this seeing essentially zero use.

For what it's worth, I think the Mute feature adds a lot of complexities to the system, in excess to the norms of the last few years:

  • Code to handle it in the sending mechanism
  • Prioritizing this feature against any other notify feature (like T9031)
  • UI to show the to the muting user (on the object and in /mail/?)
  • UI to show to other users that this user will not be notified (What if all members of a project are muting a thread?)
  • Can a mailing list/project mute a topic?
  • "why did I not receive this notification?" - there's still some issues about this - novice users don't know/understand /mail/, and admins can't see this for them. I suspect this question will require a written checklist somewhere.

There are alternatives for this feature, but they're not very good:

  • gmail has "mute" feature for mail threads, and in other clients you can define a custom rule based on headers/topic.
    • I'm not sure Phabricator emails play nice with the gmail feature.
    • in both cases, Phabricator doesn't know about the rule, so "why am I not being notified" is harder to debug.
  • In T9161, we basically decided that "too much email" is slanted much towards "emotional" issue rather than actual problem.

I largely agree. This is getting leeway because it's backed by support mana (PHI126 basically just asks for this feature, verbatim). I think the actual change in D19033 is small enough that I don't feel too bad about giving this a shot, but I'd like this feature to see significant use and not generate a lot of confusion/support load if it's going to stay in the upstream. I'm also more comfortable trying this because it's very easy to revert.

Because it's so explicit and unmagical, I think this may fare a little better than some efforts in the past. Relatively recently, we're also seeing some customers make very heavy use of Package/Project reviewers (where a typical revision may have 50+ package reviewers in relatively routine cases) and the existing tools don't handle this with much grace. PHI175 asks for the ability to ignore resignations, basically in response to this, since the install is seeing Herald add 50 packages and then a bunch of users immediately resign. To some degree this is obviously solving the wrong problem (i.e., this whole dynamic is silly), and server-side routing rules to drop this mail would probably be better than muting (T13069), but "Mute" could also help bridge that gap until I can get real fixes in place.

epriestley mentioned this in Unknown Object (Phriction Wiki Document).Feb 10 2018, 1:02 AM

FWIW I appreciate and use the mute feature (though only occasionally)

A very mild point in favor of this feature is that we haven't seen any negative feedback or confusion, although I think you might be the first user to say they actually like/use it.

Hosted instance data (see T11760) points at this feature having a very-low-but-not-actually-zero use rate.

When users are @mentioned on an object, render their name in a disabled style if they've been muted.

See T13602 for some discussion of this. This is ripe, but I have no evidence that this is actually causing problems in the wild, and mild reservations about exposing "Mute" to other users (it's currently private information). So, no plans to implement it for now.