This is an intentional (although only partially complete) change. Generally, we're making some objects act more like mailing lists. There's a little discussion in D8117, which changed the behavior (by making projects mailable, and allowing other types of objects to serve as mail aggregates in the future). See also T4361 (although this is light on discussion) and T2519 (although what we're building, at least for now, probably isn't much like what that describes).

A specific case was that when you added a project as a reviewer to a revision, its members did not receive mail, but this generally seems surprising to most users (some discussion in T1279) and I considered it a bug / limitation.

In the near term, I'm planning to make all members of a project subscribers of that project by default, but let you unsubscribe from the project if you don't want to receive mail. We'll also add notification preferences for audits like we have for Differential and Maniphest (so you can downgrade all audit mail to notifications only). I'm pretty sure there's a task for that somewhere, but I can't find it offhand. I expect this to land in the next few days, pretty much as soon as I get around to it.

Would that satisfy people? Or does everyone love this change or something and you just wanted to make sure it wasn't accidental? :)

I'm not sure that'd go quite far enough for what we're after.

We have a small team across multiple disparate projects. We all want the ability to audit all commits (for cross project knowledge etc), however don't need the emails if we're not directly involved in the particular audit (ie not the specific auditor or committer or otherwise cc'd)

But we would still want the emails if we were directly involved.

From what I understand of the Differential style preferences (T2497 I think yeah?), we'd be able to opt out of emails altogether, but not to the level of granularity described above.

Perhaps some option in the project to make it mailable/not mailable would solve this in the way we expect?

Or would unsubscribing from the project keep the audit requests but remove the mailing list aspect of things on a user by user basis? That'd definitely work.

Or would unsubscribing from the project keep the audit requests but remove the mailing list aspect of things on a user by user basis? That'd definitely work.

Yep, exactly. In the case where you unsubscribe from a project, you'll still receive the email if you're directly involved -- you'll only stop receiving the mail if the only reason you would have been mailed is your project membership. The way the code works is that it figures out all of the mailable project members, then adds those to the normal To/Cc.

There are also headers (X-Phabricator-To, X-Phabricator-CC) which can be used to write client mail rules based on the original To/Cc of the mail (these are more-machine-parseable versions of the "To:" footer in the mail, and that can also be used for clients which don't match headers well). If a mail was sent to/cc a user directly, their PHID will appear in the headers, so it's reasonably straghtforward to write mail rules that put mail you're directly involved in in a different folder or star/color it or whatever in most clients. My experience is that most users don't want to deal with this, but I personally have a handful of mail rules that took me 10-15 minutes to set up a few years ago and are tremendously helpful.

At HEAD, project pages should have an "unsubscribe" button for members. Unsubscribing should stop you from receiving emails which you would have received only because of your project membership. You will still receive emails that you would have received otherwise.

Looks good! No complaints from anyone receiving unnecessary emails. Still getting the concern emails.
Thanks very much!