Page MenuHomePhabricator

Clarify #Phabricator project confusion
Closed, ResolvedPublic

Description

The Phabricator project is confusing:

  1. The name implies its for issues related to Phabricator itself, which is fine and good and actually, I suggest, what it should be
  2. It has the coloring/icon of a team (confusing with 1)
  3. It is used for permission management (and is thus a locked project)

My proposal:

  1. Make a #Phabricator-Admins team project that is 2 and 3 from above
  2. Make Phabricator a component project (blue and briefcasae) and remove the join lock and the permissions

Why?
Because we need a place for tasks about Phabricator, which Phabricator (the team project) now house. The confusion is "Why is this thing that has a bunch of tasks that make it look like a component project colored and icon'd like a team one?" Let's make things clear for everyone (if it confuses me and makes me have that "eh?" feeling, something is odd about it).

Event Timeline

greg created this task.Sep 10 2015, 4:50 AM
greg raised the priority of this task from to Needs Triage.
greg updated the task description. (Show Details)
greg added a project: Project-Admins.
greg added subscribers: greg, Aklapper.

Generally, let's get better about the distinction between "team" projects and "software component" projects. This is a (quite visible) example of where they are conflated in a confusing way.

greg added a comment.Sep 16 2015, 3:43 PM

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, Operations, 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.

greg added a comment.Sep 17 2015, 3:17 PM

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, Operations, 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.

greg added a comment.Sep 24 2015, 1:55 AM

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 :)

greg added a comment.Sep 28 2015, 7:39 PM

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

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

greg added a comment.Oct 2 2015, 4:05 PM

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

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

greg added a comment.Jan 6 2016, 7:36 PM

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

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptJan 6 2016, 7:36 PM
Luke081515 closed this task as Resolved.Feb 27 2016, 12:07 PM
Luke081515 added a subscriber: Luke081515.

I think we have #acl*phabricator now, so we can close this.

greg reopened this task as Open.Feb 27 2016, 5:34 PM
greg triaged this task as Normal priority.
greg set Security to None.

Not yet, the other bits are not done.

mmodell added a subscriber: mmodell.EditedFeb 27 2016, 7:44 PM

@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.

greg added a comment.Feb 28 2016, 12:03 AM

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

<3

greg closed this task as Resolved.Feb 28 2016, 3:44 PM
Krenair added a comment.EditedFeb 28 2016, 9:36 PM

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