Page MenuHomePhabricator

Allow anyone to claim a mentee
Closed, ResolvedPublic

Description

I've distributed the info about Special:ClaimMentee to Czech instructors, and they did want to be a mentor for their own students, but not a general one, because they're afraid it's a lot of work.

Let's allow anyone to claim a mentee for now. It's not a widely propagated feature, and in the unlikely event of abuse, it's possible to prevent claiming by blocking. If that happens, it's easy to introduce claimmentee right and assign to autoconfirmed (or whatever we want to).

Event Timeline

Urbanecm created this task.Feb 19 2020, 4:37 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 19 2020, 4:37 PM
Urbanecm claimed this task.Feb 19 2020, 4:38 PM
Restricted Application added a project: User-Urbanecm. · View Herald TranscriptFeb 19 2020, 4:38 PM

Change 573331 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/GrowthExperiments@master] Allow anyone to execute Special:ClaimMentee

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

Urbanecm moved this task from Backlog to Waiting on review on the User-Urbanecm board.

Pinging @MMiller_WMF to approve before making any code changes here.

IMO, if there are some users who want to mentor a handful of others but don't want to be listed on the page, the new API endpoint you added could be used for you or someone else to manually process those. Otherwise, I'm a little hesitant to allow anyone to access a special page which allows modification of someone else's preferences, even if it is currently done in a pretty limited way.

@MMiller_WMF could you please weigh in when you have a moment? Moving out of code review for now.

@kostajh -- I talked about this with @Urbanecm, and yes, I think we should allow it. This will encourage instructors to get involved as mentors. Thank you!

IMO, if there are some users who want to mentor a handful of others but don't want to be listed on the page, the new API endpoint you added could be used for you or someone else to manually process those. Otherwise, I'm a little hesitant to allow anyone to access a special page which allows modification of someone else's preferences, even if it is currently done in a pretty limited way.

I was thinking about creating "claimmentee" permission, and assign that to autoconfirmed (same that our mentors list is opened to), but I decided to just unlock to everyone who has an account.

Urbanecm reassigned this task from Urbanecm to Urbanecm_WMF.Aug 26 2020, 2:08 PM
Urbanecm removed a project: User-Urbanecm.
Urbanecm edited subscribers, added: Urbanecm_WMF; removed: Urbanecm.
Restricted Application added a project: User-Urbanecm_WMF. · View Herald TranscriptAug 26 2020, 2:10 PM

@Tgr I talked about this with @MMiller_WMF in my check-in meeting, and it seems the product reasoning behind requiring all mentors to be listed at the page, and allow them opt-out from autoassignment, is to prevent potential abuse. In my opinion, that is already accomplished by three things:

  • Claiming mentees is visible in recent changes - if someone starts to claim newbies in a nonsense way, they can be immediately blocked
  • Claiming mentees is throttled - it is not possible to claim more than N mentees in X seconds (where N is 60 and X 180 right now)
  • Claiming mentees requires a special user right - my patch introduces a "claimmentee" user right that is assigned to autoconfirmed users by default (by default, users older than 4 days are autoconfirmed, but wikis can customize it; cswiki requires 4 days and 10 edits to become autoconfirmed)
    • This is the same we use as a barrier for moving pages or editing highly visible pages (for instance, majority of mainpage content at cswiki)

I think that autoconfirmed is enough for this kind of abuse. If it proves to be an issue (I consider that unlikely, but just in case), we can assign this user right to a higher user group, for instance, autopatrolled.

@MMiller_WMF Do you think that is enough to prevent possible abuse?

Thanks!

Thanks for writing this up, @Urbanecm. @Tgr, what do you think?

Tgr added a comment.Sep 17 2020, 1:30 AM

AIUI the concern was grooming. I don't feel competent in evaluating that, it sounds more like a Trust-and-Safety question.

AIUI the concern was grooming. I don't feel competent in evaluating that, it sounds more like a Trust-and-Safety question.

What? I don't really understand how that can be relevant.

Might seem like an irrelevant question, but couldn't find a better place to ask, and didn't want to create a separate task for this either. If we gather community consensus, can we limit the usage of Special:ClaimMentee to specific group(s)? I'm not sure if we really would like every autoconfirmed user to be able to be able to claim mentees as it just takes 4 days to become an autoconfirmed user by default wiki settings.

Not right now, because the usage is limited to users listed at the mentor page. As soon as my patch is merged, it introduces a claimmentee right, which can be assigned to any group you wish.

AIUI the concern was grooming. I don't feel competent in evaluating that, it sounds more like a Trust-and-Safety question.

What? I don't really understand how that can be relevant.

To clarify, someone raised this as a thing to consider during presentations of Growth Team's work, specifically the mentorship module (not specific to this patch). What is proposed in this patch made me think more about the broader issue that the Mentorship module is one of the first things a new user will see, and so there is a level of trust implied in the person we present to the user as their mentor. Providing a wiki page for defining the mentorship list at least provides for Watchlist notices when this changes, so in theory community members could keep an eye on who is engaging newcomers.

I have no idea how to measure the level of risk in allowing a potentially broad group of users being able to present themselves as a trusted mentor to new users without the minimal amount of community oversight we already have in the mentorship module, but it just doesn't sound like a great idea to me to loosen what little we currently have.

I'm also not sure why it is needed to solve the problem written in the task description here:

I've distributed the info about Special:ClaimMentee to Czech instructors, and they did want to be a mentor for their own students, but not a general one, because they're afraid it's a lot of work.

As a hopefully simple solution, could we check to see if a subpage of the currently defined Mentors page exists (e.g. /not-autoassigned) and load those usernames as mentors as well?

I think we should have a high level of "protection" with this feature. Not everyone has the experience to be a mentor, which is why we choose autopatrolled protection (30 days/500 edits) for mentors to sign up on the mentors' list. This is a reasonable threshold, meaning that future mentors have a bit of experience there. The new claimmentee right should be aligned with this level of protection.

Ideally we should have a mentor role that allows some users (by default all autopatrolled ones) to:

  • check an option to be mentors
  • claim mentees

This role would also be given to trainers for special occasions (with the accountcreation role?).

I generally agree that using a user right plus a special page to manage mentors would be the best solution long-term, and I'm sure it has a task, but I don't think that's going to happen anytime soon.

On the other hand, my patch somehow contributes to it. It allows wikis to customize who can claim a mentee by introducing the claimmentee right. It is granted to autoconfirmed users by default, but that can be changed to any group easily.

I understand that page protection kinda works at wikis that have custom protection levels, but that doesn't need to be the case for all wikis: cswiki only has autoconfirmed and sysop-only.

Tgr added a comment.Sep 23 2020, 4:09 AM

Custom protection settings can easily be applied via a one-off hook. IMO the problem here is defining what the acceptable behavior should be; implementing it won't be hard.

revi added a subscriber: revi.Sep 25 2020, 4:09 PM

Korean Wikipedia community has a requirement that any and all mentors must be eligible to run for an Request for Admin[1], due to not-enough-experienced editors offering bad answers to questions. I would expect anyone who can claim mentee to meet some higher-than-autoconfirmed criteria to claim mentee.

[1]: That is: 1000 ns:0 (main) edits, and 90 days past registration - so this means they must be included in "extendedconfirmed" user right to run.

Trizek-WMF added a comment.EditedOct 1 2020, 5:58 PM

Marshall and I discussed about this task.

The lists should be protected so that users with less than 500 edits + 30 days of experience can't be mentors nor claim mentors.

People who host workshops want to claim mentees. Let's name them "Teachers". Marshall and I weight all options and agreed on creating a second list, just for Teachers. This list would look exactly the same as the first one, with the same formatting. The user rights would be as it follows:

TeachersMentors
Have mentees automatically assigned to themnoyes
Can claim menteesyesyes

However, this is a temporary solution, that is built as a test. As we will scale to more wikis, it will be difficult to check is this second list is created the right way. I already observed on wikis where we monitor the deployments the mandatory mentor's list not being created following the instructions we gave. Scaling would require a separate, special page for mentors (see T264343).

Tgr added a comment.Oct 1 2020, 6:42 PM

The lists should be protected so that users with less than 500 edits + 30 days of experience can't be mentors nor claim mentors.

500/30 (extendedautoconfirmed) is an enwiki concept; most wikis do not have it. We could make it universal, but that probably merits more discussion (if you put tools before people, they will start using them, even when they aren't really good tools).

Change 573331 abandoned by Urbanecm:
[mediawiki/extensions/GrowthExperiments@master] Allow autoconfirmed to execute Special:ClaimMentee

Reason:
not the preferred solution

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

Change 633776 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/GrowthExperiments@master] Allow people who are not "fulltime mentors" to use Special:ClaimMentee

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

I talked about this one with @MMiller_WMF at my last meeting. He said that the preferred solution is to have a page with the list of users who can use Special:ClaimMentee, despite not being listed at the list of mentors page. I uploaded a patch that does this, and abandoned the old one. This should be ready for a code review now :).

Change 633776 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Allow people who are not "fulltime mentors" to use Special:ClaimMentee

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

Thanks @Tgr! Looking forward to this being live.

Change 636882 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] [cswiki] Set wgGEHomepageManualAssignmentMentorsList to Wikipedie:Potřebuji pomoc/Mentoři/Manuální

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

Change 636882 merged by jenkins-bot:
[operations/mediawiki-config@master] [cswiki] Set wgGEHomepageManualAssignmentMentorsList to Wikipedie:Potřebuji pomoc/Mentoři/Manuální

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

Mentioned in SAL (#wikimedia-operations) [2020-10-29T18:04:12Z] <urbanecm@deploy1001> Synchronized wmf-config/InitialiseSettings.php: b7eaaab81e1665c478f5dc1fdb495e36c53e7863: [cswiki] Set wgGEHomepageManualAssignmentMentorsList to Wikipedie:Potřebuji pomoc/Mentoři/Manuální (T245639) (duration: 00m 57s)

I discovered that I failed to update growthexperiments-homepage-claimmentee-must-be-mentor error message to support more than one list. Patch incoming...

Change 637732 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/GrowthExperiments@master] Special:ClaimMentee should mention both lists in its error messages

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

Change 637732 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Special:ClaimMentee should mention both lists in its error messages

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

Etonkovidova added subscribers: Urbanecm, Etonkovidova.

For PM review - overall, it works as expected.

@MMiller_WMF, @Urbanecm Please review my notes below.
Tested on cswiki betalabs - to summarize:

Auto-assigned mentor listManually assigned mentor list
  • the actions of a mentor on the Manual list is properly recorded in GrowthExperiments log and on RecentChanges.

Notes:
I assume that the feature will be only on cswiki since there is no translation for the added text?
It seems that cswiki betalabs has no restriction on user rights since my test user (48 h since registration, 3 edits) ET244 was added successfuully to both lists and claimed a mentee. If there are going to be some restriction on user groups, it'd be helpful to test them in betalabs.
(really minor) different bullet point style - on the auto-assigned list it's numbered list, on the manually assigned it's a dot style.

Restricted Application removed a subscriber: Urbanecm. · View Herald TranscriptThu, Nov 5, 11:58 PM

For PM review - overall, it works as expected.

@MMiller_WMF, @Urbanecm_WMF Please review my notes below.
[...]
Notes:
I assume that the feature will be only on cswiki since there is no translation for the added text?

For now, yes. Other wikis can opt into it, but it's introduced because cswiki community asked for it.

It seems that cswiki betalabs has no restriction on user rights since my test user (48 h since registration, 3 edits) ET244 was added successfuully to both lists and claimed a mentee. If there are going to be some restriction on user groups, it'd be helpful to test them in betalabs.

That is correct. I originally wanted to switch mentorship from "is listed at an user page" to "has an user right", and grant the user right to autoconfirmed, but @MMiller_WMF didn't like that solution, thinking that the list of mentors is more transparent.

The only way how wikis can do permission control right now is to protect the list of mentors via the standard MediaWiki feature. In cswiki production, both pages are protected so only autoconfirmed users can edit it (at cswiki, 4 days since registration, and at least 10 edits; this differs per wiki), but I didn't protect the mentors list in beta, because I didn't see why it would be useful. I can do that (or you can) if you want to make prod and beta state more comparable.

(really minor) different bullet point style - on the auto-assigned list it's numbered list, on the manually assigned it's a dot style.

That shouldn't make any functional difference. You can change the bullet point style back and forth and it should still work. In cswiki prod, both are dot styled.

@Trizek-WMF -- how should we handle this option to now have the second mentor page for instructors? Should we be telling all wikis about it? Should we update instructions somewhere about how to create it?

@Trizek-WMF -- how should we handle this option to now have the second mentor page for instructors? Should we be telling all wikis about it? Should we update instructions somewhere about how to create it?

Martin already worked on the documentation: https://www.mediawiki.org/wiki/Growth/Communities/How_to_introduce_yourself_as_a_mentor#separate-list
And we have an entry about it in the next newsletter. We have a Wikidata item to track other versions of this new page.

Also, I still think it is a temporary solution. T264343: Have a special page for mentors should be built if we scale to more wikis.

MMiller_WMF closed this task as Resolved.Wed, Nov 25, 7:15 PM

This all sounds good. Thank you!