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:
- 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)
- 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:
There are multiple problems indicated by that screenshot.
- The Phabricator project is confusing, see: T112040: Clarify #Phabricator project confusion
- 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)
- (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.
- 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
- -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
- SRE would be the general area project while eg #Operations-Team would be the team
- Luckily, everyone wouldn't need to change everything right away; SRE could stay as it is if that's fine with them, but any new projects should follow the proposed solution.
- 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).