Thanks for the task! I'm wondering what kind of changes would be desirable here. The parent task (T351234) asks for the mentor/mentee relationship to be dropped for mentees who are indefinitely blocked, which is what is happening here. From a "follow specs" perspective, GrowthExperiments is doing exactly what we decided it should do.

We can, of course, revisit that decision and do something else. I'm, however, not sure what that could be. From a technical perspective, there are two things we can do on a block:

• remember the mentor/mentee relationship forever (that is, until the mentor resigns),
• drop the relationship (if we do that, then MediaWiki no longer knows who that mentor is, so the relationship cannot be restored)

The first causes confusion when the mentor resigns ("why are those users still assigned to me, they were blocked YEARS ago"), the second one causes confusion when the mentee was indefinitely blocked for a very short while, for example for username violations.

From the potential A/Cs listed in the task:

Avoid automatically deallocating mentees until a certain amount of time has passed

This is possible, but fairly challenging. An option if we really want to, but I'd like to avoid it if possible.

After unblock, reassign the original mentor if the block was temporary

As described above, this is impossible to do. If the block doesn't have a fixed expiry, the relationship is dropped from the database, and we no longer know what it was. If the block has a definite expiry, the relationship survives the block.

Maybe it would make sense to only drop the relationship when the mentor resigns? In other words, blocked users would keep their mentor as long as that mentor keeps being a mentor; if they resign, the relationship is dropped, and the blocked user would be assigned a brand new mentor once (if) they are unblocked.

Would that fix the issue, @AllyD? Do you have any concerns about this, @KStoller-WMF?

Hmm, I do worry that if we only drop the mentor–mentee relationship when a mentor resigns, we may end up back where we started: with mentors feeling frustrated that they’re still assigned to accounts that have been blocked.

If I’m understanding correctly, block reasons vary across wikis, so it may not be straightforward to automatically exclude certain types of blocks (like “Username policy violation”) from triggering a mentorship change.

Unless @Trizek-WMF or others have suggestions for a lightweight solution here, I wonder if this might be lower priority compared to other Mentorship improvements we’re considering?

Thanks for the detailed explanation of the background and options, @Urbanecm_WMF.

Looking at T351234, there were two points of possible intervention: (1) at the point when a mentee is blocked, or (2) at the point when a batch of mentees are being reallocated after a mentor's resignation. Point (2) would have the virtue of only dropping a mentor-mentee relation when both parties to any prior conversation are no longer involved, but I do recognise it would give a heavier process of checking the block status of each of many mentee's while transferring.

Personally, having >200 mentees who are notionally active but only ever made 1 edit (often only to create a User page), which is presumably typical on en.wiki, I would not be too bothered by having blocked mentees on my list, but I appreciate that other mentors may have more active oversight workflows and find the blocked mentees obtrusive.

I wouldn't want to retread prior action resolutions, or to add complexity which may not sit well across different wiki's block processes. That said, I do have the nagging feeling that the people in most need of mentor involvement may be those hit with a liftable block - not just the Inappropriate Username ones, but also sometimes those blocked because they were repeatedly added reverted "facts" that they regard as true, where a block is to force them to respond. (I might even go further, and suggest that any mentee block should be notified on the mentor's talk page, so that they can offer advice, but that is going beyond the matter in hand.)

In T392280#10789119, @Urbanecm_WMF wrote:

blocked users would keep their mentor as long as that mentor keeps being a mentor

I'm not sure if it matters, but with the current statistics on enwiki, that would mean we keep 70k connections per year, while there's only 10% of that in unblocks. That looks like it would add up quite quickly.

In T392280#10794242, @KStoller-WMF wrote:

If I’m understanding correctly, block reasons vary across wikis, so it may not be straightforward to automatically exclude certain types of blocks (like “Username policy violation”) from triggering a mentorship change.

That is correct -- block reasons are completely unstructured, which means we only know an user was blocked (and when the block expires), but not why the block was imposed and whether it is likely to be removed at some point. IIRC, @kostajh and me talked about potentially structuring block reasons across wikis at Wikimedia-Hackathon-2024, but I'm unable to find any Phabricator records of that conversation. Kosta, do you have something to add here?

In T392280#10810965, @1AmNobody24 wrote:

In T392280#10789119, @Urbanecm_WMF wrote:

blocked users would keep their mentor as long as that mentor keeps being a mentor

I'm not sure if it matters, but with the current statistics on enwiki, that would mean we keep 70k connections per year, while there's only 10% of that in unblocks. That looks like it would add up quite quickly.

It shouldn't be a problem from a storage perspective, the relationship data are fairly small. It might be a problem for eg. Mentee overview (which has an upper limit on the number of mentees it can handle), but this is resolved by looking at active mentees only, and blocked mentees wouldn't be active.

In T392280#10811321, @Urbanecm_WMF wrote:

In T392280#10794242, @KStoller-WMF wrote:

If I’m understanding correctly, block reasons vary across wikis, so it may not be straightforward to automatically exclude certain types of blocks (like “Username policy violation”) from triggering a mentorship change.

That is correct -- block reasons are completely unstructured, which means we only know an user was blocked (and when the block expires), but not why the block was imposed and whether it is likely to be removed at some point. IIRC, @kostajh and me talked about potentially structuring block reasons across wikis at Wikimedia-Hackathon-2024, but I'm unable to find any Phabricator records of that conversation. Kosta, do you have something to add here?

@KStoller-WMF FWIW, T352148: Blocks: add a structured category/reason field for cross-wiki use is the task I was trying to find a link to.