I was subscribed to ops-core and ops-request, but since they were merged into the general operation tag i lost that capability, which makes it somwhat hard for me to track opsen activity. Please help me :)
|Resolved||• atgo||T88762 Enable select Fundraising people to modify policy for tasks|
|Resolved||RobH||T89053 unable to subscribe to operations tag after migration and merge from ops-core and ops-request|
|Resolved||chasemp||T90491 Create policy projects and convert people projects to open|
|Resolved||RobH||T114135 create acl*operationsteam & acl*procurement projects, cease using #operations for access control|
|Resolved||None||T112040 Clarify #Phabricator project confusion|
|Open||None||T126953 Convert (confusing) #Triagers to #acl*Batch-Editors or similar|
|Declined||mmodell||T95950 List acl* projects at the bottom of project lists|
- Mentioned In
- T90491: Create policy projects and convert people projects to open
- Mentioned Here
- T90491: Create policy projects and convert people projects to open
T114135: create acl*operationsteam & acl*procurement projects, cease using #operations for access control
T706: Requests for addition to the #acl*Project-Admins group (in comments)
T77228: Let non-members watch projects
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?
So yeah this is a side effect of how we are organizing things. A few thoughts.
- 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.
- 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
- The feed at least is useful (and honestly is what I read) https://phabricator.wikimedia.org/feed/query/5HnR.xAOCaYN/#R
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?
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 Operations project to group things at the moment. The problem is Operations 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 Operations 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 Operations 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 Operations 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 Operations 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 Operations 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 Operations 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 Operations tag without being to join it. Either thing I think is reasonable.
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.
- 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 Operations 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.
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 Operations 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 Operations give policy management so if we strip Operations 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, Operations, and adminstrators. If we make Operations 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.
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.