Good point. Maybe we should make this filter exclude users at the 'experienced' level as defined in includes/user/User.php's getExperienceLevel(). cc @Urbanecm_WMF and @Tgr who worked on this recently.

You can apply multiple filters in RecentChanges. I'd keep the filter in sync with how mentorship works elsewhere (e.g. the mentor dashboard), that's the least confusing behavior IMO.

Yeah. One option is to filter out experienced users in both places, the second option is define "experienced" in some other, custom, way.

FYI: Asked the ambassadors to leave their thoughts here, to gather more views.

The RecentChanges filter will probably end up reliant on a custom filtering mechanism (backed in some way by the x1 DB cluster) anyway because of T293182: Expectation (readQueryRows <=) 10000 by MediaWiki::main not met (actual: 20736): query-m: SELECT gemm_mentee_id AS `value` FROM `growthexperiments_mentor_mentee` WHERE gemm_mentor_id = N .

@Urbanecm_WMF, as a threshold, 500 edits and 30 days of activity is fine. But we can also consider adding a revert rate/number of block threshold. For example: if the revert rate for a newly experienced user is above 5% (or the expected average), then despite crossing the threshold, that contributor will not be out of the list. We can consider removing the editors from the list when they have passed the threshold. And if an editor gets blocked in the meantime, then we can consider setting a new threshold (1000 edits and 90 days, or something similar?).

It would be good to have an age / editcount combo after which users are always excluded, because we can efficiently filter by those things but not by e.g. revert rate. The remaining users can then be refined via more sensitive criteria.

I would set a default filter as "more than 500 edits and 30 days of activity", and provide a Community Configuration option.

We discussed about this topic and decided to use the definition of experienced users as it follows: "more than 500 edits and 30 days of activity".

A few days ago, a similar conversation took place among es.wp mentors in a Telegram group. They find confusing that experienced users (even admins) appeared in their Mentorship dashboard. They believe it adds noise to the mentor and could be even feel like "offensive" for an experience user to be assigned a mentor (that potentially can have even less editing experience as the mentee).

This is coming up again in community conversations, so moving to Needs Discussion for future consideration.

I know it is an unperfect solution but select your mentees + Newcomers + Learners will not return experienced users edits.

A solution would be to restrict the two Mentees filters users who haven't yet met the Experienced users threshold (500 edits + 30 days of tenure).

Perhaps we can approach this issue more holistically as we think about how to handle Mentorship for experienced editors: T362714: Design: Mentorship module for experienced editors.

Should we simply drop the official Mentor / Mentee relationship when a junior editor passes that "500 edits + 30 days of tenure" threshold?

In T294861#11046954, @KStoller-WMF wrote:

Should we simply drop the official Mentor / Mentee relationship when a junior editor passes that "500 edits + 30 days of tenure" threshold?

We can't simply drop it, as then it would be re-created whenever the user visits the Homepage, even if just for testing. Doing an equivalent of T395383: Community Configuration: Restrict "Add a link" suggested tasks based on newcomer total edit count for Mentorship would work.