Page MenuHomePhabricator

Allow order allusers API result by number of edits
Open, LowPublicFeature

Description

Currently various places such as Special:Contributions using allusers API, which sorts users alphabetically. It may be more relevant if the user list is ordered by edit counts.

Event Timeline

FGoodwin subscribed.

With regard to T402952, Is this table associated with user_editcount? Since API:allusers can display editcount as an optional usprop, it seems that a user of the API could sort by editcount on their end. If API:allusers were to sort by edit count, why not by any other usprop available? Cautiously this feature seems like it would fundamentally change the allusers endpoint without solving any current problems. Triaging as low priority for now.

This is an interesting request. From an API usability and functionality perspective, it seems totally reasonable to enable queries like "Give me the top 10 editors from the last 7 days," for example (knowing that the "last 7 days" is a whole 'nother can of worms). My understanding is also that the proposal here would be to add new properties that allow you to choose the sort order (either by username by default, or by edit number, or by some other/future properties if we make it extensible) on the endpoint without changing the default behavior. Page edits seem like the most obvious and immediate need in that space. I would also assume that the linked ticket would make this type of query more realistic in terms of performance, where it was previously not possible or just not a good idea from a performance perspective.

But agree with keeping this low priority unless there is a distinct and urgent need here, like this is blocking a new feature. If there is evidence that this would greatly improve performance and/or enable a new capability, we can revisit it! I know there are some event related tools rolling out where there is interest in creating an edit leaderboard for Editathons, for example, where this might be helpful.

Note:

  1. If we want to order result by number of recent edits, then this can not be achieved by user_editcount table. A query on recentchanges table, which already has scalability issues, is needed.
  2. Even if user_editcount would had an index, it may not be not that useful, since users with username having a given prefix can be very sparse in all users.
  3. I believe this feature is useful, and here is a major usecase: If I browse Special:Contributions, I can search users with a given prefix. However most users have zero edits, so are likely not relevant. In addition, many active users may be impersonated by LTA, i.e. there may be a number of usernames similar to usernames of an established user. Sometimes, they will appears above the established user (e.g. "TonyBallinoi" above "TonyBallioni"), and make established users harder to find.