Change 937950 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] Add reassignMentees.php maintenance script

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

Please move back to In Progress after merging, as this will need to be executed in production to complete the work.

Change 937950 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add reassignMentees.php maintenance script

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

Change 940142 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@wmf/1.41.0-wmf.18] Add reassignMentees.php maintenance script

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

Change 940142 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@wmf/1.41.0-wmf.18] Add reassignMentees.php maintenance script

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

Mentioned in SAL (#wikimedia-operations) [2023-07-24T07:17:55Z] <urbanecm@deploy1002> Started scap: Backport for [[gerrit:940142|Add reassignMentees.php maintenance script (T330071)]]

Mentioned in SAL (#wikimedia-operations) [2023-07-24T07:32:34Z] <urbanecm@deploy1002> Finished scap: Backport for [[gerrit:940142|Add reassignMentees.php maintenance script (T330071)]] (duration: 14m 39s)

Moving to QA, but feel free to move back to In Progress if that's incorrect.

In T330071#9263426, @KStoller-WMF wrote:

Moving to QA, but feel free to move back to In Progress if that's incorrect.

As I mentioned in sprint review I think, we still need to run the reassignment script I've created for this task to be completed. I need to sync with @Trizek-WMF on this. I have it as a reminder for when he comes back. Moving to Blocked for now.

IIRC, the mass confusion was on the notifications newcomers received, reaching out to their new mentor who wasn't aware of the change. I think we should work on T327493: Message received by the newcomer when their mentor quits could be improved before doing a new re-assignement.

Fixing the message will help, even if we will always have a few newcomers reaching out to their new mentor. Consequently, I think we should announce the reassignment in Tech News.

Thanks @Trizek-WMF! Let's move this to Backlog temporarily, work on T327493 first and complete this task in the next sprint.

In T330071#9276674, @Urbanecm_WMF wrote:

Thanks @Trizek-WMF! Let's move this to Backlog temporarily, work on T327493 first and complete this task in the next sprint.

With the other task having the change merged, moving into sprint.

Blocked on T327493 getting deployed and this task getting announced. Let's do this late next week (Thursday, Nov 09), if that's fine with everyone.

Re: Tech News - What wording would you suggest as the content?
Please either let me know here, or add it directly to the upcoming edition (within ~24 hours, after which it will be frozen for translations). Thanks.

I suggested the following language:

The Growth team has been hard at work enhancing Mentorship for a better user experience. On November 9th, we’re reassigning some newcomers from inactive mentors to active ones (T330071). Plus, we’ve revamped our notification language to be more user-friendly (T327493).

But @Quiddity is more than welcome to revise that to be more appropriate for Tech News.

Thanks @KStoller-WMF! I saw @Quiddity (thanks) added a revised version to the tech news already. I slightly revised it as well (diff): most importantly, I changed "inactive mentors" with "former mentors", as we do not judge activity (answering questions or just editing Wikipedia) in any way, we merely take away newcomers from users who used to serve as mentors, but don't anymore (whether by their own choice, or because they were removed by their community). Hopefully those changes make this ticket a bit easier to understand. Feel free to revert or revise further as needed!

In T330071#9305918, @Urbanecm_WMF wrote:

Thanks @KStoller-WMF! I saw @Quiddity (thanks) added a revised version to the tech news already. I slightly revised it as well (diff): most importantly, I changed "inactive mentors" with "former mentors", as we do not judge activity (answering questions or just editing Wikipedia) in any way, we merely take away newcomers from users who used to serve as mentors, but don't anymore (whether by their own choice, or because they were removed by their community). Hopefully those changes make this ticket a bit easier to understand. Feel free to revert or revise further as needed!

👍 Ah, good catch. Thank you!

We can have this deployed the week after T327493: Message received by the newcomer when their mentor quits could be improved is deployed.

Wonderful! In that case, let's aim for this Friday or Monday Nov 13. We've already mentioned this in "future changes" section of one of the recent tech news, so that should be okay doing.

Mentioned in SAL (#wikimedia-operations) [2023-11-13T20:47:18Z] <urbanecm> mwmaint2002: mwscript extensions/GrowthExperiments/maintenance/reassignMentees.php --wiki=arwiki --all --performer='Martin Urbanec (WMF)' (T330071)

Script's still running, leaving it to run overnight.

The script was stopped as apparently indefinite blocked users are getting a mentor.

Also, the log message should be changed to $oldmentor retired from mentorship., which is more neutral.

In T330071#9330899, @Trizek-WMF wrote:

The script was stopped as apparently indefinite blocked users are getting a mentor.

Split that question to T351234: Mentorship: Remove blocked users from Mentorship.

Also, the log message should be changed to $oldmentor retired from mentorship., which is more neutral.

I'm not sure I understand this. This appears to be the currently used message? Can you please fill a task describing what should get changed? Thanks!

In T330071#9331249, @Urbanecm_WMF wrote:

Also, the log message should be changed to $oldmentor retired from mentorship., which is more neutral.

I'm not sure I understand this. This appears to be the currently used message? Can you please fill a task describing what should get changed? Thanks!

T351241: Assignment script log comment should be improved

Moving out of the sprint and into Blocked.

We will postpone resuming the script until we can complete these tasks:

• Remove blocked users from Mentorship (T351234)
• Update the copy (T351241).
• Generate only one log entry when a mentor is removed from the list (T345016)
• Merge claimmentee and setmentor filters in GrowthExperiments log (T349434)

@Urbanecm_WMF: Hi, the Due Date set for this open task passed a while ago.
Could you please either update or reset the Due Date (by clicking Edit Task), or set the status of this task to resolved in case this task is done? Thanks!

Thanks for the ping @Aklapper. I removed the due date, as this turned out to be more work than anticipated, and we would need to first proceed with the tasks @KStoller_WMF listed at T330071#9342055 to be able to finish this one.

@Urbanecm_WMF - a related discussion here: https://en.wikipedia.org/wiki/Wikipedia_talk:Growth_Team_features#Quit_mentorship_but_still_receiving_questions

Does that issue sound related to this task, or is it a different bug? I would have thought that rejoining Mentorship and quitting again would have solved the issue.

In T330071#9430645, @KStoller-WMF wrote:

@Urbanecm_WMF - a related discussion here: https://en.wikipedia.org/wiki/Wikipedia_talk:Growth_Team_features#Quit_mentorship_but_still_receiving_questions

Thanks for the ping and for noticing the discussion!

Does that issue sound related to this task, or is it a different bug? I would have thought that rejoining Mentorship and quitting again would have solved the issue.

In a way, this task is a "clean things up" kind of a task. Some time back, we changed the Growth mentorship features to automatically reassign mentees assigned to a mentor who decided to quit. However, our changes do not impact any of the mentors who retired before we made them (this task exists as a clean-up for those legacy former mentors).

Even quitting mentorship for the first time should have resulted in FormalDude's mentees being reassigned to someone else. That didn't work (and it also didn't work when FormalDude tried to quit again, or when Extraordinary Writ or me removed FormalDude as a mentor manually), which is a clear bug in the reassignment system. I prefer tracking such bugs separately. To track the issue reported in the link above, I filled:

• T354220 to track the particular reported issue (FormalDude having mentees when they shouldn't have), and
• T354222 to fix the problem in a sustainable way (in other words, making quitting work for mentors who have many mentees assigned).

I decided to fill two tasks rather than one, because I can easily trigger the reassignment process server-side for FormalDude only, see T354220#9431086. I'm not yet sure how to fix the problem long-term; I'll comment at T354222 soon.

I also marked T354222 as a subtask of this ticket, since it does not make sense to proceed with the mass-reassignment until we ensure all mentors (including those with many mentees) can properly quit.

Still seem to be having issues with this. On 2024-08-07 on enwiki, we removed a retired mentor, User:Blaze Wolf :

https://en.wikipedia.org/w/index.php?title=MediaWiki%3AGrowthMentors.json&diff=1239123645&oldid=1237796440

This mentor, despite not being on the mentor list, still has mentees assigned (e.g. User:Kerashell)

In trying to determine if this is a one-off, or an extended issue with this user attempted to pull their mentee list ( https://en.wikipedia.org/w/api.php?action=query&format=jsonfm&list=growthmentormentee&formatversion=2&gemmmentor=Blaze_Wolf ) -- however this call continuously fails as a timeout so it's hard to tell.

1. Is this overall task still being considered?
2. Is there a different special problem going on with this user? (Do we need another task for it)
3. Is there a better client-side way to resolve a list of mentees for a mentor that won't fail?

Thanks for reporting this! Sorry to hear this is still an issue!
@Urbanecm_WMF - Any thoughts on this? Do you think that this is the underlying issue in this case: T354222: reassignMenteesJob is not able to finish in time when a mentor has too many mentees assigned

In T330071#10166259, @KStoller-WMF wrote:

@Urbanecm_WMF - Any thoughts on this? Do you think that this is the underlying issue in this case: T354222: reassignMenteesJob is not able to finish in time when a mentor has too many mentees assigned

Thanks for the ping Kirsten! I wasn't able to find evidence for this in logs, but I very much think so. I decided to spend some time investigating T354222, and I found out that a significant portion of the time is spent on "getting the list of mentees". This is something I was pointed to by @Xaosflux's comment regarding the timeouting APIs. The API specific timeouts are currently logged as T375784.

Once I focused on the getting the list of mentors problem, I managed to find out (and fix!) the problem in that. So, getting the set of mentees for large-scale mentors (~40k of users for both of those) should now be considerably quicker. According to my measurements, the speed of https://en.wikipedia.org/w/api.php?action=query&format=jsonfm&list=growthmentormentee&formatversion=2&gemmmentor=Blaze_Wolf went down from ~80 seconds (capped by timeout) to a couple of seconds, which is a considerable improvement.

This improvement should remove 80 seconds worth of time from the reassignMenteesJob, enabling the job to use it for the actual reassignment. Let's see how this will improve once the T375784 fix is in production.

Amazing, thank you for looking into this! Let's hope that T375784 fixes the issue.

In T330071#10181195, @KStoller-WMF wrote:

Amazing, thank you for looking into this! Let's hope that T375784 fixes the issue.

FYI, I just deployed the fix for that one to production. https://en.wikipedia.org/w/api.php?action=query&format=jsonfm&list=growthmentormentee&formatversion=2&gemmmentor=Blaze_Wolf now works. I'll try to readd and then re-remove the user to the list of mentors, to see what happens the reassignment. Hopefully, this was all it needed, but if not, we can investigate further.

In T330071#10190666, @Urbanecm_WMF wrote:

FYI, I just deployed the fix for that one to production. https://en.wikipedia.org/w/api.php?action=query&format=jsonfm&list=growthmentormentee&formatversion=2&gemmmentor=Blaze_Wolf now works. I'll try to readd and then re-remove the user to the list of mentors, to see what happens the reassignment. Hopefully, this was all it needed, but if not, we can investigate further.

Thank you. Will a general one-time cleanup be possible? (i.e. Find all orphaned mentees that may also have this issue needing their mentor reset)

I filled T376124: Removing a mentor from the list of mentors does not always reassign newcomers, since this conversation is getting out of scope for this task (the goal is to do a cleanup once this issue stops happening).

In T330071#10190739, @Xaosflux wrote:

In T330071#10190666, @Urbanecm_WMF wrote:

FYI, I just deployed the fix for that one to production. https://en.wikipedia.org/w/api.php?action=query&format=jsonfm&list=growthmentormentee&formatversion=2&gemmmentor=Blaze_Wolf now works. I'll try to readd and then re-remove the user to the list of mentors, to see what happens the reassignment. Hopefully, this was all it needed, but if not, we can investigate further.

Thank you. Will a general one-time cleanup be possible? (i.e. Find all orphaned mentees that may also have this issue needing their mentor reset)

Technically, sure. We even started doing so, but run into issues (tracked at subtasks of this task). If you want us to do the cleanup now for enwiki, even with the outstanding issues, I don't think that would be a problem. Otherwise, we would eventually get to it, once the issues we run into before are resolved.

No rush