@epriestley, is there an example implementation somewhere?

ManiphestTask::initializeNewTask is an example of a Policy object that initializes the default policy relative to application settings. That's the tip of the iceberg as you'll need to make a few other changes; I think the method is a reasonable start but definitely ask more questions...!

T6564 is similar too, and could be resolved by introducing a default "Can View" for Files and using it on both the manual upload form and the drag-and-drop-onto-the-homepage flow.

I presume if I could figure one out, I could do others.

Check out D7269

What about a policy to define who can edit the policy of projects?

The current patch already would save us a lot of work reminding project creators to change "Visible" policy to Public instead of All Users. Thanks! However, we are still spending a good amount of time telling them not to restrict Can Join / Can Edit, because that doesn't do what most of them think it does (restricting access to tasks associated to their project). This combined with the fact that only project members can watch projects is causing confusion among early adopters, and we haven't even launched yet.

Do you know how come they have expectations that setting the policy on a project would later impact the policy of objects associated with the project?

In T6567#84997, @btrahan wrote:

Do you know how come they have expectations that setting the policy on a project would later impact the policy of objects associated with the project?

Many (most?) Phabricator newbies are used to environments where one task belongs to one project, and therefore the policy of the project is inherited by the tasks in that project. It's like a private folder making the files inside that folder private as well.

It's funny that I have to explain this here, when usually I have to explain the opposite behavior that Phabricator has. :)

I appreciate the context, which I'll summarize as "other tools have 1:1 mappings of projects to objects where the project dictates privacy."

I don't think this is worth solving for with this context; the users should educate themselves pretty quickly here as e.g. they realize the mapping isn't 1:1 and automagical privacy expectations are wrong in this system, etc.

In T6567#85161, @btrahan wrote:

the users should educate themselves pretty quickly

Even if that would be true (/me looks back at the history of software development and user support)... there is a possibility that some of those users are quicker at modifying policies of projects without us even noticing, since such actions are difficult to track when you have 700 projects. This doesn't even count the not so well-intentioned users just willing to lock people out of projects, for a strong reason or just for fun.

This is one of those situations where I wish I would be wrong. The context of a corporate instance where users are employees that can be onboarded and fired is very different from the situation of an open source project with the door open to quasi-anonymous users.

"Projects" as an app is likely one of our hardest to explain, and certainly onboarding would help. I'm just not sure there is any easy fix here. We've talked about renaming "Projects" as "Tags" which might help some with this specific issue.

The way we work around it here is we just have restriction on who can create Projects (us, basically).

I think in the abstract locking down features because new users don't understand them sounds like the wrong solution to new users not understanding features. I also don't like to lock down features because of anticipated malicious use since the tools should be built first and foremost for good users, then bad users can be disabled and there is an audit trail for everything users do.