Removing the email makes sense but I'd like to substitute the user role in it's place (which would be more helpful anyway). Let's remove the email and substitute it for the role in this PR, then it's good to merge.

Let's add a filter for this value on the user list as well, in case folks want to substitute for some alternative (like username).

Removing the email makes sense but I'd like to substitute the user role in it's place (which would be more helpful anyway). Let's remove the email and substitute it for the role in this PR, then it's good to merge.

To confirm, you're thinking the default behavior should be no email displayed but usernames instead?

If so, I'm definitely not opposed - but do need to note that there is a "feature" removed, in that clicking on a commenters name currently opens up a mailto link to directly email them. Doesn't seem all the needed IMO, but I would need to defer to those using these in real editorial flows.

Secondly, it could look a bit funny if the user has chosen their display name to be the username. That's fixable though.

Let's add a filter for this value on the user list as well, in case folks want to substitute for some alternative (like username).

I'd like to avoid more filters/actions in regards to the markup output. Integrating with the block editor in the future will probably mean a new UI, utilizing Gutenberg styles/components. Keeping compatibility with PHP-level custom markup will be tricky at that point, so ideally we keep things as light as possible moving forward.

To confirm, you're thinking the default behavior should be no email displayed but usernames instead?

I was only thinking of the notifications panel. Swap the email with username or role (or both) to help with identification and make it filterable

If so, I'm definitely not opposed - but do need to note that there is a "feature" removed, in that clicking on a commenters name currently opens up a mailto link to directly email them.

Keep it filterable for comments, don't remove it. If you're commenting on a post it's because you've got access to it. As opposed to the notifications panel, where you can find folks emails regardless of whether you should have access to them.

If Beyoncé contributed to my site, everyone who is a contributor or higher can find her email by creating a post and looking her up in the notifications panel. The only folks who could find her email through the editorial metadata are editors or higher, and only if she comments on the post. Editorial metadata needs rethinking, but the notifications panel is more problematic.

Keep it filterable for comments, don't remove it. If you're commenting on a post it's because you've got access to it. As opposed to the notifications panel, where you can find folks emails regardless of whether you should have access to them.

True, though I think for the case in #264 the commenters don't necessarily want their email public either.

I see what you're thinking now. Makes sense. I'll try out some variations of username / role and see what will make a good default.

If Beyoncé contributed to my site

One can only hope 😆.

Hmm, so the more I look into this, the more it seems we should just leave it empty underneath the user's display name.

• user_login: Could be sensitive / contain email address still - [email protected]
• user_nicename: If the above was an email, then this would just be userexample-com, still not good.
• ID: Not terribly useful.
• Role: Users can have more than one role. Picking just the first and displaying it could be misleading.

Whereas the display_name, what we are currently displaying, is a customizable value that the user has control over. Defaulting to the First + Last name.

I'm definitely leaning towards "less is more" here. If we start with leaving it empty, we can see what happens. If no reports come in, then all is good. If there is a future report requesting more specific identifiers be shown, then we could act on that.

Using just display_name makes it both more difficult to determine "at a glance" who's receiving the notification, and also creates situations where it would be impossible to determine who's receiving a notification (with folks who share first/last names).

Email is the most useful information to show (as a unique identifier to help make "at a glance" and definitive determinations) but problematic from a privacy standpoint (see: Beyoncé). However, positively and absolutely identifying a user will be even more important for cases like #273

The concerns around user_login/user_nicename are legit, but it seems like the next best to use if we want to eliminate email. We can add an apply_filter to the user_login/user_nicename (for folks who may want to bring back email or substitute some alternative identifying information).

Sorry I never replied, lol. FWIW I'd be fine with just names, though showing user_nicename would be apprciated as it would always be unique and help you differentiate two seemingly-identical accounts.