We have a privacy policy, but this is primarily a legal document and mostly answers questions which are not interesting to users ("we use cookies!").
I think we should also have a data use policy which details exactly who has access to data and is explicit about making the minimum required use of user data. It should enumerate all the ways we'll use aggregate data (for example, if we plan to disclose that we we have X installs or Y users, we should enumerate that) and clearly forbid unenumerated uses. Internally, we should adhere to this seriously.
For example, if you want to know how many installs use Maniphest: most staff should not have the access required to figure that out, and we should publish that we gather and disseminate that information internally before gathering it.
A strict data use policy creates tradeoffs: restricting access to production makes debugging in production harder, and restricting internal access to data makes being data-driven harder, so there are reasonable arguments to be at least somewhat less strict about this. I don't think the "debugging in production" argument is very compelling, but we can build tooling to mitigate that if necessary (e.g., allow instance administrators to authorize operational access to their data for a specific purpose, then log how that access is used and revoke it once the issue is resolved). The "data-driven" case might be more compelling, but we could find a compromise like having a policy along the lines of "we examine aggregate information about usage (for example, how many installs use Maniphest) to help us make decisions about prioritizing features. When we aggregate information and disseminate it internally, we'll publish a notice here: ...". Or we could let installs opt-in to aggregate collection, but I'm generally not sure we would ever make a decision differently or more quickly based on this information. Overall, I think we should start at the strictest practical extreme and force ourselves to strongly justify any relaxation in the policy.