We'd need Herald actions "Watch project" and "Subscribe project". (The latter is less important, but I guess they are both similar, so it may be done at once.)
It is more flexible than having to edit the Herald rule "subscribe me to every single task, but avoid these projects: ..., ..., ..." not speaking about false subscriptions cruft in every single task.
(We have several users, who want to be notified on either every single task or majority of tasks with an exception of certain projects.)
Can you update this ticket after reading this wiki please. It will save time for both you and the upstream.
I think the root problem here is that "Herald added a subscriber: $user" is seen as email-spammy yet people are unwilling to edit their preferences to disable notifications for subscription-changes.
The dramatized version:
A: zomg too much mail!
B: so disable the mail in settings
A: but I NEED the mail. It's critical. I cannot breath without these notifications.
B: ok, what's the problem then?
A: Too much mail! I hate spam and this automated phabricator mail is spamming me.
B: Then disable it in settings. It's easy.
A: But I want mail. I live and breath for it.
etc.
It's still not really clear to me what this issue is describing. Here are my best guesses at how to fix various things which might be problems?
If users want to follow every task, they can write a rule like this:
When:
[ Always ]
Take Actions:
[ Send me an email ]
If they want to exclude particular projects, they can use this condition instead:
[ Projects ] [ do not include ] [ fruit, vegetables, vitamins ]
The "Send me an email" action does not generate transactions, so this won't add anything to the transaction record.
Even if they use "[ Add me as a subscriber ]" instead of "[ Send me an email ]", this only generates additional transactions when other updates occur. So users should never receive more mail, just one extra line in mail they already receive. That is, this mail:
alincoln added a comment.
...
...becomes this mail:
alincoln added a comment.
Herald added subscribers: nosyguy.
...
Perhaps having this one extra line of text isn't ideal for some users, but it's hard to imagine that this is really a particularly serious problem.
As written, the proposal doesn't make sense given how Herald works (Herald responds to actions, and can not generate "stateful" effects like "watch every project that exists except A, B and C").
Broadly, this issue feels several levels removed from describing the root problem (see Describing Root Problems). We generally expect Feed, rather than email, to be the best tool for casually keeping up with activity that you're interested in. It would be helpful to understand why these users are choosing to receive mail instead of use Feed: perhaps there are ways we could improve Feed to address their needs, which would moot any issue in Herald/Projects/Subscribers.
If we apply "5 Whys", it sounds like it looks something like this:
Instead of following this problem down to a root cause, this report only goes about one level deep and then decides on a particular solution, which happens to be impossible. It's important that you follow Describing Root Problems when filing requests instead, because we may be able to come up with a better solution if we have all of the information about a problem, but can not propose alternate solutions without it.
Here, information at the second level is questions like:
Answering those questions will probably lead to more questions.
If you'd like upstream help resolving this, please file a new issue completely describing the problem, per Describing Root Problems.
As I was asked to provide some input here:
That is what I am currently doing via Herald in our Maniphest installation. :)
- Why aren't they using Feed?
As a bugmaster, my workflow is primarily email-based (describing a fact here that likely could be challenged). I receive notifications on Maniphest task changes which interest me and filter / process them. I abuse the "Unread" status of certain emails to mark stuff I'd like to follow up on later. I have not played with Feed (or an application to consume feeds) to be able to judge whether that would also suit my needs on processing large amounts of information and acting on some of that.
- Why do they want all of this information in the first place?
As a bugmaster, I'd like to get informed of most / nearly all changes on tasks, to allow me clarifying task descriptions (steps to reproduce etc), escalate issues that seem important, manage expectations, etc., to support our many stakeholders.
A small (partially off-topic) note about feed - in such a high traffic Phabricator instance like ours (WMF), it is nearly unusable. Fortiori if there is no (preferably customizable) real feed (Atom, RSS). Lack of feed support in Phabricator is one of its biggest disadvantages. I know there was some task here about it but I can't find it now.