I don't think a switchboard of checkboxes can accommodate requests like T6296.

Generally, almost all request in this vein are fairly easy to build with client mail rules. One issue with that is that Gmail's mail rules suck (T5791). For example, you can build T6296 with a Herald rule that matches on "Author is me: do nothing", then a client mail rule: "subject contains [maniphest][changed cc]; header 'x-herald-rules' does not contain <the-rule-i-just-made>: delete mail".

Possibly we should just build server-side Herald-based mail rules ("headers match", "subject matches", "body matches", "sending application", "author", etc.), but I'm really not sure this is worthwhile.

Broadly, I'm not very sympathetic to these complaints in general: I've told this anecdote a million times, but empirically I had more than 7x the mail volume at FB (which I've never had difficulty staying on top of) that the most vocal users complaining about mail volume had. I've spent approximately 15 minutes configuring mail rules over the course of my life.

If I look at https://secure.phabricator.com/settings/panel/emailpreferences/ , this seems rather easy conceptually: there is already one row (and selector) for each possible event, they only need to be "exploded" by the possible relations one can have to the event: Actions x {I made it; or not} x {I'm author of the task/whatever; I'm subscribed to it; I'm assigned to the task; I'm backer of the fund proposal; ... }. You already have the first two combinations, just need the latter.

Then an interface is needed to set the site defaults for those.

In T6309#79446, @epriestley wrote:

Generally, almost all request in this vein are fairly easy to build with client mail rules.

Well not all of them until T6297 is fixed.

Broadly, I'm not very sympathetic to these complaints in general: I've told this anecdote a million times [...]

I feel you, same for me. But please don't forget that individual installs also need to have defaults which work for their users, rather than delegate to individual customisation.

It's easier in small and medium projects, say having at most hundreds or thousands members/employees, to train them to use basic work tools. But when you have tens of thousands users from all over the world many have no idea how to use filters, or possibly are using a webmail which barely has filtering, or they even just started using email (only 40 % of teens nowadays use email, IIRC). And you can't do anything about it. Yes, the world is a sad place.

Then an interface is needed to set the site defaults for those.

Local patches and forking are what we're currently recommending to teams who feel the defaults or how Phabricator works for their team or use case are not correct. We are not offended by this, we ship what we call "Vanilla Phabricator" which is set up for a very agile, lean, "open", and likely smaller company and we understand it won't meet every installs needs. But there isn't any reasonable way we can take every installs wishes into the upstream and still be able to move forward/maintain it off of three people.

Well not all of them until T6297 is fixed.

T5791 covers adding additional information for filtering emails.

It's easier in small and medium projects, say having at most hundreds or thousands members/employees, to train them to use > basic work tools. But when you have tens of thousands users from all over the world many have no idea how to use filters, or > possibly are using a webmail which barely has filtering, or they even just started using email (only 40 % of teens nowadays
use email, IIRC). And you can't do anything about it. Yes, the world is a sad place.

I would agree, but new users are going to best be served with a proper Phabricator NUX (new user experience) and by proper defaults on Phabricator (either in Vanilla or your fork). We will eventually build more NUX into the product. But the feature being requested here is, IMHO, as complex as adding an email rule. It's not a 'new user' feature.

This software is also not targeted at consumers or the public at large. It is targeted at professionals in software fields and adjacent fields. Product and prioritization decisions we make in the upstream reflect that.

In T6309#79515, @epriestley wrote:

This software is also not targeted at consumers or the public at large. It is targeted at professionals in software fields and adjacent fields.

Oh. This is definitely not what I was told, sorry if I came with wrong expectations. Is this documented somewhere?

Is this documented somewhere?

phabricator.org explains the target audience in large text in the page header:

Phabricator is a collection of open source web applications that help software companies build better software.

Nuance is our future product intended to let installs interact with common folk (for issues) anywhere on the web.