Putting this under needs discussion for @Urbanecm_WMF @RHo to discuss

Kind of related is T272376 which lets the mentor resign from mentorship and re-assign mentees to other mentors. T272376 is a mass opt-out effectively.

This is an interesting request @Trizek-WMF, thanks for filling it. If no one of the other mentors wants to take over that mentee, then the only option we've left is to disable the mentorship module for the newcomer, and let them know we disabled the module for them.

This likely will send a negative message to the newcomer, something like "no one here wants to talk to you, not even the mentors". If I were a newcomer, this would be a shock. Since mentors were created to talk with newcomers, and they don't want to talk to me, then I'm screwed. This makes me think the feature will need to be the last resort before blocking the user.

That being said, this task reminds me of Positive Reinforcement a little – one of the ideas mentioned on the project page is to offer guidance to users who make poor quality edits. If that works out fine, perhaps it would be a good idea to try offering guidance on bad mentorship-related involvement?

I agree with @Urbanecm_WMF that the most apt course of action for this (hopefully very edge) case is to disable the men tor module for the newcomer. However, we should provide some message that says something along the lines of "Your mentor has opted out of mentoring you. No other mentors are available right now, but you can get more help on editing via the <link to Help desk/Help articles>." That way the mentee knows what has happened and can still get help via other channels. And perhaps still then they still have the option to request another mentor when someone new is available in future if they so choose (since we may get new mentors at some point that may have better luck with this person).
I do think that to some extent the newcomer probably wouldn't be that shocked by the mentor opting out since in this case they have had some negative interaction with that mentor in the first place to cause the mentor to want to remove them without being able to/wanting to find a suitable replacement mentor.

The question was raised at de.wp.

The question was raised at fr.wp.

With the closure of T430252, two issues:

• an issue of terminology: this task should be retitled, Have a way for mentors to unclaim a mentee. You can opt out of an optional feature or capability; e.g., you can opt out of mentorship, and a mentee could opt out of being mentored. However, you cannot opt out of a mentee, or opt in to a mentee; you can only claim them (using your word here; other verbs are possible). And hopefully, you can also unclaim (release, remove, relinquish) them.

• I strongly disagree that the mentor module should be disabled for the newcomer. What reason could there be for placing a newcomer in a state analogous to a stateless person or second-class citizen? On the contrary—when a mentor unclaims a mentee, the mentee should be immediately reassigned to a new mentor. (As assignment is random, take care to avoid the statistically unlikely but nevertheless possible random assignment back to the same mentor who just unclaimed him). Whatever the reason for the unclaim, the reassignment should be instantaneous, and the message should be anodyne, and avoid assigning blame or giving reasons. Something along the lines of, "Your new mentor is MentorName." That's it; nothing more.

I wouldn't explain a thing ; all of Wikipedia, and all of mentorship is new to a newcomer; having a mentor changed will be New Thing #999; a mentee will have tons of more important things to worry and wonder about with respect to Wikipedia workings. Giving explanations and highlighting the fact that they no longer have a mentor and they are thus different from everybody else seems like exactly the wrong approach, and if anything makes them wonder what they did wrong, that will be it.

That user appears to be a newly registered cross-project abuser. Can someone lock/block him from Phab? Thanks.

I added some clearer acceptance criteria. Is this closer to what you were thinking?

However, I'm not sure this is a task we can work on any time soon. It seems like it could get complex and is really only helpful in a small number of edge cases.

Thanks for adding the criteria. Regarding this one:

Scenario: No mentors are available (edge case)

Can you explain how this edge case can ever happen?

My understanding hitherto was that every newly registered account receives a mentor after they make their first edit[1] (or within a short delay, on the order of a few hours). Is that correct? If that is accurate, then how can it be that no mentors are available? If that is not correct, that means there may be some new users who are not assigned a mentor. Can you link an example of a new user with one or more edits under their belt who does not have an assigned mentor?

However, I'm not sure this is a task we can work on any time soon.

Np; I understand there may be prioritization issues or other reasons that may prevent work on this. However, it is important for the ability to explain and document to users how mentorship actually works now that these questions be resolved. The issue about if and when a mentor is assigned is a very basic one. I thought it was: "All new users get a mentor assigned after their first edit." If that is mistaken, please enlighten, as I will have some FAQ items and other things to fix. (Can move this discussion off Phab and to Talk:Growth if you'd rather, as these appear to be documentation-only issues.)

[1] Actually, my previous understanding can't be right either. It seems clear that some users must be assigned a mentor before their first edit, as I see a number of mentor questions on my Talk page that are the first ever edit by the editor (examples: 1, 2, 3, 4, 5.) So that calls into question the whole issue of when newcomers really receive their mentor assignment and are aware of it, and I would really like to nail that down.

In T307488#12109976, @KStoller-WMF wrote:

I added some clearer acceptance criteria. Is this closer to what you were thinking?

However, I'm not sure this is a task we can work on any time soon. It seems like it could get complex and is really only helpful in a small number of edge cases.

I don't think the renamed task title (and your changes to the task description) reflect what's requested by volunteers from different wikis: We want a simple way to remove an account from mentoring without assigning them to another mentor.

There's no point in "unclaiming" the mentee if they get automatically reassigned to someone else (if that's what we wanted, we could just ask other mentors to claim the user which is already possible).

Some mentees behave in a way that makes their mentors feel uncomfortable, but not bad enough for admins to easily block them. A while ago we had a case where a juvenile mentor was faced with with such a mentee on German Wikipedia. Noone wanted to take the mentee, but obviously we couldn't just let a minor deal with this alone, that's why someone reluctantly agreed to claim his mentee. That shouldn't be the solution as it demotivates mentors and can decrease the acceptance of the mentorship module.

It's unfortunate that the WMF wants community members to use the mentorship module but doesn't offer support for unintended consequences (this task has been open for four years and multiple wikis stated the clear need). From a technical perspective it shouldn't be too hard to allow mentors/admins to unassign a mentee without reassigning them, given that users can already opt-out from being a mentee themselves.

Johannnes89 wrote:

I don't think the renamed task title (and your changes to the task description) reflect what's requested by volunteers from different wikis: We want a simple way to remove an account from mentoring without assigning them to another mentor.

If that is what is requested by different wikis (links, please), then I accept that, and I am okay with the most recent changes by KStoller-WMF being undone, and reverting this task back to what it was before. (Except for the terminology changes, which should be kept, because the previous usage was incorrect English.) But that means there are two use cases:

• unclaiming a user and leaving them with no mentor (this is your case, or correct me if I am wrong)
• unclaiming a user and immediately reassigning them

That simply means we need a separate ticket for the second one. There was one already, but it was closed as a duplicate. Your objection to the changes to this task, if we go forward in that direction, simply means the tasks are not duplicates, and T430252 should be reopened.

There's no point in "unclaiming" the mentee if they get automatically reassigned to someone else...

There is most certainly a point, even if it is not your use case. It makes total sense to reassign an unclaimed mentee. This gives the mentee seamless and continuous access to a mentor, with no gap. The Mentor module on their Homepage never stops working, and their question is always assigned to a mentor.

... (if that's what we wanted, we could just ask other mentors to claim the user which is already possible).

You can ask, but you may not receive. That leaves the mentee with no mentor for a day, a week, a year, or forever. Immediate, random [re]assignment is perfectly analogous with what happens when they first register. It makes eminent sense.

If your use case is different in some way, then so be it, and there are two use cases then. But T430252 is a mentor-initiated unclaim operation with good faith attached, along with the desire that the mentee not lose access to mentorship for even a moment.

Your use case sounds to me more like an 'expel mentee' operation, subject to whether some poor schmuck of a mentor wants to take them on or not (and maybe not). Expulsion of a mentee may very well be a valid option, but if so then it should be called what it is, expulsion (or, suspension, removal, eviction, etc.) and it should be attached to other operations such as a block, interaction ban, or other sanction. Separating a mentee from their mentor with no new mentor and no sanction is what exactly? That's why I used the 'stateless person' analogy.

Either you have a Mentorship feature where every new user in good standing has a mentor, or you don't. By creating a third category of users, bad enough to be expelled, not bad enough to be blocked, you are defining a new class of user, one to which there would be a reaction of confusion, not to mention shame. Either block them, if they are in violation of something, or don't. There should be no second-class citizenship among users with respect to their mentee status. And if you allowed it, there might be a conflict with T330071.

In T307488#12112206, @Mathglot wrote:

Johannnes89 wrote:

I don't think the renamed task title (and your changes to the task description) reflect what's requested by volunteers from different wikis: We want a simple way to remove an account from mentoring without assigning them to another mentor.

If that is what is requested by different wikis (links, please),

• The original task description said: "There is a way for mentees to opt-out their mentor, but there is no way for mentors to stop mentoring someone not nice. As a volunteer, I encounter this problem. What if a fellow mentor doesn't want to take my mentee away from me?"
• The link in T307488#10891047 points to a similar request on frwiki.
• The dewiki case with a juvenile mentor feeling uncomfortable due to his mentees questions was discussed in a private Discord channel (it prompted me to subscribe to this ticket in April 2024).

then I accept that, and I am okay with the most recent changes by KStoller-WMF being undone, and reverting this task back to what it was before. (Except for the terminology changes, which should be kept, because the previous usage was incorrect English.) But that means there are two use cases:

• unclaiming a user and leaving them with no mentor (this is your case, or correct me if I am wrong)
• unclaiming a user and immediately reassigning them

That simply means we need a separate ticket for the second one. There was one already, but it was closed as a duplicate. Your objection to the changes to this task, if we go forward in that direction, simply means the tasks are not duplicates, and T430252 should be reopened.

There's no point in "unclaiming" the mentee if they get automatically reassigned to someone else...

There is most certainly a point, even if it is not your use case. It makes total sense to reassign an unclaimed mentee. This gives the mentee seamless and continuous access to a mentor, with no gap. The Mentor module on their Homepage never stops working, and their question is always assigned to a mentor.

Ok you're right, in your good-faith scenario ("I'm not the best mentor for this specific mentee, but others might/will be") it makes sense to unclaim and automatically re-assign. I believe both use cases could be dealt with in the same ticket (implement the unclaim-feature and provide a checkbox to automatically re-assign the mentee to someone else which is checked per default but can be unchecked if necessary)

Your use case sounds to me more like an 'expel mentee' operation, subject to whether some poor schmuck of a mentor wants to take them on or not (and maybe not). Expulsion of a mentee may very well be a valid option, but if so then it should be called what it is, expulsion (or, suspension, removal, eviction, etc.) and it should be attached to other operations such as a block, interaction ban, or other sanction. Separating a mentee from their mentor with no new mentor and no sanction is what exactly? That's why I used the 'stateless person' analogy.

Either you have a Mentorship feature where every new user in good standing has a mentor, or you don't. By creating a third category of users, bad enough to be expelled, not bad enough to be blocked, you are defining a new class of user, one to which there would be a reaction of confusion, not to mention shame. Either block them, if they are in violation of something, or don't. There should be no second-class citizenship among users with respect to their mentee status. And if you allowed it, there might be a conflict with T330071.

This is a volunteer project. Volunteers may have different reasons why they don't want to interact with a user. We shouldn't force volunteers to keep mentees because their mentee's behaviour doesn't (yet) reach the level of a blockable offense, but is "just" annoying or "just" makes mentors feel uncomfortable.