**This is still an in-progress (improving, not done) proposal. Imagine an underconstruction gif here.**
Looking at the state of team projects I fear we are doing two things:
1) over-complicating things with our separate *acl projects.
** In other words: Team projects already existed, we didn't need to create *acl projects (except in corner cases, potentially, but I can't think of one, especially one that needs such an ugly/confusing name)
2) confusing "teams" with "ares of responsibility".
** This is especially confusing to newcomers and those not intimately familiar with the (always changing) WMF orgchart
Take a look at https://phabricator.wikimedia.org/project/. Notice, and then click on, the helpfully named and provided "My Teams". Mine looks like:
{F3313970}
There are multiple problems indicated by that screenshot.
1) The #Phabricator project is confusing, see: {T112040}
2) 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)
3) (not explicit in the screenshot but related to the above) People are currently joining -Team projects to watch areas of responsibility (see eg members #Release-Engineering-Team)
In summary, we aren't using Team projects as effectively as we could.
**Proposal**
1) Allow "-Team" projects to have restricted membership
** Of course, not all would. I could see some that don't restrict membership
** This would allow -Team projects to be used in places where you care about acls without having to create a (seemingly) redundant project and without having to create ugly *acl projects which are confusing to users when they see them
*** This would clear up confusion that is even seen by those intimately familiar with Phabricator. We (RelEng) created a software package and made the wrong project the owner of it (see https://phabricator.wikimedia.org/owners/package/2/#13). And now you see an ugly/confusing: "Owners: acl*releng" on that package.
** The visibility of *acl projects will only increase as we use more functionality of Phabricator (eg: Differential and Audit).
** I would recommend a requirement for the "-team" suffix, to make it clear
2) -Team projects that currently act as BOTH team projects AND general areas of responsibility should have projects created for that general area of responsibility
** eg: in the case of #Release-Engineering-Team we would create "#'Release-Engineering" and that would be a project, not a team
** #Operations would be the general area project while eg #Operations-Team would be the team
** Luckily, everyone wouldn't need to change everything right away; #operations could stay as it is if that's fine with them, but any new projects should follow the proposed solution.
3) #Phabricator should never have been a "team" and would become a component, as it should be. See, again, T112040.
** Yes, we might still need something like #Phabricator-Team, so let's make that if we do (my proposal is #Phabricator-Admins, to be clear about what the scope is, and since there's no real "Phabricator Team", just people interested in/helping with Phabricator, who would all join/watch #Phabricator).