The two forces here from my side are:

• I'd like to have a consistent rule here. We currently do have a consistent rule and standard best practice: always use the username. A couple of applications violate this with bugs (for example, I think Ponder uses real names in email) but these are bugs. There are a few rare non-bug exceptions to this rule for technical reasons.
• There are a bevy of technical and UX problems associated with using real names because users need to read and write them.
  • They are not unique (Facebook had ~20 employees with the same given and surnames as another employee when I left).
  • They are not well distributed, and highly duplicate in short form (lots of "Matt" and "Chris").
  • They have complex rules around short forms (given vs surname order, e.g.)
  • They are mutable by the user.
  • They are mutable in real life through marriage and other name changes.
  • Some are extremely difficult for humans to remember and spell correctly ("Palihapitiya").
  • They are arbitrarily long and contain arbitrarily long words; long names are unexceptional ("Christensen-Hernandez").
  • Some can't be typed by many users ("石涛", "Ramón Jiménez").
  • Some can't be represented in ASCII.
  • They are cumbersome to represent in URLs.

In particular if we switch the rule from "use usernames" to "use real names", we end up with these technical problems immediately:

• We must provide a unique, human-readable text representation of users in commit messages, e.g. in "Reviewed by:".
  • We currently do this with usernames, which are straightforward. To use realnames, I think we'd have to disambiguate with email addresses, e.g. Reviewed by: Chad Little <chad@phacility.com>. We need to do this because the text must be unambiguously machine-parseable later. This is possible, but seems worse and less usable than Reviewed by: chad.
• Users must provide a unique, human-writable text representation of users from the CLI, e.g. when filling out "Reviewers:".
  • We currently do this with usernames, which are straightforward. We could use realnames, but would have to build a bunch of heuristics to try to transliterate non-latin text and figure out if each fragment was ambiguous and correct misspellings, and then we would need to represent reviewers as real name + email. And we're in trouble on humans with the same name.
• Mentions must be representable in plain text. Although we could let you enter them with a fancy typeahead, we need to provide a text representation in commit messages and email. This would have to be something like @"Chad Little <chad@phacility.com>", I think, which seems worse by far. It can't be just @Chad because it must be machine-parsed later (and even if there's only one Chad today, we must use a globally unique form because there may be more chads in the future).
• Real names, especially in short form, aren't sufficient to disambiguate users. We have various contexts where we show users without a profile image (for instance, "Subscribers"). Profile images aren't unique either -- many users never set one, and a malicious user can copy another user's profile image to impersonate them.

From a policy perspective:

• We need to lock down real-name editing because it creates various security/trolling problems if I can change my name and profile picture to "Chad Little" with your profile picture, take some actions, and then possibly change it back later with no audit trail and no accountability.
• I like the ability to use Phabricator relatively anonymously for open source installs. Although many users have been comfortable giving us a real (or real-looking) real name, lots of users aren't and have provided only a first name or a pseudonym. This isn't problematic with usernames, but exacerbates all the real name problems. We have 9 users with realname "Chris", 8 "Andrew", 8 "Peter", 8 "Michael", 7 "Tom", etc. There are a total of 1,116 users on this install with the same real name as at least one other user.
• I don't like using email addresses as permanent identifiers. They're okay, but they're not really public, they're not really immutable, they're not really one-to-one with users, and they're cumbersome. We don't currently expose user email addresses directly anywhere in the application (conceivably, we could have a long form like "Chad Little <chad>" instead of "Chad Little <chad@phacility.com>").

We could instead pick a rule which was more like "use usernames in these contexts and real names in these other contexts", but I really dislike the inconsistency (and especially if the rule is "use full realnames here, and short realnames here, and usernames here"). We have this a little bit today with email stuff, but it's very contained.

From a purely personal perspective, even if we magically fix all the technical/product/security/practical concerns, I don't see much value in using real names over usernames. I prefer usernames and think usernames are legitimately cool and orient these tools as engineer-focused rather than management-focused: management doesn't use usernames, hackers do. Even though no one is running around with @neo or @blackdragon on most installs, the veneer of persona the username presents still feels meaningful to me.

Anyway, I'm not totally opposed to revising this decision and I know it has come up a few times, but I think the two ways forward are both very hard roads:

• We can take the hard technical road and try to make real names the primary identifier, but this is a lot of work.
• Or we can take the hard product road and just change the policy to something that I think will essentially amount to "every application can do whatever it wants, there are no rules anymore", which I think is a really bad precedent to set. And this still brings in a bunch of the concerns above (like user impersonation / real name mutability and the optionalness/incompleteness of real names): applications can't safely just switch to real names with no additional work without creating problems.

I love the usernames. I think for engineering tools it makes tons of sense because if you consider "code" our primitive when you get to that level (version control system) all you typically see is the username. People _literally_ call me "btrahan" who know me primarily / mostly from a work context and I'm cool with that. While I chose the "corporate-style" username that is basically my real name, I know that lots of people really enjoy their usernames which are more subtle (moskov) or you have no idea who they are whatsoever (codeblock) at first but the individual really loves having that username.

@chad - on the general "humanize" notion I think that's a worthy goal / thing to always push for more of in our tools.

In the examples I displayed above, I always included username. I'm not asking to switch to full name, just to include (and possibly lead?) it in any case we display username in the UI. Basically what we do in the tokenizer. :)

I absolutely believe people here should control their identity. I want to be identified as Chad Little (chad). If I delete my name, then just chad. If Bob wants to be Bob Trahan (puppylover), then awesome let's let him do that.

The two questions I'm really asking:

• Can we start showing full name if provided along with username in the UI
• Can we lead with full name instead of username

◀ Merged tasks: T2950.

Is it possible to display the real names in tooltips or brackets behind the usernames? In our organisation the usernames are randomly generated and provided by a global AD instance. It would be nice if we could keep that connection, but still have an easy means to know who we are talking to in e.g. Conpherence.

I'm in the same boat as @devurandom here, imported horrible AD randomly generated usernames.

I notice that when I autocomplete @ usernames in comments it displays realnames in brackets. I would like to have it show the realname in brackets after usernames when displayed on pages too. Or even preferably (perhaps as a configuration option) the opposite.

I agree that only displaying one may be problematic as then people will want to always autocomplete with real names (I suppose especially if it leads), but I see that if I @ a last name it autocompletes to their username anyways, so it seems like you've solved this in search, but not in display?

We are vanishingly unlikely to revisit this decision. If this is important to your organization, you should look into forking the codebase to provide the functionality you are interested in.