Possible idea -- have one log entry for the entire reassignment:
Alice reassigned Bob's mentees. Reason: Bob quit mentorship
Note implementation challenge: we need to ensure we are handling errors in a reasonable way.
Given a mentor resigns,
When their mentees are reassigned,
Then only one log is generated
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Urbanecm_WMF | T323031 Check for mentors who have mentees assigned to them, while not being listed on Special:ManageMentors | |||
| Open | BUG REPORT | None | T330071 Mentorship: ensure that all mentees are assigned to an active mentor | ||
| Open | Feature | None | T345016 Generate only one log entry when a mentor is removed from the list |
Hi @Pppery,
thanks for filling this task! We discussed this request in the 2023-08-30 mentorship prioritization meeting. We agreed that the individual logs about the changes are not necessary for mass changes when a mentor quits/is removed.
Instead of adding a checkbox to hide those entries, we were considering not logging the entries when a mentor quits/is removed at all, and instead including a catch-all entry like "Mentor XY was removed/retired from mentorship and all their mentees were reassigned to a different mentor". Do you have any concerns or opinion about this alternative solution?
You don't need a log entry at all, since the removal is recorded in the history of GrowthMentors.json already. Even if new entries are no longer generated, I would still appreciate some way of filtering out the thousands of existing log entries, however,
Thanks for the reply @Pppery. I mentioned the log entry, as GrowthMentors.json edit doesn't necessarily always mean that the mentees had to be reassigned (it only happens when GrowthMentors.json is edited via Special:ManageMentors or the quit option in the dashboard, not on manual edits made by the admin). We can completely remove the logs if that makes more sense though, that shouldn't be an issue.
I would still appreciate some way of filtering out the thousands of existing log entries, however,
I'm not sure I understand this part (the ending seems to be missing) -- I understand why the checkbox might be helpful, but it seems like something that'd clear itself, since recent logs are most likely to be used.
Good point. That means that one log entry is useful.
I would still appreciate some way of filtering out the thousands of existing log entries, however,
I'm not sure I understand this part (the ending seems to be missing) -- I understand why the checkbox might be helpful, but it seems like something that'd clear itself, since recent logs are most likely to be used.
Not missing. Just typoed a comma when I meant a period. I personally regularly browse through my old contributions and logs, but I guess if nobody else cares then you can skip this part.
Rethinking this a month or so later, I haven't actually been bothered that much by the existence of 2,500 entries in my log from https://en.wikipedia.org/w/index.php?title=MediaWiki:GrowthMentors.json&diff=prev&oldid=1172255578, so I guess we don't need to worry about old events.
That this issue was surfaced as a point of frustration and confusion on eswiki.
We have a lot of other competing priorities, but moving to Up Next so we can try to make space for an improvement.
This was discussed during the Ambassadors meeting. @Sdkb raised concerns regarding implementing this, as it would imply losing information that is now available (which is sometimes helpful when looking at a mentee activity). I'm moving this away from Up Next, so that we can discuss this feedback and double check implementing this won't backfire.
I had a chance to discuss this with @Urbanecm_WMF.
We haven’t been able to identify a clear solution that reduces the logging overload without accepting some loss of information. It would be ideal if we could visually "bundle" these logs, but that would likely require a significant technical effort.
If anyone has ideas for a potential compromise, I’d be very interested to hear them.