In T126055#2003480, @greg wrote:

But there is such a thing as the Release Engineering Team, and you aren't on it.

That really doesn't justify restricting Phabricator project membership.

You're going to need to give reasons instead of just statements that you think are facts.

Okay, as you can tell from the above, I strongly object to most of this, but let's start from the beginning. Yes, I agree that the current situation is confusing and a big mess. However, the big problem here is the difference between a 'team' of individuals with rights to do things and the foundation orgchart teams which organise paid staff work.

In T126055#2003480, @greg wrote:

But there is such a thing as the Release Engineering Team, and you aren't on it.

I don't get what point you're trying to make with this, not being on a particular foundation team doesn't mean you should not be part of an associated phabricator project.

It says I'm a part of Security-Team when really I'm not (I don't report to Chris Steipp and should not have rights/permissions that would be given to Security Team members)

Security has actual rights to do things (specifically, it's used to restrict access to security tasks and it's members have the ability to edit task policies across the whole of Maniphest - it also has gives random things like the ability to self-join Project-Admins), and includes various different people from various different organisations and, in some cases, no (relevant) organisation. And there is Security-Team, which is supposed to be for publicly planning tasks to be carried out by the Foundation's Security team. The distinction between these is important. There is no need to lock down Security-Team as it does not automatically grant any access. Security Team members should not automatically be given any access - they should have to be added to the same Security group which includes everyone else (basically: you should not be giving out rights purely on a per-team basis to the complete exclusion of wikimedia volunteers).

We don't strictly need to call ACL projects "acl*". Projects should be cleaned up on a case-by-case basis.
Phabricator is one of them. We could have a component Phabricator project in which tasks about our use of Phabricator are held, a #Phabricator-Admins project used for ACL purposes, and the existing Phabricator (Upstream).
Security could be split out into #Security-Public (tag?), #Security-Private (red ACL lock), with Security-Team being #Foundation-Security-Team-Planning (team, NO privileges or restrictions).

Oh also, maybe we should use a prefix like 'Foundation-' for projects specifically for Foundation team planning, I think the other Wikimedia organisations with phab projects have something similar.

That all said, I do like the sound of the idea of more clearly separating foundation teams from the areas of responsibility under which they operate.

I feel like I've written far too much already. tl;dr: cleaning up projects yay, excluding volunteers by restricting some (more?) projects/rights to staff teams nay
(personal opinion from mixed-role account, etc.)

The reason for the acl* projects was to clearly separate access rights from team membership and project planning. acl* may be ugly but the idea was that we can filter them from the normal UI places so that you only see acl* projects in the security policy UI. See T95950

Yeah, I should have toned down some of my language in my description of the issue; my apologies.

My proposal above isn't fully baked yet (needs improvement) and I plan to incorporate some of Krenair's feedback, just, not today.

I do like the idea of team projects using the suffix -Team, and we can change the acl* convention to something less ugly, or actually implement T95950: List acl* projects at the bottom of project lists

Phabricator and Security are leftovers that don't follow current conventions. Originally Phabricator was a team, now that doesn't make as much sense. Phabricator should be a regular project.

Now that I think of it, I can implement T95950 based on the icon rather than a name prefix, so acl* can go away.

I can only offer some historical perspective.

tldr; the idea was to create policy objects that should never be used in any other context, and equally say that objects not meant for policy should not be used as such.

Originally, SRE was done in this fashion, which is the most obvious approach (-team or not would be semantics at this level I think). We ran into volunteers not being able to equally participate in our workflow. They couldn't join the project as we were using it to ACL things, and seldom did those things being ACL'd need more protection than "WMF-NDA" in reality. I think it's now possible to follow a project without membership? Although, that still is 'separate but sort-of equal'. I'm not sure how CC'ing a project or various interactions follow through. We didn't need every team or group to have their own ACL to hide and protect things, as very few things should be hidden etc.

The acl convention was created because:

• We needed a way to communicate that this object is a security object as the mixing of security objects and adhoc groups had become really messy and not-ideal and people don't have a firm grasp of the what and the why of it

• People continually 'hide' things without understanding what they are doing and it's difficult to unravel, especially since it affects admins in the same way as normal users. i.e. if you use something not acl*foo as a policy object we know we can undo it. you have done the wrong thing. (which is except Security because that is a whole other story...and then also yep WMF-NDA)

• We needed a way to have objects that can be explicitly used for policy, while containing and classifying them in a hard and fast way. They are by nature exclusionary which was seen as a thing not in-line with values in most cases. We were trying to whitelist the methods by which things were removed from public view legitimately. The idea was to not include these in type-head suggestion to reduce confusion. In theory, we have a finite group of folks who can manipulate security in the main space and they should know what they are doing to the extent that we can remove the confusing parts for normal users.

• At the time, very few real ACL use cases existed and a handful of ugly groups easily recognized seemed like the best of bad options

I don't know what the best end game here is, other than it should be consistent (more so than now would be great) and inclusive for volunteers as much as possible. I'm not sure what the difference between SRE and #operations-team would be. If I found myself using #operations-team I would (in the cases I can think of) be better off using WMF-NDA or SRE. It's funny but the actual acl in use in some few contexts for SRE is #acl*operations-team, but I haven't found myself lacking an #operations-team grouping for normal use. #acl*operations-team is pretty much entirely limited to procurement I believe. If #operations-team is meant as a convention oriented policy object candidate ala acl*operations-team maybe the idea is just to ditch acl* entirely in favor of '-team'. The standalone '-team' moniker may have the same issues we have seen before where people use the restrictive object in places that would not be beneficial to community members. It's worth noting that the dual identifiers of *lock icon* and acl* prefix were introduced as several places in the UI did not show the icon. I'm not sure if this is different now, but I have seen it more consistently.

There is another component here worth considering, which is the spaces functionality. When much of this was tried it did not exist, but now we use it for procurement. We have fundraising folks in phabricator now who (I think) would benefit from moving into their own space, and possibly community liason's as well. Currently, they use an acl* policy object and templates together to mimic something close to the functionality from when it did not exist. The landscape of security things in phab has changed pretty dramatically in the last 9 months or so.

https://phabricator.wikimedia.org/project/query/.56Kqk_sr48z/#R

First, sorry, I should not have posted this task without sitting on it for a few days, I obviously wrote it badly.

In T126055#2007953, @chasemp wrote:

I can only offer some historical perspective.

tldr; the idea was to create policy objects that should never be used in any other context, and equally say that objects not meant for policy should not be used as such.

The only main concern I have with creating policy projects that are segregated in some places but not others makes the places where they aren't segregated very unnatural looking. The main example I had in my mind while writing this originally: https://phabricator.wikimedia.org/owners/package/2/

I have more thoughts on this, and maybe the start of a way forward, but, I wish I could go back to Friday afternoon and not post this. Sorry.

Item #2 basically describes T271292: Phab PM: Document why not to only use team project tags but also codebase project tags
Item #3 is resolved

I would recommend a requirement for the "-team" suffix, to make it clear

I'd highly welcome that, also for wiki page names.