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".