A long-term block seems like a very unlikely occurrence. Quitting is not, but how do you detect it? Time of last edit?
(I wonder if we should take that into account in mentor selection. Reassigning is a somewhat disruptive operation, but not assigning new mentees to the user could be done much more aggressively. E.g. don't assign to any mentors who had no edits in the last 30 days.)

Hello! The main idea why I would like to reassign mentees is that when the mentor leaves, he loses motivation. And his answers may be less friendly than we would like.

As one of the options, when you open the question form, a check is made for the presence of a mentor in the list. And if the mentor is not there, then the message "Congratulations! You have a cool new mentor" appears. And the message is already being sent to new mentor.

Hi, Vietnamese Wikipedia just had a situation where a mentor (also an admin and bureaucrat) was voted to have the adminship removed because he created thousands of articles badly translated using the Content Translation tool. After that, he's also banned for 43 days.

The current solution is to remove him from the mentor list by hand, but after he's back the community will need to discuss on whether he should be a mentor again.

Also, who will answer his mentee's questions now that he's banned?

Two users, from sv.wp and ro.wp, support this idea.

Could we create some kind of help page with information on how to reassign mentors using a maintance script before we implemented this feature?

We just had this problem on Polish Wikipedia. A mentor does not have time to answer questions anymore and wants to quit. He removed himself from the list of mentors. But the problem is that he still gets questions.

So I think there are two main situations here:

1. Mentor quits. He might want to re-assign his mentees to random mentors.
2. Mentor is not active (or some other problem). Person with proper rights can do the re-assignment.

And I think the 1st can be solved in the same way as 2nd. Mentor that is still active enough to ask can simply ask a Bureaucrat to re-assign mentees. So more or less the same as when a sysop no longer want to be a sysop.

So proposed solution:

1. Prepare a special page to randomly re-assign mentees of a specifc mentor.
2. Bureaucrats can access this special page.
3. There should be a confirmation with a warning. Maybe something like: "This mentor has 123 mentees. Are you sure you want to re-assign his/her menetees? This action cannot be undone!"

And unless this is not obvious 🙂... This would have to be annouced so that wikis can prepare for this. I mean some procedures might need to be developed within communities. And some info for mentors would have to be prepared by local communities.

In T272376#6910592, @Nux wrote:

So proposed solution:

1. Prepare a special page to randomly re-assign mentees of a specifc mentor.
2. Bureaucrats can access this special page.
3. There should be a confirmation with a warning. Maybe something like: "This mentor has 123 mentees. Are you sure you want to re-assign his/her menetees? This action cannot be undone!"

I like this decision, but I think that such a right can be given not only to bureaucrats, but also to administrators. Some projects have no bureaucrats, and not all bureaucrats have the same rights in different projects.

It is also worth considering what message we will write to the participant whose mentor has changed. And where this message should appear. @Urbanecm_WMF suggests the following wording in T275972#6867023: "Your previous mentor is no longer available, so we assigned you a new one".

New case, at ar.wp: the ex-mentor doesn't want to see any mentees' questions anymore.

This module is part of the Mentor's homepage. But it should be available as a raw special page in a first time, to address the requests we had received.

In T272376#7138427, @Trizek-WMF wrote:

This module is part of the Mentor's homepage. But it should be available as a raw special page in a first time, to address the requests we had received.

There's Special:QuitMentorship now (working only on wikis with mentor dashboard enabled). It works (tested at cs.wikipedia), but is not (intentionally) advertised anywhere (yet). Will be linked from mentor dashboard, and that's all.

New request.

New request.

New request.

In T272376#7664192, @Trizek-WMF wrote:

renamed this task

"A way" exists, in the API, already. I don't think the "reason" why they need to be reassigned (e.g. only "quits or blocked") is that important. Design wise I suppose an important direction is: Is this something that should be run by users, or by some sort of job/trigger?

In T272376#7711722, @Xaosflux wrote:

Is this something that should be run by users, or by some sort of job/trigger?

Speaking as a volunteer mentor here, I would prefer to have the reassignment being validated by someone identified, ideally through an on-wiki request.

An automatic trigger such as removing the name from the list could lead to some abuses: one could remove all names from the list as a vandalism, leading to a complete reshuffling of the mentees.

Maybe we should automatically set the mentor as away if they are removed from the list. I think we didn't do that because of vandalism concerns, which should be easier to handle with the new structured mentor page.

If this will be triggered on-wiki, perhaps [[Special:ReassignMentees]] or the like could be created, requiring (setmentor) permissions as is already on the API.

Inputs:
*Input: a username; %mentor
*Input: A log summary %logsummary
**Possible default log summary text: A new mentor has been assigned to you, replacing a mentor that is no longer active in this process.

Process:
*Fetch the list of mentees for %mentor; %mentees
*Fetch the list of all automatic mentors from the mentor list; %mentors
*For each mentee in %mentees; setmentor = to a random mentor from %mentors

This could all be accomplished client-side with scripting, but may be easier to maintain in the extension.

This will automatically be done with T264343: Have a special page for mentors to sign up -- so connecting it to each other.

This is not really an epic, but I moved this to Epics in Progress, since it pretty much overlaps with T264343. Not having it in In progress helps me to orient better on the sprint board.