Thanks for realizing this and taking the time to create a task about it! Appreciated.

I'm not convinced this should be fixed by the proposed solution. Stuff I could imagine (but no option convinces me):

• adding "Allow subscribers" to "Can View" at https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/edit/23/ (easiest, but that would destroy the concept that WMF-NDA tasks are restricted to folks who have an NDA, plus opens potential security-related loopholes who could access such tasks),
• thinking harder if T107136: Allow OIT to make new WMF employees members of the #WMF-NDA Phabricator project as part of their onboarding process is possible but I don't see a feasible workflow to implement that (a person is supposed to create their Phab account themselves, plus not possible for WMF ITS to impersonate that person's SUL or LDAP account when creating a Phab account which requires linking to a SUL or LDAP account),
• considering custom code which triggers "you mentioned an account but the account cannot access this task" (likely too complex, error-prone, not a good idea).

In T272476#6765016, @Aklapper wrote:

Thanks for realizing this and taking the time to create a task about it! Appreciated.

I'm not convinced this should be fixed by the proposed solution. Stuff I could imagine (but no option convinces me):

• adding "Allow subscribers" to "Can View" at https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/edit/23/ (easiest, but that would destroy the concept that WMF-NDA tasks are restricted to folks who have an NDA, plus opens potential security-related loopholes who could access such tasks),

The most common type of private tasks are security-protected, which allows subscribers. I believe it makes sense to do it with WMF-NDA tasks as well, considering they often overlap and people shouldn't need to check the policy to learn what actually will happen. So, I think we should standardize it at the very least. Since restricting security tasks to only acl*security is not feasible (some teams have 0 people with such access, relying on secteam or people with access to ping them; if there's a sec-issue in a toolforge tool, it needs the maintainer to see it, ...), I think this is a better way, as subscribing a person is easy, changing the visibility policy is not-so-easy.

• thinking harder if T107136: Allow OIT to make new WMF employees members of the #WMF-NDA Phabricator project as part of their onboarding process is possible but I don't see a feasible workflow to implement that (a person is supposed to create their Phab account themselves, plus not possible for WMF ITS to impersonate that person's SUL or LDAP account when creating a Phab account which requires linking to a SUL or LDAP account),

Personally, I don't think that should happen. While they do have a NDA (all employees/contractors do), all privileged access should be based on need-to-know basis too :). The group should probably be renamed, but that's out of scope.

• considering custom code which triggers "you mentioned an account but the account cannot access this task" (likely too complex, error-prone, not a good idea).

Would probably work, through it's way more complex than other solutions.

I think the issue in this specific example is that for a task like T272470 WMF-NDA is simply not the right group.

It goes both directions, why would all staff and NDAed volunteers need access to that ticket and why would the _only_ person who needs to act on it, the subscriber, not be able to see it? That seems to make no sense.

The only reason that was picked is probably because the ticket creator wanted it to be "not public" in one way or another.

Next is the question _why_ that couldn't be public. Either the reason is security, then it should be handled like other security tickets, where subscriber are allowed as Urbanecm already pointed out.

Or there is actually no reason that had to be hidden (personally I tend towards that), then it should just be a regular public ticket.

Or there is another (social) reason and then a custom policy can be used. And the ticket has meanwhile already been edited to do exactly that and use a custom policy.

In general I can't think of many types of tickets where the current WMF-NDA group really is the most appropriate one. Maybe the answer is to have a simple way to turn a ticket into "not public, only all subscribers can see it" that is not related to NDAs and doesn't require users to handle it via "custom policy".

Taking a step back (and maybe derailing?): IIRC we use(d) WMF-NDA for tasks imported from RT in the 2014 RT-Migration (see e.g. T676#932059).

Is it nowadays a common use case that folks want to create a task with the (1) initial task view criterion being (2) to have an NDA itself in place,
(1) in contrast to misc "I don't want this task to be entirely public for some reasons but I either could not figure out how to restrict access or I cannot restrict as I am not a member of some ACL project, so I'll simply (ab)use the NDA or Security task creation forms as a quick workaround", and (2) given other existing ACL projects now?

IIRC we use(d) WMF-NDA for tasks imported from RT in the 2014

Yea, but the only reason I know of was "in case there were some tickets that need to stay private" and the work to actually audit and decide which of these have no reason to be private (most of them) and can be published is still open until today because the shortcut was taken back then.

In T272476#6766992, @Aklapper wrote:

Is it nowadays a common use case that folks want to create a task with the (1) initial task view criterion being (2) to have an NDA itself in place

I don't think it even was back then, tbh.

(1) in contrast to misc "I don't want this task to be entirely public for some reasons but I either could not figure out how to restrict access or I cannot restrict as I am not a member of some ACL project, so I'll simply (ab)use the NDA or Security task creation forms as a quick workaround", and (2) given other existing ACL projects now?

Yes, pretty sure that is almost all the cases with very few exceptions.