Talk:Growth

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

• Discussions using Structured Discussions are at Talk:Growth/2023.
• Discussion related to the old Growth team is archived at Talk:Growth/Growth 2014.

Feedback on https://en.wikipedia.org/wiki/Special:EditGrowthConfig

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)

@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)

Welcome emails to new users?

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)

@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)

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)

@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)

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)

Feedback on mentor growth feature

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)

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)

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)

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)

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)

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

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)

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)

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

Untranslated fragment

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)

@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)

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

@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)

Proposed edits feature

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)

@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)

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)

@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)

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)

@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)

Suggestions for the Special:Homepage

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)

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)

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)

Prevent mentees from asking duplicate questions within a few hours

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)

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)

is there a section explaining how the suggestion counter works ?

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)

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)

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)

Check potential mentors before they're allowed to offer mentorshipservices

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 @Trizek

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)

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)

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)

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)

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

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

translation: nice to have included link on corresponding translatewiki group

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)

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)

bug: Add a link bot

Tracked in Phabricator
Task T373336

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)

Hello HaukweKwor

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

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

Newcomers using link task to add external links

Tracked in Phabricator
Task T376518

@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)

@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)

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)

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)

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)

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)

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)

@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)

@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)

Promoting inline tagging

I see that task 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)

@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)