One alternative approach here would be to either add a new relationship ("Following"), or make the "Subscribed" relationship mean "CC me on everything" and then have a separate relationship for "Unsubscribed" (like "Muted").

However, I think it's probably good that you can't follow a project unless you can join it, which suggests that "join/follow" should be the same relationship, with controls for notification/email.

Another alternative would be to always CC projects, and let users unsubscribe from the ones they don't want to get email for. This feels like it would make users do a lot of work, though.

Generally, I think this use case is relatively rare (we've only seen this one request for it), and some subset of the cases can be handled through Herald.

I had two long offsite meetings pop up last week and effectively eat the day I was hoping to fit this into, but this is still near the top of my queue.

I think I'm going to add a per-project "Follow" status instead, which might have a different name like "Watch Like a Hawk" or something by the time I'm done implementing it. That means there will be four states:

• Not a project member: if you are not a project member, you never receive project mail or notifications.
• Member (unsubscribed): you will also not receive mail or notifications.
• Member (normal): you will receive mail and notifications when the project is related to an object in an active role: it is explicitly CC'd, made a reviewer, an auditor, an assignee (in the future, if we implement this) etc.
• Member (following): you will receive mail and notifications when a project is related to an object in either an active (reviewer, auditor, assignee) or passive ("projects") role.

This is more granular, easier to discover, easier to query, and I suspect the granularity will let it will map to real-world uses better.

D9185 adds a "Watch" action. This has the same name as a GitHub action, but performs an approximately similar function, so I don't think it will be too confusing.

• You must be a project member to watch a project.
• "Watch" is like a stronger subscribe: you'll get object updates even if the project is not in an active role on the object.
• Watch implies subscribe: you can not be unsubscribed but watching.
• When you leave a project (or are removed) your watch ends.

There's no integration with the search or list view yet. If this turns out to be an approximately reasonable solution to the problem we can clean that up a bit in a future diff.

You must be a project member to watch a project.

Why? Isn't this up to the user? There are users that will not join a project (or will not have merits to join a project), but they will be happy to follow all its activity.

I mean, the current implementation is consistent with the request of this task, but maybe we can just broaden the scope.

We could separate them, but would need to do a lot of additional policy checks and it would involve some additional technical complexity.

Currently, we know subscribers/watchers can always view the project because they must be members, and membership grants visibility.

Additionally, engaging a project actively in an object also grants visibility (or, in cases where it doesn't, it should and it just isn't fully implemented yet).

So we know they can see the project because they're members, and know they can see the object because they have an active connection to it. We can therefor skip all the visibility checks.

If you did not need to be a project member to subscribe/watch, we would need to re-check every list member's ability to see the project every time we tried to use the subscriber or watcher list, and then separately check their ability to see the object, because we could not infer it. Expansion of project lists into email targets currently happens at a level far removed from object checks.

Currently, much of this also happen in-process, so execution of this logic blocks the action from completing. In cases where a project had a moderately large number of subscribers, these checks could conceivably take several seconds. This would manifest as "Submit" taking several seconds in Maniphest.

For other reasons, these things should move into the daemons, and the way these layers interact should change, so it would be more feasible to drop this requirement in the future.

Just to be clear: with the landing of D9185 does this mean if you watch a project, you also get email notifications for edits (or creation) on the project's wiki page as well as any subpage?

I'm also a bit confused with the definition of "members" of a project: does that entitle you to any notifications or it's purely for ACLs?

does this mean if you watch a project, you also get email notifications for edits (or creation) on the project's wiki page as well as any subpage?

No, D9185 only applies to tasks, and Phriction never sends email right now.

I'm also a bit confused with the definition of "members" of a project: does that entitle you to any notifications or it's purely for ACLs?

Yes, you'll get notified when the project is actively involved in an object: as a Subscriber/CC, Reviewer, Auditor (probably? This predates some of the recent rules and might need a tweak), in other roles in the future.

No, D9185 only applies to tasks, and Phriction never sends email right now.

Then what's the "Subscribe" button for on wiki docs?

Should I file a task to request email notifications on edits on wiki docs:

• to users who subscribe to said docs?
• to users who watch a project that "owns" these docs?

Also the copy for the prompt dialog when watching a project is not very clear:

Watching a project will let you monitor it closely. You will receive email and notifications about changes to every object associated with projects you watch.

I understood this as including wiki docs since it says "every object associated". If it's only tasks, it might be better to just say "tasks".