Page MenuHomePhabricator

Spaces request for Support and Safety
Closed, ResolvedPublic

Description

The Support and Safety team at the Wikimedia Foundation is looking to make use of Phabricator for incident tracking purposes.

The name for this space should be WMF-Support-Safety
The group lead is @Mdennis-WMF

Because these incidents often deal with sensitive information, we would be requesting to make the space and all its tasks accessible only to members of this team.

These are:

Event Timeline

Aklapper triaged this task as Medium priority.

Thanks for the request and interest in Phabricator!
Note the difference between having a Project with a workboard and in addition having a Space without a workboard (for default access restrictions for tasks in that Space). I guess you've already seen https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Requesting_a_Space so I plan to create this soon.

To be absolutely clear in communication regarding 'outsider' access to private tasks in a Space:

  • Obviously folks with shell access to the server which hosts the Phabricator database can access the database.
  • Phabricator admins (list) could make themselves members of the Space (and hence access private tasks in the Space) but you would see such a change in the web log and/or receive a notification about such a change. In theory such "could" access can be avoided if the SuSa team edits the policies after the Space has been created; in practice we've seen heads of teams leaving so we had to manually edit the database to be able to make Space setup changes. That's the intention behind allowing Phabricator admins to make themselves members of a Space.

I realize that a Trust-and-Safety project already exists. Do you plan to also use that workboard for this Space (as Spaces themselves do not have workboards)?
If so, no new project needs to get created and we will have to sort out the bug in T140897 before going ahead here...

I realize that a Trust-and-Safety project already exists. Do you plan to also use that workboard for this Space (as Spaces themselves do not have workboards)?

This comes down to if we want to have a public and a private project/workboard. I'm talking to @Jalexander about this just now and we're thinking that it may be best to begin a new, public project for "public" stuff and things assigned to us by other teams/users of Phabricator. Is that possible?

There are some members of the Trust-and-Safety project that would not have access to this requested space. How would we handle this?

If so, no new project needs to get created and we will have to sort out the bug in T140897 before going ahead here...

Looks like that's sorted :)

it may be best to begin a new, public project for "public" stuff and things assigned to us by other teams/users of Phabricator. Is that possible?

@jrbs: Yes, however I don't understand the intention. :) Isn't that exactly what the public existing Trust-and-Safety project is already about?

There are some members of the Trust-and-Safety project that would not have access to this requested space. How would we handle this?

A task can be associated to 0-∞ Projects. In addition, a task is always in exactly 1 Space. By default tasks are in Space S1 which is the only public Space.
When a task is in a private Space (means: any other Space than public default S1) it can only be seen and accessed by members of that Space. It's strict isolation - no matter who you add to CC or who authored the task.
So if you had a task which is in your private Space and in the existing public Trust-and-Safety Project, that task would only be displayed in search results and on the workboard of the public Trust-and-Safety Project to those users who are members of the private Space. (Same for task notifications etc.)
Members of the public Project who are not members of the private Space will only see public tasks in the public Project (in search results and on the Project's workboard), but no tasks which are both in the public Project and in the private Space.

Does that make things a bit clearer? :) I wonder how to document this on https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Restricting_access_via_Space_policies

it may be best to begin a new, public project for "public" stuff and things assigned to us by other teams/users of Phabricator. Is that possible?

@jrbs: Yes, however I don't understand the intention. :) Isn't that exactly what the public existing Trust-and-Safety project is already about?

Sort of. Clearly Support and Safety haven't used Phabricator in a while so there are some projects in there that may need reviewed (we can do this though!). E.g. software-focused stuff and user rights cases.

Does that make things a bit clearer? :) I wonder how to document this on https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Restricting_access_via_Space_policies

This is much clearer, thank you! I suppose I was expecting it to be less like a "tag" and more like an area of Phabricator itself (as "space" seems to indicate).

What are the next steps for moving forward here? I believe we'll use the existing project and go on from there.

the public existing Trust-and-Safety project

Sort of. Clearly Support and Safety haven't used Phabricator in a while so there are some projects in there that may need reviewed (we can do this though!). E.g. software-focused stuff and user rights cases.

Looks like we talk about <30 open tasks... I take this as a "we'll use the existing project and triage those tasks"? :)
How you want to organize the Project workboard is entirely up to your team - see the docs; Team-Practices are happy to help.
Two examples coming to my mind: Developer-Advocacy has a column "Team radar" for stuff we don't work on / drive but want to check periodically, use milestone subprojects per quarter with their own workboards (click the column headers to see), and assignees (you can filter the view per assignee in the upper right corner). And WMF-Legal uses "Backlog" / "Assigned" / "Legal done" workboard columns and don't assign tasks to themselves but keep the 'real' task owner intact. There's many ways.
For the records, the current columns on the project workboard were created by Jalexander (in case you want to discuss / change them).

What are the next steps for moving forward here? I believe we'll use the existing project and go on from there.

I'll create a Space for you in the next hours (need to run now, evening plans). :)

I take this as a "we'll use the existing project and triage those tasks"? :)

Please do :)

No rush on the Space, of course!

  • Regarding the project and its workboard:
  • Regarding the Space (a Space is not a project and hence there is no workboard):
    • For access control, created #acl*support_and_safety_policy_admins. This defines access to tasks in the Space.
    • Created the private Space S10 ("Support-and-Safety"). Its Join and Edit policy is intentionally set to #acl*support_and_safety_policy_admins and should not be changed.
    • @Mdennis-WMF can add/remove users (who can create and access tasks in S10) via editing the members of #acl*support_and_safety_policy_admins. Note that Phabricator admins could also add themselves (this is a fallback for when a team lead has left; we had that situation); if you watch #acl*support_and_safety_policy_admins project you'd get a notification about such an action.
    • Please do see Displaying and using a Space for more information (For example, when creating private tasks in that Space you must choose "Visible To: Space S10" in the task creation form to create private tasks only accessible to members of S10 and nobody else).
  • For convenience, created Herald Rule H178: If Space is set to S10, add project: Trust-and-Safety.
  • Documented the creation of S10 in T138677: Make a list of spaces we have, and who can access them.
  • Please ask if things are unclear. Happy to help you organize your work effectively.