In T9161#136555, @epriestley wrote:

My personal, completely subjective experience is that Phabricator mail is trivial to deal with, almost all valuable, takes very little of my time, and I want to receive >95% of the mail that I receive, and that I'd barely notice if I had 10x this mail volume.

Makes sense!

what do you think about supporting a mode that always uses the client (browser) timezone by default without any manual action taken by the user?

FWIW, from our perspective we really want the time zone to be correct (for our users) by default without any manual intervention. From the discussion above, it seems like this ticket is leaning towards a scheme were the user is expected to set their time zone in Phabricator, but displaying a recon dialog if it mismatches the browser.

For whatever it's worth, here are the comparable (14-day) numbers from this install with the more modern script:

(See also T5358 for previous discussion on this setting).

~50% of the preference entries include disabling self actions. There is probably a bit of hand waving to get to that that to a percentage 'all users', or 'all active users'.

A few people have commented that their first time user experience with a flood of self action emails left a poor initial impression.

14 days seemed like enough time to get some reasonable results. They are.... complicated.

• To my surprise I'm not in the top 10 for delivered email.
• Very roughly, people who get more email seem better at handling it.
• Among the 'too much email it is terrible!' crowd some people turned off virtually all email in phabricator while others have a client side filter. The most vocal complainers have usually succeeded in using the available tools to no get email, but at the cost of creating larger coworkers-ignoring-each-other ones.
• Most people are doing some filtering although perhaps ironically some of the best responders send almost everything to their client.
• For anyone looking at the raw numbers, we have a lot of audit related mail.

I also want to note the consideration that "good accuracy" + "simple ruleset" is probably a better default than "great accuracy" + "complex ruleset".

My 'useful' bar for email is "would I want to reply to this".
Does the user have to do something about this email?

Closing for lack of feedback.

I should mention, sometimes people are CC'd because we want them to know that a task has been created, but this doesn't necessarily mean they want to know when every action happens on that task forever into the future. Having some way of distinguishing between "I need to give someone a heads up about this tasks existence" and "I want to know whenever anything happens on this task" would help here as well.

I think these users are just giving up immediately.

At my company, the majority of non-technical users simply turned off email notifications entirely. I know it won't happen but it would be awesome to be able to say "turn off everything but subscribed Maniphest tasks for this user" because then I could still get them to reply to tasks that I've cc'd then on. Otherwise, I have to have the conversation outside of phab and keep the task updated myself.

In T9161#131941, @chad wrote:

My 'useful' bar for email is "would I want to reply to this".

There's a lot of back-an-forth here but @epriestley pointed one thing in particular that reasonates well with my experience:

In T9161#131972, @chad wrote:

Or maybe even only have these 5 settings, and everything else is Herald.

Or maybe even only have these 5 settings, and everything else is Herald.

One more idea, maybe "GROUP" settings? Everything seems to fall into a groupable setting. This could be the "basic" view.

I would like to see that tracked as well in the workflows.

We do record the originator of the mail internally, and could expose it in /mail/ or bin/mail volume, etc., without much work. For example, it would be easy to add:

bin/mail volume doesn't report what fraction of mail is generated by the user, if that's what you mean.

(is that tracked?)

In fairness, I think self-actions should be a part of this conversation also.

Yeah. I'd also really like the objective numbers from bin/mail volume, but they won't be very good for 30 days. Maybe we just wait that long to attack the "too much email" aspect of this -- role profiles and herald outbound rules are justified on their own anyway. I'd want to get this data:

Maybe better feedback to get from people is "what mail did you receive that was unexpected or not useful"?

Put another way, "send no mail by default" solves a different problem, which is "administrators complain to us that their users complain to them that they get too much email, but some of this is rooted in personal/emotional issues and has no technical/product solution".

I think there are a lot of reasonable things we can do to make it easier to get your settings set the way you want them, but they'll only help users who have a "oh, these settings aren't very good, let me go fix them" mindset. My concern is that the root of this problem may not be users having difficulty setting things up, it's users just feeling helpless and overwhelmed by the problem for essentially personal/emotional reasons which we can't easily fix.

Yes, T4103 is the task for this. I'm going to merge this there.

See also T8227: Why not just add an option/setting/preference?.

Rolling.

(but maybe @epriestley will roll secure for us).

secure is not precisely at HEAD.

The default can be changed using following patch (cf. P1821):

It is always English (US).

But where does "Server Default" come from? Apparently there is a default set somewhere, I just cannot find it…

There is no way to do this right now. T4103 will provide a way.

Oh, haha, there is nothing useful in there.

In T8878#126901, @chad wrote:

I'd rather over-engineer a more generalized "new in phabricator" type feature, so people understand what new functionality was added since their last update.

Safari's Push Notifications for Websites, for example, sounds pretty awesome.

I don't think desktop notifications in it's current state is worth additional touting (it doesn't do Conpherence, for example). Even if it were, I'd rather over-engineer a more generalized "new in phabricator" type feature, so people understand what new functionality was added since their last update.

The slack way of doing think can be a possibility, no ?

Woah, same thing for me. Had no idea.

Did you have something specific in mind? It feels about right to me. "New" settings are always going to be somewhat under-discovered.

In T8885#126858, @chad wrote:

Also, #phui is the best tag for these, which is "Phabricator UI". Maybe a good way to think about it is #design is pre-commit, #phui is post-commit. :)

Actually, I might have a way to make these work in the mobile/button case.

Also, #phui is the best tag for these, which is "Phabricator UI". Maybe a good way to think about it is #design is pre-commit, #phui is post-commit. :)

T7993 is the opposite of this. There are essentially two ways to lay these font icons out, either make them absolutely positioned or make them inline. Both have different drawbacks. Inline icons look more fluid, but they break at the icon when wrapped. Absolute are more predicable and break after the first word, but they can have uneven spacing between the icon and words. For buttons I prefer the more predicable route, and for tags, we go more fluid, though T7993 would maybe disagree. I don't really know any other CSS magic to fix these... maybe tables?

No, it's not meant to be centered. The FontAwesome icons all have varying widths. On buttons they are aligned left, which looks correct in 99% of cases, and wrong on this one case given the icon.

Current notion of "recent" versus "standard" dates should expire as soon as date preferences have been specified.