Some of these just haven't been updated yet, like the developer tools. A few have more specific issues:

Audit

See T4715.

Calendar
Facts

These applications are "Beta", and not expected to be fully operational.

People

Did you also set "Can Browse User Directory" to public?

People

Did you also set "Can Browse User Directory" to public?

Oops, no, we hadn't. Now the list of users can be accessed anonymously, but accessing to user profiles still requires authentication.

Another important one is Differential. E.g. http://fab.wmflabs.org/D1

The policy on that revision is "All Users" -- not "Public (No Login Required)" -- so it's expected that only logged-in users will be able to see it.

You can set the default policy in Applications -> Differential -> Default View Policy.

Changing the default does not change policies retroactively. You can Edit Revision -> View Policy to change the policies of existing revisions.

D1 there is set to "All Users", not "Public". Differential supports Public visibility.

Thanks, my mistake.

accessing to user profiles still requires authentication.

It looks like this is the only problem related to this task blocking our Phabricator Day 1. The rest is not urgent for us.

I think there's a bit of a policy question there.

Particularly, in the long run, I'd ideally like user profiles to feel somewhat personal and safe enough that users are comfortable listing their real names and adding profile pictures if they want. Making these accessible in general makes them googleable, etc., and generally reduces the safety of the space.

Generally, one hurdle we've had to overcome with Phabricator is shaking some of the negative associations technical users have with Facebook about it stealing all your data and selling it to the highest bidder on the black market, and so on. At the very least, I worry that opening up previously closed profiles is the kind of not-totally-thoughtful-about-privacy move that Facebook is frequently criticized for. It seems reasonable to me that some users, even on a public install, would not expect their personal information to be completely public.

There's also a class of information that we do not currently expose (or even collect in most cases) but might or will in the future, like email address, phone numbers (for SMS alerts), and maybe things like chat handles. I think these things should never be exposed publicly (unless the user explicitly wants that, maybe) but there is some utility in letting users share them privately or with others who they trust.

I'm not sure what the best way forward is here. One approach is just to avoid the issue:

• What are the things you want logged-out users to be able to do on user profile pages?

If it's a small set of things, maybe we can create a simple logged-out page and tell users to log in to access most features, and then not resolve the rest of this for now.

If it's a larger set of things, we probably need to figure out a more concrete strategy for moving forward here.

Public user profiles are ordinary in online communities and basically customary in open source projects. You follow contributions recorded publicly, you click the username of the authors, and you expect to access to their profiles. Wikipedia or GitHub are popular examples.

I worry that opening up previously closed profiles is the kind of not-totally-thoughtful-about-privacy move that

Sure, I'm not asking to open up the profiles here or in all Phabricator instances. The request is to allow Phabricator instances to have public profiles setting a policy for it.

There's also a class of information that we do not currently expose

Currently user profiles show the Name, Title, and Blurb entered manually by the user, and also offer links to the contributions of the user. There is nothing problematic about these fields. Emails are already defined through a different interface, separated from the profile.

What are the things you want logged-out users to be able to do on user profile pages?

The request is very simple: allow admins to set a policy to make the current user profiles public. Nothing else.

For instance, for Wikimedia users there is no reason to keep http://fab.wmflabs.org/p/qgil/ visible only to logged-in users.

In T4830#28, @epriestley wrote:

I think there's a bit of a policy question there.

Particularly, in the long run, I'd ideally like user profiles to feel somewhat personal and safe enough that users are comfortable listing their real names and adding profile pictures if they want. Making these accessible in general makes them googleable, etc., and generally reduces the safety of the space.

If googlability in particular is a problem (though I'm not sure that is an issue, particularly with the limited profiles shown currently), that can be addressed separately with a NOINDEX directive (either robots.txt or <meta>).

... and now we have a real use case where the lack of public user profiles affects us.

Thanks to the beauty of Dashboards, now we are testing a new homepage that is meant to become the homepage of the official Wikimedia Phabricator when we release it: http://fab.wmflabs.org/

It looks great when you are a registered user. Not so much when you are still anonymous. One main reason to include the profiles of the last three registered users is to show Phabricator as something human & approachable to newcomers. Basically, we are showing user profiles to those that cannot see them because of this policy limitation.

I also have learned that the custom avatars in Recent Activity will not be shown to anonymous users either... I still think that the decision of making user profiles public or AllUsers could perfectly be made by the admins of the Phabricator upstream.

I also have learned that the custom avatars in Recent Activity will not be shown to anonymous users either

Oh, this is just a bug. I can see most of them, but not @btrahan's -- I think because he hasn't changed his recently. I'll see exactly what we're missing, migration-wise. (@btrahan, you're the only repro I have, so don't change your profile picture!)

In T4830#74187, @epriestley wrote:

(@btrahan, you're the only repro I have, so don't change your profile picture!)

Broadly, this is T7879, and resolved by D12821, so you can change your profile picture freely again.

D13024 fixes this for Owners.

Philosophically I'm fine making People "public". The main reason for me is that all the information on a Profile is already (in the most common cases) exposed in other "public" areas of the product (like hovercards). I do think though that when an install is public, we should have an additional reminder/note when someone goes to edit their profile as a reminder. With public profiles, I think we also need to be mindful of upcoming apps like oncall schedules, where some information might be actually private (and thus displayed in that individual app, like Calendar can) and not randomly exposed.

If there is a reasonable path forward that @epriestley will approve, I can do the grunt work and close this out.

Yeah, I'm mostly concerned about future changes (offhand: phone numbers, emails, messenger handles, oncall schedules, events/availability).

I'm okay with making profiles public for now, since we probably won't move on any of that for a while and probably need specialized policies around it anyway, and are likely to end up with some kind of public version of the page no matter what, and the more-modular direction we have on profile pages now generally lines up well with putting policy controls at that level.