Also see T108989 and https://www.mediawiki.org/wiki/Phabricator/Code#Wikimedia_Phabricator_bug_workflow

In T112040#1630288, @Aklapper wrote:

Also see T108989 and https://www.mediawiki.org/wiki/Phabricator/Code#Wikimedia_Phabricator_bug_workflow

Neither clarify the confusion reported in this task :)

ping :)

See also, my current proposal for the RelEng team, which echos much of my reasoning for this: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Phab_process_proposal

(NB: that proposal is also very similar in spirit to how the Reading team manages their tasks/projects: https://www.mediawiki.org/wiki/Reading/Web/Phabricator )

Looking back I'm wondering why the edit and join policy should be restricted at all for Phabricator. Currently the reason is that we also use it for some permissions stuff, e.g. currently Project-Admins is set to "Editable by Phabricator" and "Joinable by Phabricator, SRE, Security".

Creating a #Phabricator-Admins project sounds like duplication: An admin group (not: project) already exists in Phabricator's default implementation.
I wonder if we'd want to replace current group permissions using the "Phabricator" project by the admin group (but no idea how to find all projects that currently use Edit/View Policies based on current "Phabricator" membership) and then turn the actual Phabricator project into a normal component.

In T112040#1648956, @Aklapper wrote:

Looking back I'm wondering why the edit and join policy should be restricted at all for Phabricator. Currently the reason is that we also use it for some permissions stuff, e.g. currently Project-Admins is set to "Editable by Phabricator" and "Joinable by Phabricator, SRE, Security".

Question, as a Phab admin (but not in any of those 3 projects) could one join Project-Admins?

Creating a #Phabricator-Admins project sounds like duplication: An admin group (not: project) already exists in Phabricator's default implementation.

Didn't think of that. Good point.

I wonder if we'd want to replace current group permissions using the "Phabricator" project by the admin group (but no idea how to find all projects that currently use Edit/View Policies based on current "Phabricator" membership) and then turn the actual Phabricator project into a normal component.

+1. I guess let's do a best effort (I'd need your guidance here, I can't think of anything other than Project-Admins) and then JFDI and then fix anything that breaks.

In T112040#1649360, @greg wrote:

In T112040#1648956, @Aklapper wrote:

I wonder if we'd want to replace current group permissions using the "Phabricator" project by the admin group (but no idea how to find all projects that currently use Edit/View Policies based on current "Phabricator" membership) and then turn the actual Phabricator project into a normal component.

+1. I guess let's do a best effort (I'd need your guidance here, I can't think of anything other than Project-Admins) and then JFDI and then fix anything that breaks.

ping :)

Andre, would you like to have a call about this? See what I can do to help with the transition?

In T112040#1682386, @greg wrote:

Andre, would you like to have a call about this? See what I can do to help with the transition?

@greg: Could have a call but if I'm afraid I'd be as clueless (e.g. your question in T112040#1649360) as in this written conversation because there's lots of other stuff that is more urgent and has deadlines. Preparation to do this right and understand what we're doing vs. end of quarter. :(

Uh, and there is also #acl*phabricator adding more ingredients to the mix, sigh

Wouldn't it be helpful if you could list policies referring to an object and find out what uses those policIes? I imagine someone with database access could manage it...

In T112040#1696741, @Aklapper wrote:

Uh, and there is also #acl*phabricator adding more ingredients to the mix, sigh

Is that redundant with Phab Admins as well? But it also seems like that could stay around if needed, and any permissions that were once managed by Phabricator could instead be managed by #acl*phabricator (in my mind making this even easier).

In T112040#1696756, @Krenair wrote:

Wouldn't it be helpful if you could list policies referring to an object and find out what uses those policIes? I imagine someone with database access could manage it...

yes please... :)

I say we should follow the steps that @chasemp and @RobH took for operations:
https://phabricator.wikimedia.org/T114135#1743376

See also: https://phabricator.wikimedia.org/diffusion/PHTO/browse/master/project_merge.py

just a note that this exists https://phabricator.wikimedia.org/project/view/1081/

@Aklapper: wanna pair on this today? :) :) :) :)

@greg: which parts aren't done?

There probably isn't much need for a phabricator-admins group/project since, as pointed out, there is already an admin flag built in to phabricator separate from projects.

There isn't really a phabricator team, either so not much need for a team project.

Gah! They are?! I just saw it turned to a component (not team).

<3

In T112040#1697397, @greg wrote:

In T112040#1696756, @Krenair wrote:

Wouldn't it be helpful if you could list policies referring to an object and find out what uses those policIes? I imagine someone with database access could manage it...

yes please... :)

I filed https://secure.phabricator.com/T10472

I also found a load of objects where this was not completely dealt with in this case, and updated edit policies on the following objects: W1, W2, W3, W4, W5, W6, W7, W8, W9, W10, W16, W128, W180, W599