This was probably caused by removing that clear: both div.

Thanks, see D10480 for a more complete approach to that.

It seems obvious to me that A to Z ordering by username excluding disabled users should be the default query (exactly like is done in Projects which excludes archived ones in the default query), and then you could allow sorting my creation date and others.

I think it's better because it's already built, it's simpler from a code perspective, it's consistent with most other applications (which sort from newest objects to oldest objects), and it does serve some use cases like checking how many users have signed up recently (which are rare, but probably more common than the browse-for-usernames use case).

The single letter example was... an example.

Even if we assume that you frequently need to look up users whose names you roughly remember how to pronounce but do not know how to spell (which I don't believe anyone does regularly), the proposed solution is a bad solution to the problem. It doesn't help if you remember their real name, or only part of their full name, or know the initial sound but not the initial spelling (e.g., "chris" vs "kris"). The best way to find users who you only know a tiny amount of information about is still search, and always will be. This is dramatically more true on large installs.

If the search was better I would agree with that; at this point I don't see what's the purpose for the People page. If I want to find people that need to be verified, there's a query for that, but if I actually want to find people then it's not possible.

If you only know the name starts with "g", there are nine pages of results on this install. There will be many more on the WMF install. In all reasonable cases it is faster to go get more information about the user you're trying to look up so you can narrow your search instead of scanning through 900+ results manually.

Except in those cases where you are not sure about the exact name (which I would say is the reasoning behind even starting T6092), if I enter "pg" it doesn't show "g-p-g", if I enter "gp" it shows someone else with username "gpg".

If you want to find people by username, start typing the username into the global search. You can also type any part of their real name, or a combination of letters from the username and real name (like "eprie priestley"). The typeahead is dramatically better for finding people than an ordered list.

It's useful for me to have sorting as it's easier to go through the list and find people. It seems obvious to me that A to Z ordering by username excluding disabled users should be the default query (exactly like is done in Projects which excludes archived ones in the default query), and then you could allow sorting my creation date and others.

Beyond being unexpected, is this actually useful?

I'm politely requesting a reconsideration of this ticket as I filed a similar task at https://phabricator.wikimedia.org/T914 and was pointed here.

Closed by commit rP9dd09f717192.

Hi Chris, thanks for your reply.
'Needs approval' is different from 'unverified'. Needs approval means that an admin still has to acknowledge the registration, while unverified means that the user did not finish the double opt-in yet.

Is Unverified different from 'Show only users who need approval'?

I think we should just remove Gravatar support completely. I don't think it's valuable enough to justify the complexity that supporting it implies.

Thanks @chad
I think gravatar option ( default = false ) is needed.

Please see T6261#78678

@chad
I think T6322 is different a little bit.
Change user picture was success, but it took very long time to see edit picture page.
Please check this,

Re-opening as people will still likely hit this case and it's likely fixable.

Maybe not enough but depends from your point of view...maybe the real solution is give the opportunity to ask if you want gravitar or not.

In T6261#78754, @leonardo.furio wrote:

Perfect!!! thank you!

Perfect!!! thank you!

For the record, here's an example of what we have to cope with in our code-base: https://phabricator.haskell.org/diffusion/GHC/browse/master/.mailmap

The current sorting option doesn't make any sense when dealing with people, that's the motivation behind this.

I don't understand this use case and haven't seen other requests for this.

Also, this is not random access, it's "alphabetical" access.

epriestley, the use cases you're mentioning are already covered by the search features available for the People app (joined after, joined before); the one I'm mentioning is not. There's also a page only for the Approval Queue, which doesn't need to be modified.

Most objects in Phabricator sort chronologically. The chronological ordering is helpful if you're creating accounts, because you can review or access those accounts the accounts you recently created easily. In the approval queue, it's helpful to show users in the order they entered the queue.

Thanks, is this closer to what we're all after?

I really think the question is a different one, how could the current behavior be useful or consistent with other areas? For instance, you don't get to sort projects but they are ordered alphabetically. Have you used an address book sorted by creation date, and how helpful was that?

The parser isn't that bad, but I did discover a Git feature which appears to be undocumented and used only by the kernel:

It seems difficult to identify what the "latest" .mailmap file is. For example, we may be importing a commit which is an ancestor of an arbitrarily large number of branch heads, each with different and conflicting .mailmap files.

How is this helpful in finding users if you don't remember names?

I'll accept this if you:

Thanks for all the information! Seems safe to close as wontfix, but reopen if needed.

• However, I'm not sure if there's an agreed-upon or standard way to canonicalize combining marks.

Alright, thank you for the explanation. I'm proposing Declined at Wikimedia (aka Wontfix) after understanding your reasoning.

We are unlikely to support this:

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

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