The concern here is users watching or subscribing to projects (like "Security") which they may have permission to see, but not to join. In particular, we are likely to allow subscribers to punch through policies in the future (T4411), which probably means project subscribers should get the same exception. It's very bad if anyone can subscribe to any project, and subscribing to a project means you can see anything the project is subscribed to.

A more correct way to implement the policy exception is to provide it only for project members, but that adds a level of complexity to the ruleset, where sometimes "being subscribed" matters and other times "being a member" matters.

A general future concern is that if you create, say, a Conpherence and invite some project (after T5364), we should only be inviting members, but then subscribe/watch sometimes work and sometimes don't.

I think there's no clear way forward here yet. The current ruleset give us the most flexibility going forward, and we could relax who is allowed to subscribe or watch later. It's harder to put the genie back in the bottle.

Ok, technical problem understood.

/me goes to write basic Herald documentation for new Wikimedia Phabricator users. :)

As anticipated, there is notable community demand for this feature in Wikimedia : https://phabricator.wikimedia.org/T77228

In fact, the strong community demand is to identify members of projects as "members", and sometimes assign policies to these members. In installations like this one there is less need for this, because there is only one team of maintainers, and whenever an object needs to be restricted, it is probably the same team who gets included in the policy. In our cases we have dozens of teams, each controlling different things. There is also a bigger need to know who is really member of a project, who should I CC when my task is languishing, or when we need an opinion from project X? Here in case of doubt you add three users and you are done.

But... of course, if the price of restricting Can Join to the actual members of the team implies losing watchers from other teams and the community at large... That is an expensive price to pay. You want eyes watching your open source project, as many as possible. Sure, they can create Herald rules, but it is clear that only a portion of users willing to click "Watch" will go down the route of knowing what is Herald and how to create a personal rule.

If the main problem of watchers is receiving notifications that you shouldn't receive, then how complex would it be to implement a policy check before sending the notification?

PS: in order to make the discussion a bit simpler, let's focus on watchers only.

Creating restricted-join projects (or perhaps duplicate projects so one can be used for ACL, and the other for grouping objects) on Wikimedia will have to get a lot harder unless this can be fixed.

Would you be able to give a rough estimate for paid prioritization of this task?

Looking at this again, it's actually less problematic to change than I originally believed.

It would mean that "watching" a project notifies you about only some objects (those objects you could otherwise already see). I think this is reasonable and will almost always align with user expectation, but it may occasionally cause some confusion.

We should possibly consider merging the concepts of "subscribing" (being notified of updates to the project itself) and "watching" (being notified of updates to things that are associated with the project) but these concepts still feel distinct-enough to keep separate, and there will probably be more reason to separate them in the future (i.e., projects are likely to acquire more types of updates in the future, not fewer).

It's possible that I'm missing something, but I think we have enough clarity around likely future policy changes in T4411 and T6367 to implement this safely without needing to backtrack later. Other product ideas (like how Conpherence rooms work) have also stabilized.

That said, we definitely should fix T7703 before this. This is 1-2 hours of work after T7703 is resolved.