There is only one flavor of "Visible To", which is the second, more general one:

Who can see this object and sub-objects / contents?

"Visible To" always means this. If you can point out cases where it doesn't, we'll fix them.

It sounds like the root issue here is really confusion around projects, and an expectation that associating a project with an object puts the object "in" the project. It doesn't, and, by design, project associations never affect visibility.

I feel strongly that this is the right technical and product direction, and that making projects affect visibility would make the situation much more confusing and much worse.

I think "Projects" is a consistent point of confusion among some users. The word carries a lot of connotations, and users assume projects do more than they actually do (control policies) and less than they actually do (they don't realize they can use them as tags and groups).

Some things we could possibly pursue:

• Documenting projects better; we should do this anyway, but I doubt it will help much.
• Renaming projects: I can't come up with a name (tags, groups, keywords, labels) that doesn't have the same problems in some other direction. For example, users are probably less likely to assume "labels" imply policies, but more likely to assume they can not be used as groups of users.
• Force users through some sort of clippy-guided tutorial, either on first signup or when they try to interact with projects for the first time?

Perhaps the "not realizing the use case" cost is a much smaller than the "assuming it impacts policies" cost, and we'd benefit on the net by using a name that sets lower user expectations (probably "Tags" or "Labels"). That is, it's potentially less problematic if users don't realize that they can use a project as a group than if they think they can use it as a policy control, so choosing a name which sounds useless might produce better results. In this vein, the ideal name would be "Meaningless Do-Nothings".

If we actually picked that name, presumably this would actually solve the policy problem (new users would not expect changing the policy of a "Meaningless Do-Nothing" to affect related objects), and would also solve the use case problem (users would go read the documentation about "Meaningless Do-Nothings" because the name forces you to be curious about it, and learn what they're good for). However, lots of users hate it when we use silly names, and experienced users would be stuck with this gross mess. Even using "Tags" or "Labels" seems a bit worse to me for experienced users.

We could maybe choose some fanciful-but-not-completely-silly name like "Sigils", "Emblems" or "Elements" (more standard words like "Components" are generally heavily overloaded already) to achieve some of the effect of "Meaningless Do-Nothing" without making new users hate us as much. But the general idea with this line of thinking is that it may be better for new users to be confused than to come in with a bunch of assumptions because we use a word that means something different in other software. This line of thinking is generally perilous, though (see T9168 for one example).

We could also split projects into two completely separate but essentially identical applications, "Groups" and "Tags". In the simplest form, both applications would run exactly the same code, except one would say "Groups" everywhere and one would say "Tags" everywhere, and each object would have an internal type flag specifying whether it is a "Group" or a "Tag".

This is sort of the tack we were heading toward with T390. The general problem with this is that it's much worse for experienced users: once you understand how the application works, it's easier to use a single application, and there are a lot of hybrid use cases with objects that aren't precisely either strictly a Group or strictly a Tag.

Any of this becomes more complicated after T3670, etc., when projects will get subprojects and formal sprint/milestone/iteration support, and eventually progress and charting.

Calling them anything but "Projects" once those features land seems probably-worse-on-the-balance.

In T9165#131879, @epriestley wrote:

It sounds like the root issue here is really confusion around projects, and an expectation that associating a project with an object puts the object "in" the project. It doesn't, and, by design, project associations never affect visibility.

Aaand that's why in some other task/diff I suggested having dynamic "Members of associated projects" policy available ;) THAT would IMO create less confusion. Case in point: Tasks. Tasks with that policy would fit the bill for those that want behaviour like "in projects" ;)

I feel strongly that this is the right technical and product direction, and that making projects affect visibility would make the situation much more confusing and much worse.

Yep... Policies are good.

I think "Projects" is a consistent point of confusion among some users. The word carries a lot of connotations, and users assume projects do more than they actually do (control policies) and less than they actually do (they don't realize they can use them as tags and groups).

Some things we could possibly pursue:

• Documenting projects better; we should do this anyway, but I doubt it will help much.

IMO, projects are documented nicely :-)

• Renaming projects: I can't come up with a name (tags, groups, keywords, labels) that doesn't have the same problems in some other direction. For example, users are probably less likely to assume "labels" imply policies, but more likely to assume they can not be used as groups of users.
• Force users through some sort of clippy-guided tutorial, either on first signup or when they try to interact with projects for the first time?

Oh hell no... Well... OK, clippy guide through would be very nice for all non-prototype apps, but only on user's wish :)

In T9165#131879, @epriestley wrote:

There is only one flavor of "Visible To", which is the second, more general one:

Who can see this object and sub-objects / contents?

"Visible To" always means this. If you can point out cases where it doesn't, we'll fix them.

Ok, you're right. To be more precise: The difference is, that nothing but Spaces and Phriction pages has sub-objects or other objects as contents.

In T9165#131879, @epriestley wrote:

We could maybe choose some fanciful-but-not-completely-silly name like "Sigils", "Emblems" or "Elements" [...]. But the general idea with this line of thinking is that it may be better for new users to be confused than to come in with a bunch of assumptions [...]. This line of thinking is generally perilous, though (see T9168 for one example).

With the difference, that the wiki, repository or bugtracking applications, which behave very similar to what everyone is used to, have phablicious names, while something like projects have a very common name, but behave different. Maybe I should really go with T9168 and translate them to Phrojects...

In T9165#131885, @epriestley wrote:

We could also split projects into two completely separate but essentially identical applications, "Groups" and "Tags". In the simplest form, both applications would run exactly the same code, except one would say "Groups" everywhere and one would say "Tags" everywhere, and each object would have an internal type flag specifying whether it is a "Group" or a "Tag".

This is sort of the tack we were heading toward with T390. The general problem with this is that it's much worse for experienced users: once you understand how the application works, it's easier to use a single application, and there are a lot of hybrid use cases with objects that aren't precisely either strictly a Group or strictly a Tag.

Any of this becomes more complicated after T3670, etc., when projects will get subprojects and formal sprint/milestone/iteration support, and eventually progress and charting.

Calling them anything but "Projects" once those features land seems probably-worse-on-the-balance.

I agree with you here.

When having Tags which only tag things, and Groups, which are used to build Policies, one might end up having a lot of Tags that are named like Policies (or the other way round). Whichever way I think about simplifying the split responsibilties afterwards for everyday use, I end up with the current Projects...

In T9165#131910, @johnny-bit wrote:

In T9165#131879, @epriestley wrote:

It sounds like the root issue here is really confusion around projects, and an expectation that associating a project with an object puts the object "in" the project. It doesn't, and, by design, project associations never affect visibility.

Aaand that's why in some other task/diff I suggested having dynamic "Members of associated projects" policy available ;) THAT would IMO create less confusion.

Might work, if I made this the default policy on our install... But then a lot more things would have to be taggable like Maniphest tasks are now.

I feel strongly that this is the right technical and product direction, and that making projects affect visibility would make the situation much more confusing and much worse.

Yep... Policies are good.

They are. In fact they are an awesome distinction from systems like Redmine, which make Phabricator much more flexible than these. They solve a lot of problems very elegantly. E.g. my users asked: "In Phabricator, can I block a task, so no one else can tamper with it? Like in OTRS?" I was able to answer: "Yes, set Editable-By:@self".

Maybe the problem is not so much user confusion about Projects, but more confusion about Policies. At least my users seem to be unaware of their existence. Maybe I can try putting them more into the spotlight in the next training session, so users realise that what actually defines access are the Policies and not Projects, and that there is no such thing as "this object is part of a project". Explain to them to be enhanced Unix groups, behaving in much the same way...

What I must also figure out how to explain properly are Spaces, which to them currently look just like "Projects" (they actually mean "Project-based Policies"), but confusingly behave very different. That, and visibility Policies of Spaces affect other objects, which makes them behave similar to Policies on Phriction pages (T9165). In addition, the Spaces UI is displayed as part of the Policy controls (T8442), which probably makes matters worse.

So to sum things up:

• I think T8442 is utterly needed to get Spaces out of the way. (Project-based Spaces will appear less like just another variant of Project-based Policies.)
• Making users more aware of the existence and purpose of Policies and their distinction from Projects and Spaces might help a lot. The proposed "Policy templates" (T9164) might be a way for me to force my users to more often do something other than setting Visible-To:#this_project, and thus help them understand that "Visible-To" does not "put the object into a Project".

P.S: While searching for a Maniphest, I just found this bit in the search form: "In Any Project". Shouldn't it be "Tagged with Project" or "Associated with Project"?