In T90055#1054919, @EBernhardson wrote:

I'm wary of implementing a display name that is only used in Flow, i would much rather see this come from the other direction where core adds a display name property and uses it, and we then also use it.

Agreed. The user field should not be Flow-specific. Core already has the field; it's just disabled on WMF. (Real name vs. Display name can be handled in WikimediaMessages i18n, should we choose to do this).

(Copying&tweaking my comment from Trello...)

AFAIK, there are three possibilities, given that User:Foo wants to be known as "Barbaz" in their comments on a specific wiki :

1. Take the current contents in the user's "Signature" preferences, and if the "Raw wikitext" box is not checked,(*) then use that. E.g. https://i.imgur.com/pv4RQXp.png - (IMO this is the easiest & best solution)

2. Encourage users to Rename their entire account, if they want their signatures to say something different. (Because having a display name that is different from my username, confuses everyone - as the names in comments versus logs won't match.) (However, this won't help users who want to use different names for different languages/projects, e.g. user:مشيرة might want a different name to display in their comments at Dewiki/etc).

3. Reinstate the (currently disabled on all WMF wikis) preference, for a "real name" field. (Can be seen at ee-flow preferences). If we relabel the field to "preferred name" or "display name", this might be acceptable to the communities. (See my note below for extensive information on why we will not consider it whilst labelled 'real name'.) Note/Question: this field doesn't seem to have any affect if used (it doesn't change what name appears in the logs); I'm not sure what it's meant to do?

(*) Re: "raw wikitext" - we don't want to support this because of the huge quantities of CSS that are possible (see this gallery for some extreme signatures), and because of the subst'd-templates that a few editors use. [see WP:SIG#NoTemplates where it is discouraged but not forbidden].

Old notes about 'real name' (copy&pasted from Trello, in Jan 2017)

TL;DR: recommended to avoid the term "real name", and instead use "preferred name" or "display name" (in addition to the main "username" (aka login name)).

It's Complicated.

Prior discussion includes:

• public email thread: http://lists.wikimedia.org/pipermail/ee/2013-September/000723.html (Many good comments from many editors and staff)
  • Particularly http://lists.wikimedia.org/pipermail/ee/2013-September/000735.html
  • and http://lists.wikimedia.org/pipermail/ee/2013-September/000740.html
• private email thread: [E2] Design review: outcomes (2013 Sept 18/19)
• article pointer: http://lists.wikimedia.org/pipermail/ee/2013-October/000778.html
• Notes: https://www.mediawiki.org/wiki/GlobalProfile/design#Collected_Data
• policy: https://en.wikipedia.org/wiki/Wikipedia:Username_policy#Real_names

Google+:

• http://gigaom.com/2011/07/25/google-and-the-loss-of-online-anonymity/ http://boingboing.net/2014/07/23/the-apology-letter-google-shou.html

Blizzard:

• http://www.gamingunion.net/news/2141/blizzards-community-manager-the-first-victim-of-real-id/ "In an attempt to defend the change in policy, Bashiok posted his real name in the World of Warcraft forums. Within minutes, pretty much everything about him was exposed. From key points in his life to the name of his wife and child and even his room mate. Photos of his house and what street he lives on where also posted up thanks to Google Street View."

I'm feeling option 3 is the most ideal especially if it is blank for most users (no effect when we flip the switch) and hopefully already checks for plain text only. If it doesn't already validate for plaintext perhaps we could make this change before reenabling it.

Hmm, would option 3 enable "mention-autocomplete" to include both account-name vs display-name ? If so, then that might be best.

@Quiddity I would recommend that be part of the acceptance criteria, that the search ahead do both full text and prefix matching against both user names, and preferred names. I'd also recommend that we weight these based on participants in the current conversation, with the second weighting criteria be people the user had mentioned or was mentioned by in the recent past.

In T90055#1113918, @Jaredzimmerman-WMF wrote:

@Quiddity I would recommend that be part of the acceptance criteria, that the search ahead do both full text and prefix matching against both user names, and preferred names. I'd also recommend that we weight these based on participants in the current conversation, with the second weighting criteria be people the user had mentioned or was mentioned by in the recent past.

This task (adding back real name/displayed name) would/will require a lot more communications than the mention feature. I don't think it should block the mention MVP.

To refine the mention inspector, I've broken out T92588: Implement mentions inspector. We decided earlier that the initial version will only auto-complete users in the current topic.

@Mattflaschen, that makes sense. I wasn't considering it a blocker for
release.

In T90055#1106883, @Jaredzimmerman-WMF wrote:

I'm feeling option 3 is the most ideal especially if it is blank for most users (no effect when we flip the switch) and hopefully already checks for plain text only. If it doesn't already validate for plaintext perhaps we could make this change before reenabling it.

I agree - real name or display name would be excellent.

I have some thoughts, but please don't let any of them be blockers for moving forwards:

• IIRC, Real name existed on Wikimedia projects when I joined ten years ago, but was disabled. I wonder whether there are any veteran users who still have it saved in the database.
• When people change this option, what will they want to appear on old conversations - whatever it was at the time of posting, or update retroactively? Ideally, I'd allow both.
• Even if we have Display name, a separate actual Real name may have value if Wikipedia or another Wikipedia project ever wants to allow something like "confirmed" accounts for experts and so on. It's currently "against the spirit", but I can imagine future configurations where this could happen as Wikipedia matures.
• Signatures as they are probably can't cut it. They are for talk pages and usually include a direct link to the user's talk page, and sometimes Other Stuff - links to pages about the user's pet projects, contribs, edit count and whatnot. It's nice for the anarchy of the old talk pages, and there actually is something nice about this anarchy, but the users can just do such things on their user pages.

@Amire80 that all sounds reasonable, but i do worry about the maintaining a history of display names and showing them attached to historic posts, this could be complicated and VERY confusing, it would allow a user to change then name mid-conversation and and appear as each within a thread. This isn't how most (any?) systems with display names work that I'm aware of, so I'd be very wary of diverging from what users expect.

In T90055#1135781, @Jaredzimmerman-WMF wrote:

@Amire80 that all sounds reasonable, but i do worry about the maintaining a history of display names and showing them attached to historic posts, this could be complicated and VERY confusing, it would allow a user to change then name mid-conversation and and appear as each within a thread. This isn't how most (any?) systems with display names work that I'm aware of, so I'd be very wary of diverging from what users expect.

Oh, totally, as I said, don't let it be a blocker.

Just as a thought - there's something that happens on Facebook, too: people change their names whether as a joke, or as a participation in a meme, and so on; and then it changes all their past messages, which is kinda weird. And sometimes people change their name for privacy reasons or because they legally changed it in real life. Sometimes they will want to change all past occurrences and sometimes not.

But yet again, don't let it be a blocker.

(Something that Facebook do and I definitely don't want Wikimedia to do is limiting the number of time that a name can be changed. Free encyclopedia = free unlimited changing of names, except maybe database performance issues.)

I've been hoping for a while that someone would advocate for this feature. :) I think it's important in a discussion system to have a way for people to express what they actually want to be called -- my personal username on Wikia and WP is "Toughpigs", a reference to a Muppet website that I started. I like it as a username, but I don't want people calling me that.

My thought on how it would look: The signature would be: Username (Preferred name). The username would be bold and a blue/red link, as it is now. The preferred name would be regular text, and unlinked. If they haven't added a preferred name, the parentheses don't appear.

It keeps the standard of everyone having their actual username in the same place so that this doesn't become a confusing world of sockpuppetry.

The preferred name is rendered when the page loads, so you always see the user's current preferred name (minus whatever cacheing we might run into). You can change your preferred name, and that new name will be displayed on all of your Flow posts past and present, until you decide to change it again. This is one of the advantages of not having the entire message be one unchanging splotch of wikitext; we can do cool stuff like this.

We'll have a sane character limit on the preferred name, render it as plain text and use the appropriate abuse filter. With that in place, people could feel free to be playful with it -- change it to (Happy New Year) or (On vacation until Monday) or whatever they'd like to say to the world.

I'm happy to use the existing "real name" field, although we might want to change it to "preferred name". I have one question about that: it's possible that a user put their name in that field 10 years ago and forgot about it, because it was never displayed anywhere. One day, they suddenly see it appear on their Flow posts. Is that going to be an unpleasant surprise for them?

Thanks for writing that up Danny, one suggestion and one question.

If it really is a preferred name I'd suggest we switch the order,

*Jared Zimmerman* ( jaredzimmerman (WMF) )
My message is here, and its just a good message…

(I don't know if any of the formatting above will survive emailing to phab)

The question is… will be able to have the mention interface be able to
match against preferred name AND user name, i think we should if possible,
twitter, facebook, quora, and most other sites that support both name types
support searching on both.

In T90055#1136748, @DannyH wrote: "preferred name". I have one question about that: it's possible that a user put their name in that field 10 years ago and forgot about it, because it was never displayed anywhere. One day, they suddenly see it appear on their Flow posts. Is that going to be an unpleasant surprise for them?

Possibly. We should check how many (if any) have user_real_name set in the database.

In T90055#1136849, @Jaredzimmerman-WMF wrote:

The question is… will be able to have the mention interface be able to
match against preferred name AND user name, i think we should if possible,
twitter, facebook, quora, and most other sites that support both name types
support searching on both.

I think this makes sense. If we do this, we need to add an API to query this. https://www.mediawiki.org/wiki/API:Allusers does not mention the "real name" field.

Change 221607 had a related patch set uploaded (by Matthias Mullie):
Change mention inspector template

https://gerrit.wikimedia.org/r/221607

Change 221607 merged by jenkins-bot:
Change mention inspector template

https://gerrit.wikimedia.org/r/221607

It's my understanding that bugs entered here are supposed to have consensus first -- rather than generating consensus here on phabricator. Is that accurate? If so, where is the consensus for this substantial change on the various projects it will affect?

In T90055#1893133, @Peteforsyth wrote:

It's my understanding that bugs entered here are supposed to have consensus first -- rather than generating consensus here on phabricator. Is that accurate? If so, where is the consensus for this substantial change on the various projects it will affect?

In general: Not exactly. Having a Phabricator task does not mean anything will actually be implemented. In fact, there are contradictory tasks in some cases (where it would be impossible to implement both). Individuals often file tasks for feature-requests or bug-reports before discussing anything with anyone. There are also frequently discussions about "the technical options" that take place before (or concurrently with) a discussion about the "communities' preferred option". There are also discussions where consensus is reached on mailinglists and IRC and sometimes in-person (e.g. meetups, chapter board meetings, etc).
There is ongoing work at https://www.mediawiki.org/wiki/WMF_product_development_process to refine and clarify some of these processes, though that is focusing on the broader software scale (product development, vs individual features/aspects therein).

Specifically for this task: There is not currently enough information on how we could resolve this bug (technically speaking), nor on how we should resolve it. It has not been looked at recently (many months), because there are other features with a higher-priority.
The current (old) FAQ item is at https://www.mediawiki.org/wiki/Flow#What_happens_to_my_custom_signature.3F which acknowledges the desire to deal with this at some point. - there's also some prior discussion about it at various locations (from the last few years). TL;DR: It's not a simple case of just re-using our custom-signature preference-settings, because of the way that flow pages are put together (i.e. the raw HTML in a signature would need to be specially sanitized - see the last line in T90055#1105594 above); and that needs to be balanced with the desires of some editors to remove the colorful formatting (which would be a nice option, but complicates caching); and various other factors (such as what to do with old posts by subsequently renamed-users, etc. etc.). HTH.

Absolutely helps, Quiddity -- thanks. And I'm glad to hear that WMF product dev process aims to document all this stuff better. Every time I ask about something like this, I seem to get a nugget of useful information...but nobody's ever pointed me to a document that (e.g.) describes the proper/intended use of sites like phabricator, bugzilla (which I do understand is now history), trello, gerrit, github, or even mediawiki.org or the tech email lists or IRC channels, and perhaps other sites/lists I'm not aware of. Any effort to create high-level documentation of that stuff would be tremendously useful to the movement. (Detailed documentation is good too, but IMO some kind of overview is more pressing.) Anyway, I appreciate this good explanation -- it makes sense.