Talk:Growth

Interact with the Growth team | Community conversations | Newsletter | Contact page

The following Wikimedia Foundation staff monitor this page: KStoller-WMF Timezone: UTC−8 Language(s): en

• Discussions using Structured Discussions are at Talk:Growth/2023. Wikitext exports are at Talk:Growth/2018, Talk:Growth/2019, Talk:Growth/2020, Talk:Growth/2021, Talk:Growth/2022, Talk:Growth/2023/Flow export.
• Discussion related to the old Growth team is archived at Talk:Growth/Growth 2014.

It's not clear from this page whether it's scope is per-user, per-wiki or something else. It needs to be more clearly an admin function. Also "privileged users" needs to link to explaine xactly what privileges are needed. Stuartyeates (talk) 20:09, 23 April 2024 (UTC)Reply

@Stuartyeates - sorry for the delay in responding! This Special page is "per-wiki", and I agree we could make this more clear.

The Growth team is actually working on a Community Configuration project right now that will address UI improvements, along with some fundamental changes to this feature. You can check out the in-progress version of the new Special page that will eventually replace Special:EditGrowthConfig on Spanish Beta:

https://es.wikipedia.beta.wmflabs.org/wiki/Especial:CommunityConfiguration

Does that landing page help add clarity, or do you think we need to add additional guidance? KStoller-WMF (talk) 21:54, 7 May 2024 (UTC)Reply

A few months ago I uploaded a crappy MP3 file of neighbourhood traffic noise to Soundcloud, and that triggered a sequence of emails from Soundcloud saying welcome and encouraging me to add more. Every commercial website of course does this - you sign up and they email you repeatedly until you unsubscribe Wikipedia doesn't seem to send new users automated emails even when we have their email addresses. Is there a reason we don't do this? Clayoquot (talk) 17:49, 2 May 2024 (UTC)Reply

@Clayoquot, thanks for the feedback! I would love to focus on a series of onboarding emails! We have some initial project ideas documented here: Growth/Personalized first day/Engagement emails. And we even completed an initial Welcome email experiment.

And last month, Growth released a new feature as part of our Positive Reinforcement project that will generate a notification and an associated email (if the new account has an associated email address). But the email is just the standard Echo notification generated email, certainly not what I would call adequate onboarding.

My understanding was the Engagement email project was put on hold, partially because of the low emailability rates. Many new accounts don't associate an email address with their account, and those that do often never verify their email address.

That being said, I personally still think it's worth restarting the engagement emails project in the future. This next fiscal year, the WMF Product & Technology annual plan key results includes a focus on improving "constructive activation" (AKA the number of new accounts that try editing and don't have their edit reverted). And I think engagement emails could be one potential way to move the needle on constructive activation.

Do you have any thoughts on what we should include in onboarding / engagement emails? Should they be mainly focused on learning about how to get started editing? How can we strike the right balance between zero onboarding emails and the "they email you repeatedly until you unsubscribe" standard that is (unfortunately) the norm across the internet? KStoller-WMF (talk) 22:31, 7 May 2024 (UTC)Reply

Thanks for the detailed reply! The main things I was going to suggest were:

- Traffic statistics (I see you've already explored that).

- Explain what Watchlists are and encourage the person to add articles to their watchlist so they can see what other people are doing and join in conversations.

- Encourage the person to log in and check their watchlist regularly.

- Address privacy concerns that might make people hesitate to log in or to use watchlists. E.g. who can see what articles I add to my watchlist? Who can see what articles I visit and what search terms I use when I'm logged in?

Fix the bug in which if you change your preferences to be emailed whenever an article on your watchlist changes, it works for articles that are already on your watchlist. Currently it only works for articles that you add to your watchlist after changing the preference.

Regarding what should trigger emails, the default should be to email them whenever someone posts a message to their talk page or thanks them. Assume they don't log in and the only way the community can communicate with them is by email. Keep assuming this until they ask to stop being notified about talk page messages and thank-yous.

To encourage people to provide their email addresses when they register, tell them about the benefits. E.g. you'll be notified if an article you wrote is nominated for deletion. Also tell them about what Wikipedia usage data is and isn't associated with their email address.

Whatever you do, if someone has shown a talent for writing about a serious and under-served topic, please don't give them task suggestions that distract them from why they started editing. Clayoquot (talk) 01:39, 13 May 2024 (UTC)Reply

@Clayoquot, thanks for all of the suggestions; I agree those are all important concepts for new editors to learn about.

By Traffic statistics, do you mean like pageview stats? Something like: https://en.wikipedia.org/wiki/Special:Impact/Clayoquot?

The Growth team has increased emailability rates by adding the following prompt to the Welcome survey after account creation (the prompt only displays if an email address wasn't already added):

We noticed you didn’t enter an email when creating this account. It’s highly recommended, since an email is needed for account recovery if you ever lose your password. NOTE: Your email address is not revealed when other users contact you.

But I agree there is more we can do to encourage people to associate email addresses with their accounts.

And your last point is critical in all of this; I want to ensure Growth features support newcomers that need the additional guidance and structure, but I also want to ensure this onboarding isn't distracting new editors that are self-motivated and passionate about contributing to an under-served topic. In fact, the Growth team has been thinking more about how we can help connect new editors with other community members and help highlight knowledge gaps, here's a related project we will work on soon: Community Updates. This will just be a small experiment, but hopefully a way for communities to highlight meaningful ways for new editors to get involved. We are early in planning the Community Updates experiment, so please let me know if you have any thoughts! KStoller-WMF (talk) 23:50, 21 May 2024 (UTC)Reply

Thanks Kirsten. Re "By Traffic statistics, do you mean like pageview stats?", yes. I had never seen the Special:Impact page before. I think that's the right idea. I'd prefer to see pageview stats in addition to (or instead of) than "Most viewed (since edit was made)" which presumably biases the results towards older edits. And I don't know why it maxes out at showing statistics for just 5 articles. I would expect to be able to click something to see statistics for all articles that I've edited.

It would be good for the Impact page to say whether the list of articles it shows includes articles in which my edits were reverted. If we have a way of telling people what percentage of their edits and/or what percentage of text they added has stuck, I think that would be useful information.

Regarding Community Updates, I'm totally meh on this. The English Wikipedia does not really have "events, projects, campaigns, and initiatives" that would be of broad interest to Learners. "Events", "campaigns", and "initiatives" might be familiar concepts to offline organizers and activists, but they seldom emerge from the way Wikipedia itself operates. I hope "Community Updates" doesn't become another Portals.

Many Wikiprojects used to do things like "collaboration of the month", which was great because it brought together newer and more experienced people who shared interests in a particular topic area. Unfortunately as I'm sure you're aware, most Wikiprojects have stagnated and some currently might be worse than nothing, e.g. WikiProject Cetaceans has a sign-up list but after someone signs up nothing happens. Is the WMF looking into things like trying to help rejuvunate Wikiprojects? Clayoquot (talk) 18:12, 22 May 2024 (UTC)Reply

Hello,

I am using the mentor dashboard quite frequently as a mentor on the English Wikipedia (and I love it!). I currently have "about twice the average" of mentees assigned to me, and was wondering if it could be possible to add options to have more, say "about four times the average"? On average, I get asked four questions per week and have found myself able to answer more than that in a week.

Let me know if this is the wrong place to propose this :)

Cheers! Cocobb8 (talk) 17:11, 7 May 2024 (UTC)Reply

Hello @Cocobb8! You came to the right place, and I'm so glad to hear that you enjoy providing Mentorship!

We don't currently have a way to change to four times the average from within your settings, but it might be possible by editing the associated JSON configuration "weight" value. However, that's a protected page, and I'm not sure if that's actually a good suggestion at all... let's check in with @Martin_Urbanec_(WMF) to see if he has a suggestion.

Another way to double your questions is if we release mentorship to all new accounts created at English Wikipedia. :) OK, I'm joking, we won't fix your dilemma by essentially doubling the questions all English Wikipedia Mentors receive, but please let me know if you have any thoughts about how we can recruit more Mentors so we can eventually scale Mentorship to all newly created accounts at English Wikipedia (T323048). Currently only 50% of newly created accounts on English Wikipedia are connected with a Mentor.

I glanced at your talk page, and I love seeing the positive interactions with your Mentees, including the newcomer that thanked you for help (which unfortunately happens rarely) and the newcomer who just wanted to check if you were a bot. Thanks for providing such detailed and helpful responses to new editors!

I realize this didn't fully answer your question, but Martin, @Trizek (WMF), or I will get back to you soon with more info.

Cheers, - KStoller-WMF (talk) 23:05, 7 May 2024 (UTC)Reply

Hello @KStoller-WMF, thanks so much for your quick response!
I do have some ideas on how to promote Mentorship on English Wikipedia, like adding that to the task center for "experienced editors", and perhaps mass-messaging users who are active at responding at the Teahouse/Help desk. However, these would need community consensus before they are used as ways to promote Mentorship.
I look forward to hearing for what others have to say about potentially increasing the amount of mentees assigned on English Wikipedia.
Thanks, Cocobb8 (talk) 14:16, 8 May 2024 (UTC)Reply

Hi @Cocobb8

The Growth team would love providing a mentor to each newcomer. However, it is very difficult to recruit more people to become mentors, and to keep these mentors active. Having some people like you helping us promoting the feature and creating a spirit of fellowship around this initiative would definitely help. :) Trizek_(WMF) (talk) 13:22, 13 May 2024 (UTC)Reply

Hi @Trizek (WMF),
Thanks for the reply. I've started a thread on English Wikipedia's village pump to gather some ideas on how we can promote Mentorship there!
Cheers, Cocobb8 (talk) 13:25, 13 May 2024 (UTC)Reply

Thank you!! Trizek_(WMF) (talk) 16:19, 13 May 2024 (UTC)Reply

I've been so excited by your initiative that I forgot to say what seems like a no-brainer but, of course, let us know how we can help! :) Trizek_(WMF) (talk) 16:28, 13 May 2024 (UTC)Reply

I'll reach out if I do have some questions! For now, we'll just wait and see what the community thinks as well, and I'll post back here if it looks like anything is being decided . Cocobb8 (talk) 16:35, 13 May 2024 (UTC)Reply

I subscribed to the topic you started. Let's chat here if we need! Trizek_(WMF) (talk) 19:24, 13 May 2024 (UTC)Reply

Our user found an untranslated fragment on the Home page: https://ru.wikipedia.org/wiki/Файл:Непереведенный_фрагмент_(2961).png I don't know how to fix. THX. Lesless (talk) 19:41, 15 May 2024 (UTC)Reply

@Lesless: Assuming that the fragment appears on ru:Служебная:Домашняя страница, you can open https://ru.wikipedia.org/wiki/Служебная:Домашняя_страница?uselang=qqx to see message IDs instead of the Russian or English message texts. When you see for example (growthexperiments-homepage-tab), you can update/create the translation on translatewiki:MediaWiki:growthexperiments-homepage-tab/ru – remove the parenthesis, prefix with MediaWiki: and suffix with /ru for the Russian translation. (This qqx trick works on almost any MediaWiki page, not only on Growth Experiments pages.) —Tacsipacsi (talk) 23:48, 15 May 2024 (UTC)Reply

"У вас нет прав на выполнение действия «редактирование этой страницы»" Lesless (talk) 05:53, 16 May 2024 (UTC)Reply

@Lesless, thank you for reporting it. This sentence is missing. If you like, I can post the translation at translatewiki.net.

Or you can create an account there (it is not a Wikimedia website), to become a translator. Any help would be welcomed as 11% of the interface for newcomers is not translated.

@Tacsipacsi, thank you for stepping in! :)

Trizek_(WMF) (talk) 07:59, 16 May 2024 (UTC)Reply

Hi, I was wondering if you've ever considered something like this (the section 'Proposed edits feature') with newer editors in mind Alexanderkowal (talk) 17:08, 9 June 2024 (UTC)Reply

@Alexanderkowal - Sorry, I read the thread you linked to weeks ago, but apparently never responded!

The 'Proposed edits feature' is an interesting idea, and it could certainly be helpful for a subset of newer editors who are aren't confident in the edit they are considering. But I can also see how it might also add complexity to the editing process and the patroller side of reviewing edits.

The Growth team currently plans to focus on providing newer editors with initial edit tasks that are structured and guided so they can successfully edit for the first time. We will also partner closely with the Editing team's Edit Check project that helps provide in-context policy and guidelines support.

You can read more about the Growth team Annual Plan, and our upcoming project: Constructive activation experimentation.

Our upcoming work clearly isn't the Proposed edits feature you are suggesting, but I do think it's work that is attempting to solve the same underlying issue: Newcomers often don't know how to contribute in a way that adheres to Wikipedia policies and guidelines.

Do you have any thoughts on the Constructive activation experimentation? Do you think that Edit Check and Structured Tasks are solutions that will help address the underlying issue? Are there aspects of the "Proposed edits feature" that more adequately addresses newcomer needs? KStoller-WMF (talk) 18:24, 27 June 2024 (UTC)Reply

That's okay, no worries. Edit check is a really positive feature, my only gripe is that referencing is really unfamiliar for anyone who hasn't been to university/college, and they may not know the best places to look, like google scholar. In my opinion, the policy needs to really spell out how to reference (for each style), Wikipedia:Citing sources is inadequate in this regard (the only way I learnt was by copying how other people did it on the same page and asking family). The suggested edits are good, but new users are more likely to focus on what they're passionate about imo, and as such I haven't used them, but I'm sure they suit some editors. Structured tasks is really really good, I like it a lot. I do think proposed edits can add to this, but I understand that what you've done/are doing is a better and more targeted approach, and therefore a better use of resources.

I think proposed edits best impact would be regarding edit warring, do you have any ideas/actions on how to reduce that? In my mind it works really well, users are encouraged to use proposed edits when making an edit that is controversial or likely to be controversial. At the moment a user sees perhaps a perceived injustice and makes an edit, which is likely to be biased and worded badly due to their own personal bias, but nevertheless a progression; the user has achieved their goal of getting it published. The edit offends another user deeply, either due to its bad wording or content, and the user reverts; a regression, with this user furthering their goal of obstruction, possibly in defence of quality control. This frustrates the initial user as they had already achieved their goal, and the regression radicalises them, and they try to force it back the way it was. It's this tug of war facilitated by the binary of published and unpublished that creates edit wars. Proposed edits make the whole journey one constant progression and counter the binary nature of publishing (which usually facilitates "us" vs "them" conflict), provided the reverter collaborates, and the initial user knows of the various dispute resolutions like 3O and RfCs.

Idk, I'm not tech literate so don't have any idea of how many resources this would take up, and I'm still very new so I can't see all the possible implications of such a feature. Regardless, I'm really impressed with the work you guys are doing, and am satisfied problems are being addressed. Alexanderkowal (talk) 19:08, 27 June 2024 (UTC)Reply

@Alexanderkowal, thanks for the kind words and feedback!

The suggested edits are good, but new users are more likely to focus on what they're passionate about imo, and as such I haven't used them

This is a great point! It reminds me of research that was published last year. The results seem relevant to how Growth thinks about Suggested Edit topic selection, and the need for more specific and granular topic selection: "Accurate matching between expertise and the task… is among the most significant predictors of both contribution length and quality." The Wikimedia Foundation's Research team is currently investigating improvements to article topic filtering. Currently the topics available are broad and fairly generic, and we want to allow editors to filter Suggested Edits and Content Translation tasks to topics they are truly passionate about!

I think proposed edits best impact would be regarding edit warring, do you have any ideas/actions on how to reduce that?

Hmmmmm, I wish I did. It's a complex issue, and I generally focus more on the very early part of the editing funnel. If you want to chat with a team that thinks more about edit warring, the Moderator Tools team might be interested in discussing ideas further. Sam Walton is the Product Manager of that team, and as an Admin at English Wikipedia I imagine he has a more well-informed perspective on this than I do.

Thanks again for sharing your thoughts and feedback! KStoller-WMF (talk) 21:30, 27 June 2024 (UTC)Reply

Maybe new editors could be asked which topics they're interested in or select from a menu some topics and the suggested edits go off of that (and you can toggle random/personalised)? Thank you for engaging with me and being so kind Alexanderkowal (talk) 22:14, 27 June 2024 (UTC)Reply

@Alexanderkowal That sounds close to what we have in production on Wikipedia right now (see screenshot).

If you want to experiment with the Suggested Edits feature, you'll find it at: Special:Homepage. Older accounts don't have the Homepage enabled by default, but all Wikipedia editors can access it if they enabled "Display newcomer homepage" in their preferences: Special:Preferences.

That being said, I think the idea of providing a "randomize" option, or even a "personalized" option based on previous edits is an intriguing idea. I'm hoping that once the associated API offers more advanced topic filtering options we can consider further improvements to this selection menu.

One idea we've also experimented with is allowing editors to narrow down to two or more topics. In other words, we offer the first option below, but we don't currently offer the second option:

• Current UX: Suggestions will be based on 1 or more topic selected. So in this example screenshot, suggestions will be based on a "Architecture" or "Art" or "Biography (women)" topic search.
• Missing UX: Suggestions narrowed to all topics selected. So in this example screenshot, suggestions could be based on an "Architecture" and "Art" and "Biography (women)" topic search.

Ideally we can allow users to decide if they want the more expansive list of suggestions (the current UX) or allow for a more precise topic selection (the missing UX).

All this being said, we hope to eventually improve this topic selection menu, to include more topics and more precise filtering of suggestions, and I hope at that point we can also consider other "nice to have" ideas like randomization and personalization.

Thanks again for chatting through this and offering ideas! If you have any further feedback, I'm always curious and interested in how we can improve Growth features! We have a fairly small team, and many other features we maintain, so we have to make some difficult prioritization decisions, but I attempt to make sure we fit in the most impactful work. KStoller-WMF (talk) 22:59, 28 June 2024 (UTC)Reply

I saw that eswiki already has the option in the preferences to activate "Show home page for new users"

Although I am no longer an experienced user, I have 2 points of view to give

• The first, if it is supposed to be new, I would like to know if they have planned that in the configuration it can be configured by default that it appears to all newbies without having to activate said option and that it is automatically deactivated as soon as certain parameters are met, I have more extensive things to say about this, but I limit myself to saying just that for now.
• The second thing is that the welcome page for newbies is still in the development phase, and the page Special:Homepage at first becomes inaccessible, and I activated it and I thought that when I touched the Wikipedia logo I was going to replace the general mainpage that is configured in MediaWiki:Mainpage so it is not very intuitive for a novice to be entering through the link and when entering the wiki it is not the predestined page for them.

At the moment I feel that they activated this function at a very early stage, and it is not very well-prepared for newbies who want to learn about basic tasks on Wikipedia

Greetings, Danielyepezgarces (talk) 05:02, 1 July 2024 (UTC)Reply

I was watching the previous thread and I see that yes for new users it is active by default but as an old user to test these features I click on the Wikipedia logo, and it takes me to the default page Danielyepezgarces (talk) 05:05, 1 July 2024 (UTC)Reply

Hello Danielyepezgarces

As the Homepage is not a page experienced users visit as their usual workflow, being surprised and having questions is common. And we are happy to answers your questions about it!

The Homepage is not a new thing anymore. it is activated for all newcomers at all Wikipedias for a few years now. At Spanish Wikipedia it was activated more than two years ago, and we have a good number of edits that were made using the suggested edits on the Homepage, so as questions asked by newcomers to their mentors.

We add new possibilities to this Homepage, the more recent being suggested edits. We will soon work on promoting community events.

The Homepage doesn't replace the actual homepage. Any new user who gets the Homepage as their default homepage will access it by clicking on their username. In short, we remplace the user page by a link to the homepage. Of course, the user page remains accessible.

Let me know if you have more questions! Trizek_(WMF) (talk) 14:40, 1 July 2024 (UTC)Reply

Currently, the mentee can ask duplicate or similar questions to the mentor within a few hours (Example cases: Lovewyx, 呂哲元, Coidea and Jocelyn IU), and there is no measure to prevent them from doing so. This may cause annoyance for the mentor, as they receive several questions in a short period of time, and it can also make the talk page a bit messy, especially when it's not just one user doing this.

Therefore, it is suggested that the mentee be notified if they asked the question a few hours ago (maybe around 3-6 hours). The notification may remind them that they have already asked the question and encourage them to directly reply to their previous question, if they want to ask similar questions or follow up on their previous question. The text of the notification may be written like: "If your new question is related to your previous one, you are welcome to continue the conversation by directly replying to that earlier message. This helps keep things organized so your mentor can provide the most helpful response." etc.

This can not only avoid frustrating the mentor, but also help the newcomers learn more about how the Wikipedia discussion system works. cc @SunAfterRain: who flagged this issue. Thanks in advance! SCP-2000 (talk) 06:17, 7 July 2024 (UTC)Reply

Thank you for your message @SCP-2000.

I think these users believe that their mentor is always online. Or that they are responding to a chatbot.

I see mtwoultiple possibilities to solve this, which all have their pros and cons:

• Editing Growthexperiments-homepage-mentorship-preintro. This message is shown above the mentor's name at zh:Special:Homepage. A short and precise addition could be added along the lines of: "your mentor is a volunteer who will reply when they can". It is also possible to consider growthexperiments-homepage-recent-questions-header that is above the list of questions already asked (change it to "continue previous conversations") or Growthexperiments-homepage-mentorship-questionreview-header, shown in the pop-up where mentors post their question. It could be edited to prompt users to go to their mentors' talk page if they have a follow up question. It is the quicest way to address the problem you describe, but editing these message will overload the interface, with possible "too long, don't read" or "I don't know, I give up" effects.
• Provide a FAQ before posting a message (T270523). Not yet built, not planned, it could be a good proposal for the community wishlist. A chatbot was also considered at some point, but I don't think there is a ticket about it.

I'm a mentor myself at French Wikipedia, and I don't observe the issue locally. It it happen, I tend to regroup all messages under one unique thread and tell users that they can reply directly under the message if they need to follow up. But all wikis are different! :)

Thank you, Trizek_(WMF) (talk) 13:09, 16 July 2024 (UTC)Reply

heratic (?), but i believe no, behaviour of the number of suggestions. When i select for example 2 domains : maths and physics on the FR Wikipedia to simply 'add a link', the number of suggestions does not decrease in spite of my positive work. Why ? why these bursts ?

Example: 2968 2968 2970 2966 2965 2968

--Christian 🇫🇷 FR ⛹🏽 Paris 2024🗼 (talk) 08:00, 15 July 2024 (UTC)Reply

Bonjour Christian

I observe the same changing numbers just by refreshing the Homepage.

Do you think that the absence of change in these numbers (or even their increase) could demotivate newcomers?

Trizek_(WMF) (talk) 12:47, 16 July 2024 (UTC)Reply

personally i am happy when i see my effort has allowed to solve the amount of pending cases. And this is what the counter should show. Sinon à quoi il sert ? adding that i have mainly stopped when the value has reached its initial ammount (its like always pouring water in a basket whith hole, you never see it is empty). Deeper analysis should be lead to explain/correct these variations. Christian 🇫🇷 FR ⛹🏽 Paris 2024🗼 (talk) 10:45, 20 July 2024 (UTC)Reply

In a recent discussion around the role of mentors on the Dutch language version, initiated by a sour reaction of a mentee on a comment in good faith by his mentor, the following point came up. There doesn not seem to exist something like a general check of a person, by an independent committee, before he/she can act in the role of mentor. Anyone can become a mentor with the right to 'handpick' mentees and present himself to that person as a mentor. A general check whether a person is suitable for the job, before being able to act as such, seems essential to me and others.

• In the first place because a diplomatic, welcoming mentor with a 'let-someone-learn-by-doing' mentality, and able to show the way into the different projects and tasks (tech tech tech) can play an important role in the transformation from newcomer to longstanding member of the Wikimedia movement. To gain resilience and recover from unhealthy community circumstances, in certain communities there's a need for a secure and steady growth of newcomers turning communitymembers the next couple of years.
• Second because this person often will be the first 'face' representing the Wikimedia Movement and as generally known, there is no second chance for a good first impression.
• Third because there is a higher risk of abuse - a newcomer will trust a mentor more than other communitymembers and might not from the start understand or recognise possible wrongdoings.

The first proposal is for people responsible for this programme, to please think about this issue and develop something like an 'universal accreditation structure' for mentors, including the obligation for potential mentors, to agree in writing on the Terms of Use, the Universal Code of Conduct and the UCoC Enforcement Guidelines, plus a set of standards applicable for mentors. A test period of twelve monthes could be included too. People now acting in the role of mentor, should all close the same agreement with the WMF. In our language version almost no one is aware of the validity of the ToU, UCoC/Enforcement Guidelines. The second proposal is, that for a certain period of time, when a newcomer does agree to be under the wings of a mentor, patrolling community members are not allowed to take heavy measures like blocks, or do have the task to act with the utmost caution when deciding those actions, and/or with the obligation that the mentor should be consulted and/or that the mentor will help defend the actions of the mentee.

When a local chapter is active, their officers and contractors can play a role here, and the Foundation could nudge Chapters to do so, in any case when there is a lack of editors / patrollers in the specific Wikimedia project. Thanks for your attention and engagement, Kevin Bouwens (talk) 11:00, 16 July 2024 (UTC) | FYI @TrizekReply

Thank you for your message @Kevin Bouwens. I'm happy to read the message of someone who understands the purpose of mentoring (and Growth features): to help train the next generation of Wikipedians. This is quite rare, as many people see mentoring only as an information desk... And I totally agree with you: mentors are the first face newcomers encounter, hence it is better to show a nice one!

The default workflow to become a mentor is on a volunteer basis. It is true that you only have to sign up and be a mentor. It is possible to change the conditions to become a mentor. At the moment, in the Community configuration, any admin can define different number of edits and days of presence to become a mentor.

As I said, edits and days of tenure are the default, which means that an alternative exist: it is possible to manually assign a mentor role to a user. This right could be granted after applying to become a mentor. This could have negative effects, with users who won't apply to be mentors because they are afraid of applying for the role.

If the case your report is the only one found at your community, maybe it could be interesting to define some local rules on what to do and not do? Any user can check on how mentors work, and if the respect the local rules (so as the UCoC, of course). Any local rule can be defined, regarding how the community should consult the mentor, etc. However, this should not be done without taking into account the fact that some novices have no idea that they have a mentor.

Speaking of checking how mentors work, has your community defined a way to find and remove inactive mentors?

Also, I'm not sure about your last paragraph, regarding the role of chapters/WMF. Can you clarify it please?

Thanks, Trizek_(WMF) (talk) 12:44, 16 July 2024 (UTC)Reply

Thank you Trizek_(WMF) for the swift reaction with interesting, partly eye-opening points and issues. When most people see the mentor primarly as a helpdesk, smart communicative and diplomatic work lays ahead for people who are aware of the role mentors can play, in bending the years long decline in volunteering contributors and patrollers into growth. I see your point that the necessity for an application to become mentor can and will withhold people from taking the role. Nevertheless, a minimum requirement for becoming a mentor should be the disclosure of real name and contact details to a steward or ombudsman, and to make them verifiable (under strict privacy protection), together with an active agreement in writing on the ToU, UCoC and UCoC Enforcement Guidelines, the promise to act according them in the mentoring role and 'walk the talk'.

As for local rules: most people working in our community do not know the main sets of rulings that are 'reigning' the Wikimedia Movement ecosystem. Besides, rules approved by the WMF Board of Trustees like Bylaws, Terms of Use and the Universal Code of Conduct are seen as being "top-down" imposed on them, infringing on what they think is a basic right: 'autonomy of the community'. This goes in the Dutch version community so far that no one accepts general rules, when someone writes that something is a rule, it is being handled as an opinion, to be discussed. No one knows that ToU and UCoC have been drafted "bottom-up" and the communities in a legal sense do not have autonomy because they're bound to act within the borders the WMF has drawn. It is this attitude that makes it practically impossible, to agree on local rules, even when only an estimated 30 - 50 people are active in this area.

When you register an account at the Dutch language WP you get a friendly designed, well written message on your userpage with basic information, useful tips and a message that you've been connected to a personal mentor. So novices do know about it.

As far as I know there are no community rules about mentors.

As for the chapter: Wikimedia Nederland is not active in stimulating a more healthy, diverse and welcoming working environment on the digital workfloors, imho a conditio sine qua non for steady growth of contributors and content quality. Although it's known since around 2015 from a study the chapter orders every year, that the atmosphere is being experienced as hostile by many and that over 90% of community members come from a small segment in society. There's a steady decline of contributors, at the moment there are not enough people to create content about new topics or persons that have become encyclopedic. This story can be heard from other communities (personally I did read about India and Russia). I think chapters can be more active here, "to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally" :). Thanks for your attention, Kevin Bouwens (talk) 18:47, 22 July 2024 (UTC)Reply

Thank you for these details.

I'm not sure to understand the need of disclosing real identity to anyone to be a mentor. It could create a two-peace system, where "official" mentors would need to disclose personal information while anyone interacting with any newcomer would not need it. but both would do the same thing. And also that disclosure would certainly prevent users from volunteering to a task that is sometimes tedious to get qualitative results. Are you afraid of abuses? Which kind of abuses?

I agree with your analysis of how ToU or UCoC have been drafted and how these aren't well known by community members (honestly, given the number of local rules and implicit rules, it can be hard to keep track!). I observe exactly the same thing at French Wikipedia, my home wiki as a volunteer. With others, I sometimes need to recall that there are rules above the 5 pillars... If some rules (or even just basic guidance) are written for mentors, they should indeed mention the ToU and the UCoC, at least. I'll add it as a best practice in our documentation, but I'm afraid I can't do more.

And I also agree on the need of a better environment for newcomers. it is also a requirement to see the community thriving. I really think that the social aspect of things must be changed, beyond providing technical solution to lower the barrier of entry. But what's the point of paving a better road if the same misbehaving people control that road? Chapters can help, community initiatives can to this too. I truly believe that mentors can help changing this as they are active inside of the community. Starting in September, I'll work on a personal project to identify mentors profiles and question their needs. would you be interested to participate in this project?

Some chapters and user groups are have identified mentorship as a way to improve user retention. Again it is a matter of them knowing that it exists.

Best, Trizek_(WMF) (talk) 14:00, 23 July 2024 (UTC)Reply

Bonjour @Trizek (WMF), yes, disclosure of identity could help prevent abuse. It would be a pleasure to participate in a project initated by you (because I sense the same kind of goals) that could support growth. Please feel free to send a message with the email function. Kind regards, Kevin Bouwens (talk) 12:59, 24 July 2024 (UTC)Reply

Thank you @Kevin Bouwens. I'll recontact you when I start the project. :) Trizek_(WMF) (talk) 13:45, 24 July 2024 (UTC)Reply

On y va :) @Trizek (WMF) Kevin Bouwens (talk) 14:10, 24 July 2024 (UTC)Reply

Hi all, it is very useful for translators : link to 'Translate the interface'. Should be mandatory on each page as soon as a pending part exists on translatewiki.net . It facilitates research when looking for strings in specific problematic cases (wrong indentation, typos, misinterpretation due to the contexte, wrong terms in regard of the culture of the product...). Thanks, -- Christian 🇫🇷 FR ⛹🏽 Paris 2024🗼 (talk) 10:34, 20 July 2024 (UTC)Reply

Thank you! I try to indicate this whenever possible. I agree that it should be systematic, and done in a unified way. Trizek_(WMF) (talk) 14:01, 23 July 2024 (UTC)Reply

Hi all, I really like the Add a link bot, but I found what might be a bug. When using the Vector (2022) skin in dark mode, the 'highlighted' words appear in light gray while being placed in a white square, making them unreadable. This forces the user to switch back to light mode. HaukweKwor (talk) 10:30, 26 August 2024 (UTC)Reply

Hello HaukweKwor

Thank you for reporting this! We should work on it soon.

Trizek_(WMF) (talk) 13:30, 26 August 2024 (UTC)Reply

@Trizek (WMF) and @KStoller-WMF, seeing edits like this one, are we doing enough to let newcomers know that the "add a link" task is for internal links to other Wikipedia articles, not external ones (which violate w:WP:ELNO if placed in the intro or body)? Sdkb ^talk 04:46, 4 October 2024 (UTC)Reply

@Sdkb, step 1 of the instructions says:

> Links between Wikipedia articles allow readers to click on something they want to learn more about. They help people navigate easily to other Wikipedia articles.

This would not happen with Suggested links, as newcomers are strictly guided to add internal links. We replaced the Add a link task, mainly for misuse reasons, by suggested links at almost all wikis. For English Wikipedia, it is up to the community to activate this feature. Trizek_(WMF) (talk) 14:23, 4 October 2024 (UTC)Reply

Thanks for bringing this up, @Sdkb!

Although we are providing instructions in the unstructured "add a link" task, obviously it's not always followed and new editors will still make mistakes.

As @Trizek (WMF) mentioned, one solution is to enable the "Add a link (Structured task)" viaSpecial:CommunityConfiguration/GrowthSuggestedEdits. Essentially then newcomers will ONLY be allowed to add internal links when completing the task, and communities can define which sections should be avoided entirely.

I also wonder if this is an opportunity for an Edit Check? @PPelberg (WMF), has Editing considered adding an Edit Check that warns newcomers when they add an external link outside of certain sections (like External links and References)? KStoller-WMF (talk) 20:31, 4 October 2024 (UTC)Reply

I also wonder if this is an opportunity for an Edit Check? @PPelberg (WMF), has Editing considered adding an Edit Check that warns newcomers when they add an external link outside of certain sections (like External links and References)?

Great spot, @KStoller-WMF and thank you for the ping.

There is an idea for a Check that would activate when someone attempts to add, "...an external link in an article body." Although, it's not a Check we've prioritized yet.

A couple of follow-up questions for you @Sdkb...

1. Can you think of a way for how we might see how often edits like this are being made?
2. How might you describe the impact of mistakes of this sort?

PPelberg (WMF) (talk) 22:19, 4 October 2024 (UTC)Reply

Thanks for creating the Phabricator ticket! Regarding (1), I think it might be possible to code some sort of edit filter that triggers when an external link is introduced into an article body (or such a filter might already exist)?

Regarding (2), there are various reasons we have w:WP:ELBODY (e.g. link rot, consistency), but at its core I'd boil the main reason down to this: We want to have a specific reader experience on Wikipedia, that of reading an encyclopedia. When we link out to an external site from an article body, the reader experience following the links and exploring the content there becomes an extended part of their Wikipedia experience. We have no control over content on external sites, and it is very rarely encyclopedic, so we don't want it to be part of the reader experience. (Different considerations apply for external links in references, which are needed for verification, and in external links sections, which are at the end and serve as further reading suggestions.) Therefore, having external links in article bodies makes Wikipedia a worse encyclopedia.

On a more practical level, as you mention in the Phabricator task, because ELBODY is a very established standard, when a newcomer violates it, generally what happens is that they're reverted at some point, which takes additional effort from the patroller and wastes the effort the newcomer thought they were making to improve Wikipedia (and can also bite them). Sdkb ^talk 05:35, 5 October 2024 (UTC)Reply

A check around external links would be a great candidate for a good community configuration case, as not all Wikipedias disallow (some) external links in the article's body. And if they do, they could do it a various levels (for instance, French is stricter regarding which links and where to add them). Trizek_(WMF) (talk) 14:58, 7 October 2024 (UTC)Reply

Everyone with serious vision impairments that I know has ranted at me about how Wikipedia has too many internal links and their screenreader reads them all aloud and it renders the site almost unusable. Obviously if the screenreader did a background chime or a change in timbre or something that would be better. One could either fix an open-source screenreader -- the news would soon get about -- or develop a basic audio interface for Mediawiki, possibly with a variant for users who are illiterate and not blind, or just keen on podcasts. HLHJ (talk) 18:12, 23 October 2024 (UTC)Reply

@HLHJ, that's an interesting observation, and one I'd like to see discussed more (Graham87 might have some insights). But whether Wikipedia ought to have fewer internal links doesn't have much to do with the issue I'm reporting here, which is about external links. And even its connection to the "Add a link" Growth task is tenuous, given that it applies only to articles tagged as needing more links. I'd suggest w:WT:MOSLINKS might be a more appropriate venue to raise this. Cheers, Sdkb ^talk 20:02, 23 October 2024 (UTC)Reply

@HLHJ: Yes this; I was quite surprised to be pinged in this discussion until I read your message. Proficient screen reader users just have to get used to whatever websites throw at them. Of the major Windows screen readers, JAWS makes it possible to change the voice, make a sound when a link occurs, or disable link announcements while NVDA only allows the third option. To keep things on-topic with the original thread, I'd very much agree that anything that can be done to stop new users adding external links to the article body in the English Wikipedia would be greatly welcome. Graham87 (talk) 03:00, 24 October 2024 (UTC)Reply

I see that T209797 has been triaged; does this mean it is likely to happen moderately soon? It'd be great to have this, especially as tagging seems to help newcomers. HLHJ (talk) 18:17, 23 October 2024 (UTC)Reply

@HLHJ Thanks for the question! On the Growth team's workboard "Triaged" column simply means a Growth team member reviewed the task and determined that it's a valid feature request, but not related to our current work and it's not a high-priority bug that we need to address ASAP.

So no, it doesn't mean that the Growth team has this work planned.

Have you been following along with the Editing team's Edit check work? The T209797 task sounds related to the Reference check work. Recent Edit Check A/B tests show Reference check increases the number of new content edits where newcomers add references. It seems like a different approach to addressing a similar core issue. Do you agree? KStoller-WMF (talk) 21:46, 23 October 2024 (UTC)Reply

Hello, is it possible to remove blocked accounts (aka mentees) from the mentorship-system...? Due to LTAs (long-term abuse) + abusive usernames... نوفاك اتشمان (talk) 14:09, 26 December 2024 (UTC)Reply

Hi @نوفاك اتشمان

We prioritized this task for upcoming improvements. :)

Trizek_(WMF) (talk) 15:09, 6 January 2025 (UTC)Reply

Thank you very much. نوفاك اتشمان (talk) 21:51, 6 January 2025 (UTC)Reply

Hello,
In the Hebrew Wikipedia, we configured "maxTasksPerDay": 1 as required, but it seems that the setting is not applied to all users. When I tried using the tool, I was limited to one edit per day, and the same applies to other users I asked. However, I noticed that some users are not subject to this limitation and appear to be able to add as many links as they want in the same day, despite the defined limit of one.
These edits are not manual, as evidenced by the tags "newcomer task" and "newcomer task add link" attached to them.
Here are two recent examples of users brought to my attention:

• w:he:Special:Contributions/Gevayu
• w:he:Special:Contributions/ברק דיבה (regularly performs 2 edits per day).

Unrelated to this, I would also like to know if there is a way to block a specific user from using the automatic suggestion tool.
Thank you, Neriah (talk) 15:06, 29 December 2024 (UTC)Reply

Hello Neriah

This is strange. I'll investigate.

May I ask what was the resonating behind limiting to one task per day? I see that newcomers are allowed to add up to 10 links over one edit. Was it consider to have something like 3 tasks of 3 links per day? Aren't you afraid that newcomers would be frustrated by this low number of articles being available?

On the unrelated question, there is no way to prevent a user from editing Wikipedia using the suggested edits. I have several ideas around why it could be useful, but also the opposite; both are quite balanced, hence haven't been implemented. Could you share more on how you would use it?

Trizek_(WMF) (talk) 15:31, 6 January 2025 (UTC)Reply

Thank you for the response and for clarifying the issue.
There is a single answer to the two concerns you raised. On the Hebrew Wikipedia, votes are held on controversial topics, including political issues. A minimum threshold of edits is required to participate in these votes, and edits made using this tool count toward that threshold. However, external actors seeking to sway Wikipedia towards a particular narrative misuse this tool to easily gain voting rights and participate in votes that favor their narrative. Limiting the tool to one edit per day helps us hinder this misuse, thereby enabling us to protect Wikipedia from the political tensions surrounding the world.
Additionally, blocking access to the tool allows us to prevent users who misuse it from editing through the tool, without needing to block them entirely (for example, the second user I linked to their contributions page, who, aside from their current misuse, has authored several articles in the past).
Thanks again, Neriah (talk) 15:52, 9 January 2025 (UTC)Reply

Thank you for the details. I understand the reasons, while I would balance them with a broader picture: anyone wanting to reach a certain number of edits can do it without using the suggested edits. Also low level on suggested edits could frustrate new users that would be the next generation of editors. But again, I fully understand, and respect the community decision! :)

I documented the need of the block in T383410, and I will keep you posted regarding "maxTasksPerDay". Trizek_(WMF) (talk) 15:16, 10 January 2025 (UTC)Reply

@Neriah, regarding maxTasksPerDay, we found that if you open multiple Add Link sessions in separate tabs within your browser, then you are able to complete all of them. We will discuss the issue during our next team meeting. Trizek_(WMF) (talk) 13:45, 13 January 2025 (UTC)Reply

I assume you work closely with those Wikipedias that have Welcoming Committees, like en:Wikipedia:Welcoming committee. Within that context, I have some ideas:

• Expand welcome templates to include a new set of check-in, or follow-up templates. What I have in mind, is that after a defined interval elapses following placement of a welcome template, something happens to help trigger a reminder to see how that editor is doing. Either a timer, or (better:) a category of users needing follow-up based on a fixed interval, or (best:) bot-calculated categorization based on some function of elapsed time, total edits (or edit frequency?), reverted edits, warning template presence, and other useful factors that might contribute to deciding that a new user could benefit from a check-in.
• Help for finding users in needing of a welcome. Besides just brand new users with empty Talk pages, I am working on en:Template:Welcome needed that targets users that have received a warning template but have not been welcomed yet. It is partly functional, but needs a rewrite (mostly to use urlencode, and has some bugs as well), but it will give you an idea.

Another idea I has involves reducing biteyness of user warning templates, intended for placement on user talk pages. This would involve a proposal at en:WP:WARN to allow modification of all Level-1 warning templates to include a new |welcome=yes param, so that experienced users placing warnings on newbie talk pages, could at a stroke place a welcome template *above* the warning, just by using a parameter. So that for example, instead of a new users seeing their Talk page created with nothing but a dry warning about unsourced content (template en:Template:uw-unsourced1), it will start off with a welcome message, and then the unsourced warning below it, with the hope that the spoonful of sugar will help the medicine go down. Thanks, Mathglot (talk) 08:43, 30 December 2024 (UTC)Reply

Thank you for sharing these ideas, @Mathglot.

On your first point, I'm afraid I don't really get what you mean. Are you suggesting a way to check how a newcomer performs?

On point 2, most wikis welcome everyone, indiscriminately. The idea behind it is pretty simple: if the newcomer has a question, they are more likely to look at that "you have a new message" notification and find a username to contact. Being a welcomer/mentor at French Wikipedia on my spare time, I observe newcomers whose very first edit is a question to me. This effect was proven by research: we know that some users need a get a confirmation when they want to start editing. And a side effect is that you can advise some editors not to edit as they shared their plans...
Growth features offer a mentorship system that provides a username to contact to every account, not just to editors who already edited. Newcomers get a direct contact to their mentor at their personal homepage. However, at English Wikipedia, this system is only available for 50% of newcomers (hopefully getting to 100% soon?).
If you combine this Growth feature with an automated distribution of the welcome message signed using a magic word that returns the mentor's name, you multiply the chances of welcoming newcomers in an efficient way.

This welcome message being posted right after account creation would solve the issue you describe with your last paragraph, as any warning message would be posted after the welcome template.

On warning templates, my guts feeling is that most users don't look at them. When you are in an editing tunnel effect adding your spam link, you don't really pause and look at your talk page ("I'll do it later, it is not urgent"). In reaction, communities have made warning templates bigger, with more colours and CAPITALIZED titles. There is a small gap to fill here, but I disgress.

Anyway, some solutions exist to solve the issues you described. It is mostly a matter of applying them to your wiki.

Trizek_(WMF) (talk) 16:04, 6 January 2025 (UTC)Reply

Is there a reason the text starting from 'To better understand what causes …' is not marked for translation? The Dutch, French, and Russian versions show as 100% translated, but a considerable amount is still in English. Jeroen N (talk) 12:57, 19 January 2025 (UTC)Reply

Hi @Jeroen N

Initially, we choose not to translate these parts. Apparently, reorganizing the contents makes it less relevant.

I reviewed the text and marked it for translation. Trizek_(WMF) (talk) 14:25, 20 January 2025 (UTC)Reply

Thanks! I updated the Dutch translation. Jeroen N (talk) 16:24, 20 January 2025 (UTC)Reply

Thank you! :) Trizek_(WMF) (talk) 15:36, 21 January 2025 (UTC)Reply

Please unsubscribe my page https://www.wikidata.org/wiki/User_talk:Conny#c-WikiBayer-20250123213300-Conny-20250123204000 from the newsletter. Regards, Conny (talk) 06:22, 24 January 2025 (UTC).Reply

Hi Conny

You already unsubscribed on July 30.

Trizek_(WMF) (talk) 10:59, 24 January 2025 (UTC)Reply

Hi, I have a mentee from the English Wikipedia (user Dazzlemonk) who is blocked indef, but Special:MentorDashboard shows 0 blocks. Is this due to a lag or something? Myrealnamm (💬talk · ✏️contribs) at 20:20, 13 February 2025 (UTC)Reply

Hi @Myrealnamm, sorry for the delayed response!

Yes, there is a delay in Mentor Dashboard data updates. I assume this was resolved after a few hours—can you confirm whether you still see 0 blocks for that mentee?

I should also mention that we recently worked on a related task to remove blocked users from Mentorship (T351234). This change should be testable on Beta wikis but has not yet been rolled out on English Wikipedia. KStoller-WMF (talk) 19:13, 19 February 2025 (UTC)Reply

That task seems fair, but the blocked user Dazzlemonk already no longer shows up on my dashboard (I've tried searching). I wonder why. Thanks, Myrealnamm (💬talk · ✏️contribs) at 21:04, 19 February 2025 (UTC)Reply

T351234 is included in the MediaWiki 1.44/wmf.17 release, so I had assumed the change's impact was not yet visible on English Wikipedia. However, I may be mistaken. Thank you for following up on the related task—an engineer should provide more details soon. KStoller-WMF (talk) 22:47, 19 February 2025 (UTC)Reply

Hi, I received a question in the normal mentoring format on my English Wikipedia talk page yesterday. However the user (Kevinmjc) is not appearing under Your Mentees on my Special:MentorDashboard, nor is their account creation and draft activity visible on the filtered view of Recent Changes. Is this a known issue (failed data transfer, or whatever)? AllyD (talk) 11:38, 6 March 2025 (UTC)Reply

Hi AllyD, thank you for informing us!

I checked who is Kevinmjc's mentor using {{#mentor:Kevinmjc}}and it appears to be Ixtal.

The message is clearly coming from the mentorship module, as the diff shows the tag. Nothing is visible in the logs. SO we might have a technical glitch.

I documented the case and informed the engineering team. The response might be a bit delayed as the person who knows the feature most is away for a couple of weeks. :)

Trizek_(WMF) (talk) 14:10, 6 March 2025 (UTC)Reply

Problem solved! I was reminded that it is normal: as Ixtalis away until 25 September 2025, Kevinmjc was redirected to you. From there, two things:

• with such a long period of absence, maybe Ixal should be removed from the mentors list
• we should work on providing context for replacant mentors when they receive a newcomer's message

Trizek_(WMF) (talk) 16:13, 6 March 2025 (UTC)Reply

Trizek_(WMF) thanks for identifying the circumstances. A replacement-mentor facility is useful for deflecting and picking up queries from an existing mentor-mentee relationship. In this case, though, I note that the mentee's account was registered at 18:52 yesterday and their query came just over 3 hours later. So, assuming Ixtal had already marked as gone-away, I would suggest the mentee should not have been allocated to them in the first place, so that the replacement (in this case me) would have the normal Dashboard, etc. available, rather than having to trigger new messaging if the mentee raises a query. AllyD (talk) 16:47, 6 March 2025 (UTC)Reply

@AllyD, good point! We will fix this eventually. Trizek_(WMF) (talk) 18:20, 10 March 2025 (UTC)Reply

• Me again! On answering a query from a user (Mangahuanga), I noticed that they weren't showing on my Special:MentorDashboard or the filtered view of Recent Changes. Checking the {{#mentor:Mangahuanga}}, they do seem to be allocated to me, just missing from my Dashboard. AllyD (talk) 14:43, 21 March 2025 (UTC)Reply

  Hi @AllyD! Is it still the case? The list of mentees is updated only a few times per day. Trizek_(WMF) (talk) 20:07, 25 March 2025 (UTC)Reply

  Yes, it isn't appearing in the Your mentees box table and, whereas putting an other user's name in the search box immediately shows their name under that box, nothing shows for this particular user. AllyD (talk) 20:15, 25 March 2025 (UTC)Reply

  And while I was writing that message, I got a query from another new editor (Ahmed Alency). After replying, I looked at my Mentor dashboard and they aren't there, nor does their 20:13 message to me show in the filtered Recent Changes view. AllyD (talk) 20:34, 25 March 2025 (UTC)Reply

  Two cases in a few days may indicate a pattern, so I have raised this at Phabricator. AllyD (talk) 08:31, 26 March 2025 (UTC)Reply

  Thank you, we will investigate this case. Trizek_(WMF) (talk) 13:08, 26 March 2025 (UTC)Reply

Hi. Is it possible for you to claim this Phabricator task? I just noticed that Growth uses moment.js on newcomer homepage. Nemoralis (talk) 17:03, 27 March 2025 (UTC)Reply

@Nemoralis: Please don't forum-shop like this. Jdforrester (WMF) (talk) 22:54, 27 March 2025 (UTC)Reply

I wasn't trying to forum-shop. I saw the Growth team tagged in previous tasks, so I posted here in case they were interested. Sorry about that. Nemoralis (talk) 23:02, 27 March 2025 (UTC)Reply

@Nemoralis: You filed in Phabricator (which was the right place), then immediately pinged me as a drive-by comment, and then when I didn't reply in my volunteer time fast enough(?) you came here to ask another particular team or person, rather than a more general forum (like the village pump here or IRC), without even mentioning that you'd already pinged at least me (and maybe others?). I'm sure you wanted this upgrade to be done for the best reasons, but this is very aggressive, especially given that it has been five years since the previous upgrade. Sorry for the Labyrinth of our different technical fora, it doesn't make it easy to do the right thing. Jdforrester (WMF) (talk) 00:00, 28 March 2025 (UTC)Reply

My main current editing task concerns the biography of Sofia Henin. My aim is to get this more up-to-date and take out a lot of the rather stale tennis history. A user, name escapes, has somehow blocked my work progressing over a rather minor matter. How can I move on from this block? Jahm Mackenzie (talk) 02:06, 13 April 2025 (UTC)Reply

Hello @Jahm Mackenzie

This page is about technical issues, not editorial ones. I noticed that you contacted your mentor at English Wikipedia, which was the best way to get more context on how to understand what happen. A look at the article's history page could also provide you some context.

Trizek_(WMF) (talk) 12:29, 14 April 2025 (UTC)Reply

Documenting a situation:

(1) While the Mentor dashboard Your mentees table was dormant, I was using the Filtered list and noticed a new user and their first page being speedy-deleted, so I put some advice on their User Talk page.

(2) Shortly afterwards, they were blocked for an unacceptable username, with the usual advice to seek a name change that made clear they didn't represent an organisation.

(3) The user sought a name change and their account is now active again. I noticed that their activity (replying to my earlier message) wasn't showing on my Your mentees table (now that it being updated again) or Filtered list. This is because they are now allocated to another mentor.

I had previously noticed that the #mentor function returned blank for another user who asked a question but had then been blocked, so I guess there is a mentor-mentee deallocation tied to logged blocks?

However, when seen in the whole it creates discontinuity of engagement, such as in the situation above. I suspect it would be a pain to ensure reallocation to the same mentor after a name change / deblock. Another approach would be to not deallocate blocked users, or just those with the particular situation of a Username Block, which is often temporary, and a situation where a mentee may be confused and seek advice. AllyD (talk) 07:53, 17 April 2025 (UTC)Reply

@AllyD Thanks for outlining this so clearly. I agree this isn’t the ideal user experience for either the newcomer or the mentor.

I’ve created a task to capture the issue here: Mentorship: Preserve Mentor-Mentee connection after temporary blocks.

Feel free to share any additional ideas or perspectives. While it’s not something we’re able to prioritize right away, I’m hopeful the Growth team will have an opportunity to focus on mentorship-related improvements in the near future! KStoller-WMF (talk) 04:17, 18 April 2025 (UTC)Reply

The question of what to do when a mentor is absent, and when, needs to be addressed. There are two facets:

• marking the mentor away, so future questions will be redirected
• dealing with pending unanswered questions already published at the UTP of an absent mentor

There is a discussion at WP:VPT that touches on this issue. I have recently responded (diff) in a cursory fashion to a dozen questions at a user talk page (here) apparently generated via the help panel, because the mentor is not answering questions and may be absent, which was what originally inspired me to start the VPT discussion. Per KStoller-WMF's response at VPT, it sounds like there are already three phab tasks addressing these issues.Thanks, Mathglot (talk) 21:24, 23 April 2025 (UTC)Reply

I presume there is some sort of throttling mechanism for questions to individual mentors, based on something they have declared on signing on as a mentor, so that they could volunteer for ten questions a month, or whatever level. It occurs to me that it would be useful to gather some statistics on mentors around how long it takes to answer questions, which could start with first response time, and when sufficient data has been gathered, latency or mean response time.

Additionally, do users get one mentor, or more than one? It seems like they could get more timely responses by having one mentor chosen to align with the beginning of the mentee's time zone + a delta, and another whose day starts after the mentee's ends, so their question might be answered overnight. Mathglot (talk) 22:08, 23 April 2025 (UTC)Reply

@Mathglot There is a basic throttling mechanism in place that allows mentors to receive more or fewer newcomer assignments than average. Special:ManageMentors (see the “Number of Newcomers assigned” column). While this roughly functions as a throttling system for questions, in practice, the number of questions a mentor receives depends on several other factors—such as the total number of active mentors, how many are marked as “Away,” and random chance.

I would love to add mentorship stats! We’ve always envisioned something like an "Impact module" for Mentors. That said, it's still technically challenging to calculate collaborative contribution metrics and manage data caching effectively. Hopefully, we can make progress in this area going forward (see related task: T341649).

Currently, the Growth Mentorship system assigns a single mentor to each newly created account. We could explore alternatives in the future, though changes would be complex due to the current design—questions are posted directly to each mentor’s talk page. It would be helpful to have a sort of automated backup system. For example, if a question isn't answered within a certain timeframe, it could be escalated, perhaps posted to the Teahouse or another venue—so other editors have a chance to respond. This kind of system could also help surface mentors who are no longer active, allowing admins to update their status accordingly. Just brainstorming for now—not sure if that’s something worth pursuing, but it could be an interesting improvement.

Thanks for the feedback and thoughts regarding Mentorship! We haven't had a chance to focus much on Mentorship improvements recently, but I'm hoping the Growth team has time to work on some of the top Mentor priorities soon. KStoller-WMF (talk) 22:18, 29 April 2025 (UTC)Reply

(Moved discussion from en:Wikipedia:Village pump (idea lab)) — ‍Relativity ⚡️ 21:02, 2 June 2025 (UTC)Reply
I'm one of the mentors for en:Wikipedia:Growth Team features, and sometimes I become inactive for a couple of days and forget to set myself as "inactive". This leads to delays in my mentee's questions being answered. I'm wondering if it's possible to have some sort of feature that enables a mentor account to automatically be set to "inactive" after they haven't edited in a couple of days. The list of current mentors is available at en:Wikipedia:Growth Team features/Mentor list. I'm curious to hear anyone else's thoughts on this. ‍Relativity ⚡️ 21:37, 1 June 2025 (UTC)Reply

I suggest asking at mw:Talk:Growth, the talk page for the WMF growth team. isaacl (talk) 22:00, 1 June 2025 (UTC)Reply

Moved discussion. ‍Relativity ⚡️ 21:02, 2 June 2025 (UTC)Reply

Good for you that this is your concern. 🙂 As a huwiki mentor, I’m happy if I can answer questions once a week (on weekends), but I don’t want to be marked inactive in the meantime, as there wouldn’t be anyone to take over (there are only two automatically assigned mentors, but only one of them is really active). If this thing happens, I wish it’ll be opt-in (for those who know they often forget to set themselves as inactive, not for those who are just slow to answer). —Tacsipacsi (talk) 22:26, 2 June 2025 (UTC)Reply

Thank you for this excellent question (and for responding to new users). I say ‘excellent question’ because this is not the first time we have been asked this, but we have not been able to come up with a good solution. This issue also applies to mentors who have marked themselves as absent for a very long period of time. May I ask for your input to try to find a solution that works?

Here's a summary of what's already been said in terms of pros and cons:

• What's the right length of time for a break?
  • We need to specify an end date.
• If I am marked as ‘absent’, when am I considered present again?
  • Making a quick change to a page just because you find two minutes in your schedule to participate in a community decision should theoretically put the person back in the loop, but is that the goal? In the meantime, questions may arise again, with no possibility of answering them due to lack of time.
• Shouldn't someone who is marked ‘absent’ for a long period of time withdraw from mentoring?
  • I have seen people listed as absent for a year.

Note that some of these questions may already have been decided within a community, and that the community may set up a bot to modify the file where the names of mentors are stored.

Trizek_(WMF) (talk) 19:33, 3 June 2025 (UTC)Reply

@Trizek (WMF): Thanks for the prompt response. My thoughts are along the lines of this, but of course other people have different opinions on this as well:

• If you haven't edited in, say, three days, your mentorship is paused.
• Once your mentorship is paused, it says paused for maybe 30 days (I'm not entirely sure on the length here), during which time if you become active again, you have to manually un-pause.
• If you do not un-pause and your 30(?) days has lapsed, you are removed from the mentor list.
• I think the current system with editors manually pausing their mentorship works well; if you manually pause the mentorship and set yourself to be away for a set number of days, your mentorship will not be removed.

What do you think? ‍Relativity ⚡️ 19:46, 3 June 2025 (UTC)Reply

As far as how someone "should" withdraw, yes, of course they should, but sometimes we just don't remember to. ‍Relativity ⚡️ 19:47, 3 June 2025 (UTC)Reply

If not too complicated, I think a better solution could be pausing when there's been 4 new questions since the mentor last edited. Aaron Liu (talk) 20:38, 3 June 2025 (UTC)Reply

@Aaron Liu, I think that's a very good idea. Better to measure it based on what we want (newcomer questions being answered) than trying to use some other metric that's only an approximation of that. Some number of unanswered questions automatically triggering a "we put you on vacation" notice would be useful. -- Asilvering (talk) 01:46, 18 June 2025 (UTC)Reply

And when it pauses, it should send a notification! Aaron Liu (talk) 20:37, 3 June 2025 (UTC)Reply

out of 13, these are men articles: christian nang, joseph victor gonzales, tomas ocana Kiji-Jiki (talk) 08:21, 14 June 2025 (UTC)Reply

Hello @Kiji-Jiki

Thank you for reporting this.

We use a specific model to identify the topics we show. We have an accuracy of 90% at the moment but we are working on improving the model to avoid all these false results. The examples you shares will help us improving the model.

Thank you again! Trizek_(WMF) (talk) 17:59, 17 June 2025 (UTC)Reply

happy to help! Kiji-Jiki (talk) 18:07, 17 June 2025 (UTC)Reply

i am trying to abandon or reduce reliance or usage on web broswers. can do small minor edits on app also, why waste huge resources and recent local mess bug. where can i find list of suggested edits - easy task? Kiji-Jiki (talk) 08:30, 14 June 2025 (UTC)Reply

Hi @Kiji-Jiki

The Official Wikipedia Apps have a different set of suggested edits (on Android or iOS). You can log in to the app with the same username and password you used on your mobile browser.

I'm not sure to understand the rest of your message. Can you share more context, please?

Trizek_(WMF) (talk) 18:03, 17 June 2025 (UTC)Reply

By “recent local mess bug”, I guess you mean https://localmess.github.io/. However, I don’t get why you want to reduce reliance on web browsers in order to avoid this vulnerability – the vulnerability relies on native apps, so if you have no native apps (other than the absolutely necessary ones, like settings and calling apps), you also avoid it; and it’s unrealistic not to use the browser at all, as probably you have from time to time websites that you access only once. Also, an untrusted native app can exploit all vulnerabilities a website can, and more, so you’re absolutely worse off privacy-wise if you only use native apps. (Network traffic is another question, apps use less data if they’re well-written.) —Tacsipacsi (talk) 20:52, 17 June 2025 (UTC)Reply

I tried to conatct the project leader ages ago to get some info for North America first-time grant applicants and have heard nothing back. So am wondering how to go about things. I would like to organise wikipedia-editing-a-thons.

The site is here Grants:Start

Any info is mucch appreciated!

I&I22 (talk) 21:10, 18 June 2025 (UTC)Reply

@I&I22: Here is the talk page for discussing with the Growth team. If you have any questions about grants application, you can contact the Regional Program Officer by following this instruction. Thanks. SCP-2000 (talk) 05:06, 22 June 2025 (UTC)Reply

Amazing!! Thanks so much. That is very helpful. Woohoooo! 🥳 I&I22 (talk) 11:56, 22 June 2025 (UTC)Reply

Hey :) out of interest, does the Growth Team currently steward Extension:WikiLove ? Developers/Maintainers says that the extension is currently unassigned (AFAICS, the Growth Team was removed as stewards in Special:Diff/4132968); but phab:H26 still adds the Growth Team's project to WikiLove tasks, and (e.g.) phab:T397529 includes WikiLove in a task scoped to Growth Team repos. Best, ‍—‍a smart kitten_[meow] 18:33, 20 June 2025 (UTC)Reply

@A smart kitten - Apologies for the delayed response. I didn’t have a clear answer when I first read your question, and unfortunately, I still don’t have a definitive one. While the Growth team does not officially maintain WikiLove, we do care deeply about increasing positivity for newcomers and encouraging positive reinforcement across the wikis. In that sense, the extension aligns well with many of our goals.

The Herald rule at Phab:vH26 still automatically tags the Growth team on several features and projects we don’t maintain. In general, I’ve only updated that rule when we’re able to formally transition ownership to another team. KStoller-WMF (talk) 00:20, 8 July 2025 (UTC)Reply

@KStoller-WMF: Thanks for the answer, and no worries about the delay! It's definitely not the most pressing question in the world, but it's been something I've been curious about… so I thought I might as well ask :)

The Herald rule…still automatically tags the Growth team on several features and projects we don’t maintain - ah, I wasn’t aware of this, thanks for the context! ‍—‍a smart kitten_[meow] 13:06, 8 July 2025 (UTC)Reply

I've spent a lot of time trying to test AI-based link recommendations on English Wikipedia. Now it seems that it's disabled there. But I don't even know that.

"Have you read the docs?" – "Yes":

1. First, I followed the instructions at mw:Help:Growth/Tools/Add a link in English Wikipedia. But instead of AI-recommended links I got the regular "Add links between articles".
2. mw:Help:Growth/Tools/Add a link states "The following procedure is only applicable where Link recommendation is available", so I checked the table on mw:Growth/Deployment table to make sure it's deployed. It is.
3. It took me time to notice the link "Varies by wiki" (what varies by wiki?) at mw:Growth/Deployment table#Add a link. There, it's stated "Add a link is available at all Wikipedias except: Wikis that decided to turn it off", but there is no way to check which wikis have turned it off.
4. There is a "#Suggested: add links" tag in English Wikipedia which has some edits. So it works? But how do I enable it, goddamnit.
5. I even opened w:Special:CommunityConfiguration/GrowthSuggestedEdits and made sure "Add a link (Structured task)" isn't disabled. It also took time for me to realize that Structured task means AI-suggested recommendations. ("Structured task", "Suggested edits", "Suggested", "Add a link" – all these terms completely blended in my mind, and I'm not sure I know what is meant by any of them.)
6. I also opened w:Special:NewcomerTasksInfo. There, there are two "Add links between articles" tasks, but it seems the one with the ID link-recommendation is what I look for. There are tasks with that ID, so it should be enabled?
7. I tried to search for "Add a link" in English Wikipedia, but there is no w:WP:Add a link or w:Help:Add a link page. I've only found w:Wikipedia:Growth Team features, but it says nothing about whether this feature is enabled on English Wikipedia.
8. Finally, I've seen the text "At some wikis, this task is replaced by Add links between articles" at mw:Help:Growth/Tools/Newcomer Tasks#Suggested: add links, which made me suspect that it's not available on English Wikipedia after all.

So, I've went above and beyond, and I still don't know the very basic fact: whether AI-recommended links are available on English Wikipedia and how do I use this feature there. I'm completely lost and confused. Please help me and help others like me by improving the docs. JWBTH (talk) 07:08, 22 June 2025 (UTC)Reply

Hello @JWBTH

Sorry for the late reply. Thank you for your message, with all the details and suggestions.

"Suggested links" are available at all wikis but a few. At the moment,"Suggested links" are available as a limited test at English Wikipedia. This test was documented at w:Wikipedia talk:Growth Team features; however, the topic was moved to w:Wikipedia talk:Growth Team features/Archive 9.

Since March 18, 20% of newcomers get Suggested links. We are now working on the report for this test, which will be published in the coming week.

As it was a limited test, we haven't documented it is our general documentation, which should have been done (and is now done).

It is possible for you to have access to the feature, using a code snippet. Here is the process, using a desktop browser:

1. visite the homepage at w:Special:Homepage
2. do a right click on the page to open the Inspection tools or Inspector (that name can vary from browser to browser)
3. locate the "console" tab
4. copy and paste this snippet into that console: ge.utils.setUserVariant( 'control' )
   • Please note that the console may have some safety procedures to follow, which will be displayed when you will try to paste. They are different depending on the browser. For instance, Chrome/Chromium asks you to write "allow pasting" and press Enter before allowing you to paste the snippet.
   • You may see some error messages being displayed. You can ignore them.
5. the Homepage reloads with links suggestion enabled.

I hope this helps you. Let me know if you need any other detail or assistance!

Sorry again for the confusion, Trizek_(WMF) (talk) 12:46, 9 July 2025 (UTC)Reply

Thanks for the detailed instruction and for updating the docs. That small edit sorts this out full well. JWBTH (talk) 09:04, 10 July 2025 (UTC)Reply

Glad this solved your long journey.

Pleas let me know how your test of the feature went. And feel free to ping me regarding any question or feedback you might have, either here, at w:Wikipedia talk:Growth Team features or via a direct message. :)

Trizek_(WMF) (talk) 12:07, 10 July 2025 (UTC)Reply

I am seeing a lot of these Growth edits adding links in my watchlist. Now a lot of them seem to relate to archictural features, e.g. linking the word "balustrade" to en:Baluster and so on. These seem to be fine. But when it involves people and places (given that the world has a lot of people and places with the name same, regardless of whether there is a Wikipedia article about one or more of them), it seems some new users are not bothering to do even the most basic check. For example, linking the name of a builder of 1880s structure to a current professional tennis player, clearly someone not even born at the time of the build. Now, I don't get to see how these suggestions are being made to these new users but I think there needs to be some advice about checking both articles to confirm it is the same person/place and not just the same name. Nobody likes reverting new users, so it would be better if this could be avoided. Kerry Raymond (talk) 23:45, 13 July 2025 (UTC)Reply

Hi @Kerry Raymond, thank you for raising this concern!

The "Add a Link" feature is designed to help newcomers make their first contributions more easily, and it has shown promising results in terms of engagement and activation (see our recent recent A/B test analysis). That said, you’re absolutely right that accuracy is important, especially when it comes to names of people and places where context matters. Mismatched links, like the example you mentioned of a 19th-century builder being linked to a modern tennis player, are clearly problematic and can create confusion for readers.

While some level of imperfection in the suggestions is expected and should help encourage newcomers to review and make thoughtful decisions, we know this relies on newcomers taking the time to evaluate the context carefully. To support this, our onboarding emphasizes that the machine-generated suggestions can be wrong and that users should always verify whether a link is appropriate. Here's the current guidance shown during onboarding:

Adding links will help people learn faster. You will decide whether words in one MediaWiki article should link to other MediaWiki articles.

Suggested links are machine-generated, and can be incorrect. The suggestions might be on words that don’t need them, or might link to the wrong article. Use your judgment to decide whether they are right or wrong.

Guidelines

Link concepts that a reader might want to learn more about.

Make sure the link is going to the right article.

Don't link common words, years, or dates.

If you're not sure, skip.

That said, we know this isn't foolproof. We appreciate reports like yours, as they help us understand where additional clarity or safeguards might be needed. Local communities also have the ability to influence how suggestions work. On English Wikipedia, admins can adjust the configuration of the “Add a Link” task to help reduce problematic suggestions. Those settings are available here:

https://en.wikipedia.org/wiki/Special:CommunityConfiguration/GrowthSuggestedEdits

We’ll continue working to strike the right balance between simplicity for newcomers and accuracy for readers and patrollers. Thanks again for your thoughtful feedback. KStoller-WMF (talk) 22:57, 21 July 2025 (UTC)Reply

Well, it seems the user in my example above has just been blocked as a sockpuppet with a long history of vandalism involving adding false information, so in this case I think we can assume the problem was this user, not the suggested edit process. However, it is not the only example of failure to disambiguate people and places. One of the problems that we face with checking these edits is that we do not know what exactly has been said to the new user as part of the suggested edit process. It would be better if a link to what they have been suggested to do and any instructions for doing it could be linked from the automated edit summary; currently someone reverting them or trying to help them is flying blind as to what has actually been suggested in terms of the task or the guidelines for doing it. Since I can't see these suggested edits on the user's Talk page, evidently they must be appearing somewhere else, but surely they are logged somewhere that could be linked into the automated edit summary. I think that would be helpful for responding more usefully to problematic edits done in good faith through the suggested edit system. Kerry Raymond (talk) 01:35, 22 July 2025 (UTC)Reply

Hello, I hope the entire team is doing well. Good job! I have a suggestion regarding the tools. There is an Add links between articles (Machine suggestions) feature and when adding a certain number of linked articles it says come back tomorrow. I'm an admin here and it helps me a lot to add links to articles also training more students online. Is there any way to allow admins to have no limit for that? Hussein m mmbaga (talk) 09:25, 12 August 2025 (UTC)Reply

@Hussein m mmbaga - That's great to hear this tool is helping with training new students!

No, there isn't currently a way to only change the limit just for admins. What is currently possible is that you can increase that limit for everyone here: https://sw.wikipedia.org/wiki/Maalum:CommunityConfiguration/GrowthSuggestedEdits

You would just change the The maximum number of "Add a link" suggested tasks a newcomer can complete daily to a higher number. However, that will allow ALL users to complete more tasks every day.

@Trizek (WMF) - let us know if you have other suggestions, or if you think we should log a Phab task for this request. KStoller-WMF (talk) 22:46, 14 August 2025 (UTC)Reply

Well, as the intent of this feature is to help newcomers adding links. I usually advise experienced users not to use this feature, as there is a risk of emptying the backlog of tasks (it already happen at other wikis). While Swahili Wikipedia has +6k Add a link tasks available (as I write this), some topics are already a bit empty. I'm not blocking the idea, just providing more context so that @Hussein m mmbaga can tell us what he thinks! ;) Trizek_(WMF) (talk) 14:08, 18 August 2025 (UTC)Reply

Thank you @Trizek (WMF) and @KStoller-WMF for the clarifications.

Anyway, I understand that the main purpose of the tool is to support newcomers. However, I have another suggestion: when the tool suggests to add a link to an article, sometimes I notice that the entire sentence also needs adjustment to make it more understandable for other readers. But when I switch to visual editing (since the machine suggestion does not allow me to edit the sentence), I am required to publish the changes first. After publishing, the machine’s suggested link then becomes unavailable in that article. Is there any way to allow edit article sentence and then active a tool to suggest ?

Asante sana!Hussein m mmbaga (talk) 20:21, 20 August 2025 (UTC)Reply

@Hussein m mmbaga I don’t believe there is currently an easy way to return to a link suggestion once you leave it and publish an edit in Visual Editor. That said, there is ongoing work exploring a “Suggestion Mode,” which may be closer to what you’re describing: the ability to navigate to a version of the article that displays suggestions at any time (see: T399612).

These ideas are still in the early stages, and the initial version will not include link suggestions, so it may not fully address the situation you’ve noticed. I do agree, though, that it would be ideal to offer a way back to suggestions (when available) even if you didn’t arrive at the article directly from the Suggested Edits feed. Thanks for raising this point! KStoller-WMF (talk) 23:50, 21 August 2025 (UTC)Reply

Thanks for the explanation. I agree it would be very useful to have a way to return to link suggestions in the future. Hussein m mmbaga (talk) 13:40, 22 August 2025 (UTC)Reply

See the various discussions on en.wp Village Pump for context. We're still trying to come to a firm policy about this but the gist is that we're getting overwhelmed with AI edits, and it's come to light recently that the problem is much more widespread than anyone thought.

In my experience tracking AI edits down, a significant amount seem to be originating in newcomer tasks, especially the ones involving copy-editing and finding sources. AI copy-editing tools are not good and tend to introduce editorializing and original research under the guise of "improving writing." Here's a good example of why AI copyediting is bad, apparently coming from Grammarly. Stuff like "revolutionized the way Peruvians prepared their meals" is both POV slop and not actually copy-editing, given that the original text had no such statement. Commentary like "this initiative has been successful evidenced by the declaration of July 28 as 'National Ceviche Day'" is even worse: not only is it promotional and going beyond the original text, but it introduces a possible inaccuracy -- what if the initiative wasn't going so well, and the National Ceviche Day thing was an attempt to salvage it?

Meanwhile, we all know the issue with AI generating hallucinations and such in citations.

So, given that this is one of the first things people see, it would be nice to have some language around the task for this. Gnomingstuff (talk) 19:39, 30 August 2025 (UTC)Reply

@Gnomingstuff - Sorry for the delayed response! I’m open to copy improvements, but I’m not sure this is actually an issue specific to Newcomer tasks. The diff you shared doesn’t appear to have been initiated through the Suggested Edits feed (copy edits that come from there all receive the Newcomer task: copyedit tag).

If this is a significant issue with Newcomer tasks, I’m open to making improvements. That said, we’ve often found that adding more onboarding text tends to get skimmed and doesn’t meaningfully change newcomer behavior. I wonder if tools like Edit Check could help by detecting problematic editing in the moment and giving editors guidance right when they need it, rather than relying on them to absorb policy information upfront. Do you think Paste Check could help in cases like you linked to? KStoller-WMF (talk) 00:16, 10 September 2025 (UTC)Reply

As always, my watchlist is full of these suggested edits and but today a lot of them than normal are resulting in appropriate links. For example in an Australian article, the term "Church of England" refers to the Anglican Church of Australia, not the UK Church of English. The term "east room" used in the simple English sense of a room in the east of building is suggested to link to the East Room in the White House in the Washington DC. And so on. These suggested edits all have to be reviewed and quite a few reverted. This is a massive waste of volunteer time to review and revert. Also multiple suggested edits are in one edit, meaning that one bad edit reverts the other edits too. Does anyone review these suggestions before they released to weed out the obviously inappropariate ones (like "east room"). Kerry Raymond (talk) 00:00, 24 September 2025 (UTC)Reply

@Kerry Raymond: I don’t think anyone from the Growth team reviews these machine-generated suggestions, since the point in them being machine-generated is that there is no human review before they are suggested to the newcomers. The newcomers, however, are expected to review the links before actually adding them to the article – but this review apparently doesn’t happen as often as it should. (I hope many newcomers do review the links, so what you see is only a small percentage of the wrong machine suggestions, but this doesn’t mean it isn’t too much.) I don’t know if there is any way to make the algorithm smarter or the interface more obvious, or the only solution is educating newcomers more. —Tacsipacsi (talk) 15:20, 28 September 2025 (UTC)Reply

I recently had to revert a couple of edits on enwiki by a new user who used the tool and sometimes added links that didn't make sense. Maybe the tool should enforce a rate limit. (The user made several edits per minute.) Or have something like big red warnings that remind users to be careful... — Chrisahn (talk) 08:23, 7 October 2025 (UTC)Reply

We have a daily rate limit in place, which could be lowered: Special:CommunityConfiguration/GrowthSuggestedEdits

And it might be worth considering additional limits. That said, some tolerance for mistakes is essential. Errors provide opportunities to engage with new editors, guide them, and welcome them to the community. I also envision a future where reviewing simple edits, such as "Add a Link," could serve as an onboarding opportunity for newer editors to learn basic patrolling and moderation skills.

In the short term, reviewing the relevant community-configurable settings is the quickest way to implement adjustments. Meanwhile, the Growth team will continue exploring additional strategies to support newcomers and improve the overall experience of this task for the community. We are working on a new project that includes “quiz-style” onboarding, which could be applied to "Add a Link", allowing editors access to the task only after successfully completing the onboarding. Do you think that style of limit could help? - KStoller-WMF (talk) 23:34, 9 October 2025 (UTC)Reply

On enwiki, the manual of style specifies in en:MOS:DABBLUE that entries on disambiguation pages should contain no links (except the link to the target page). I recently had to revert an edit on en:USS Myrtle where a new user added links in disambiguation entries, apparently following suggestions of the tool. I think the tool should be disabled for disambiguation pages on enwiki (and other Wikipedias as well, if they have similar rules), since its suggestions for these pages are very likely to violate the manual of style. — Chrisahn (talk) 08:17, 7 October 2025 (UTC)Reply

Oops, I was wrong. Maybe this was a false alarm. Someone pointed out that the page en:USS Myrtle isn't actually a disambiguation page. It just looks like like one. Maybe the tool is already smart enough to not suggest additional links on disambiguation pages, I don't know. But just in case it isn't, I'd still like to point out that it should be. :-) — Chrisahn (talk) 17:57, 7 October 2025 (UTC)Reply

"...in the north of Australia after the devastation of Darwin and the West Australian towns." Another case-insenitive suggested link replacing plain English with an inappropriate link to a newspaper of that name. Can this suggestion be removed from the program please. Can we improve the instructions given to these new users to READ the article before deciding whether to link. It would also be nice to allow feedback from these new users to know when they decided NOT to add a suggested link (and perhaps why). Kerry Raymond (talk) 23:14, 8 October 2025 (UTC)Reply

Hei hei! I wonder if mentees are automatically subscribed to their own questions (discussion threads initiated using the Growth mentorship feature). I think if not, this could be beneficial to mentor–mentee communication! Although I usually ping the mentee directly, not all mentors and helpful users do. It could perhaps show up with a tooltip of "You will get a notification when you receive a reply to this question! If you don't want to get more notifications for this question, click 'unsubscribe' next to its header!" or something similar. EdoAug (talk) 23:39, 27 October 2025 (UTC)Reply

Hello @EdoAug

Oh, I filed this bug report today before noticing your message: T408566: Mentees aren't subscribed to the message they send to their Mentor using the Mentorship module.

Pinging is the current best practice, as we deployed the feature before the deployment of the subscribe feature.

Trizek_(WMF) (talk) 16:18, 28 October 2025 (UTC)Reply

@Trizek (WMF): What a fun coincidence! As I've noticed some other users reply to "my" mentees on my talk page without pinging, I figured it would be a good idea for them to also be subscribed. EdoAug (talk) 18:16, 28 October 2025 (UTC)Reply

This article is discussing a historic form of timber framing and as the article says in the lede "with joints secured by large wooden pegs". However, there are buildings built with timber framing in the last couple of centuries mostly all use nails (or other methods), so a link to this article is inappropriate. Can it be removed as a suggestion as it is being suggested for many articles and none of those suggestions so far appears to be appropriate. It is a suggestion doing harm not good. Kerry Raymond (talk) 23:15, 31 October 2025 (UTC)Reply

This article is about the process of tree planting on a wide scale (e.g. afforestation) and not about planting a tree or two at a house, but again this suggested link is being mindlessly added to many articles inappropriately. Could it be removed as a suggestion as it appears to be doing more harm than good? Kerry Raymond (talk) 23:20, 31 October 2025 (UTC)Reply

Is an alert, message on my talk page, or other notification sent to me when I am assigned (or lose) a mentee? If not, can you add this feature? My preference would be an alert at en-wiki (where I signed up) with a message, "[[User:Example 1]] is [now | no longer] assigned to you as a mentee. You now have [[Special:MentorDashboard | N mentee(s)]]." Thanks, Mathglot (talk) 00:23, 27 November 2025 (UTC)Reply

Depending on the number of newcomers and that of the mentors, one can be assigned dozens of mentees each day – most of whom never ask, many never even edit anything. Do you really want to be spammed with notifications about them?

On the other hand, the “no longer assigned” message could make sense – as far as I know, there are two ways someone can loose a mentee, either by the mentor quitting mentoring (in this case, no notification is needed, since the mentor themself initiated the action), or by someone else claiming the mentee via Special:ClaimMentee, which should be rare, so a notification in those cases wouldn’t be too spammy. —Tacsipacsi (talk) 22:40, 27 November 2025 (UTC)Reply

Hm, I see your point. Nevertheless, I still want to keep informed but not spammed. Perhaps it could be modeled after something like the en:WP:Feedback request service? There, I sign up, and define how many notices I want (and about what categories of topics) per month or per unit time. Maybe a MentorBot could be created, and at my discretion (by dint of a sign-up page like at en:WP:FRS, say) would write me a monthly, or weekly message (or whatever I specified), enumerating my mentee list, any drops or adds, and perhaps include a brief summary of my Q&A activity per mentee over the last month, or other interval. Maybe some of the existing db reporting tools could later be applied to the repository of Q&A info and create useful reports and charts of how I am doing, and summary charts at higher levels about how the whole project is doing over time. Thoughts? Mathglot (talk) 09:40, 28 November 2025 (UTC)Reply

On further consideration, I think I need to get an alert the minute a user is assigned to me. Although I refresh and check my Mentor dashboard frequently, apparently I am not fast enough, because several users assigned to me today were welcomed by other users before I was even aware that they were registered as users. While I appreciate that other users are busy welcoming new users and certainly don't wish to discourage them to do so, I see part of the benefit of the Mentorship program being the possibility for a mentor to welcome their mentee personally on their Talk page, either using one of the mentor welcome templates or in their own words.

So now, four of my new mentees have nondescript welcome messages of the standard, Welcome committee template variety, taat are okay as far as they go, but that say nothing about Mentorship, much less who their mentor is. I have been wrestling with possibly replacing the original welcome with my own welcome, but that would look like (and indeed would be) a revert to the editor who placed the original welcome, and annoy them or put them off placing more welcomes, and that wouldn't be a good result; not to mention possibly whipsawing the newbie, if they had already seen the first welcome. Two welcomes on the page might be an alternative, but could seem like too much to the newbie, all at once. All in all, this is not an ideal situation.

Can you arrange for the possibility for mentors to get an alert ASAP after a newcomer signs up? I can imagine that not all volunteers would want this, so it might have to be an opt-in (or -out) feature at signup time. This would no doubt be a feature that would require time to define, design, and implement, but I can envision a quick fix involving a bot: write a bot that pings a user (or writes a one-sentence User talk page message, 'User:Example1 is your newest mentee!') where opting out requires no additional software, just a brief note on the MenteeAlertBot doc page explaining how to mute the bot user in your Preferences. Another path to the same result is on the other end: slow down whatever feed currently displays newly signed up users to give the Mentor alert time to catch up; sort of like the Dow-Jones 15-minute delay.

Various other alternatives occur to me involving changes to the existing Welcome committee templates, or to the procedures for placing them. It would be easy to modify existing Welcome templates to detect the existence of a mentor using {{#mentor}}, and then do something, but what? Suggest they welcome someone else? Or maybe, all welcome templates should identify their mentor, even if placed by a different user. But that would be a fairly major change (technically easy, but major in concept), and would require some level of consensus at the Welcoming Committee, possibly an Rfc to get wide community support. Mathglot (talk) 21:57, 2 December 2025 (UTC)Reply

P.S. One user was assigned to me *while* I was composing this message. I managed to catch it and welcome them, because I was refreshing the dashboard several times while writing the message, but that is not sustainable. Mathglot (talk) 22:00, 2 December 2025 (UTC) updated by Mathglot (talk) 02:56, 3 December 2025 (UTC)Reply

Hi @Mathglot, Thanks for raising this and for the care you put into welcoming your mentees. I appreciate the thought you have given to how these first interactions shape a newcomer’s experience!

I worry that real-time notifications for every mentee assignment could become overwhelming for many mentors, especially since a large share of new accounts do not go on to edit. That said, I agree that a personal welcome from a mentor can feel more meaningful than a generic welcome message from a random editor, and I understand why you would want to be aware of new assignments quickly.

One idea I've considered in the past is if we should allow Mentors to opt into automatically welcoming their new mentees: T345780. I would be interested in your perspective on whether something like that would address the underlying problem you see here.

There is also a Mentorship feature that we have not yet released on English Wikipedia that sends a notification only when a mentee reaches an edit milestone. It was part of Growth's Positive Reinforcement work: Growth/Positive reinforcement#Personalised praise 3.

Earlier pilot tests showed that few mentors ended up sending messages in response, and we did not see clear impact that justified investing further at the time. You can read experiment results here.

Our hope is to revisit and improve this feature so it can be scaled to more wikis. We have had competing priorities recently, but if English Wikipedia mentors express interest, we can enable the existing version. Mentors can disable the notifications easily if they prefer.

Thanks again for taking the time to think through this. Your feedback helps guide future improvements to Mentorship. - KStoller-WMF (talk) 23:18, 3 December 2025 (UTC)Reply

I’m not sure how useful such notifications would be – after all, you’re probably not online 24/7 (for example, you need to sleep sometimes…), so you’ll inevitably miss some new mentees (especially on a wiki with global reach like enwiki, since newcomers from around the globe can register at any time, even at times that are in the middle of the night for you).

However, if you really want to get real-time notifications, maybe it could be a Toolforge tool rather than on-wiki notifications. A Toolforge tool would naturally be opt-in (people who don’t go there and sign in don’t get notified), and it could support notification methods not currently supported by on-wiki notifications, for example RSS or even desktop notifications (the kind of notifications you can enable in your Phabricator settings). Toolforge tools are usually community-maintained, so they are also a good fit if the Growth team doesn’t have the capacity to work on your request. —Tacsipacsi (talk) 12:36, 6 December 2025 (UTC)Reply

I take it that temporary editors (unregistered/anonymous/IP editors) do not automatically receive a Home page, and cannot receive a mentor. Is this a correct assumption, and is it a permanent state of affairs, or might this change? There are IP editors who are very reliable, senior, and experienced, and have been on the project for many years, and even help out very effectively at the en:WP:Teahouse, en:WP:Help desk, and other forums with good advice for new editors, registered or not. I don't see a priori why newer, less experienced temp/anon/IP users should not receive the benefits of mentorship, when their more senior cousins are respected, contributing members of the voluntariat.

I get it, that their IP or temp address may be dynamic, and change; but so what? We could either just assign them a new mentor, or if they want to self-identify as previously having been at some other IP where their mentor was User:XYZ and they liked their advice, we could have a (new) process like, reclaim-mentor, or some such, where when they popped up at a new temp username, they could just reapply and keep their previous mentor, assuming the mentor was agreeable. I would certainly have no qualms about mentoring a sincere IP/temp user, who wished to stick with me while their IP/temp username bounced around over time. Mathglot (talk) 09:53, 28 November 2025 (UTC)Reply

@Mathglot You are correct. Temporary Accounts do not currently receive any Growth features, including the Homepage and Mentorship. This decision was made to limit major changes during the initial rollout of Temporary Accounts, and because IP editors have historically not received Growth features, we applied the same approach.

We can certainly revisit this. I am interested in hearing how other Mentors view this question. One factor to consider is that, if enabled, mentors would receive significantly more mentees by default.

Another factor is that, from a community health perspective, we want to encourage editors to create regular accounts in most cases. If all features are made available to Temporary Account holders, we may reduce the incentives for creating a standard account. KStoller-WMF (talk) 16:37, 30 November 2025 (UTC)Reply

KStoller-WMF, that makes sense. I think it is worthwhile looking into further. I remember seeing (in some other Wikimedia context) the possibility of A–B or percentage-rollout release testing. Maybe a small number of temp accounts could be tested that way, and you could then gauge mentor reaction based on a very small increase in load, trackable separately between temp and registered accounts, with the compliance of mentors who give prior opt-in to your test. Is that something that could be considered? I am recently signed up as mentor, so not the best person to ask about increased load since I hardly have any, but I'd certainly opt in, so you can sign me up as a volunteer for a three-month test to see how it goes. If the temp pool is large enough, you could even further subdivide it into two groups: those to whom the mentors urge registration (more than standard welcome messages already do) and those they don't, and measure the effects of that. Thoughts? Mathglot (talk) 23:17, 30 November 2025 (UTC)Reply

Hi @Mathglot, I definitely think that it's worth running an A/B test in this space! After the Revise Tone project, the next major project the Growth team will focus on is around improvements to Account Creation:

T409236 Account Creation: Audit and improve the account creation experience across Wikimedia wikis

This work will allow for some time to focus on improvements and experimentation around Temporary Accounts. I'm unsure exactly what that will look like, but I just added a link to this discussion to the task, so we will review this idea when we are ready to start that project. Thanks for the feedback! KStoller-WMF (talk) 01:25, 2 December 2025 (UTC)Reply

Sounds good. Ping me at the appropriate time. Mathglot (talk) 10:50, 3 December 2025 (UTC)Reply

I have rewritten section Growth/Communities/How to configure the mentors' list#Welcome templates, keeping as much of the original wording as possible, but deleting some inappropriate advice from that section. In particular, the recommendation to use magic word {{#mentor}} in a welcome template placed by a mentor to inform a newcomer about the name of their mentor is bad advice. For one thing, the stated reason that the magic word will change names if the mentor changes, is true (if transcluded) and egregiously bad advice, as a welcome message is intended to identify the mentor who placed the welcome (and any other changeable data) at the time the welcome was placed, and not some other mentor down the road; that is why they are always substituted.

Instead, the mentor should simply sign the template with four tildes, which will automatically tell the newcomer who their mentor is. Furthermore, if the intent of a templated welcome message is to display and link the Mentor name in the message body itself, then it should either provide a param where the Mentor can enter their name, or more simply, just identify them automatically by using subst:REVISIONUSER, and not the magic word. This is the approach employed by template w:Template:Welcome mentee. I suppose if one wished a bot to place a Welcome message on behalf of the mentor, then, yes: the bot could use the magic word to display the mentor name for a given newcomer, but why would we want a bot do it if the whole point is to have a mentors introduce themselves?

I left a sentence about the magic word in that section in order to change as little as possible, however, in fact nothing about the magic word should be mentioned in a section labeled 'Welcome templates' at all. Something about the magic word does belong somewhere on the page, but this is not the section for it, as it is entirely irrelevant here. Imho, it should either be moved to its own section 'Magic word', or else to some other section, if a relevant one can be found. Mathglot (talk) 02:54, 1 December 2025 (UTC)Reply

I find your edits relevant, but they may be limited by the way you think of welcome templates as they are used at English Wikipedia. Other wikis have other ways of doing things, which aren't less relevant that what English Wikipedia do. It is up to a community to decide if the welcome message should have a permanent name, or see this name being substituted. This is the kind of question they should ask themselves, for instance if they decide to use a bot or NewUserMessage to distribute welcome message to every new account. I re-edited the page to show that diversity of solutions, with pros and cons.

Regarding the point of having a bot, I documented it in a response below. In short, it relates to equity; everyone gets a chance of being properly welcomed. Trizek_(WMF) (talk) 14:30, 3 December 2025 (UTC)Reply

See this edit on my en-wiki Talk page (here) which is formatted like a mentee question, but when I look at my Mentor dashboard, which currently has nine users, they are not listed there. Evaluating {{#mentor:Khushi0305}} at en-wiki displays my username, so I appear to be assigned as their mentor, so why do I not see them on my dashboard? Is there a delay involved post-assignment? It's been at least an hour. Mathglot (talk) 10:04, 1 December 2025 (UTC)Reply

Now they are listed. They registered their account 2025-12-01 06:19 and asked their mentorship module question at 06:20, so given the time of my comment above and this one, there seems to be a delay of four to twelve hours before someone shows up on your mentor dashboard. Does that jibe with your expectations? Mathglot (talk) 18:09, 1 December 2025 (UTC)Reply

@Mathglot - you are correct, the data on the Mentor Dashboard is only updated periodically, it doesn't fully refresh upon page load. Currently the data updates every three hours I believe. The Growth team is actually working on an improvement right now to make that clearer: Mentee overview: Add "last updated" indicator (T293454).

Thanks for asking questions and working on template improvements! The Growth team has a lot of other projects in progress, but we hope to continue to make gradual improvements to Mentorship, so always welcome feedback. Thanks! KStoller-WMF (talk) 01:13, 2 December 2025 (UTC)Reply

Use of labels like "about half the average" or "about twice the average" are mathematically unsound and should be replaced. They are circular definitions and may fall into an unstable feedback loop based on a moving average, if you are actually computing the average load and using it for assignment. If most people choose "half the average", the average moves downward, and would end up at 1. If most choose "twice the average", the average moves upward, and could continue to increase indefinitely, or at least until there are no more accounts to assign, or mentors complain and someone steps in. Mathematically, it is an unstable system with a tendency to diverge rather than settle down (unless half and 2x choices are evenly balanced).

There are various ways to label these in a way that is mathematically sound, either in absolute or relative terms. You could talk about absolute load and list the numbers: (light load e.g. 1–10 mentees; medium: 11–20; high: 20–40); or you could mention mentor activity preferences (low mentoring activity, normal, high); or have relative tiers where you map the labels to numbers of mentees under the hood: (tier 1: minimal; 2: standard; 3: expanded); or any labels that avoid self-reference. Thanks, Mathglot (talk) 22:25, 2 December 2025 (UTC)Reply

It is not possible to have an absolute number as we have a moving average of new accounts. We assign a mentor to every new account, and we will keep that equitable assignment up: we know that some newcomers' first edit is a question to their mentor.

The choice offered to mentor are about assignment at the time they select it. When you select "half the average", then your name is picked less when we assign a mentor to new accounts. If everyone choose the lowest level, then everyone would get the average.

We can't predict the number of mentees who will reach at their mentor: you can pick the lower threshold and have almost all your mentees contacting you (and maybe feeling overwhelmed), or pick the highest level and get zero message.

It is not possible to list numbers, as these number vary depending on the seasonality of new accounts, the wiki's activity and and its appeal. Relative tiers could be a better fit, even if it wouldn't reflect the real volume of questions you'd get. Thank you for suggesting this. Trizek_(WMF) (talk) 13:16, 3 December 2025 (UTC)Reply

Suppose a mentor having a full roster of mentees on their dashboard and a volume preference of either '2x' or 'average' downgrades to the next lower volume level. Please consider the following questions in the aftermath of the downgrade:

1. Does the system unassign half of their mentees?
2. How does it choose which ones to remove?
3. Are any unassigned mentees immediately reassigned to a different mentor, or what happens to them?
4. How does the mentee find out their new mentor, are they notified by some bot?
5. What if all signed-up mentors have full rosters, i.e., no spare capacity anywhere, then:

   a Who tells the user they no longer have a mentor?

   b Does the mentor module disappear from their homepage?

Thanks, Mathglot (talk) 04:16, 3 December 2025 (UTC)Reply

Thank you for your questions, Mathglot.

The only ways to have your mentees being reassigned is by either having one being claimed by another mentor using Special:ClaimMentee, or to quit, using Special:QuitMentorship. In these cases, the mentee get a notification through the system (no bot involved); if a claim is made, as a mentor, you receive a notification as well.

If a mentor quits, we reassign a mentor to all mentees, except the mentees who signed-out of mentorship in their preferences.

A community can use the Community Configuration so that experienced users are be automatically opted-out from mentorship after a certain treshold. These opted-out users can sign-in again. This was created as some experienced users didn't felt okay having a mentor assigned to them.

When you change the volume preference, you change the "weight" of your assignment but all previous mentees remain assigned to you.

What could be a full roster? It depends on the mentor. So far, I observed:

• mentors who sign out (or put themselves on pause) as they don't have enough time to dedicate to the newcomers or to the wiki
• mentors who stop responding to newcomers, which is a concern as a new comer not getting a reply could be frustrated.
  • As a volunteer mentor, I sometimes patrol the list of mentors to see how my colleagues respond. Something, I remove them from mentorship.

Hope this helps. Trizek_(WMF) (talk) 13:37, 3 December 2025 (UTC)Reply

Can you clarify? You currently have a dropdown listing volume preferences, and if you can upgrade your preference (i.e., go from 1/2 to avg, or avg to 2x) but not downgrade it (reverse operation), then there is no way for a mentor to say, "Uh-oh, I bit off more than I can chew, I had better take on fewer mentees". Are you saying, that once you have signed up for avg or 2x, there is no way to reduce your desired load anymore? This sounds like a very serious design error to me, unless I am missing something. You said:

When you change the volume preference, you change the "weight" of your assignment but all previous mentees remain assigned to you.

What is the "weight of your assignment"? I don't see this defined anywhere.

As I understand it, as new users register, you have a pool of newcomers with no mentor, until your assignment process picks them up and assigns them a mentor. What I am suggesting, is that you need an unassign procedure as well, and when a mentor downgrades their volume preference, you (randomly? by age?) grab some of the mentor's mentees (exactly half, if the mentor has a full roster) and put them back in the unassigned pool. Surely you must already have such a procedure to deal with mentors who leave the program and give up all their mentees, right? Once back in the pool, your existing assignment process will pick them up and assign them again. If your assignment process grabs users sorted by oldest registration date as I assume it does, then your existing process will automatically prioritize assigning such users restored to the pool before dealing with brand new accounts. This is exactly as it should be, as the older accounts lost their mentor through no fault of their own, and deserve to have one assigned ASAP, and this would fall out automatically without having to code for that case, assuming you grab oldest users first.

What I meant by the term "full roster" does not depend on the mentor, how they respond, or their pause status. It depends solely on their volume preference choice and how many mentees they currently have. As new mentors sign up, they start off with zero mentees. Then, the mentee list on their dashboard starts to grow longer, as the assignment process starts to assign users to them. At some point, the assignment process stops assigning them new users based on their volume pref, right? A strict definition might be: "A mentor's roster is full, when the assignment process will no longer assign the mentor any new mentees based on their mentee count and the mentor's stated volume preference." The part about a mentor downgrading their volume pref in the case of a mentor with a full roster, means that when they downgrade they are 200% of full and exactly half their mentees would need to be returned to the unassigned pool in order to be at 100% (full roster) with half their previous mentees at the lower preference level. Hope this makes sense now. Mathglot (talk) 23:24, 3 December 2025 (UTC)Reply

Mentors names are immediately assigned based on their current volume preferences, and that's all. What you describe in your paragraph starting by "As I understand it..." is not how mentors assignment work.

"Weight of the assignment" is the mentor preference that offers to select 'half the average', 'average', and 'twice the average'; I also used "volume preferences" which was confusing. Think about that weight as a tap. The tap is open with a default debit. When you change your preferences, you turn the tap more or less (half the debit or twice the debit). The volume of assigned mentors increases or decreases accordingly. But any liquid /number of mentees that already came through that tap remains yours.

There is nothing like a full roster: we don't have a limited volume to fill in, and we don't limit the number of newcomers who get your name. The reason is that most new accounts will never start editing, or drop quickly, meaning that the volume remains manageable. Trizek_(WMF) (talk) 11:56, 4 December 2025 (UTC)Reply

Could you please add anchors to the homepage modules so I can address them directly? I am currently using some hacky code to accomplish this in w:Template:Welcome mentee, but I would like to do it properly. Here is sample template code with a hacky direct link:

• As your Mentor, you can always find me listed in the "Get editing help" module bottom right on your homepage.

If you click the link, it will take you to the mentorship module on your own homepage, but due to the hack, it won't display the top border of the module because the hack involves using a fortuitous anchor already inside it. This is a fragile hack (as it is undocumented an may go away or change, and also isn't quite in the right place. Please see this pretty-printed code snippet:

<div class="growthexperiments-homepage-group-sidebar-subgroup-secondary growthexperiments-homepage-group-sidebar-subgroup-secondary-user-variant-control">
  <div class="growthexperiments-homepage-module growthexperiments-homepage-module-mentorship growthexperiments-homepage-module-desktop growthexperiments-homepage-module-user-variant-control" data-module-name="mentorship" data-mode="desktop">
    <div class="growthexperiments-homepage-mentorship-header-wrapper">
      <h2 class="growthexperiments-homepage-module-section growthexperiments-homepage-module-section-header growthexperiments-homepage-module-header">
        <div class="growthexperiments-homepage-module-header-text">Your mentor</div>
     </h2>

I believe a new id=mentorship-module or similar could be added to one of the divs; I'm guessing the second one is the logical location for it. Thanks, Mathglot (talk) 07:41, 3 December 2025 (UTC)Reply

I documented your idea, which I find really relevant. Thank you for that suggestion.

---

If I may, as a volunteer —

A while ago (2010), I worked on welcome templates. We got better engagement when we added a simple and clear call to action close to the top of the message, like:

Hello, Trizek, and welcome to Wikipedia! I'm Mathglot and I've volunteered to be your Wikipedia mentor. You can contact me for you whenever you need help with Wikipedia. What matters most is discoverability.

Since then, French Wikipedia has one unified welcome message, which has pretty much the same contents as yours. It was adopted by some other Wikipedias over time and it inspired the Mentorship system Growth developed.

Also, some newcomers don't look at their Homepage, while others don't look at their talk page. As a consequence, my community decided to post the welcome message to every new account, signed by their mentor (using the magic word #mentor). It is a way to provide an equitable welcome to most new accounts. We stopped thinking about "let's just welcome users who already made an edit", as we discovered that sometimes a newcomer's first edit is a question to their mentor.

Recently, addressed the case of newcomers who use the "reply" button to respond to their mentor's welcome message, using a LLM. The bot detects if the message is a real question, and then tells the mentor that someone responded to their welcome message.

Consider this as food for the thought. :) Trizek_(WMF) (talk) 14:01, 3 December 2025 (UTC)Reply

Thanks for opening the Phab ticket; I subscribed. I am very interested in editor retention (en-wiki has w:WP:WikiProject Editor Retention) so I'd like to hear more about discoverability and links to your 2010 research, or whatever has been done after that.

Regarding the rest of your message, it is pretty far from the section topic of Homepage module addressability, so I have taken the liberty of starting a new section below to discuss your other points. Thanks, Mathglot (talk) 01:23, 4 December 2025 (UTC)Reply

Don't expect anything huge regarding 2010: we were a small group of enthusiastic users with absolutely no resources. At some point, we tested the idea of having that call to action "please contact me" and we simply observed things without interfering. It appears that we switch from zero contact from newcomers to "a few per week". That's all. It was presented at Wikimania 2012.

Later, the Growth team created the mentorship module for the homepage, based on Adopt-a-user programs. It also changed the number of newcomers reaching an experienced user. Again the numbers changed to almost zero with AAU-like programs to 1 to 6 contact per user per week (based on previous observations done at fr.wp and es.wp when the deployments were done).

Trizek_(WMF) (talk) 08:49, 4 December 2025 (UTC)Reply

The second half of your message @14:01, 3 Dec. above is on a different topic than the section heading, so I have taken the liberty of starting a new section with a copy of it, for further discussion:

You raise a bunch of issues here that I would like to respond to. It's a funny coincidence that you mention the case of users with no edits now, because just yesterday I was looking at the en-wiki nutshell and first sentence at the w:WP:Welcoming Committee home page, which includes these statements:

It is widely accepted (but not required!) that users with no edits should not be welcomed...
— Nutshell of w:WP:WC (1)

Welcoming committee members welcome new users who have already made good-faith edits and help them get started in various ways.
— first sentence of w:WP:WC (2)

I was at the edge of boldly changing both of these statements, as they are no longer common practice at en-wiki, imho. However, being the very first sentence, and the summarizing Nutshell box above it, both stable for long duration, I decided that was too bold a change, and would require community input first. I intend to take that up at the Talk page, but was too busy yesterday to start the discussion (mostly because I have been busy here, ).

The Welcoming Committee at en-wiki has dozens of welcome messages, so we take a different approach than fr-wiki, apparently. There was some effort to produce a single, unified welcome message, and there is some support for w:Template:Welcome, but there is still a lot of support for some of the other ones, and as you saw, I just created w:Template:Welcome mentee to address the needs of newcomers with mentors, which was not being handled in any of the others. But I do agree with their approach of welcoming everybody, though this has not been standard at en-wiki, at least in the past, hence my reluctance to make a bold change unilaterally.

I was particularly interested in your comment:

Also, some newcomers don't look at their Homepage, while others don't look at their talk page. (3)

What are the percentages for en-wiki? Is there some published data on this somewhere? I would like to read it.

As a consequence, my community decided to post the welcome message to every new account, signed by their mentor (using the magic word #mentor). (4)

You imply, but do not say, that the mentor is not placing or signing these messages (otherwise they would use four tildes, not #mentor). Can you confirm that welcome messages are being placed by bot at fr-wiki, and that they are signing on behalf of their mentor? I believe that may be contrary to WMF principles that are linked just above the publish button; see WMF Terms of Use, 1. Our services, point b): "You are legally responsible for your edits and contributions on the Projects." This implies to me that the bot operator is responsible for the edit, and attempting to assign responsibility to the mentor, thus violating this ToU #1 using a counterfeit signature. I don't believe this is permissible. Aren't you a member of Legal? Maybe you could discuss this point with the team. Anyway, I am pretty sure en-wiki users would rebel at any proposal to have a bot write content over their signature; I know I would. (Update: I emailed legal@wikimedia.org about this.)

We stopped thinking about "let's just welcome users who already made an edit", as we discovered that sometimes a newcomer's first edit is a question to their mentor. (5)

Agree fully with this. I often welcome users with no or just a few edits. What is less clear to me, is what to do with bad-faith editors. Suppose you encounter a user with four edits, which all seem to be vandalism or blatant promotion (e.g., adding their C.V. link or company link to articles), or have language problems, do you still welcome them? So far, I have welcomed 22 mentees, and reverted myself once, removing the welcome from an editor whose only edit was possibly vandalism, and in any case not in English, and replacing it with a bilingual notice in English and Kinyarwanda. What would you have done?

Recently, addressed the case of newcomers who use the "reply" button to respond to their mentor's welcome message, using a LLM. The bot detects if the message is a real question... (6)

Do you have a link that elaborates on this?

Note: I've numbered the talk quotations, in case that makes it easier for you to contextualize your comments. Mathglot (talk) 01:13, 4 December 2025 (UTC)     updated by Mathglot (talk) 02:20, 4 December 2025 (UTC)Reply

First, it is important to sate that each wiki is unique. I was just sharing something that seem to work, from my wiki.

On quote 3, I need time to find these numbers back. Observations at editing workshops confirmed it as well. There is no standard funnel to onboard the wikis. You have many ways to escape the standard path. Having several welcome signs at the various places newcomers are more likely to go (homepage, talk page) seems to be a good idea to me.

On 4, I confirm that users have delegated the distribution to an extension. At many other wikis, it is done by a bot. I'm not a lawyer, but as the distribution is based on a list of users who agreed to delegate that posting to the system, I think it is perfectly fine.

On 5 and bad faith editors: you can't predict if someone you greet will behave strangely, no matter if in the street or on wikis. WP:AGF stands strong there, and this is why French Wikipedia decided to welcome everyone. As a volunteer, no regrets. Usually, warning messages are posted after the welcome message. It proves that we were nice at the beginning.

On 6, you can read more here, in French .

I'm out for a few days, I won't be on wikis until Tuesday.

Trizek_(WMF) (talk) 12:14, 4 December 2025 (UTC)Reply

When a user opts out of mentorship, is this logged somwhere where I can view the action? I have an example on en-wiki of a user whose account is a few hours old, and according to the {{#mentor:...}} method of id'ing a user's mentor, they have no mentor (this en-wiki user). This seemed very surprising, and I wondered if there is a possible glitch somewhere in the system which may have failed to assign this user a mentor for some reason, and where I can look up assignments, claims, and reassignments. Also, two corollaries:

• a. if I spot a user with no mentor, will the claim process work? Or does it only work when they are already listed as being assigned?
• b. If a user has opted out, and I try to claim them, what happens?

Thanks, Mathglot (talk) 20:47, 1 January 2026 (UTC)Reply

Hello @Mathglot,

Thank you for your questions. Opting out from mentorship is not a publicly logged action. This has been an intentional decision on our end – we do not want to increase visibility of those who are opting out more than we have to (especially if they opted out because they felt uncomfortable with a mentor, or for similar reasons). There's been a feature request to add some kind of community-visible logging at phab:T353931; feel free to comment on there if you think a change would be useful.

That being said, we do measure the opt out rate for mentees (meaning we are able to say how frequently are mentees opting out). Such numbers are currently not being reported publicly, although that would be possible to change if there's interest and need for this.

Regarding the enwiki user that prompted this: They do not have a mentor on en.wikipedia, because their account was not created directly on enwiki (but on fawiki) and consequently, they do not have Growth features enabled on enwiki. Growth features are enabled by default for every new account created, but only on the Wikipedia it is created on. If the user would enable Growth features in Special:Preferences on enwiki, they would receive an enwiki mentor. The user already has a fawiki mentor (as well as Growth features enabled on fawiki).

We recognise not having Growth features for autocreated accounts is not ideal, as situations like this one show. Historically, we did not want to enable Growth features for current users, because they already know how to edit (and directing them to the Homepage would be likely interpreted as a disruptive change, rather than a helpful one). Since even highly experienced users are getting new autocreated accounts, we decided not to enable Growth features for autocreated accounts.

Currently, we are thinking about potentially changing that, and somehow making Growth features available. First, we need to research possible technical solutions and their impact. This is being tracked in Phabricator as phab:T292090. Once we know what the options are, we will decide what makes the most sense, and implement the changes. Of course, the community would be kept in the loop as this progresses further.

Regarding the two corollary questions:

• Re (a): Claiming the user would work and the user would receive a mentor. The question is whether they would see it somewhere – that depends on whether Special:Homepage is enabled for them. If they do not have Growth features enabled, the mentor would be recorded in the database, but never displayed.
• Re (b): In that scenario, an attempt to claim that user would fail, and "$1 opted out of mentorship" would be displayed as the error message.

I hope I clarified all questions you had about mentorship. If there is anything else unclear to you, do not hesitate to ask, and we'd be happy to clarify further.

Best regards, Martin Urbanec (WMF) (talk) 20:38, 6 January 2026 (UTC)Reply

Martin Urbanec (WMF), this is really good, detailed info, much of it rather non-intuitive so the explanations help lot; thanks very much. Much of it will be transformed into Q&A format and added to en:Wikipedia:Mentorship, which I originally expanded with content copied from Growth/FAQ#Configuration and operation of the mentoring system, but which within its area of scope may now be more detailed than the original, or soon will be. I may also comment at the tickets; thanks for including those.

As you appear to be considering changes in various areas, I should also ask you about timeline, and whether you or someone else is the best person to talk to about the mentor dashboard UX. I have a list of over a dozen improvements to it I would like to see intended eventually as a Phab enhancement ticket which is not quite complete yet, but I also don't want to miss some critical time slot and have to wait a year for results.

Finally, I am active in the en-wiki Welcoming committee and I think there is a natural synergy between Growth/Mentorship and WC (and also with the en-wiki Editor retention WikiProject) and I wonder if there is someone/some group at Growth assigned to outreach, as it were, to liaise with such projects such as those two at en-wiki and whatever else exists in other Wikipedias, and who it is. Mathglot (talk) 21:06, 6 January 2026 (UTC)Reply

I am very glad the details were useful! I agree that some aspects of the system are not intuitive, particularly the fact that Growth features are not currently available for autocreated accounts. Your point about documentation is well taken. We aim to keep documentation concise and focused on how to use the features, but that can sometimes mean important context becomes outdated or underexplained. It is helpful to know where additional explanation is proving valuable.

Regarding timelines, Mentorship is not a primary focus area for the Growth team at the moment. As a result, our work in this space is limited to bug fixes and smaller improvements that we can fit in alongside other priorities, and we are not currently planning any major UX changes currently. The upside of this is that there is no fixed window for feedback. We very much welcome suggestions at any time. Small improvements will be considered and prioritized against other initiatives, and larger ideas will be considered as we plan out next fiscal year.

For coordination with the English Wikipedia Welcoming Committee and related efforts, @Sdkb-WMF is the best primary contact on the Growth side for mentorship and newcomer-focused discussions on English Wikipedia. I am also happy to be looped in on talk page discussions or Phabricator tasks and will respond when I am able.

Thanks again for the engagement and for the work you are doing to strengthen mentorship and welcoming newcomers on the wiki! - KStoller-WMF (talk) 00:32, 8 January 2026 (UTC)Reply

And a follow-up on the fa-wiki user example: so with Growth features not enabled for them here, I assume if I try to claim them as mentee at en-wiki, that will not work, right? (I don't want to try it, because I don't want to nab them away from fa-wiki, in case it does work!) Does the mentor dashhoard display an error message of some sort if a claim fails? If you can assure me that I won't be stealing them away from fa-wiki, I will just attempt to execute the claim to see what it does, so I can record the result; the point is to update our en-wiki FAQ with a new Q&A about this situation, which is very particular.

I guess a corollary question is this: a user can only have a mentor on one Wikipedia? Or is it more, only one automatically, but others opt-in-able on Wikipedias where Growth features are enabled, *and* they have enabled growth features in their Preferences, for all Wikipedias where they want a mentor, except the one where they initially registered, where it is automatic? Do I have that right, now? It's a bit confusing. Mathglot (talk) 21:16, 6 January 2026 (UTC)Reply

Mentorship is currently handled independently on each wiki. This is intentional, since expectations, norms, and editing practices can differ significantly between projects. A mentor who is a great fit on fa-wiki may not be the right fit on en-wiki, so keeping mentorship local to each wiki generally makes sense.

Because of this separation, claiming a mentee on en-wiki will not affect any mentorship relationship they may have on fa-wiki. You do not need to worry about pulling them away from another wiki’s mentoring system.

If a user does not have Growth features enabled on a given wiki, the behavior is a bit subtle. A mentor claim can still be recorded in the database, but the user will not see the Newcomer Homepage or the mentor information there. In that situation, I don't believe there is an error message.

In practical terms, a user can have one mentor per Wikipedia where they have enabled the Newcomer Homepage. By default, this is only the wiki where the account was created. On other Wikipedias, mentorship becomes active only if the user explicitly enables the homepage in their preferences by selecting “Display newcomer homepage.” Once that is enabled, and assuming Mentorship is configured on that wiki, a mentor will be assigned automatically.

So your understanding is essentially correct: mentorship is automatic only on the home wiki, and opt-in on other Wikipedias where Growth features are enabled and the user has chosen to enable the homepage.

I hope this helps clarify the situation, and thank you again for taking the time to document these edge cases for the en-wiki FAQ. - KStoller-WMF (talk) 00:49, 8 January 2026 (UTC)Reply

Martin, based on earlier responses, I upgraded en:WP:Mentorship, adding sections for the following questions:

• § Do I have to apply for a mentor?
• § Can I get another mentor for my work on other Wikipedias?
• § How can I check if my Homepage is enabled?
• § Can I claim a user as my mentee?
• § If I change my username, do I get to keep my mentor?

Can you please have a look and make sure the answers are accurate, and either update them if they are not, or let me know what the problems are? Also, some of your responses above provoke further questions. You said,

Growth features are enabled by default for every new account created, but only on the Wikipedia it is created on.

• In that light, consider this: Iñaki creates his account on Basque Wikipedia, where he gets no mentor iiuc, because GTF is undeployed there. A little while later, he comes to en-wiki and signs on. What happens? Iñaki has no automatic mentor anywhere; does he get one at en-wiki because it is the first opportunity for it to happen automatically at a deployed wiki without requiring opt-in? Or, is he forced to enable his Homepage manually in Preferences, even though it is his first wiki that supports it? (If the latter, this is a kind of second class menteeship; maybe something to look at next round?)
• Suppose François creates his account at fr-wiki, gets a French mentor, comes to en-wiki, and wants a mentor there. So, he enables his en-wiki Homepage, and now a mentor at en-wiki is assigned to him automatically, right? And he also keeps his French mentor, so then he has two mentors, one each at fr and en-wikis, correct? Repeat at es-wiki, and now he has three, correct?
• I presume a mentor can volunteer at other language Wikipedias simply by just there, but the current load throttling scheme is a deterrent, because the individual loads add up. Something else to think about, next round.
• If a user disables their homepage, is that functionally equivalent to opting out of mentorship, or just hiding it without severing the connection? In particular, does {{#mentor:Username}} still show the mentor's name, and does the mentor dashboard still list the mentee user?

Thanks, Mathglot (talk) 04:28, 18 January 2026 (UTC)Reply

Hello,

I would like to help. Could you please advise

1. What communucation platform does the team mainly use such as google meet or mumble or matrix or other.

2. Do you have an IRC channel.

3. Do you have a mailing list.

4. Could you please add {{Feedback }} at bottom of wiki pages belonging to the team.

5. Anyone from Oceania or Australasia on the team?

Hope this is OK. Thanks. Gryllida 15:51, 19 January 2026 (UTC)Reply

I am bit curious why you want to know this kind of information. Thanks. SCP-2000 (talk) 16:57, 19 January 2026 (UTC)Reply

To connect and possibly help to fix some bugs. This kind of information is commonly available for other teams. Gryllida 17:11, 19 January 2026 (UTC)Reply

@Gryllida Sorry for the slow reply!

1. We generally use Google meet for team meetings.
2. This page works for publish communications. I also closely follow: Wikipedia_talk:Growth_Team_features. We also aim to be as responsive as possible on Phabricator, so feel free to tag me (KStoller-WMF/) or other Growth team engineers there. If you want to work with us more closely, I can see if we can set up an IRC or Discord channel.
3. Growth doesn't have a mailing list. We do share Growth/Growth team updates & Growth/Newsletters
4. When @Trizek (WMF) returns, I'll see if he can support this. (Trizek helps maintain Growth team documentation and help pages)
5. Unfortunately, no. Growth team members are based in Europe, North America, and Africa.

KStoller-WMF (talk) 00:49, 6 February 2026 (UTC)Reply

I notice this situation in w:zh:Special:Diff/91194695. This edit added [[美国|美國]]. However this violated a local guideline which permits only [[美国]] (a direct link) or [[美國]] (a redirect). Please fix it. Thanks. 迴廊彼端 (talk) 08:54, 26 January 2026 (UTC)Reply

@迴廊彼端 Thanks for reporting this issue, and sorry for the trouble. The machine learning model learns from links that already exist in articles. Because of this, it can sometimes suggest links that are not helpful or correct.

We just completed an update to remove all country and continent name suggestions from zhwiki (T414297), so I believe this particular issue with 美國 shouldn't be a problem again. KStoller-WMF (talk) 06:22, 30 January 2026 (UTC)Reply

User:KStoller-WMF Thanks for your dealing and replying. However this update only fix a part of problem. My main concern is "Suggested: add links" adds redirecting wiki-links which use different variant of simplified/traditional Chinese. It violates a local guideline and there are a lot of redirects use different variant of simplified/traditional Chinese. Not only country and continent names. Please help. Thanks. --迴廊彼端 (talk) 16:28, 8 February 2026 (UTC)Reply

The root cause seems to be related to the VisualEditor link feature phab:T382816. SCP-2000 (talk) 18:04, 8 February 2026 (UTC)Reply

User claims (among other things) to have tried to contact their mentor, but is unable to do so:

I do have newcomer homepage enabled and do see my homepage. Just no mentor module.

I am requesting feedback from a team member here directly at en:WT:Mentorship#I'm working on my 1st new article; how do I Contact my Wikipedia mentor? to interact with the user. I'm guessing there is just a misunderstanding somewhere, but if there is a legitimate bug, can you please summarize here and/or provide a Phab ticket? Thanks, Mathglot (talk) 18:59, 31 January 2026 (UTC)Reply

User has provided additional info on this, and I am at a loss to explain why they cannot see a mentorship module on their homepage. This needs feedback from someone in engineering, I would think. KStoller-WMF, can you move the needle on this, please? More user details and reply location here. Mathglot (talk) 06:55, 5 February 2026 (UTC)Reply

Hi @Mathglot thanks for the ping!

On February 17th, 2025, Mentorship was rolled out to 100% of newcomers on English Wikipedia: T384505.

Prior to that date, only some new accounts received mentors, because we simply didn't have enough mentors to cover all of the new accounts made on English Wikipedia. It's been a long and gradual rollout: T323048.

However a 100% release of Mentorship just means that all NEW accounts receive mentorship. We didn't retroactively assign mentors to all existing accounts. It looks like the editor in question created their account in 2024 and didn't receive a mentor at that point (since only 50% of new accounts were paired with mentors on enwiki at that point).

I believe if you, or any other Mentor "claims" them as a Mentee, they will start to see Mentorship in their Homepage. But it's possible I might be mistaken. As usual @Martin Urbanec (WMF) knows all there is to know about Mentorship and can correct me if I'm incorrect. Thanks for supporting this newer editor and helping identify potential bugs! Best, - KStoller-WMF (talk) 00:35, 6 February 2026 (UTC)Reply

That makes sense. On the positive side, they now see the Mentor module, although not by anyone claiming him, but by a pretty unorthodox method involving looking at the mediawiki API, and designing his own homebrew js to tweak the value of growthexperiments-homepage-mentorship-enabled directly. I wonder if something like that could be adapted as a new tool linked from the module so that legacy users could enable mentorship if they wished to? I not infrequently run into users who registered years ago, and have ten to a hundred edits; that is, they are not new, but they are newbies who might wish to have a mentor. A tool link like that would be handy for them to have. Basically, it would be the inverse of the opt-out link. Martin, does that seem like something that ought to work, and would be worth adding? Mathglot (talk) 08:04, 12 February 2026 (UTC)Reply

Great to see what you're building here. Thought I'd share a wish in the m:Community Wishlist that's highly related. It would make getting started and finding interesting things to easier, especially for those users past their first 10 edits (e.g. they finished doing what they initially registered for such as writing that article they meant to or correcting that misinfo they found in an article) but before they become durably highly active editors (>1 k edits):

W316: Suggested tasks based on contributions history (user interests) also for experienced editors

Regarding "Finding help", "Iterative learning" and "In-context help", also see Wish 442 which would enable users to easily find the answers to any wiki questions they have and make finding meta / help pages (or sections/paragraphs within them) very easy. One could also think about things like badges for learning new skills/contributiontypes such as how to create a table or how to add Chart. I think "In-context help" and related things are a better approach as most wiki-related questions newcomers have already been answered at some point somewhere (in some VillagePump discussion or more often on some policy/help page) so it's more about surfacing the info quickly and easily to the user and such would also consume less scarce volunteer time than "Human-to-human help"-centered approaches. Many help sites are cluttered, time-intensive and repetitive – asking there would be best when that question hasn't been answered before. Further ideas include making discovery mode Wikipedia browsing possible and widespread instead of people just coming here to learn about one specific topic or fact where one could e.g. integrate talk page questions from time to time so people see what editors think about or discuss (for one example). Prototyperspective (talk) 19:42, 5 February 2026 (UTC)Reply

Is there a design goal about the mentee status of a blocked user? It appears from observation that a blocked user immediately loses their mentor, or at least, the {{#mentor:...}} magic word stops returning a result and returns empty instead. (See example at en-wiki here.) Perhaps the growthexperiments-homepage-mentorship-enabled is still set but a block masks it somehow? Or is it immediately unset? Does a blocked user also lose the Mentorship Module on their Homepage?

I would strongly suggest that a blocked user not lose their mentee status, or their Mentorship Module. For one thing, during a block is when they may need their mentor more than ever. I have helped a number of blocked users with their questions prior to the existence of Mentorship, and was probably instrumental in bringing back at least two users out of indeffed status (sometimes many months or a year or two later). A blocked user should be able to communicate with their mentor, one way or another. I would like to start a discussion on how blocked mentees might best do this. Some solutions might require software changes, but others not.

Any mentee who retains Talk page access, even if indef-blocked, can still communicate with their mentor if they know enough to ping them from their own Talk page. However, newer users (even some experienced ones) may not know this and therefore be cut off from assistance at the time they most need it.

I can envision a few ways to solve this:

1. retain the Mentorship module, but alter its functionality – module checks for user block and TPA status, and then, if the user is:
   • blocked, and retains TPA:
     1. approach one: adds the user question as before, but *on their own Talk page*, along with a mentor ping added to the message (possibly an issue if mentor has Notifications turned off; how many current mentors in the table are in this category?)
     2. approach two: define a new privilege, perhaps growthexperiments-homepage-mentorship-blocked-talk-enabled which, if set to 1, expands the blocked users range of permitted pages from 'their own talk page only', to 'their own talk page, and their mentor talk page but only when accessed via the Homepage mentorship module contact-your-mentor link'. This seems like the best/easiest alternative for the blocked user, and possibly also for their mentor, but would obviously require software changes both in mentorship, as well as whatever filter currently blocks them from all pages except their Talk page.
     3. approach three: does not offer the user the capability to add their question anywhere, but instead pops up an explanatory message (or link to an explanation) instead, explaining how they can still add a message on their own talk page, along with a ping to their mentor
   • blocked, and lost TPA: I don't know what kind of response a user without TPA gets currently when they click the edit button on a page or section currently, but I presume something like an edit filter pops up a message saying they cannot edit and should contact UTRS. Whatever the case, an additional clause should be added saying something like they have to detail with the lost TPA issue first via UTRS before they can contact anyone, including their mentor.
   • not blocked: (default case): continue as now.

I don't wish to instantly abandon a mentee just because they have been blocked—even indeffed in some cases—when they most need advice; it seems almost cruel to do so. There must be some solution to being able to continue offering them assistance (which would, of course, be limited to questions about appealing their block). I would be interested in your responses to the questions above and also thoughts on these suggested approaches for blocked users. Thanks, Mathglot (talk) 01:16, 14 February 2026 (UTC)Reply

As a corollary to 1.1 above, I have long thought that the proper venue for a mentee question is *on their own Talk page*, along with a ping to their mentor. This would have advantages for both mentees and mentors:

• mentees –
  • would be able to find their questions and mentor response more easily, right there on their own talk page;
  • would no longer lose access to their own Q&A when their mentor archived it somewhere where the mentee would effectively never see it again
  • could control archiving of their own Q&A as they wished
  • mentees are automatically notified of mentor response on their Talk page (unless they opt out)
  • third-party users coming to their Talk page are not going to know about any mentee questions located at their mentor's page
  • new users often begin to accumulate warning messages from other editors for various policy or guideline transgressions; this is more the rule than the exception. Having their mentor questions stored on their Talk page would give third-party visitors a more balanced view of their activity, including possible questions to their mentor about the warning messages on their page, than is the case now, with all their warning messages on their page, and all their earnest questions about them on somebody else's page, where no one will see them
• mentors –
  • mentors end up with lots of mentees, and it can flood their talk page (and later, their archives), making other discussions harder to find
  • their average talk page length for the same archiving config delay period becomes much longer
  • archive pages fill up more quickly
  • mentors must remember to ping with every response, or the mentee might miss it

This lends additional support for approach 1.1, even for users who are not blocked. Mathglot (talk) 02:17, 14 February 2026 (UTC)Reply

I don't know what kind of response a user without TPA gets currently when they click the edit button on a page or section currently – if you want to get a sense of what it looks like being blocked (with TPA off), you can go to https://patchdemo.wmcloud.org, select a random wiki, and log in as Mallory with the password patchdemo1. Of course, that won’t have enwiki customization like UTRS references, but it’ll give you a generic picture. —Tacsipacsi (talk) 21:38, 14 February 2026 (UTC)Reply

Either I am missing existing functionally, or you need to add a way for a mentor to unclaim a mentee—i.e., return them to the pool where they will presumably be reassigned to another mentor. You already have a way for a mentee to be assigned a mentor (automatic upon registration), for a mentee to delink themselves from their current mentor (via opt-out) and be assigned another (opt-in), and for a mentor to have a user assigned to them, via claim mentee. The missing one (I think, unless I missed it) is you need to add a procedure for a mentor to unclaim a mentee and return them to the pool of unassigned mentees. Mathglot (talk) 13:02, 16 February 2026 (UTC)Reply