Page MenuHomePhabricator

Allow the use of team projects as representation of teams
Open, MediumPublic


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 Notice, and then click on, the helpfully named and provided "My Teams". Mine looks like:

Selection_097.png (488×320 px, 33 KB)

There are multiple problems indicated by that screenshot.

  1. The Phabricator project is confusing, see: T112040: Clarify #Phabricator project confusion
  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.


  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 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
    • 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.
  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).

Event Timeline

greg raised the priority of this task from to Needs Triage.
greg updated the task description. (Show Details)
greg added projects: Phabricator, Project-Admins.
greg added subscribers: greg, Aklapper.
Restricted Application added subscribers: StudiesWorld, Luke081515, scfc. · View Herald Transcript
greg set Security to None.
Krenair claimed this task.
Krenair added a subscriber: Krenair.

ACLs should never be tied to the WMF org chart.

Krenair, please have a discussion and not a knee-jerk reaction.

I didn't say they *had* to be. But there is such a thing as the Release Engineering Team, and you aren't on it. Other Team or ACL projects can have wider membership rules.

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.

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.

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

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:

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.

Aklapper triaged this task as Medium priority.Feb 9 2016, 11:01 PM

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.