Page MenuHomePhabricator

Unify the "user registration" and "experience level" groups
Closed, ResolvedPublic

Description

Experience and reflection tell us that it makes sense to combine the "User registration" and "Experience level" filter groups into one group. The primary reason for doing so is to enable users to search for "Unregistered" OR "Newcomers", which is a common desire, yet currently impossible.

Functional Changes

  • Combine the groups, so that an "OR" relationship obtains among all members.
  • Conflict states: Remove all Conflict states that currently exist between "Experience level" filters and "Unregistered."
  • New "No-effect display states". The following combos would be redundant, according to the terms defined in T149391. There are two flavors of redundant:
    • Full coverage: these combos would constitute full coverage, and would get the full coverage messages and display state:
      • Registered + Unregistered
      • Unregistered + Newcomers + Learners + Experienced
    • Subsets: Any of the former Experience filters (Newcomers, Learners, Experienced) would be subsets of Registered, and would get the subset messaging and display state.

New wording

Please note that numerous descriptions have changed in some subtle ways.

User registration and experience

Registered
Logged-in editors.
Unregistered
Editors who aren’t logged in.
Newcomers
Registered editors with fewer than 10 edits and 4 days of activity.
Learners
Registered editors whose experience falls between “Newcomers” and “Experienced users.”
Experienced users
Registered editors with more than 500 edits and 30 days of activity.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I can think of two ways to address this, but they both have issues:

One is to make the "experience" filters orthogonal to registered-ness. Currently, filtering by one or more experience levels always excludes IP edits, this change would make that always include IP edits (unless you exclude them separately using the registered filter). A problem with this though is that filtering for "experienced" users would still show newbie IPs; and that if you filter for "newcomer or learner" and highlight both with different colors, some edits (the ones by IPs) wouldn't be highlighted with either color.

Another is to consider all IPs to be "newcomers" for both filtering and highlighting purposes. This wouldn't lead to strange highlight gaps as above, but it would mean that to get "true" newcomers, you'd have to use two filters (newcomers and registered); it would mean that "unregistered" would be a subset of "newcomers" (and we don't support cross-group subsets currently); and it would be somewhat inaccurate, because some experienced IP editors exist.

Trizek-WMF renamed this task from Patrol IP edits and newcomers edits at the same time is not possible to Consider unifying the "user registration" and "experience level" grups.May 15 2017, 8:58 AM
Trizek-WMF updated the task description. (Show Details)

I can think of two ways to address this, but they both have issues:

In T165289, I was considering the option to keep their existing meaning but combining both "user registration" and "experience level" into the same filter group. Leaving aside how to name the group (and whether that is perceived as an intuitive way to group filters by users), in terms of filters I don't see issues.

Interesting! Yes, that would work. Each of the experience-related filters would be a subset of the "Registered" filter, but that's fine. We already do something like that in the "Watchlist" filter group.

Trizek-WMF renamed this task from Consider unifying the "user registration" and "experience level" grups to Consider unifying the "user registration" and "experience level" groups.May 16 2017, 5:27 PM
jmatazzoni renamed this task from Consider unifying the "user registration" and "experience level" groups to Unify the "user registration" and "experience level" groups.May 25 2017, 8:45 PM

Moving this to Product Design and assigning myself to think through any issues.

If we do this, we will probably want to deprecate the old parameters (hideanons and hideliu), and redirect them, plus use subsets in the new group.

If we do this, we will probably want to deprecate the old parameters (hideanons and hideliu), and redirect them, plus use subsets in the new group.

@Mattflaschen-WMF, what do you mean by "subsets"?

I'm preparing the newsletter. Any update?

I'm preparing the newsletter. Any update?

The ticket seems to be assigned to @jmatazzoni but it is in the "Ready for pickup" column. Since Joe did the later move, I'll assume his review was completed and we can unassign it from Joe to make it more clear that it can be picked up.

Change 365234 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RC Filters: combine user registration and experience level filters

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

Change 365234 merged by jenkins-bot:
[mediawiki/core@master] RC Filters: combine user registration and experience level filters

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

Change 366307 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCFilters: proper group name for user experience level

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

Change 366307 merged by jenkins-bot:
[mediawiki/core@master] RCFilters: proper group name for user experience level

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

Checked in betalabs - all specs seem to be in place. The combined group is titled: "User registration and experience".

QA Recommendation: Resolve

Krinkle subscribed.

This broke the Postgres build due to the unit test involving the real database (no mocking) but still asserting a MySQL-specific result.

Re-closing since this task is still resolved (you didn't revert the fix for this task). I will update the tests so they pass in Postgres.