Actually that would be great if someone could let me know where to patch the default value in the source, thanks.

I also find odd to have notifications about your own actions enabled by default. Many users in our test instance complained about these notifications before finding where to disable them.

Very old feature, so I can't say why it exists by default. Ref T228 is the earliest I could find.

https://secure.phabricator.com/diffusion/P/browse/master/src/applications/settings/panel/PhabricatorSettingsPanelEmailPreferences.php;2f5dedc97e2cae7f75924b29e029a5404cb915b4$111

@chad, the line you mentioned, wouldn't this changed the default for the option as it is displayed but not as it is implemented? I mean shouldn't I instead change the initial value for PhabricatorUserPreferences::PREFERENCE_NO_SELF_MAIL?

Oh yes, I am likely wrong. @epriestley do you recall the reason we have this by default to self-email? I would expect the opposite.

Sending yourself mail about your own actions makes threads in your mail client complete (e.g., if someone is responding to something you said, you can scroll down to see exactly what you wrote), and makes mail search more useful (since it can index everything).

(I personally use mail client search fairly often -- theoretically Phabricator could do this, but Mail.app has a local index and "stuff I've received mail about" ends up being a meaningful filter for me.)

Generally, I want to make it easier to find email settings (particularly, by linking to them in email) but am pretty hesitant about making the defaults more complex, even if we expect many users to adjust them. The current defaults are easily learnable ("everything sends email"). If we picked the most common settings as defaults some users would save a few seconds adjusting preferences, but some users would also be confused by the complex default rule ("actions I don't take, which aren't just CCs or project changes in Maniphest, unless I am added as a CC, send email"). I don't think this is a big win overall, and that it's reasonable to expect users to spend a minute or two adjusting email preferences to fit their needs.

For what it's worth, we've had about 200 users adjust mail preferences on this install, into 32 different configurations. The most popular configuration is used by only ~23% of users, and there are 8 different configurations with at least 5% usage. These are back-of-the-napkin numbers, but suggest that there isn't one "right" set of defaults which we could just push everyone into to save everyone a few seconds. Even if we picked the most common configuration, 70% of users would still presumably want to make an adjustment.

Also, at least on this install, among users who have set anything in the "Email Preferences" panel, only 35% have disabled self mail:

 84 No self mail
159 Yes self mail

This is probably not representative and this install is undoubtedly weirder than most, but this at least suggests that this default isn't wildly unreasonable.

I don't think implementing this task would make anything more complex. It doesn't change anything UX wise: things would work exactly as before in all the cases you described since the default behavior is unchanged. It only allows exposes explicitly said default behavior like for other settings on the page and let orgs in which the majority of users would rather not receive self-notifications change from opt-out to opt-in.

I personally think opt-in is better for adoption by non-engineers as it reduces the email notification noise and ensure that they will look at every email since there's no "it's probably from me, I'll ignore it" risk.

Regarding the default of this install, the problem is you don't know how many people haven't changed this setting because they simply didn't know it existed ;)

FWIW, our install also would like to have the option to turn self-notifications off by default. The reason is pretty much what @swisspol said, that the new-indicator in the inbox only reflects that something really needs attention.

FYI when I go see people in our org to help them with Phab, mostly non-engineers who may have some problem staying on top of things, most still have self action emails enabled even though I recommended a few times to turn if off to reduce notification noise.

This would be helpful if this enhancement could be implemented soon.

I'm looking forward to see whether the successful launch of Phacility and the new instances being created shed some light here. I still suspect most new users get confused about this defaut setting, mostly because I don't think it is found by default in any other popular service.

My concern with the current default (send self-actions) is that it's surprising and it gives preference to a specific developer workflow (one that could be opt-in, not opt-out). I do find the number of people who have switched it here specifically, high. If we flipped the setting, I'd guess less than 5% would opt-in. Is there other software that offers this feature?

I guess my questions are two part: If we built Phabricator from scratch today, would we build this as the default? If changing neither changing the default nor giving admins control, what is the correct path forward (user nux?).

How about changing the entire product to default to not sending any email?

I'm not sure how come people don't think sending emails on self action ISN'T the default in most enterprise software...?

Sure, Facebook, Twtter, etc... You know, consumer software where people upload videos and stuff...

But Jira, Service Now, Workday,etc all did back when I was using them. Enterprise software where people like logs and consistent data, etc.

Taking a step back, this seems silly to even debate. @chad - if you want to change it based on some objective metric, let's define that framework, get the metric, and then do or do not.

You listed JIRA and Workday as examples, and I think it's really important to not just list other software that does this, but to understand more specifically why. We haven't been in the practice of just adding features because x,y, or z company has them (pull requests, for example). Part of my concerns is getting to the very why of this feature in Phabricator. If that is well defined, then it's easy to either defend or debate/discuss if it's still worth having.

• In the case of Workday, my assumption is HR related items (changes to benefits, sick time, finances, etc) are all helpful to have confirmed records of over email. These emails are highly important.

• In the case of JIRA, I found it helpful when filing IT related issues (hey I need a new Macbook) getting that initial email was a nice timestamp, and provided a way for me to get back to the initial ticket. There are also a number of help topics complaining about this feature, when I Google around.

• In the case of Phabricator, the main points used are either "completist", in that some developers want a copy of the entire record in email (this is the "workflow" I mentioned above), or like JIRA, that a record is produced to make it easier for users to find their way back.

Diving into those two main points, the "workflow" in my opinion should be opt-in, not opt-out. We seem to be lending preference to a small set of users and how they want to work.

The second point, is actually pretty interesting. I think it should be solved with Nuance. One off support requests are a great avenue for this type a feature, and I think, is the "self-action enterprise default" that you are pointing out.

Lastly, I always think of Phabricator as a productivity tool and excessive email is pretty much the opposite of that. We're also blanket covering all use of Phabricator (every application) under this setting. So while it may be more arguable in some cases, it's less arguable in others.

I'd obviously love to be able to A/B test things to solve harder debates. That is one thing I miss from that old place we used to all work. The best I can come up with, in that regard, is to convince some poor install to patch an A/B test themselves and give us the results (*cough @qgil*) although maybe that's also a highly terrible idea.

I don't know how serious @epriestley was with his suggestion, or maybe it came with a bunch of wavy hands. It's one approach but I don't know if that's correct - at least in the current state.

Broadly, I understood this topic was likely touchy, but my response and thinking about this from a user-empathy perspective I feel is still spot on. Mostly, it feels like ignoring the stream of concerns from admins and users on this type of issues is no longer the correct direction - I want us to actively care about the user. It may be overly difficult to solve, it may be long and drawn out debates, it may not get resolved this year, but I do think it's important to show concern for the user-related issues such as this. For those who are bothered by it, it is one of their first introductions to Phabricator, and that's sad to me that it's a negative one.

https://medium.com/@johnolilly/design-like-you-re-right-listen-like-you-re-wrong-308e3930fdbf

This was a great article I recently read. I think a lot of time triaging bugs and features here I instantly looked for ways for the user to be wrong. I thought a lot about it. I realized I should try the opposite. I should always find a way for the user to be right. Apple Store people are told expressly, "find a way to say yes". It's changed my perspective on working on features here. I'm likely not perfect, but @qgil brought up this task again and I wanted to challenge myself for a way to say yes.

This feature didn't even exist in Phabricator until 2012 (see T228). For the entire time we were employed at Facebook (more or less, I guess you guys left a little later than me), no one complained about this or requested the ability to change the behavior. And the user who eventually complained is the #1 email hater of all time.

Regardless, even if we were unanimously in favor of changing this default it's way too messy to do on its own from a purely technical perspective, and is only realistically going to happen as part of T4103, where it will presumably be picked up for free. I'm just going to merge this there.

I brought this task again because we keep receiving feedback from our users against this approach, and I am genuinely interested in seeing whether you will get similar feedback channeled to you in your new role as Phacility hosting admins.

About the theoretical discussion... we are not asking Phabricator to have Self Actions disabled out of the box. If you think the current approach is right for Phabricator upstream, this is fine. We are requesting a setting to allow our admins to disable Self Actions by default in our instance, because we know our community and this is what they are clearly asking for.

Linking this request to T4103 is conceptually correct, but here we are talking about a single system-wide binary setting that could be defined from the Configuration backend without any UI changes. T4103 encompasses a collection of rather rich features that will take a long time to start and complete, and that is currently prioritized as Wishlist. Maybe this was a way to say yes, but is pretty close to a no. :)

In T5358#102281, @epriestley wrote:

This feature didn't even exist in Phabricator until 2012 (see T228). For the entire time we were employed at Facebook (more or less, I guess you guys left a little later than me), no one complained about this or requested the ability to change the behavior.

You are describing a scenario of 100% full-time developers writing and reviewing code primarily, right? We have a majority of sporadic and part-time volunteers using Maniphest. In fact, the use of Phabricator in Facebook before 2012 and the use of Phabricator in Wikimedia right now probably have exactly an empty set intersection (as we haven't enable Differential yet), and therefore both situations probably cannot be directly compared.

In T5358#101777, @epriestley wrote:

How about changing the entire product to default to not sending any email?

Not a bad idea. :-) But seriously, better exposing notification preferences early on might help mitigate this issue.

With regard to statistics, in my personal experience, you only adjust this setting if you're an active user. For example, on Wikimedia's Phabricator installation, I almost immediately had to update this setting because I'm very active and the flood of e-mails wasn't adding any value to my life. But on Phabricator's Phabricator installation, I still occasionally get stupid notifications, but I'm too lazy to change my settings on yet another site, especially when the frequency/volume is so low given my participation here.

This is to say, the number of total users changing from the default setting may be lower than expected due to only power/active users being bothered enough to make a change. For very light/inactive users, the setting is probably a lot less painful and noticeable (a few extra e-mails telling you what you just did). This doesn't answer what the default should be or whether a user preference is warranted, of course, but it seemed worth calling out explicitly.

In T5358#102327, @qgil wrote:

We are requesting a setting to allow our admins to disable Self Actions by default in our instance, because we know our community and this is what they are clearly asking for.

Linking this request to T4103 is conceptually correct, but here we are talking about a single system-wide binary setting that could be defined from the Configuration backend without any UI changes. T4103 encompasses a collection of rather rich features that will take a long time to start and complete, and that is currently prioritized as Wishlist. Maybe this was a way to say yes, but is pretty close to a no. :)

I'm curious about this as well. Can Wikimedia's Phabricator installation override the default value here? At worst it would be a local hack, I suppose. But ideally the configuration settings would allow this.

Worth noting that the desirability of self-notifs is highly contextual. We use gmail, I was shocked to find there is no way to get gmail to let me see my own posts. But then I'm one of the few people using a local mail client, and it is actually kind of annoying when I have to slog thru the copies of the self-notifs on my phone to try and get to the one comment in the midst of potentially dozens of self-notifs.

A lot of orgs are transitioning to very low mail quantities and using alternative methods for audit trailing. I wish that wasn't the case, but that's what happens when we go from elm/tin to super-powerful laptops that do little more than emulate a pretty version of a chrome book :)

"Set up a filter" - our users aren't all engineers, and with the sheer number of notification sources they have to cope with, email is somehow the most repugnant to them.