General feedback from @swisspol:

1. Spaces in themselves are not complicated to understand (just needs a bit of UI polish for integration in apps).
2. Visible To / Editable By are not complicated to understand either, I completely agree.
3. The *combination* of the 2 is complex: case in point the amount of explanation needed in "Space Policies” in https://secure.phabricator.com/book/phabricator/article/spaces/.

I would argue this is very powerful but needlessly complex for the average user: even tech people *cannot* know out of the box how these things interact together unless you read the docs. I’ll bet you lunch that showing this to the majority of tech people (phab users or not) results in them not being able to understand at a glance how this works - it truly is confusing:

Then you say spaces make it more reliable to enforce policies across the board and less error-prone, but not really: because visible to / editable by are still here, you can still get it wrong: e.g. someone sets them to something else than “all users” in a restricted space, then other people need access, that author changes the space: it still doesn’t work.

I would point out that the model of visible / editable by is simple and elegant. Same for a pure space model (i.e. no visible / editable by) which happens to be ideal for organizations that want easy/can’t-shoot-yourself-in-the-foot access control. The current space model is probably for orgs that have quite more complex access control requirements. I’m not suggesting to this take this off, just add a middle ground which I’m betting plenty of users would be happy with :)

I love Phab because it’s elegant, professional, reliable *and* doesn’t make it easy for average users to shoot themselves in the foot. IMO Spaces are not there yet.

@swisspol nails it.

I also find it especially difficult to explain to my users the destinction between Project-based Policies and Project-based Spaces. As I understand it: Apart from the hard guarantees that Spaces make and the resulting behaviour for one-space-only users, there are no differences.

From my understanding, Spaces are supposed to simplify access control when an organisation works with multiple external groups on one Phabricator instance. They should remove the burden of adjusting the Policies of each and every object from our users. Or at least that was my hope. ;)

For users who have access to one Space only, I think it works quite well already. They basically cannot screw up: All objects they create are locked into their Space.

For everyone else, Spaces just added one additional control, which they can get wrong. Our crude patch (P1834) for a space switching ui (T8442) helps, but someone with more insight into Phabricator can probably come up with something that is even more obvious to use (please see my suggestions there).

How we currently use spaces: Q76#A96

Some related issues: T9021, T9150

More:

Visible-To

The different behaviours of Visible-To for different types of objects are currently quite confusing to our users.

EDIT: I split this off into T9165.

Visibility of Projects

It is currently unclear to us how we should best set-up Projects and Spaces with regards to ease-of-use, external users and projects.

In general we would like to have maximum possible visibility for everyone in the organisation, to make people actually work together. When it comes to what external users can see of internal structures, however, we need to apply more care.

We have three cases of projects:

1. Secret projects
   • No one but members (internal or external) shall know about their existence and content.
   • With Visible-To:#this_project on the Project and a Space with the same Policy, this is easy to manage.
2. Internal projects
   • Everyone in the organisation shall know about their existence and content.
   • With Visible-To:#organisation on the Project and a default Space with the same Policy, this can be dealt with.
   • Setting a default Policy of Visible-To:#organisation for all applications and object types helps to push people to use it.
3. External projects
   • Everyone in the organisation and people related to the project shall know about their existence.
   • Only members (internal and external) shall see their content.
   • This can be dealt with by setting the Project's Visible-To to Custom Policy(#organisation + #this_project) and the Space's Visible-To to #this_project.
   • These projects are usually managed by the employees related to the project.
   • Setting a Custom Policy is rather bothersome and not as obvious as setting a Project-style visibility. So what happens here is that people just lock down the Project entirely, as if it was a case 1 secret Project.

Case 1 secret projects appear to be the most simple to deal with, while we would actually like to encourage more openness, i.e. the opposite.

EDIT: I created T9164 to deal with possible ways of simplifying Policy controls to solve the issue.

Related D14128