Context: Wikimedia has hundreds of projects, technically we could set manually permissions for Project "Foo" specific to Team "Foo", but we'd rather define a policy based on Project(x) permissions given to Team(x).

Is this already possible in Phabricator and I'm just blind? It's somewhat strange that we are the first ones requesting this feature.

T3820 has some general discussion of why projects do not currently imply policies directly. In particular, an object can be in multiple projects in Phabricator, which tends to complicate anything in this vein.

Some issues that would arise with a "Project Members" setting, offhand:

• You would also need to lock the projects field itself, to prevent a user from adding a task to a project like "epriestley loves prioritizing things", then re-prioritizing tasks (since the user is now a member of one of the projects the task is in).
• If you lock the projects field, legitimate administrators of the "Goats" project can't put an existing task in "Goats" because they won't have edit permission for the field.
• If the user filing the task can edit the projects field, he or she can add "epriestley loves prioritizing things" and then prioritize it. If they can't, they can't meaningfully categorize the task.

A coarse solution is to create a project called "Users Who Can Prioritize Tasks", set that as the policy, and add anyone who should be able to edit priorities to that project.

T3820 might offer more fine-grained solutions here, by letting you separate projects across namespaces, although that's not completely fleshed out.

I think no one has requested this because most projects have highly-trusted users (e.g., employees) and may have relatively-untrusted users (e.g., contractors, clients, contributors) but it's rare to have somewhat-trusted users (presumably, volunteers who have seniority in project X but shouldn't be allowed to touch project Y?).

I'm not sure if T3820 will offer a good solution to this problem or not, but I think a "Project Members" setting is probably not the right way forward here.

I see. So far my concern has been theoretical. If we do have a real problem one day, probably the long-term solution will be a workflow that you can find in many membership sites:

1. User requests joining a team.
2. Any admin or any team member can accept/ignore.

This way users cannot just walk in to a team, but they cannot be forced to join a team either.

It is fine if you wontfix this task (or merge it with T3820). I might revisit it in the future, if we run in a situation where the current system of distribution permissions doesn't scale.

We had thought about an EditTasks group, just like we have an EditBugs group in Bugzilla. We can work out an initial configuration based on it, allow exceptions for projects with more restrictive requirements, and see how it goes.

A coarse solution is to create a project called "Users Who Can Prioritize Tasks", set that as the policy, and add anyone who should be able to edit priorities to that project.

I think I mentioned this in T6502, that is having a more generalized "Users Who Can Plan Tasks" which would encompass Workboards and Priority might be a good solution. Of course my language isn't completely perfect.

Workboards and Priority are something I'd likely want on this install as well. I don't think they need to be two separate Policies.