####User story & summary:
As an admin who cares about new editors receiving timely responses to their mentorship questions, I want to be able to monitor mentors and be fully informed about Mentor activity and responsiveness so I can make the right decision about whether to be proactive and reach out to a Mentor, reassign their mentees, possibly dementor them, or whether to allow a proposed automatic procedure (see T321509) to take over and cull them when a configured threshold is reached.
As a Growth team member interested in Mentorship, I need data about mentor activity, responsiveness, awayness, performance, abandonment, and exit from the program so I can measure and evaluate how Mentors are performing overall at an individual wiki and know how to best allocate team resources to optimize for mentee satisfaction and retention based on mentor response.
####Background:
Currently, an admin has no easy access to information about mentor activity, as it affects what mentees are experiencing from their mentors. At task T321509, @Kudpung pointed out (at T321509#11881665) that a mentee was assigned a mentor with 1,465 edits and 508 days of inactivity. Some wikis (de, ru, ko) are coming up with bot-driven auto-dementorship to deal with this. As a partial solution, T321509 "Provide a system to automatically suspend or remove mentors from the list of mentors" was proposed. That proposal addresses the issue of ensuring we do not miss cases where mentors are inactive for long periods via a new automated dementorship process.
What the current manual system and the proposed automated system have in common is that they both lack the ability to provide admins with access to full information about mentor status and activity to support admins who wish to remain fully abreast of mentor status in order to support making administrative decisions about mentors when warranted. Under the current system, we don't know about Mentor1465 and their 508 days of inactivity, so admins don't do anything about them. Under the proposed system, we still don't know anything about Mentor-1465; the automated process will eventually strip their bit and reassign their mentees, and we will either learn about it after the fact (if logged or otherwise reported) or we will never know at all. The admin is left out of the picture, even if they might have been able to help (either the mentor, or the mentee) earlier in the process, had they been aware.
Regarding the automated system, in T321509#11882195, @KStoller-WMF wrote:
> It is important to note that this type of automation can address inactivity, but it cannot reliably identify or remove mentors who are ineffective, as that would be much harder (and likely problematic) to attempt to address programmatically.
We need to support providing admins the information they need to reliably monitor and remove ineffective mentors in a way an automated system cannot. The way to support admins in this way is via a new dashboard tool that provides the missing information.
####Proposal:
A new reporting tool should be created aimed at admins to provide them the ability to make manual decisions about mentors when appropriate. A **Mentor Status Dashboard** is proposed.
The Mentor Status Dashboard should be a table of all mentors with sortable columns:
* MENTOR – mentor name
* RTNDAT – self-declared away status/return date
* LEDAT – date of last WP edit
* N30 – number of edits in last 30 days
* LQDAT – date of last mentee question
* LADAT – date of last mentor response ('A' for answer, as in Q&**A**)
And some frequency stats t.b.d. to assess mentor activity, but perhaps things like:
* Q30 – number of mentee questions in last 30 days to this mentor ('volume'; skip last 5 days)
* A30 – number of mentor answers in last 30 days from this mentor ('responses'; skip last 5 days)
* NA30 – number of mentee questions in last 30 days not answered ('dropped'; skip last 5 days?)
* A30pctQ – mentor answers as a percent of all mentee questions in last 30 days, i.e., A30*100/Q30 ('responsiveness')
* MTBQ30 – mean time between mentee questions in last 30 days ('mean Q frequency')
* MTBA30 – mean time between mentor answers/responses ('mean A frequency'
and maybe also some stats to assess mentor burden, like:
* A30pctE – mentor answers as a percent of all mentor edits in last 30 days (skip 5), i.e., A30*100/N30 ('burden')
This would provide admins with the data they need to watch what is going on, never miss a user like Mentor-1465 again, and decide what, if anything, to do about a mentor nearing (one of?) the dementorship threshold(s?).
#####Style
As for styling, some things to consider:
* mentor name – set max-width and force-wrap or use ellipsis with tooltip to limit col 1 width and avoid horizontal scroll
* liberal use of classes and a default style sheet, in order to enable individual admins to restyle the table to their liking using common.css.
* perhaps an unobtrusive row background coloring of faded green, amber, and pink to highlight mentors at various levels of activity relative to a local community threshold might be useful; or just several row classes with no default bg-color so individual admins could pick their own scheme for whether and how to highlight.
* transparency – who should be able to view it (everyone, imho)
* dementor column – an optional convenience column with action and/or visibility restricted to admins which would remove the mentorship bit and initiate mentee reassignment
NOTE: Not shown are other stats of more interest to the Growth team itself, such as abandonment (no answer to questions, but mentor still active) and exit from the program. But stats like 'burden' (here defined as A30pctE, perhaps others) should be plotted against abandonment as curves on a time-series graph, which might give an early warning about individual mentors who are approaching values that indicate they are at risk for leaving or not answering based on previous experience. If averaged over all mentors, it could show when a program at an individual wiki program is at risk and needs resources applied to recruitment.