Page MenuHomePhabricator

How should I create audits without always emailing all project members
Closed, ResolvedPublic

Description

I presently have our instance setup to generate audits according to the 'audits in small teams' suggestion. This has been working well but we don't really need the emails to go to everyone in the team. Especially not the emails about comment discussions once someone has taken on the responsibility for the audit. I tried just removing people from the project but while this does inhibit the unwanted emails it causes 'Accept commit' to only result in 'Partially audited' commits.

In short, I want email when I am directly associated with the action but not when I am only associated via being a project member.

Any thoughts on either how to achieve this or why I shouldn't want this? Thanks for the help.

Event Timeline

altendky raised the priority of this task from to Needs Triage.
altendky updated the task description. (Show Details)
altendky added a project: Audit.
altendky added a subscriber: altendky.

You can assign Auditors in your commit message instead of a blanket Herald Rule, this can be a team, person, many people, or cats.

Thanks for the pointer. We do generally do this but would still like the catch-all for when we don't. Mostly I want to be able to go get a list of all commits which have not been accepted (or derived from an accepted revision) within some set restricted to certain paths in certain repositories (and since some time). Don't bug the entire team up front or whenever anybody comments on anything, but make it easy to get a list of things that need to be looked at.

Are you using a pre-commit workflow? We also highly recommend that. If you're only performing post-commit auditing, you're missing the main benefit of Differential (which is, catching issues and top level architecture discussions before they land). People are also more likely to resolve something pre-commit vs. post-commit.

Basically, if you're assigning a Project as an Auditor, everyone in that Project will get a notification. We have no mechanism of claiming an Audit and removing that Project. Herald and Owners are available for you to build more complex assigning rules to reduce noise.

Peer-review is going to be the best way to reduce noise, either assigning Reviewers pre-commit or Auditors for post-commit.

I think 'only email certain people on certain cases' for audit is covered by T2497. T5889 might also be of interest if you are trying to do herald rules with Audits.

I agree whole-heartedly with your comments about pre-commit review. We do some of that but mostly not. I am picking my battles and already fighting on too many fronts. Even audits are optional at best.

I took a look at the owners article and it does seem like a much simpler way to do what I did with a pile of herald rules. It did not clarify email activity but I can test it out and see what it does. Also, the linked tickets are certainly on topic and good for me to be aware of.

chad claimed this task.