Did the test of the NDA volunteer process work?

If you go to the Operations tag page at

https://phabricator.wikimedia.org/tag/operations/

can you "Watch Project" or "Subscribe" there?

that was before the migration, and at the time, it worked.

None of them.

When I go to https://phabricator.wikimedia.org/tag/operations/ , "Join Project" and "Edit Members" is greyed out for me as I am not a member of the "operations" project: Project is only Editable By and Joinable By "operations".
Description there says "This group should reflect the 'ops' group in admin.yaml." and I wonder where "admin.yaml" is (URL please!) and if I can access it (making it a link in the description might not be the worst idea, but again, only operations member can edit it).

Question "Did the test of the NDA volunteer process work?" is still open I think?

I guess it refers to: https://git.wikimedia.org/blob/operations%2Fpuppet.git/e568e9aa26b8abfa4b8cbb0ceaba7d2497d39b11/modules%2Fadmin%2Fdata%2Fdata.yaml

So yeah this is a side effect of how we are organizing things. A few thoughts.

1. T77228: Let non-members watch projects -- I think we need this on our install honestly and we should push for it. A way to follow a project for things that you have perms to access.

2. We can't just add a dummy user that is a mailing list as it would violate all of the ACL's set up to allow only Ops members

3. The feed at least is useful (and honestly is what I read) https://phabricator.wikimedia.org/feed/query/5HnR.xAOCaYN/#R

Can we amend the policy to say "this should reflect users in admin.yaml .. and NDAed volunteers" or similar and then add him as a watching member?

Nooooooo....well maybe. We can't effectively use SRE as an ACL object if it has non-ops people I think. It would create a very non-intuitive situation (at least for me). Probably deserving of some more team discussion.

The problem for me is that we had some folks on the general ops queues in RT and suddenly they are being told now, "No thanks". One of our reasons for liking the move to phab was, I thought, wanting to open things up more, making queues publically visible and so on. Doing that but at the same time removing subscription/editing rights from trusted volunteers seems a bit silly. So I'd like to see how we can _at least_ preserve folks' access from RT, even if that means shuffling things around a bit.

So I'd like to see how we can _at least_ preserve folks' access from RT

Technically, past: I added folks which have/had web access to RT to the WMF-NDA group in Phabricator. I have no clue about RT's underlying mailing list setup stuff though...
Socially, present: Might need more discussion among Ops how open things can/should be?
Technically, future: Depends on "Socially" part above?

In T89053#1049211, @ArielGlenn wrote:

The problem for me is that we had some folks on the general ops queues in RT and suddenly they are being told now, "No thanks". One of our reasons for liking the move to phab was, I thought, wanting to open things up more, making queues publically visible and so on. Doing that but at the same time removing subscription/editing rights from trusted volunteers seems a bit silly. So I'd like to see how we can _at least_ preserve folks' access from RT, even if that means shuffling things around a bit.

I totally agree on the last bit, but I wanted to (hopefully?) help and clarify what is going on here as far as I understand it. I think the "no thanks" part of this isn't accurate or fair to say really.

All things from RT were given policy limited to WMF-NDA. We have been using the SRE project to group things at the moment. The problem is SRE is used in a few places within Phabricator, mostly at the global config level for taking certain actions, and in order to be effective in that way has to be limited. That doesn't mean exclude @Matanya, but that does mean including him should be a really conscious decision. But either way with this, it's not preventing someone not in SRE from seeing anything that came from RT, nor should it be preventing them from seeing anything relevant in Phabricator. The "confidential issue" field in security does not hide things to SRE at all, it uses WMF-NDA as well. My understanding is that we are all using WMF-NDA and that it's the inclusive way to protect content. If people are using SRE as an ACL in a way we shouldn't, then that's an education and consensus thing, but it's not intended.

So the lack here isn't access, it's ease of notification. Any volunteer can watch the /feed using SRE as a filter, and they can subscribe to any issues they want updates for. The thing they can't do is get updates by default with the SRE tag, which I agree is crappy at this moment. But it's a big difference between we are keeping people out, and we haven't figured out the best way to easily notify.

We could shuffle things a few ways, we could stop using SRE as an ACL object, which means we need a new thing to serve that purpose. Which may be the best idea. We could enable Herald, at least for WMF-NDA and that would allow these folks to set up emails for anything with SRE tag without being to join it. Either thing I think is reasonable.

Thanks Chase, that's useful. Where do we use SRE used as an ACL object?

In T89053#1049974, @faidon wrote:

Thanks Chase, that's useful. Where do we use SRE used as an ACL object?

So we use it for project creation and policy manipulation, originally it was also used for Operations specific security items. We also have planned to use it for the vendor/procurement communications stuff.

Maybe:

• We just say ops ppl need to join Security for policy
• Ops ppl need to join project-creators like everyone else
• we make an acl object to use in the vendor/procurement case.
• we open up SRE and make it clear WMF-NDA is the right thing to use for restriction unless it's Security

I've been thinking about this a bit actually as fundraising has a similar problem we are thinking of solving by creating an obfuscated ACL object only grouping that won't be discoverable, etc. https://phabricator.wikimedia.org/T88762#1048335

I'm leaning towards all "groups" being open and making any project that is policy oriented use the policy icon and never used for task association. Still a burgeoning thought though.

The other solution is to make an open project always follow SRE via herald which is ugly and hate it. But technically possible.

Well, first of all:

• I'm not sure if there's much value for every opsen to be in Security. There are a few people in the team that should be in there but I don't see membership in SRE as implying Security access.
• I feel even more strongly about being in #Project-Creator by default. Why is that the case?
• Vendors/procurement… I'm not sure yet. Perhaps even WMF-NDA could be enough. We have to discuss this a bit first.

All that said, opening up #operations… I don't know, I think it is useful to know who's actually part of the team (staff or not!) and who's watching a project for updates. Having watchers be a subset of members doesn't make much sense to me, even less so in an open Phabricator instance such as ours. Moreover, I think the current situation with subcribers/watchers is super confusing, so maybe this is something that we can/should raise upstream and perhaps even provide patches for?

• No real opinion on all ops folks in Security or not, the idea here is that Security and SRE give policy management so if we strip SRE of its current context we have to do something else there.
• Not sure what you mean by default, there are three groups that can create projects. Members of Project-Admins, SRE, and adminstrators. If we make SRE membership not meaningful then we have to do something else there. Such as anyone in ops who wants to create projects can join Project-Admins. I'm don't know why this would be a problem? Other than it's more stuff to keep track of.
• Vendors stuff from talking with @RobH my impression was WMF-NDA was indeed too broad.

On upstream, we have talked to them about this a few times. There is a ticket here https://secure.phabricator.com/T6183, but I have asked outside of that, and I know a few others have. The long story short is, they do not plan on changing this scheme because it creates a lot of cases they don't want to handle. I think the sanest thing may be to move away from using people projects as ACL objects as we have a few of this same case. I am scheduling a call with the other Phabricator people to talk about how to handle this across the board.

Maybe members of a project should be a subset of the watchers, rather than the other way around.

I don't think Operations should (automatically) be project creators.

There has been quite some discussion about (how much) to broaden that group and historically the same concerns have come up on Bugzilla about creating components. (T706).

If you are in Operations and you only need a new project every once in a while i think you are better off just asking for it like everybody else and let one of the project creators do it. If you "just do it" there is a high chance you will have follow-ups about naming schemes etc.

If you think you are going to need new projects on a regular basis, you can still ask to be added like several others did on T706. But that might also mean to get requests to create projects for others.

Also, when i wanted a new project i made a task for it and then was surprised that i can do it myself because i didn't think i was in project creators.

I noticed after my update there are long standing discussions about policy involving project creation, however it seems outside of scope of this particular task, and more on point for parent task T90491.

If others disagree simply reopen the task. Thanks!