I'm going to close this task, since it has served its purpose and we have basically-usable policies almost-everywhere now.

Policies are newly implemented, and are obviously not mature. There are likely to be some remaining bugs, rough edges, etc. However, by all appearances they work correctly and are reasonably usable. You should be cautious about using them to protect nuclear launch codes from hostile nations, but they should be fine for hiding information from your enemies at your company, and for opening up applications on open source installs.

The policy implementation today consists of flexible infrastructure, a basically reasonable UI on top of it, and some application-level defaults and settings (accessible in the "Applications" application). We expect to refine all of these things in time, but mostly in response to feedback. If you begin using these features, let us know what works, what doesn't work, what's confusing, what you wish were easier, etc.

Some particular notes:

• Open-Source Installs
  • There's no logged-out version of the home page yet. Do you want one? What should it look like or do?
  • There may be performance issues with some queries if you have a large amount of private data and a small amount of public data. Let us know if you run into these.
  • There's no script to retroactively open up access. You can generally update the viewPolicy column of an object type in the DB, or we can build tools for this.
• Installs with Clients or Project-Level Policy Implications
  • We suspect the current implementation is very labor-intensive for the use case of having several clients, each of whom you only want to see their own stuff. Is this true? Some discussion in T3820.
  • Broadly, the implementation is easier to use with policies that are default-open, selective-deny than default-deny, selective-open. We think this is the more common use case, but maybe not?
• Tooling
  • There isn't much support tooling yet. What do you need?
  • The bin/policy tool does exist, and will let you unlock objects which you accidentally lock yourself out of. (We'll make it harder to lock yourself out of things, too -- it's fairly easy in a few interfaces now.)
• Custom Policies
  • The custom policy UI provides "user", "project", "admin", and "lunar phase" rules. What additional rules do you need? "Time of day"? "LDAP group"?
  • These rules are relatively pluggable. Are you interested in writing custom rules?
  • Do you even end up using custom policies? Could we have gotten away without building them?
• Defaults
  • We provide global defaults in most applications now. Do we need more fine-grained defaults (per-user, per-project...)?
  • There's no way to save or bookmark specific custom policies. Is this important?
  • Some object types have implicit rules, e.g. the author of a paste can always view and edit it. Are there other rules we should have? Do current rules make sense?
• Clarity
  • A particular goal of this implementation is to make it clear how policies operate. Did we succeed? When you can't see an object, is it clear why you can't see it? Are policy rules intuitive?
  • Is it easy to set the policies you want to set?
• Incomplete Applications and Policies
  • Not all applications have full policy support yet, usually because it's blocked by something or they're beta. Which remaining apps do you want support for?
  • Capabilities are relatively coarse right now, and mostly fall into "edit" and "view". Do you need more fine-grained capabilities (like "comment" as distinct from "view")?
• Documentation
  • If you're lost, yell at me and I can write some sooner rather than later.
  • Or if you'd just find this interesting or whatever.
• General
  • We believe policies are broadly at a level where they're usable, make sense, and are consistently enforced everywhere. If you see anything suspicious or confusing or which seems obviously broken or doesn't make sense, let us know. From here on out, they're expected to work in a generally reasonable way.

If you have feedback on any of this, file a new task and we'll merge things together into some smaller piles and move them forward separately with less than 100 people on the CC list. I'd guess that most of these topics are not interesting to most installs.