Change Details

Umbrella task describing the next round of changes to mail.

Umbrella task describing the next round of changes to mail. The major issue with mail today is that some users feel like they receive too much mail, and are unsatisfied with the tools to understand and manage it. This is largely discussed in T9161. This roughly breaks down in two ways: - Users who want to do specific mail routing, but don't have a way to configure the behavior they want (sometimes because Gmail can not filter on arbitrary headers). These are generally reasonable and actionable. - Users who don't like the mail behavior but, for whatever reason, do not make a serious attempt to configure it (i.e., the complaint is "the behavior is bad", not "I can't configure the behavior to work like I want"). In the general case, this is probably not something we can fix except by disabling all mail by default. There's general product tension between reducing mail and two other concerns: - Users don't want mail, but they //do// want //others// to receive mail. For example, when you request review, you want your reviewers to receive mail. In most cases, the world is a better place if this mail is delivered. - It should not be possible for attackers or malicious users to act in a way that suppresses notifications to others. There are some kinds of mail which we know is probably not useful, but which we we deliver because failing to deliver it would let an attacker act in secret. Some of this problem is a UX problem rather than a technical problem, and some users give us very, very little to work with (e.g., they appear to be unwilling to configure any settings at all before complaining that our behavior ruins their lives, so our defaults must exactly align with their expectations). I think we can't ever resolve all of these, since some of these users have different expectations (except possibly by not sending mail). --- I anticipate making these changes: **Explain Why Users Receive Email** (T9412). Currently, users are sometimes confused about why they're receiving email. We're fairly good about explaining mail-system reasons (e.g., Herald) but do not do a good job of explaining application reasons (e.g., you're watching a project the object is tagged with). This is an unambiguous product improvement. **Improve Mention Handling** (T4654) Mail that mentions a user by username (`@username`) is almost always interesting, but we currently have no special routing for it. We should. **Improve Mail Tags**. Currently, we have a huge list of checkboxes for different types of mail actions {nav Settings > Email Preferences}. I don't think this is the right long-term approach: in five years, Phabricator shouldn't have the same screen just with 10x as many options. Some of the specific issues are: - As implemented today, it's not modular. Third-party transactions can not extend mail tags. - There's no way to express a mail tag preference across applications. If you don't care about policy changes in //any// application, you have to fiddle with tons of settings (and make additional changes every time a new application is installed). - The bucketing of transactions into groups is somewhat arbitrary, and sometimes does not align with user expectation. - The existence of "other" buckets and "other" transactions is confusing (users sometimes don't understand where "other" came from, and the UI can't explain it to them). I expect to change this system to be more rules-based (i.e., "Herald-lite"), more directly tied to transactions, and more integrated with mail (e.g., ways to edit preferences based on a particular mail message). **Herald Outbound Rules** (T5791) This basically works, but can't take any actions today. I have two major concerns: - Because Herald is complex, our ability to explain Herald-based rules to users in a simple way is diminished. If we, e.g., replaced email preferences with Herald rules completely, users would have a more difficult time making simple changes and a more difficult time understanding routing rules. - Being able to turn off mail with Herald allows an attacker to disable all mail, then act silently. This is compounded because Herald itself does not currently send mail. There are some use cases where I think this probably is the best solution in the long run, but I'd like that to be 1% of the most complex cases, and use simpler systems for the other 99% of things. We can probably deal with the security side of things by making Herald send mail, and preventing that mail from being disabled using Herald, I guess? Ayyyyy...

Umbrella task describing the next round of changes to mail. The major issue with mail today is that some users feel like they receive too much mail, and are unsatisfied with the tools to understand and manage it. This is largely discussed in T9161. This roughly breaks down in two ways: - Users who want to do specific mail routing, but don't have a way to configure the behavior they want (sometimes because Gmail can not filter on arbitrary headers). These are generally reasonable and actionable. - Users who don't like the mail behavior but, for whatever reason, do not make a serious attempt to configure it (i.e., the complaint is "the behavior is bad", not "I can't configure the behavior to work like I want"). In the general case, this is probably not something we can fix except by disabling all mail by default. There's general product tension between reducing mail and two other concerns: - Users don't want mail, but they //do// want //others// to receive mail. For example, when you request review, you want your reviewers to receive mail. In most cases, the world is a better place if this mail is delivered. - It should not be possible for attackers or malicious users to act in a way that suppresses notifications to others. There are some kinds of mail which we know is probably not useful, but which we we deliver because failing to deliver it would let an attacker act in secret. Some of this problem is a UX problem rather than a technical problem, and some users give us very, very little to work with (e.g., they appear to be unwilling to configure any settings at all before complaining that our behavior ruins their lives, so our defaults must exactly align with their expectations). I think we can't ever resolve all of these, since some of these users have different expectations (except possibly by not sending mail). --- I anticipate making these changes: **Explain Why Users Receive Email** (T9412). Currently, users are sometimes confused about why they're receiving email. We're fairly good about explaining mail-system reasons (e.g., Herald) but do not do a good job of explaining application reasons (e.g., you're watching a project the object is tagged with). This is an unambiguous product improvement. **Improve Mention Handling** (T4654) Mail that mentions a user by username (`@username`) is almost always interesting, but we currently have no special routing for it. We should. **Improve Mail Tags**. Currently, we have a huge list of checkboxes for different types of mail actions {nav Settings > Email Preferences}. I don't think this is the right long-term approach: in five years, Phabricator shouldn't have the same screen just with 10x as many options. Some of the specific issues are: - As implemented today, it's not modular. Third-party transactions can not extend mail tags. - There's no way to express a mail tag preference across applications. If you don't care about policy changes in //any// application, you have to fiddle with tons of settings (and make additional changes every time a new application is installed). - The bucketing of transactions into groups is somewhat arbitrary, and sometimes does not align with user expectation. - The existence of "other" buckets and "other" transactions is confusing (users sometimes don't understand where "other" came from, and the UI can't explain it to them). I expect to change this system to be more rules-based (i.e., "Herald-lite"), more directly tied to transactions, and more integrated with mail (e.g., ways to edit preferences based on a particular mail message). **Herald Outbound Rules** (T5791) This basically works, but can't take any actions today. I have two major concerns: - Because Herald is complex, our ability to explain Herald-based rules to users in a simple way is diminished. If we, e.g., replaced email preferences with Herald rules completely, users would have a more difficult time making simple changes and a more difficult time understanding routing rules. - Being able to turn off mail with Herald allows an attacker to disable all mail, then act silently. This is compounded because Herald itself does not currently send mail. There are some use cases where I think this probably is the best solution in the long run, but I'd like that to be 1% of the most complex cases, and use simpler systems for the other 99% of things. We can probably deal with the security side of things by making Herald send mail, and preventing that mail from being disabled using Herald, I guess? Ayyyyy...