Wikipedia talk:Growth Team features

  1. Home
  2. Wiki

Shortcut

Looking for volunteers for a test

[edit]

We are looking for a few volunteers to review a model we plan to use to identify peacock/puffery wording in new edits. Our idea is to show new users in-context help so that they can improve their edits.

If you are interested to help us reviewing a few edits, please add your name to the table at mw:Edit_check/Peacock_check/model_test, for enwiki. This task has more context, also feel free to ask your questions in response. :)

Trizek_(WMF) (talk) 14:31, 15 May 2025 (UTC)[reply]

Growth News #34

[edit]

A quarterly update from the Growth team on our work to improve the new editor experience.

Mentoring new editors

[edit]

In February, Mentorship was successfully rolled out to 100% of newcomers on English Wikipedia. Following this milestone, we collaborated with Spanish Wikipedia to expand Mentorship coverage to 70% of new accounts, with plans to reach 85% soon unless concerns are raised by mentors. (T394867)

“Add a Link” Task – Iteration and Experimentation

[edit]

Our efforts to improve and scale the “Add a Link” structured task continued across multiple fronts:

  • Community Feedback & Model Improvements: We’ve responded to community concerns with targeted changes:
    • Restricting access to newer accounts (T393688)
    • Some links types were removed to align with recommendations written in the English Wikipedia Manual of Style (T390683)
    • Allowing communities to limit “Add a Link” to newcomers (T393771)
    • The model used to suggest the links was improved to ease its training (T388258)
  • English Wikipedia rollout and A/B test: We increased the rollout to 20% of newcomers, with analysis underway. Preliminary data suggests this feature makes new account holders more likely to complete an unreverted edit. (T386029, T382603)
  • Surfacing Structured Tasks: An experiment where we show “add a link” suggestions to newly registered users while they are reading an article is running on pilot wikis (French, Persian, Indonesian, Portuguese, Egyptian Arabic). Initial results are under analysis. (T386029)

Newcomer Engagement Features

[edit]
  • “Get Started” notification: Engineering is in progress for a new notification (Echo/email) to encourage editing among newcomers with zero edits. Early research shows this type of nudge is effective. (T392256)
  • Confirmation email: We are exploring ways to simplify and improve the initial account confirmation email newly registered users receive. (T215665)

Community Configuration Enhancements

[edit]

Communities can now manage which namespaces are eligible for Event Registration via Community Configuration. (T385341)

Annual Planning

[edit]

The Wikimedia Foundation’s 2025–2026 Annual Plan is taking shape. The Growth and Editing teams will focus on the Contributor Experiences (WE1) objective, with a focus on increasing constructive edits by editors with fewer than 100 cumulative contributions.

Get Involved

[edit]

We value your insights and ideas! If you would like to participate in a discussion, share feedback, or pilot new features, please reach out on the relevant Phabricator tasks or at our talk page, in any language.

Growth team's newsletter prepared by the Growth team and posted by bot • Give feedback • Subscribe or unsubscribe.

18:51, 17 June 2025 (UTC)

"Add a link" experiment and next steps

[edit]
A mockup of the feature

Hi everyone! We wanted to reach out with an update on the "Add a link" structured task.

Background

[edit]

Structured tasks are designed to break down the editing process into a series of steps that newcomers can accomplish easily, particularly on mobile, to help them become accustomed to editing. "Add a link," the first structured task the WMF has been developing, aims to help improve underlinked articles by suggesting potential links and letting editors evaluate whether or not they are appropriate to add. You can try it out by following these steps:

As those of you monitoring this page may already know, "Add a link" was deployed on other language editions of Wikipedia starting in 2021. It was enabled for 2% of English Wikipedia users last November following this discussion. The rollout was increased gradually up to 20% of users in March. The Growth team has been working on improvements to address issues as they arise.

Experiment results

[edit]

We conducted an analysis to see the impact of the feature on newcomers here, and we're pleased to share the results, which we find very encouraging. The group of newcomers for whom the feature was enabled was 33.7% more likely to successfully make an edit that was not reverted ("constructive activation"), 3.7% more likely to stay active ("constructive retention"), and 19.6% less likely to have their edits reverted ("revert rate"). This is similar to our prior findings for the feature in other languages. We are interested to know any thoughts that this analysis brings to mind.

Next step: Proposed full rollout

[edit]

Given the experiment results, we are considering rolling out "Add a link" to all users (increasing from the current 20%). We are interested to know any thoughts or feedback you have on this plan.

The settings for "Add a link" can be changed through Community Configuration, and we are also interested to hear if there are any settings you'd like us to add to the configuration to help ensure the feature suits your needs. The default settings are the following:

  • The maximum number of "Add a link" suggested tasks a newcomer can complete daily is 25.
  • The Homepage doesn't stop suggesting "Add a link" tasks based on newcomers' total edits.

If you'd like to use different settings, feel free to discuss, and any admin will be able to implement the consensus.

Cheers,
Sdkb-WMF (talk) 17:45, 28 July 2025 (UTC)[reply]

Notified: WP:Village pump (proposals), WT:Teahouse, WT:Manual of Style/Linking. Sdkb-WMF (talk) 17:56, 28 July 2025 (UTC)[reply]
Exciting work :). Cool to see a positive effect on retention rates. —Femke 🐦 (talk) 18:22, 28 July 2025 (UTC)[reply]
Access to XMLHttpRequest at 'https://en.m.wikipedia.org/w/index.php?resetTaskCache=1&title=Special:Homepage' (redirected from 'https://en.wikipedia.org/w/index.php?title=Special:Homepage&resetTaskCache=1') from origin 'https://en.wikipedia.org' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
All the best: Rich Farmbrough 10:30, 31 July 2025 (UTC).[reply]
Hi Rich, and apologies for the delayed reply! It looks like you've pasted an error code you encountered when trying to test the feature. We're not sure what's causing that — could you share any additional details that might help us look into it? Cheers, Sdkb-WMF talk 00:03, 8 August 2025 (UTC)[reply]
User:Sdkb-WMF: I was following the testing instructions. This is the console error after pasting ge.utils.setUserVariant('addlink'). There are two "Failed to load resource: the server responded with a status of 500 () Understand this error api.php:1" already on the console. After pasting there is

{state: ƒ, always: ƒ, catch: ƒ, pipe: ƒ, then: ƒ, …} always

ƒ () catch

ƒ (fn) done

ƒ () fail

ƒ () pipe

ƒ () progress

ƒ () promise

ƒ (obj) state

ƒ () then

ƒ (onFulfilled,onRejected,onProgress) Prototype

Object

Then the CORS error then:

Access to XMLHttpRequest at 'https://en.m.wikipedia.org/w/index.php?resetTaskCache=1&title=Special:Homepage' (redirected from 'https://en.wikipedia.org/w/index.php?title=Special:Homepage&resetTaskCache=1') from origin 'https://en.wikipedia.org' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.Understand this error jquery.js:9940 GET https://en.m.wikipedia.org/w/index.php?resetTaskCache=1&title=Special:Homepage net::ERR_FAILED

All the best: Rich Farmbrough 13:18, 30 August 2025 (UTC).[reply]
Hello, @Rich Farmbrough! Thanks for sharing the additional details and for attempting to test this feature! I checked with a software engineer about the error you encountered, and it seems likely that a conflicting gadget is causing the issue. This should only affect testing through this awkward opt-in method and does not indicate a problem with the feature itself. We plan to deploy the "Add a Link" feature to all accounts tomorrow, so you’ll be able to try it in production then if you are still interested. Thanks again for taking the time to testa and follow-up with us! Best, - KStoller-WMF (talk) 22:54, 2 September 2025 (UTC)[reply]

Update: We are planning to roll out "Add a link" to all users on 2 September with the default settings. As always, we continue to welcome your thoughts and feedback. Sdkb-WMF talk 02:17, 25 August 2025 (UTC)[reply]

@Folly Mox, @Asilvering, @WhatamIdoing (I apologize for the ping if you already saw this message) I’m curious if you have thoughts on adjusting Community Configuration limits ahead of the 100% release next week.
Newcomers will inevitably make mistakes with this task, just as they do with others. If we roll it out to all accounts, we can expect more edits of this type and therefore more feedback, similar to what has been raised in Ongoing problems with adding inappropriate links.
From my perspective, I'll support whatever the community decides. That said, I would prefer to see some limits in place rather than risk significant frustration among experienced editors, which could lead to calls for disabling the task entirely.
Community Configuration allows us to limit the task in several ways, including:
  • Task availability: Restrict the feature primarily to newcomers, which is in line with its original purpose of helping people make their first successful contributions. Community Configuration allows for limiting based on newcomers' total edits (5, 20, 50, 75, or 150 edits).
  • Daily task limit: Reduce the number of Add a Link tasks available per day, which would slow down high-volume editors. (Currently this is set to 25 edits per day, but it can be set to any whole number).
In both cases, the Growth team has built user-friendly messages to explain these limits, so newcomers understand what’s happening and are less likely to feel frustrated when they reach the limit (see example: T393771).
Please let me know if you have feedback or suggestions on whether we should adjust these Community Configuration defaults before the full release. KStoller-WMF (talk) 22:58, 27 August 2025 (UTC)[reply]
@KStoller-WMF, sorry, I missed the earlier post in July. I'd have suggested jumping up to 50% or something before the full 100% for the reason you describe, but at least anecdotally speaking I haven't noticed much complaining about the list task recently - nothing for a while, actually, aside from that recent one you link to. Perhaps I'm out of the loop. It sometimes has come up in accusations of "gaming" extended confirmed, and a few times someone's been reported to SPI about it, but the kind of patrollers who tend to see these things have gotten used to it. I haven't been monitoring the teahouse as closely as I usually do, so someone there might have a different perspective. Given the "gaming" concerns I think we should probably limit it to 150 edits before giving it to 100% of editors. Do we know how many editors are hitting the 25-per-day limit? -- asilvering (talk) 23:25, 27 August 2025 (UTC)[reply]
Thanks for the feedback, @Asilvering! I don’t currently have exact metrics on how many editors reach the 25-per-day limit on English Wikipedia. However, looking at Recent Changes filtered to this task type, it’s clear that many editors complete a large number of these tasks in succession and often return to do more. On one hand, this is a positive sign, as it shows the task is engaging and encourages newcomers to continue contributing. On the other hand, these edits are often lower in value and create additional review work for experienced editors. Introducing a lower daily limit could help address this by encouraging newcomers to explore other types of editing while also reducing frustration for patrollers and experienced editors.
I also agree that setting a cap of 150 total edits for this task should help address concerns about “gaming” the system, and if we set a limit it might be nice to first start with a higher limit like 150 rather than setting it very low initially. KStoller-WMF (talk) 00:02, 28 August 2025 (UTC)[reply]
My main suggestion for timing is: Don't do anything that's anywhere near the mw:Temporary accounts deployment here. You either want it to be several weeks before, or several weeks after that, with the goal that your project can't be blamed for anything related to that.
I like the idea of having a fairly high task availability limit. The combination of 25/day and 150/total means that someone who really loved this task (and was good enough that they didn't get blocked, etc.) might be limited to do this for just six days. That's not very much. WhatamIdoing (talk) 01:15, 28 August 2025 (UTC)[reply]
Hi all! We're deploying tomorrow rather than today due to staffing reasons, but otherwise proceeding on track.
We won't be adjusting the Community Configuration settings (e.g. restricting tasks per day or limiting to newcomers) ourselves so as to leave that in your control, but any admin can change them based on your reading of consensus in the discussion we've had so far.
Cheers, Sdkb-WMF talk 23:11, 2 September 2025 (UTC)[reply]
The Add a Link task is now available to all accounts at English Wikipedia.
All newly created accounts will receive this task (and other "easy" tasks) by default from their Suggested Edits feed on their Homepage, AKA Special:Homepage. Admins can adjust limits and settings for this task via Special:CommunityConfiguration/GrowthSuggestedEdits. KStoller-WMF (talk) 19:19, 3 September 2025 (UTC)[reply]
I've set it to 15/day and <150 edits total for now, and we'll see how that goes. -- asilvering (talk) 21:34, 3 September 2025 (UTC)[reply]
[edit]

Yet again, my watchlist had two inappropriate suggested links added by the same user without any care being taken. One of them maybe stemmed from that person not understanding the difference between a town and a pastoral station (but then, if you don't understand the topic area, why attempt to edit that article at all?). But this edit by the same person shows they are NOT checking anything.


https://en.wikipedia.org/w/index.php?title=Australian_Geography_Competition&diff=1307996407&oldid=1307816663


Replacing the plain English words "the Australian team" with a link to the newspaper The Australian. Surely there is no way anyone could think that appropriate substitution. If I spotted two on my watchlist, how many other similarly inappropriate substitution is this user making on other articles which don't have someone actively watching. I personally do not edit articles that are outside my areas of knowledge for these reasons, yet this growth program is randomly parachuting new users into articles that are evidently outside their areas of knowledge and they are blindly making the suggested change. Can we please get a bit smarter and find out some things about these new users (e.g. variant of English they use), topics of interest and limit suggestions to articles that are in their variant of English (sick of American "spelling fixes" on Australian articles) and within their likely ability to assess the link selection as being appropriate or not. I do not know what these new users are shown about the suggested add-a-link tasks but can they be shown the lede at least of the suggested link and asked to tick a box confirming they have read it before then adding link. I think someone needs to review all of this user's edits based on what I have seen of their behaviour. I think the growth team need to review these edits themselves and not make it an extra burden (as it is) on already overworked active editors. Thanks. Kerry (talk) 22:55, 26 August 2025 (UTC)[reply]

Thank you for reaching out, @Kerry Raymond!
Newcomers can select topics that interest them. Seeing the user's contributions, it is quite clear that they edits mostly about Australia like you do. Maybe a local? (Or a fan?) Have you contacted them so that they would learn the specifics and fix their mistakes? Add a link provides onboarding, but that onboarding is not specific to topics.
Also looking at the 383 edits this user made, they mostly Add links. 9 were reverted. I know that reviewing all their edits would take time, so maybe some of the remaining edits remain unchecked. Putting things in perspective, most of the time, edits made by most users aren't checked. Have you specifically checked these edits as they were tagged as Add a link, or was it part of your usual watchlist monitoring?
Seeing that this user is mostly doing links additions, maybe it is time for them to move to another task type? Add a link has been proven as an efficient way to start editing (and understand that it is possible to edit, which is not natural to many). It is possible to limit the number of articles users can add links to, through Community Configuration. Communities can decide on the number of articles newcomers can add links to daily, and for how long. The was one of the options offered on the Add a link rollout conversation, above. What would be your suggestion regarding a configuration change so that newcomers can start editing, but users like you wouldn't be overwhelmed?
Thank you, Trizek_(WMF) (talk) 18:16, 27 August 2025 (UTC)[reply]
I am not monitoring this program specifically. I am just monitoring my watchlist and this program comes up a lot. I contribute to Queensland content, mostly places (a narrow subset of Australian content) but still gives me a watchlist of about 13,000 articles, (any more means that you hit the bug in the watchlist software where it times out which prevents you from editing your watchlist, any chance of getting this long-reported bug fixed?!) which keeps me very busy and most days I don't get to check all of the edits that appear on my watchlist -- just too many most days or I would do nothing else. If this person is Australian, then their inability to distinguish a town from a pastoral run and that "The Australian" is a major newspaper and not something that be substituted for any random use of words "the Australian" makes their behaviour even more incomprehensible (hence my assumption they were not Australian). Have I contacted this user? Yes, as I would have written an edit summary when I reverted their edits. Not sure if I also put a message on their User Talk page (they would not have been the only person who appeared on my watchlist with problematic edits so I have to decide if they seem like someone worth the effort). Given the nature of the error being made (totally inappropriate link addition) would have made me think that this wasn't someone who showed any potential of being a useful contributor, just mindlessly adding whatever was suggested without any exercise of judgement. My experience on wiki over many years is that communicating with new users about problematic edits via User Talk rarely achieves anything than a waste of my time, so I tend to be selective (or use a canned Twinkle reponse). I do new editor training via Zoom through Wikimedia Australia and through my own on-wiki outreach so I am quite willing to invest time in new users, but these are new users wanting to be helped. This onboarding project has significantly increased my daily watchlist and I guess I am getting pretty fed up with the assumption that volunteers like me have nothing better to do than monitor and clean up the problems that arise from this program. Aside, I recently completed 300K edits and you know what -- WMF can't even bother to have an automated process to send you a thank-you so it is pretty obvious that WMF doesn't value volunteers (aside, if it was an automated process, I'd have valued it even lower -- at least it was a honest "couldn't care less" that I got). Anyway, I have heard that this program assesses the revert rate on these suggested edits, but I suspect many of them are not being reviewed at all, so I suggest the success metrics for the project should not just be the revert rate but a more thorough review of the edits (particularly focussing on users who do get reverted to see why and whether the user seems to learn or not from being reverted) and importantly whether these new people progress to more "high value" contributions. A lot of the links being added are to peripheral topics in the article (probably because the important related topics are already linked); I have a couple of thousand heritage buildings on my watchlist and this program is constantly adding a lot of links from these building articles to articles like Sash window and other very common architectural features when the significance of the building rarely relates having common architectural features. Harmless (apart from MOS:SEAOFBLUE issues) but not the best use of everyone's time (to add the link, or to review it). Kerry (talk) 01:22, 28 August 2025 (UTC)[reply]

I have reviewed a few edits, and I am concerned that we may need a programme to review all the " Suggested: add links" edits. One specific feature that might help reduce false links is case sensitivity. The example of "listen to the music" being linked to Listen to the Music is a good one. There's room for some nuance here, as editors often make capitalization errors, and (substantially) all article names start with capitals, but the principle is there to build on. All the best: Rich Farmbrough 10:07, 3 September 2025 (UTC).[reply]

Thanks for the feedback, @Rich Farmbrough. Sdkb-WMF and I discussed this and we will create a task to capture next steps, including coordinating with the Machine Learning team, which maintains the model powering this feature.
I agree that, similar to most newcomer edits, it would be valuable to review Add a Link edits. Earlier today I spent some time reviewing Suggested: Add Links edits on English Wikipedia with my volunteer account. While most were correct, I did find a few errors, which I fixed.
In the short-term, @Sdkb-WMF and I talked about drafting a revert message specific to this task. Do you think that would help?
Looking ahead, as the Moderator Tools team explores ways to encourage more contributors to participate in patrolling and moderation, do you think tasks like this could serve as a way to introduce the basics of reviewing diffs? KStoller-WMF (talk) 23:05, 9 September 2025 (UTC)[reply]
@KStoller-WMF, I think a revert message specific to this task would be great - how do you imagine this working? I also think that the moderator tools idea is worth pursuing. Being able to funnel editors who have hit the suggested links edit cap into reviewing other editors' suggested links edits could be an interesting task. -- asilvering (talk) 03:14, 10 September 2025 (UTC)[reply]

Mentor inactivity threshold

[edit]

For a while I've been marking mentors with no edits in two months as "away" so that questions aren't directed to inactive users. I've seen several requests, most recently at WP:AN#Inactive mentors to mark mentors who have been inactive for less time as away, so it seems the community thinks two months is too long. But then there's no agreed-upon threshold for when to do this; I invented two months out of a hat a year ago for reasons I can't recall, Aaron Liu suggested one month there, and so on. I'm fine with anything, but we should have a consistent standard, not "when does somebody notice".

Under what circumstances should admins mark inactive mentors as "Away"? * Pppery * it has begun... 21:41, 28 August 2025 (UTC)[reply]

At the mwwiki growth team development page I suggested a software feature to automatically away someone when they have four unanswered questions (maybe since they last edited). Aaron Liu (talk) 00:06, 29 August 2025 (UTC)[reply]
I like @Aaron Liu's idea, but in lieu (sorry) of that technical solution, we ought to pick something. I think even a month is really pushing it, but maybe it's worth trying a month for now, @Pppery? -- asilvering (talk) 00:59, 29 August 2025 (UTC)[reply]
I also like Aaron Liu's suggestion. Barring that, doesn’t the mentor dashboard suggest setting yourself as away if you’re going to be out for more than a week? I’d think two weeks a reasonable period of time, but shortening to a month is fine with me for now. Happy editing, Perfect4th (talk) 01:23, 29 August 2025 (UTC)[reply]
Just saw this via AN, I'm a little late to the party. Thanks Pppery for your work checking this list. In my view, if an editor has not edited at all for two weeks, they should be marked as inactive. I'm not a developer, but time since last edit seems like it would be easy to check. Honestly, even one week of inactivity is pushing it. A lot of mentees (perhaps unfairly) expect answers in real time or within a day; even if we're not chatbots, we should try to be quick so as to not disappoint. Checking for a certain number of unanswered questions is probably very complicated, but if it can be done it would be a better metric. IMO four unanswered questions is too generous. I get that not all questions are worth an answer, but I think two or three unanswered questions would be the limit for me.
Another task for the Mediawiki folks: Mentors who get blocked should be automatically marked as inactive or removed from the mentor list entirely. Toadspike [Talk] 20:01, 30 August 2025 (UTC)[reply]
I think blocked mentors already are effectively marked away. * Pppery * it has begun... 20:14, 30 August 2025 (UTC)[reply]
By "effectively", do you mean "enwiki admins are on top of this" or "the software does it automatically"? I know it probably doesn't matter much for us, but if it's the former I'd still like to file a Phab ticket for automatic removal, as it might help smaller projects with fewer active admins keeping an eye on obscure features like this. Toadspike [Talk] 02:41, 31 August 2025 (UTC)[reply]
I mean the latter; except being blocked and being away are different statuses in the software, so they aren't actually marked away but mentor questions are nevertheless not directed to them. Although I agree that was ambiguous. * Pppery * it has begun... 03:11, 31 August 2025 (UTC)[reply]
See phab:T317148. * Pppery * it has begun... 03:13, 31 August 2025 (UTC)[reply]

Another question, then: right now when I mark a mentor as away I mark them as away for the maximum one year, thinking I have no idea when (if ever) they will come back. They can still go to Special:MentorDashboard and reset their own status to active. Is this correct?

(It's happened twice before that a mentor stayed inactive for a whole year and their away period expired. In that case I just removed them from the list entirely which reassigned all of their mentees). * Pppery * it has begun... 20:14, 30 August 2025 (UTC)[reply]

I would think so, though of course with notification of the mentors awayed. Aaron Liu (talk) 23:00, 30 August 2025 (UTC)[reply]
A bit late on the conversation, but I'm wondering if the opposite could be doable – automatically marking mentors as active if they were auto-set as inactive and started editing again? Of course, that shouldn't affect people who set themselves as inactive on their own, so maybe it could be worth it to create a separate status ("auto-inactive" or "stale" maybe?) that can be automatically set after a time of inactivity. If technically possible, the "checking unanswered questions" aspect is also worth looking into, especially since this automatic status could be removed once answers to these talk page questions are detected. Chaotic Enby (talk · contribs) 14:05, 9 September 2025 (UTC)[reply]
This would probably be really helpful. I don't have numbers to back that up but I expect it's pretty common for people to set themselves as inactive and forget to reactivate. -- asilvering (talk) 19:27, 10 September 2025 (UTC)[reply]

I think I'll have a go at creating WP:Database reports/Unanswered mentor questions; it looks like something that should be doable (I tried a few times to come up with a reasonable way write a report for this yesterday and couldn't find any way of getting the list of mentors into a database query for arcane technical reasons but then I had the epiphany that it's better to focus on this in a question-by-question level rather than a user-by-user level, allowing me to not care whether the "mentor" is really on the mentor list). * Pppery * it has begun... 20:23, 30 August 2025 (UTC)[reply]

@Pppery, can you add a timestamp column to that report? Then it's really easy to sort by age. -- asilvering (talk) 20:58, 30 August 2025 (UTC)[reply]
I thought the report was already ordered by age, but sure, I've added a timestamp. And, having created this report, I'm frankly horrified at what I've unleashed. * Pppery * it has begun... 21:16, 30 August 2025 (UTC)[reply]
Ok, I've given Pickers an off-wiki poke and I think we should probably be removing Alex from mentorship entirely for now - thoughts? -- asilvering (talk) 21:22, 30 August 2025 (UTC)[reply]
Assuming you mean Alextejthompson, their only fault seems to have been going unexpectedly inactive (they haven't edited since July 30), combined with their large number of mentees. I would just mark them as "away" for now; I don't see cause for the more extreme action of removing them entirely from mentorship. * Pppery * it has begun... 21:25, 30 August 2025 (UTC)[reply]
Based on the message on their user page, I suggest marking Pickersgill-Cunliffe as Away for a while. Toadspike [Talk] 02:49, 31 August 2025 (UTC)[reply]
I have marked Pickersgill-Cunliffe, Alextejthompson, and everyone else who has been inactive for at least a month as away. (I left Raydann alone since their self-marked away period expired only today so I'd give them a week or two to return to activity before extending it). Looking at the report, the following mentors have four unanswered questions in the last month, discounting people who are already away:
1AmNobody24
Aafi
(Aaron Liu is listed in the broad version of the report but is a false positive)
Alpha3031
(AlphaBetaGamma is listed in the broad version of the report but is a false positive)
Ampimd (sidenote: they also seem to be using AI to answer the questions they do answer)
(Bsoyka is listed in the broad version of the report but is a false positive)
Destinyokhiria
Estar8806
Ferien
(GraziePrego is listed in the broad version of the report but is a false positive)
Idoghor Melody
JayCubby
JJPMaster
Lordseriouspig
Mwwv
Nedia020415
Như Gây Mê
NightWolf1223
(Oshwah is listed in the broad report but seems to be a false positive - mostly talk page stalkers answered before he could)
Rambley
Relativity
Robertjamal12
Royiswariii
(Shellwood is listed in the broad report but seems to be a false positive)
(Shushugah is listed in the broad report but seems to be a false positive)
Snowmanonahoe
(Thebiguglyalien is listed in the broad report but seems to be a false positive)
Vacant0
Vermont
Zippybonzo
(Deliberately not pinging these people)
I can't bring myself to mark so many people as away, many of whom are still actively editing just not consistently responding to every question; if some other admin wants to move things in that direction they'll have to take the initiative themselves. * Pppery * it has begun... 03:56, 31 August 2025 (UTC)[reply]
Better to pester those folks to remind them to respond to their mentorship questions, I'd say. -- asilvering (talk) 03:59, 31 August 2025 (UTC)[reply]
As for the AI one... christ. They've got AP too. I call "not it". -- asilvering (talk) 04:01, 31 August 2025 (UTC)[reply]
I call "not it" too. I don't think I have the will to actually enforce any kind of unanswered questions rule (I'm not in the right state of mind to pester so many people), but I will keep awaying mentors at one month of inactivity rather than two when I do my periodic maintenance checks. * Pppery * it has begun... 04:10, 31 August 2025 (UTC)[reply]
I answered the newest question and asked one(/two) of my own about the AI use on Ampimd's talk page. I largely just addressed questions though, and while I did little else GPTZero does think a large part of the one recent article diff I checked is AI-generated, so article text may need something further. I checked most of the refs in that edit and they looked fine, though. Perfect4th (talk) 15:54, 1 September 2025 (UTC)[reply]
Having false positives is interesting. My answering of questions do include the section in the edit summary: Nahwikiweh Aaron Liu (talk) 17:45, 31 August 2025 (UTC)[reply]
The problem for you seems to be that you're using some script that adds extra emojis to section headers, so, for example, this answer isn't detected by my dumb report as matching the question because one has an emoji and the other doesn't. * Pppery * it has begun... 19:15, 31 August 2025 (UTC)[reply]
Ah, that is true; I use User:Bugghost/Scripts/UserRoleIndicator. I'll see if I can fix the script.
On initial investigation it looks like the problem is also with WP:Convenient Discussions. The script doesn't break the section-editing autocomment but CD adds its own. Aaron Liu (talk) 20:20, 31 August 2025 (UTC)[reply]
I've removed Nedia020415 from mentorship entirely since their user page says retired. * Pppery * it has begun... 21:58, 3 September 2025 (UTC)[reply]