Talk:Growth/Personalized first day/Newcomer tasks

Specific goals

@MMiller (WMF): The page indicates that the software won't "get in the way of them accomplishing their goal". I wanted to raise a concern about this; I hope that's appropriate at this stage of development.

It's sometimes the case that newcomers are unaware that they shouldn't do what they want to do, and have to learn the hard way; I believe there has been research indicating that e.g. reverts have a significant impact on whether new editors are retained in the short term (example; DOI/full text). There is probably some noise from advertisers in the linked paper's dataset, but I think it should still be somewhat significant (I think there has been some related research on the topic but I can't find it).

Perhaps rather than not taking measures to prevent this sort of thing from happening, it would be better to somehow tell newcomers that there are certain things that they definitely shouldn't do (e.g. upload copyrighted media to Commons, add song lyrics, write articles about self) and perhaps what they should do instead. It might be possible that this results in unintended consequences (e.g. newcomers leave without doing anything, even though they would otherwise have decided to stay if they had had a negative experience), but I think it might be worthwhile to test whether displaying such advice and/or linking to policies/guidelines has an impact on editor retention. In any case, this would likely have a positive impact on the workload of experienced users.

Furthermore, if reverts in particular are likely to discourage users from continuing editing, perhaps the home page could reflect this by giving users advice after they get reverted (or some other pop-up could try to reassure the user after a revert, rather than putting this in the home page, but I guess that might be a little off-topic). Jc86035 (talk) 07:09, 30 July 2019 (UTC)

Thank you for your comment, @Jc86035. I'm pinging @Trizek (WMF), who is Community Relations Specialist and I think he'll be interested in your comment as well. Martin Urbanec (WMF) (talk) 16:45, 30 July 2019 (UTC)

@Jc86035 -- thank you so much for reading over the project page and gathering your thoughts. It's definitely appropriate at this stage (and every stage) to raise concerns, so please keep it coming (and I hope others do, too.)

I think we're thinking along similar lines with respect to not wanting to "get in the way of them accomplishing their goal". The idea is that we know for a fact that many newcomers arrive with these difficult tasks in mind, such as creating a new article or adding a photo. Yes, some of those initiatives are self-promotional or otherwise inappropriate, but many of them aren't, and the smaller wikis definitely need that new content. So the question is, how can we help a newcomer who single-mindedly wants to write an article about something like their hometown to eventually be successful in it? Our current hypothesis is that we might find out from the newcomer via the welcome survey that they are trying to write a new article, and their homepage might convey something to them like, "If you're trying to write a new article, you should know that's one of the hardest things to do on Wikipedia. We recommend trying some easier, but relevant, tasks so you can learn to edit and have a better chance at success." And then we would want to recommend tasks that actually help them build the skills they need, such as adding a section to an existing article, or adding a citation.

What we would not want to do is recommend tasks that are irrelevant to their goal, such as translate an image caption. That would be "getting in their way". Does this make sense? What do you think? It would also be interesting to hear from you what kind of tasks might be most relevant and nurturing for newcomers to do. MMiller (WMF) (talk) 23:31, 30 July 2019 (UTC)

I think that's probably a sensible way to go about it (and it definitely makes sense not to pressure users into doing things that they wouldn't want to do). I'm not sure what sort of tasks would be appropriate, and users with more experience assisting new editors and patrolling recent changes might be better at answering that.

I think I would probably phrase a warning message more like "there are a lot of things you need to take into consideration" rather than "this is really difficult"; partly to avoid being overly discouraging, and partly since it might not be very difficult to create a given article, at least with the minimum detail needed to avoid the article's deletion. (For example, someone's hometown would probably be inherently notable on the English Wikipedia due to being a legally-recognized populated place, so it would be relatively easy to find one or two sources and create that article.) Jc86035 (talk) 08:33, 31 July 2019 (UTC)

Add images from Commons

I am not sure, if this is good task. There are articles that have images in some language Wikipedias but not in others. Typical example: article about some music album, newbie looks to en.wikipedia and "voila, there is cover image, lets add it to my wiki's article".

But this image is not on Commons. So part of newbies give it up. But second part will try to upload image to Commons or to home wiki, where will be problem because of en.wiki's fair use.

If there is item with commons category and this task will be active only for these articles, it's better, but also here are many categories without images (e.g. author with book scan in his category). JAn Dudík (talk) 19:03, 2 October 2019 (UTC)

+1 Also deducing this from "Depicts" statements on Wikidata is super useful. Sadads (talk) 21:14, 2 October 2019 (UTC)

Thanks for reading the newsletter and posting your opinions, @JAn Dudík and @Sadads! That's a good point about fair use being different in different wikis. It sounds like you're saying that if such an activity were restricted only to images that are in Commons, then this is more likely to work well. That said, I also imagine there are cultural considerations. For instance, an article about "bread" in Czech Wikipedia might show a kind of Czech bread, but the article about "bread" in Indonesian Wikipedia might need an imagine of a kind of Indonesian bread.

The reason we thought of this task idea is because a lot of newcomers want to add images to Wikipedia articles and think that it will be an easy thing to do. We know that it is actually quite a complicated thing to do: you have to understand licensing, use the right templates, navigate to a completely different website (Commons), etc. So we are trying to think of an easy task that would help a newcomer learn how to add an image so that they will be more likely to succeed when trying to add their own image. Do you have any recommendations of how we could accomplish this? MMiller (WMF) (talk) 00:08, 3 October 2019 (UTC)

Is possible to have list of articles, which

• are connected to wikidata item
• have commons sitelink or P373
• have no image
• commons category or its subcategories contains image files (.jpg, .gif,...)

When newbie wants to help with images, he should got gallery from this category.

I tried inserting image with VE for the first time - and I got gallery of possible images based on pagename, which often depicts completely different thing. So there is possibility that editor can add bad image (e.g. two villages with same name, one with images second without) JAn Dudík (talk) 05:54, 3 October 2019 (UTC)

Thanks, @JAn Dudík. These are good ideas that we can hang on to for when we want to try this method! MMiller (WMF) (talk) 16:35, 3 October 2019 (UTC)

Use of maintenance templates

I think it's a good idea to use maintenance templates in the general case.

I am concerned that there may be some maintenance templates that are unsuited. For example, the templates in en:Category:Wikipedia copyright maintenance templates usually require some delicacy/care to ensure that that fix has been implemented correctly, and usually require administrator effort to remove the copyright violation copy from the page history. Izno (talk) 00:58, 3 October 2019 (UTC)

Hello, the Growth team has asked ambassadors for each target wiki to provide a list of maintenance templates, and we're not using _all_ maintenance templates, just some of them, which we deem to provide reliable results. Martin Urbanec (WMF) (talk) 07:40, 3 October 2019 (UTC)

@Izno -- thanks for reading the newsletter and weighing in! Yes, like @Martin Urbanec (WMF) said, we are being careful to use maintenance templates that actually make sense for newcomers to work on. We did that work in this Phabricator task and its subtask, if you're interested in seeing the details. Which maintenance templates do you think are the best ones for newcomers to work on? MMiller (WMF) (talk) 16:34, 3 October 2019 (UTC)

I think the lists I see in that task are pretty reasonable. I would be concerned about image-related ones since we immediately get into complex questions of non-free media and possibly biting new users who naively upload a non-free image which is immediately deleted. Izno (talk) 16:47, 3 October 2019 (UTC)

Got it -- thanks. That makes sense about images. We were also talking about images in this other thread: Topic:V8fug8k6weg1p4ua MMiller (WMF) (talk) 16:56, 3 October 2019 (UTC)

There seems to be a belief - among new and inexperienced editors, at least - that adding a maintenance template is going to lead to (relatively) quick action by other editors. This is false. For example, the category https://en.wikipedia.org/wiki/Category:Articles_lacking_sources (generated by maintenance templates) has 186,000 articles in it. There are several hundred thousand articles in the https://en.wikipedia.org/wiki/Category:Articles_needing_additional_references category, and many articles that have that template were marked as such in 2006.

In other words, the value of adding a maintenance template that asks other editors to improve an article is somewhere between very small and zero. If the Growth Team succeeds in teaching lots of editors how to place these templates, they will have contributed very little to the project. And, in fact, editors who spend a lot of time placing these templates could, in a more perfect world, be actually improving Wikipedia articles, instead. John Broughton (talk) 16:23, 18 May 2020 (UTC)

Thanks for checking out the project pages and for your thorough comments, @John Broughton! I've learned a lot already from your input. I wanted to answer this one first before getting into the ones specifically about "structured tasks".

First, I just want to make sure it was clear that with newcomer tasks (which has been live on several wikis since November), we are not asking newcomers to place maintenance templates on articles -- rather, we are drawing on the existing maintenance templates to surface articles needing attention to newcomers. So hopefully this feature is a force for drawing down the backlog of maintenance templates, as opposed to increasing it. Indeed, I think a great potential outcome would be if enough newcomers were working through maintenance templates that it did make sense for more to be added by other users, starting a virtuous cycle.

One of the biggest problems with using maintenance templates for this project, though, is how open-ended they are -- we've seen newcomers who want to know which words should be links, or which sentences should be copyedited. That's why we're now talking about structured tasks on the other project page.

Another big problem with maintenance templates is removing them after the work is completed. The issue is that if a newcomer makes edits on an article after being prompted by a maintenance template, they probably don't yet have the wiki skills to understand templates and how to remove them. They also may not have the judgment necessary to tell if the template's need is entirely, or only partially, resolved. We don't yet have a solution for this -- perhaps we could encourage patrollers to look out for edits via this feature, and take a look at whether the template should be removed? Can you think of anything that would help here? Thank you! MMiller (WMF) (talk) 00:23, 19 May 2020 (UTC)

@MMiller (WMF), I'm looking at this from the point of view of Tamil Wikipedia. I have a similar concern as @Izno. Many tasks like adding references or even illustrations from the commons require a familiarity with Wiki editing as well as policies sometimes, which is hard to expect in newcomers. Is the plan to guide them through the entire process? If not, it's better to stick with simpler tasks, I think. -- ~ Sundar (talk) 13:08, 6 August 2020 (UTC)

@Sundar, we have set difficulty levels for each task we cover (adding images is not included).

|Task

|Difficulty level

|-

|Copyedit article

|Easy

|-

|Add Links

|Easy

|-

|Update article

|Medium

|-

|Add References

|Medium

|-

|Expand article

|Hard

|}

This way, users aren't encouraged to take more advanced tasks. Sure they can start with an hard task if they are fearless, but that's at their own risks.

Each task we cover has guidance. When one selects an article with a given task, they receive specific guidance on how to achieve this task. This covers editing basics; going deeper into policies is something we expect users to discover as time goes by, or by interacting with other users (especially their mentor).

Hope this helps! :) Trizek_(WMF) (talk) 13:37, 6 August 2020 (UTC)

Thank you for clarifying, @Trizek (WMF). Sundar (talk) 13:59, 6 August 2020 (UTC)

(1) The word "copyedit" may not mean what you think it does. Per https://en.wikipedia.org/wiki/Copy_editing , it "encompasses any or all of the tasks along a continuum from simple mechanical corrections (mechanical editing) through sentence-level interventions (line, or stylistic, editing) to substantial remedial work on literary style and clarity, disorganized passages, baggy prose, muddled tables and figures, and the like." In other words, at minimum one should distinguish between the extremes of grammatical corrections and rewording of sentences, and reorganizing and revising an article, both of which fall under the label of "copyediting".

(2) There are two different types of links, external (rarely used in the English Wikipedia) and wikilinks (internal). It might be helpful to treat the two as separate things.

(3) Adding a citation using Citoid isn't particularly difficult. John Broughton (talk) 21:55, 6 August 2020 (UTC)

Hi @John Broughton -- thanks for weighing in! I have some responses and follow-up questions for you:

(1) I agree that copyedit is a broad concept! A challenge we have here is that since we are sourcing these tasks based on maintenance templates, we're using the templates that communities call their "copyedit" templates, and different wiki communities may have different conventions around the types of copyediting problems for which they apply their copyedit template. We're using the word "copyedit" deliberately to be broad, because we're not sure more specifically exactly which type of copyedits the articles will need when the newcomer arrives. Do you think we should use a different word? I think you participated in a similar conversation about finding spelling error tasks with the Growth team's future "structured task" workflows. I think those workflows will allow us be more specific with what exactly newcomers should do.

(2) I think that could be a good idea -- to use the phrase "wikilink" instead of just "link". I remember in one of our user tests, a newcomer thought that by "add links", we actually meant adding references, since references are links to external websites.

(3) I agree that using Citoid itself is pretty easy. I think the reason we classified "Add references" as a medium task is that the harder part of references is finding the actual reference, and using judgment to decide whether the source is reliable. Does that make sense? MMiller (WMF) (talk) 02:19, 14 August 2020 (UTC)

(1) The problem is that it's not at all true that most copyediting is "Easy". If it were, for example, there would not be articles dating back to 2007 that still require "clarification" - https://en.wikipedia.org/wiki/Category:Wikipedia_articles_needing_clarification . [I realize this isn't necessarily a very constructive response; I'll ponder what additional comments I can make that would be helpful.]

(2) Glad to be helpful.

(3) The point is well made that finding a reliable and relevant source is the difficult part of correctly adding a citation. John Broughton (talk) 05:25, 14 August 2020 (UTC)

Deploy Newcomer tasks and other growth features to Wikimedia Commons?

I think Newcomer tasks and other growth features would be helpful on Wikimedia Commons. Commons probably has the largest backlog of all Wikimedia sites. It would encourage newcomers to clean up file pages, vectorise existing raster images, perform cleanup on Files, some necessary cropping, and other maintenance tasks. Before I propose this to Wikimedia Commons Village pump, any thoughts on the matter? Ainz Ooal Gown (talk) 02:30, 23 October 2019 (UTC)

I recommend reading Growth/Communities/How to get the Growth experiments on your wiki if you haven't already :-). Martin Urbanec (WMF) (talk) 07:32, 23 October 2019 (UTC)

I embarrassed to say that I hadn't read it then. But I have now and it looks like I should first ask this on Talk:Growth. Thanks for showing me the correct procedure! Ainz Ooal Gown (talk) 07:41, 23 October 2019 (UTC)

You're welcome. Please note that newcomer tasks aren't yet developed, and the Growth team probably wouldn't be confident to deploy them elsewhere for some time. Thanks for your interest in the features! Martin Urbanec (WMF) (talk) 07:42, 23 October 2019 (UTC)

A quick side note: the current prototypes are designed for Wikipedias, first. It may be a bit difficult to have the current prototypes working on Commons, but who knows! :) Trizek_(WMF) (talk) 11:11, 30 October 2019 (UTC)

Can prototypes be designed for Commons? If so, Commons can be the testing ground (after a community discussion of course) for these unreleased features until they are implemented. What do you think? Ainz Ooal Gown (talk) 11:16, 30 October 2019 (UTC)

They can't, for now.

The Growth team's objective is "to address this problem through software changes that help retain new contributors in mid-size Wikimedia projects, starting with Wikipedias". It is possible for other wikis to get the feature, but "as they are".

But the different features may be useful as they are:

• the welcome survey may help the community to know what are newcomers' goals
• the help panel can help any user to have access to the most important help pages when they edit an image, and post messages to an help desk
• the homepage can gather useful informations, like newcomers impact and a direct access to a mentor.

I'm not active enough on Commons to know how to articulate these features to this wiki. Trizek_(WMF) (talk) 11:28, 30 October 2019 (UTC)

Yes, I think the features you mentioned above can be customized without making extra changes. So can I ask the Commons community for their approval for adding these basic Growth features? A discussion there will sort out all pros and cons and what features can be implemented. Ainz Ooal Gown (talk) 11:38, 30 October 2019 (UTC)

You can. Please share the link! :)

Any Wikimedia projects can start this process. However, for Commons, this wiki would get the features as they are, all of them, and the Growth team will not have time to prioritize improvements specific to those wikis.

This, plus some other useful information are listed on the recommendation page. You should read it first, if not already done. Trizek_(WMF) (talk) 10:01, 31 October 2019 (UTC)

Localization

Which part of the page is recommended to translate? The note at the bottom of the Summary section says, that "The sections below may be changed significantly in the coming weeks, are too technical or less relevant for the understanding of the project. We have decided not to have them translated.", but the whole User testing section is selected for translation at the bottom of the page. Samat (talk) 18:07, 2 November 2019 (UTC)

Yes, it was included mainly to inform communities about the user testing results. However, you should feel free to translate it or leave it out - it's up to you. Martin Urbanec (WMF) (talk) 21:35, 2 November 2019 (UTC)

Big mistake

It is a big mistake to expect newcomers will edit as experienced editors, when the newcomers know nothing about creating a new WP-article.

I suggest encouriging them to correct small mistakes, typos and such in existing articles to gain experience first, and much-much later they will start a new article by themselves.

Maybe also would be good if they would point to mistakes in articles, or suggest corrections.

Many times we notice that they leave a message somewhere in Help forums with a suggestion about an article (which contains errors), but they do not know how to correct this and ask editors for help. Maybe this is also not an easy task for a newcomer.

Misibacsi (talk) 16:34, 18 November 2019 (UTC)

This is for newcomers to learn and make first steps to "edit as experienced editors".

"Maybe this is also not an easy task for a newcomer" - so there is need for resources for them. This project can help. wargo (talk) 17:34, 18 November 2019 (UTC)

We encourage newcomers to make small tasks. That's the entire principle of the newcomer tasks. Maybe we haven't explained it well.

Difficulty filters are selected by default for Easy tasks, and creating an article is locked (because too difficult for a first experience) until newcomers have tried to edit.

We also plan to use the help panel to explain what to do to achieve the suggested edit. Trizek_(WMF) (talk) 18:14, 18 November 2019 (UTC)

Thanks for explaining, @Trizek (WMF). @Misibacsi -- does this make more sense now? The project uses maintenance templates to surface articles that need copyediting, links, references, etc. Newcomers will be encouraged like "Just add one link to this article and save it!" In this way, we hope they learn to edit in small steps. Do you have additional ideas? MMiller (WMF) (talk) 22:35, 19 November 2019 (UTC)

This makes more sense. Thanks for the explanation. Misibacsi (talk) 09:22, 20 November 2019 (UTC)

UX feedback to the version 1.2 prototypes

I was made aware of what's called "version 1.2" here and started playing around with the two prototypes. I would love to give some feedback. Overall, I think the prototypes are very well designed. All guidance, what to do where, when, and how, all this is very well picked. I'm looking forward to see how this performs! However, I might have a few nitpicks. Please forgive me if I'm poking at details that are specific to the prototype and not meant to be like this in the later product.

• There is the sentence "Help make English Wikipedia better for its ~8B readers each month" at the bottom of the list of suggested edits. Not only is this corporate speech I personally do not like. It's misleading. The edits we ask these newcomers to do are not going to reach "~8B readers each month". It's not fair to suggest this.
• For some reason the cards in the "suggested edits" list do have an ✕ button in the upper right corner. I believe this is a mistake.
• I love that the cards resemble how PagePreviews already look like.
• Having an actual page view count is a superb idea. However, I wonder why you decided to use a "60 days" period? I find this surprising. In my experience it's more common to talk about 30 days periods, or a year.
• There is a little sequence of 3 "quick start tips". These panels advance automatically after (I believe) 10 seconds. I find this quite distracting. It's the largest animated element on the page, way larger than the flashing dot on the edit button. Chances are high it advances either to early or to late. I'm just trying to read the text – and get interrupted. I'm just trying to find a button to advance to the next tip – and get interrupted.
• It's not obvious the 3 little numbers are meant to be buttons. Later, there is another UI element that looks like "← 1 / 5 →". I feel this would not only fit better, it would also help reducing the number of different UI elements. There is quite a lot going on in these prototypes.
• There is one detail in the "← 1 / 5 →" UI I find distracting: When I click, the button I just clicked scrolls away along with the content, and another pair of buttons scrolls into view. Not only is this conceptually confusing. It should behave like one pair of buttons. The channel buttons on my TV's remote also don't scroll away when I switch channels. The current animation also makes it impossible to fast-forward.
• On mobile, there is a screen with the sentence "Ready? Click the edit pencil icon to start" at the very bottom. But since this is mobile, the edit UI is not visible the same time. What's visible is this icon, which also shows an "edit pencil", but can not be clicked. I guess the sentence after "Ready?" needs to be rephrase on mobile, or the icon be changed or removed.

I hope this helps. Thiemo Kreuz (WMDE) 12:12, 15 January 2020 (UTC)

Thanks for taking time to review and leave comments on the prototypes @Thiemo Kreuz (WMDE). Apologies it has taken so long to reply, but please see my responses below.

• There is the sentence "Help make English Wikipedia better for its ~8B readers each month" at the bottom of the list of suggested edits. Not only is this corporate speech I personally do not like. It's misleading. The edits we ask these newcomers to do are not going to reach "~8B readers each month". It's not fair to suggest this.
  • We wanted this to express the sentiment to users that every small improvement helps to make their Wikipedia language better. I understand this may come across slightly as pandering to commercial appeal, but we do use real page view counts (with rounding) for the specific projects so as not to mislead with enwiki numbers. So for example, on cswiki right now, it shows the number as 1M daily users. Also the period was changed to daily due to the pageview extension not supporting counts of monthly or hourly. Here's the phab task detailing how we included the figures if you'd like to know more: https://phabricator.wikimedia.org/T236050
• For some reason the cards in the "suggested edits" list do have an ✕ button in the upper right corner. I believe this is a mistake.
  • Ah yes, thanks for noticing. The idea for the ✕ button is to allow users to remove suggestions they don't like, but we are not yet doing this on Suggested edits right now.
• I love that the cards resemble how PagePreviews already look like.
  • Thanks :D
• Having an actual page view count is a superb idea. However, I wonder why you decided to use a "60 days" period? I find this surprising. In my experience it's more common to talk about 30 days periods, or a year.
  • Agree and I've filed this task T248636 to amend the period from 60 to 30 days.
• There is a little sequence of 3 "quick start tips". These panels advance automatically after (I believe) 10 seconds. I find this quite distracting. It's the largest animated element on the page, way larger than the flashing dot on the edit button. Chances are high it advances either to early or to late. I'm just trying to read the text – and get interrupted. I'm just trying to find a button to advance to the next tip – and get interrupted.
  • This may be a limitation of the prototype as I think the actual auto-advance behaviour designed addresses your concerns. The intention (detailed in T244541) is that the tips auto-advance every five seconds, but only until the user interacts with the panel in some way. Once the user interacts with the panel, the tips stay on whichever one they were on when the user interacted.
• It's not obvious the 3 little numbers are meant to be buttons. Later, there is another UI element that looks like "← 1 / 5 →". I feel this would not only fit better, it would also help reducing the number of different UI elements. There is quite a lot going on in these prototypes.
  • We decided to go with numbered tabs in the end instead of previous/back arrows mainly as the hypothesis is that people can navigate faster across the different tips without having to tap prev/next multiple times. It is also a visual signal that there are only a limited number of tips so as to not overwhelm users with too much detail.
• On mobile, there is a screen with the sentence "Ready? Click the edit pencil icon to start" at the very bottom. But since this is mobile, the edit UI is not visible the same time. What's visible is this icon, which also shows an "edit pencil", but can not be clicked. I guess the sentence after "Ready?" needs to be rephrase on mobile, or the icon be changed or removed.
  • Yes, the mobile copy is different and asks the users to tap on the edit pencil instead.

Thank you again for taking time to give feedback! And please consider subscribing to our team's newsletter to keep updated on when we work on other new experimental features, including the release of the first version of this guidance panel. RHo (WMF) (talk) 16:27, 3 April 2020 (UTC)

Thanks a lot for the detailed response! This sounds really good. Very much appreciated! However, I do have a few minor points I would like to bring up again:

• […] every small improvement helps to make their Wikipedia language better.
  Than why not just say that? My point was not how exact the number is. Every wording that uses accumulated page impressions of thousands of pages to justify an edit on a single page is misleading. It's not fair to suggest that the edit the user is going to make will reach thousands of users.
• We decided to go with numbered tabs […] hypothesis is that people can navigate faster across the different tips […]
  How is this relevant? All I see are numbers. I don't know what these numbered tabs contain. How is it relevant to be able to quickly navigate to a specific number? Thiemo Kreuz (WMDE) 08:23, 6 April 2020 (UTC)

Hi again! Let me try to address your additional points as best as I can.

• Than why not just say that? My point was not how exact the number is. Every wording that uses accumulated page impressions of thousands of pages to justify an edit on a single page is misleading. It's not fair to suggest that the edit the user is going to make will reach thousands of users.
  • It sounds like your objection is this number misleads users to thinking their single edit will be seen at the magnitude of the project level views – do I understand that correctly? If so, I want to stress that is really not the intention. This is why we are showing the page views on each suggested edit article (see example at F31736797), and also showing them the views on the any article page with their contributions after they've contributed (see example at F31736801).
  • As for why include the project-level views in that sentence at all? Besides it giving users an impression of the overall audience size for each project; including a specific number in my opinion gives more resonance to the generic sentiment of "every little bit counts". That said, we could consider changing this in future to another number such as number of articles on the wiki (similar to the portal page). This would be a product consideration for @MMiller_(WMF) to weigh in on.
• How is this relevant? All I see are numbers. I don't know what these numbered tabs contain. How is it relevant to be able to quickly navigate to a specific number?
  • There are two main scenarios that this design is meant to help with users more efficiently navigate across tips. The first is when a user has read through some tips, say 1-5 of 7 tips. Using these tabs, they can then easily go back to tip 1 without having to tap a previous arrow to go back through 4,3, and 2. The second scenario is if users do not touch the panel but see the auto-advancing tips. Here, having the tabs change to active state helps draw user attention to the different tips being shown, and again allows the user who has been auto-advanced to tip #5 (perhaps they had not noticed the panel until then) to quickly go back to review the tips from #1 in one tap. While I hope this helps explain the decision to go with tabs over arrows in this first iteration of guidance, I want to stress that we will keep your points in mind when we review user feedback on both the auto-advance behaviour and tabs, in case either are a source of annoyance or confusion. RHo (WMF) (talk) 16:40, 6 April 2020 (UTC)

Thank you so much for these detailed thoughts, @Thiemo Kreuz (WMDE). They are coming at just the right time, because our designer, @RHo (WMF), is in the middle of finalizing this work. We're going into a week of intensive meetings, and she'll get back to you after that. MMiller (WMF) (talk) 19:59, 22 January 2020 (UTC)

SuggestBot and Newcomer tasks

I correctly understand that this is an analogue of the en:User:SuggestBot but only for beginners? :) Iniquity (talk) 09:03, 25 June 2020 (UTC)

Hi @Iniquity -- thank you for getting in touch! It is true that our work is inspired by SuggestBot -- in fact, one of the maintainers of SuggestBot is a member of the Growth team: @MWang (WMF). The most important thing we learned from SuggestBot is that suggestions that match the interests of a user are more likely to get edited by them (per this paper). A big difference between Newcomer Tasks and SuggestBot is that Newcomer Tasks is available for users to browse through, whereas SuggestBot pushes suggestions to the user.

Regarding your question about it being "only for beginners" -- our team focuses on beginners, but there's no reason that this feature, which is essentially a feed of editing tasks that need doing, couldn't be used by experienced editors, too. One day, we may be able to proactively expand it for those users, but in the meantime, any user (in the wikis that have the feature set) can turn it on in their preferences.

Are you a user of SuggestBot? Do you think we're heading in the right direction? MMiller (WMF) (talk) 00:06, 1 July 2020 (UTC)

> but in the meantime, any user (in the wikis that have the feature set) can turn it on in their preferences.

@MMiller (WMF) where? :) Iniquity (talk) 20:04, 7 July 2020 (UTC)

Hello, @MMiller (WMF)! Thanks for the detailed answer. I did not know that Nettrom is one of the Grown team. This is cool :)

> A big difference between Newcomer Tasks and SuggestBot is that Newcomer Tasks is available for users to browse through, whereas SuggestBot pushes suggestions to the user.

I'm not quite sure, but the bot seems to have such a function: w:Wikipedia:Community_portal/Opentask.

> Are you a user of SuggestBot? Do you think we're heading in the right direction?

No, I don't use the bot, as I solve other problems. But I brought open task to Russian Wikipedia. And yes, it seems to me that you are on the right direction, this is a very cool thing that allows you to gently guide participants to improve Wikipedia. And for beginners, it helps to understand Wikipedia, since it is very difficult to know where to start your contribution. Keep it going! :) Iniquity (talk) 10:10, 2 July 2020 (UTC)

@Iniquity -- we are actually looking for more wikis that want to try the Growth features. Do you think there would be interest from Russian Wikipedia? If so, our team's community relations specialist, @Trizek (WMF), can help start a discussion about it. MMiller (WMF) (talk) 18:39, 3 July 2020 (UTC)

@MMiller (WMF), Yes, I think it will be interesting. I'm generally surprised that you work with so few projects.

By the way, I immediately want to suggest improving the documentation, and add a description of the project with a screenshot in the first paragraph. Otherwise, you can understand what the main projects are about, only at the end of the page:

• Growth/Personalized first day/Welcome survey
• Growth/Personalized first day/Newcomer homepage
• Growth/Personalized first day/Newcomer tasks
• Growth/Personalized first day/Structured tasks
• Growth/Focus on help desk/Help panel Iniquity (talk) 12:26, 4 July 2020 (UTC)

@Iniquity -- I went through and made sure all the pages you listed have up-to-date screenshots. Thanks for pointing this out! MMiller (WMF) (talk) 18:20, 16 July 2020 (UTC)

If you have any questions about the deployment of Growth team features on Russian Wikipedia, let me know!

We have a page where all work needed is listed. Trizek_(WMF) (talk) 15:09, 6 July 2020 (UTC)

Well, thanks, then I'll start the discussion in the community. Iniquity (talk) 15:14, 6 July 2020 (UTC)

I have started discussion:

ru:Википедия:Форум/Предложения#Команда Роста и инструменты для улучшения пользовательского опыта новичков. Iniquity (talk) 21:20, 7 July 2020 (UTC)

Great!

Have you created a Phabricator task? You don't really need one for now, but it will be mandatory for the deployment. Let me know if you need assistance. :) Trizek_(WMF) (talk) 17:19, 8 July 2020 (UTC)

I just created it, I will supplement it with information later :) phab:T257490. Iniquity (talk) 17:51, 8 July 2020 (UTC)

Yay! Great!

Out of curiosity, how have you heard about the Growth features? Trizek_(WMF) (talk) 18:14, 8 July 2020 (UTC)

On the Phabricator, I noticed activity in the tasks that interest me :) Iniquity (talk) 18:25, 8 July 2020 (UTC)

Redirects

Hi WMF Growth folks! An idea for a possible newcomer task occurred to me, namely helping create redirects, and I wanted to run it by you all.

The appeal of it is, first, that there's a lot of need: the search functionality isn't great, we currently have no good way to tell which popular searches are candidates for redirects, and the sheer number of possible redirects means that there's a lot more of them to add.

The second part of the appeal is that they're extremely easy to make and to prompt. I imagine that the workflow would go something like this: First, a reader searches for a term, say "Window washer", that does not have a redirect. They are brought to the search page like normal, and they click on Window cleaner. At this point, the software recognizes that this is the 10th person who's searched for that term recently and every one of them has gone to Window cleaner, so it generates a pop-up box asking if "window washer" should be redirected to "window cleaner". The user is taken to the page afterwards whether they click yes or no, but if they click yes a redirect request is generated in their name (or, if this works well enough, the page could be generated directly). The thing I like about this is that, since it only requires a single click, it's unobtrusive enough that we could use it even for readers who have never expressed interest in editing before and thus get them over the hurdle of making their first edit.

The main concerns that come to mind are (1) privacy, since this involves use of search data, and (2) that creating new pages, including redirects, is limited to autopatrolled users, so we'd either have to carve out an exception to that, or established editors would have to handle the queue. I think both of those challenges are surmountable, though. Feel free to let me know what you think! Courtesy pinging @MMiller (WMF). Sdkb ^talk 03:56, 31 December 2020 (UTC)

I am quite opposed to this idea, precisely because it is so easy to create a redirect. I recently had to threaten to block a user on en-wiki for creating innumerable redirects for every single person's name ever credited with making any minor contribution to anime films they were interested in, and they made over 80 redirects for alternative spellings to one single article (see Example.) The fact that a redirect for a trivial name has been created can seriously hinder searching for that name across multiple articles. Having a redirect does not improve search functionality - it weakens it if not done sensibly.

Thinks of an example wherein a minor session musician contributed to backing music for a notable band. Their name might be listed in the infobox or main article text, but they might have worked in a lesser way with twenty other bands. Ten of these bands or albums have articles about them, and this session musician is mentioned in three of them. Without any redirect present, a user searching for that name will encounter search results offering all those different articles, and so they can go an look at each one in turn to find the information they seek. But if a well-meaning new user and music-lover decides to accept the invitation to create a redirect to the first article, their 'helpfulness' may actually hinder many other users finding the information they seek.

Now, the example of the troublesome user I've given above was extreme, but I could envisage us being flooded out with inappropriate and unnecessary redirects made by uninformed editors, every one of which will need a deletion discussion to get rid of. So, no, please let's not consider offering this facility. Nick Moyes (talk) 11:48, 31 December 2020 (UTC)

The troublesome scenario you're describing sounds like what could happen if we just let people loose and told them to make redirects however they wanted. That would indeed be bad, but what I have in mind here is something a lot more controlled. It certainly wouldn't allow something to create 80 redirects to the same page, as it'd only be triggered as I described above. For the example of a musician, if they were part of several bands, different people searching for them would click on several different pages and the system would not suggest a redirect. Is their affiliation with one particular brand is really so strong that all 10 searchers chose that page, then the redirect would likely be appropriate as a related topic.

Regarding "every one of which will need a deletion discussion", not if this is done via w:WP:Requested redirects. Sdkb ^talk 17:43, 31 December 2020 (UTC)

Redirects are indeed a tricky topic. Some communities allow plenty of them, some other have very strict rules. Since we are looking for universal workflows, I don't think working on redirects would be easy.

This said, the search issue you raise Sdkb is a concern. I don't know much about Search, but I though that aliases listed on a given Wikidata item are taken into consideration on search. But maybe I'm totally wrong and, if so, you should suggest it to the Wikimedia Search Platform team. Trizek_(WMF) (talk) 14:26, 6 January 2021 (UTC)

@Sdkb -- thank you for coming to us with this fresh idea! I haven't thought that much about redirects, and I would need to learn more. I definitely like that Community Wishlist idea you pointed out, as such a list could be useful for both redirects and new article creation. I also understand the kind of burdensome scenarios that could come about as @Nick Moyes describes. If I'm thinking ahead to how such a task might work, it might be something like a feed of suggested redirects, surfaced from an algorithm that looks at search data, and the user would be asked, "If someone searches window washer, should that take them to the window cleaner article?" Then the user would be constrained to confirming suggestions, as opposed to being able to create any redirect that they think of on their own.

I'm going to add this idea to my team's list of possible structured tasks, just so we don't forget about it. I'll also ask the WMF Research team if they know of any research into redirects and patterns with their creation.

@Nick Moyes -- if you have some time, it would be really helpful to us if you could check out the "add an image" project that the Growth team is thinking about, and add any thoughts to the discussion page. Your input was very valuable when we were first talking about "add a link", which we're building now -- but this "add an image" project is more ambitious with more pitfalls that we want to avoid. MMiller (WMF) (talk) 01:20, 16 January 2021 (UTC)

Spelling

Can we do something to prevent newcomers from "fixing" the spelling in articles that use a different variant of English from their own? We don't want to bite the newbies, but we have to revert them when they do this, which is not a good welcome. Could we somehow ask what variant of English they use and only point them at articles that use that variant? Kerry Raymond (talk) 07:24, 30 March 2022 (UTC)

Hi Kerry, and thank you for bringing this.

I'm afraid that not everyone is aware of these English differences. To be honest, I wasn't aware of them until recently, and the more I'm exploring English language the more I discover these subtile details.

Can you tell me more on how the articles using a given variant are identified? I know that some wikis have banners, especially the ones hosting multiple dialects, but it is not something I saw at English Wikipedia.

Also, how do you deal with these newcomers, besides reverting (which is indeed not a good welcome)? Do you inform them, and if so, do you react?

Thank you! Trizek_(WMF) (talk) 12:55, 30 March 2022 (UTC)

Hi, Trizek. I've noticed a similar thing with users trying to change such spellings. The main way English variety can be identified is that a template has been placed in the source text at the top of articles which then populates related categories. An example would be https://en.wikipedia.org/wiki/Template:Use_Indian_English which populates Category:Use Indian English. The template isn't present in all articles but a significant number have been logged. In my opinion, spelling in Indian English is virtually indistinguishable from British English, it only differs sometimes in writing style (Indian English can be more poetic), so if absolutely necessary for efficiency it could be possible to group varieties together. Thanks, Zindor Zindor (talk) 00:27, 8 June 2022 (UTC)

Regarding the reverting of the changes, there is a variety of ways in which editors will react. Some will revert with no explanation, some will provide a simple text explanation in the edit summary and others i've seen have posted on the users talk page. The simplest way to explain to a new user is to provide a link to [1] , the policy page we have on English varieties at en-wiki. Zindor Zindor (talk) 00:32, 8 June 2022 (UTC)

Thank you for these details, Zindor.

I observe that 138k articles are tagged as Indian English, 238k are tagged for British English, but only 49.5k articles are tagged for American English. So tagging is not systemic, so it could be difficult to use it. Plus, would it scale to more wikis? At the moment I'm not really aware of other wikis applying different spellings.

We have the cases of variants. Some wikis apply dialects variants (like Normand and Alemanic), where an article is written in a given variant (example). For Chinese, you can choose which variant to display (a script searches and replaces the ideograms), but I think (to be confirmed) that you can write in any form.

Maybe we can do some magic to detect the right spelling, but at the moment, I don't know yet if it is possible. We are likely to work on spelling, offering a task around it. We will certainly use your valuable input there!

To be continued. Trizek_(WMF) (talk) 13:37, 8 June 2022 (UTC)

Because of the prevalence of U.S editors, American English is the presumed variety unless another indication exists (such as the article unambiguously being an inherently British topic), so tagging for the U.S variety will naturally be far less. So thinking of it in the reverse, an avoidance strategy could make a difference. Recommending U.S based users anything except Indian and British categorised articles would remove 376k articles where these errors could occur. That's a significant number in my book . Regards, Zindor Zindor (talk) 13:51, 8 June 2022 (UTC)

No, this is not true; AE is not the presumed variety for an article in principle. The presumed variety is whatever variety the article creator or early modifiers used; or to put it another way, the presumed variety is whatever the variety was in the earliest version of the article where a particular variety (and not some other variety) is clearly evident. Overriding this however, is the principle of en:MOS:TIES, which stipulates that even if Americans first wrote the article Big Ben in AE and it became stable early on, nevertheless, the AE variety should be overturned in favor of BE, because the *topic* "Big Ben" has clear, national ties to England; therefore, British English is the choice, regardless who got there first.

In a practical sense, it's probably true that many articles that have no national ties to any country end up being written in AE due to the sheer number of American editors, but for any given article with no TIES, the variety is unpredictable because we are a volunteer project, and it just depends who volunteers first to create the article. Mathglot (talk) 04:58, 20 July 2023 (UTC)

What isn't true? While correct in what you're referencing, you've missed the context of this thread, I omitted mentioning existing English variety because the entire reason for this thread is that new users are struggling to make the realisation that other varieties exist and that existing variety takes precedence! This is about triaging where new users are sent so we can actively avoid the situations where MOS violations are likely to occur, not about teaching them policy after they've done the damage, we don't have the volunteers for that. American English has always been presumed unless there is an indication otherwise, if there is an indication then there is no longer a presumption. Avoiding sending American editors to the 376k articles i mentioned would go a long way in preventing damage. I've not kept track of what has since been implemented but it was a good idea at the time and there was nothing untrue in the advice i gave. Zindor (talk) 19:31, 15 September 2023 (UTC)

Just came across an edit apparently using newcomer tasks which was purely changing the English variation. I can't see from the page here how this is recommended to new users, the only mention of spelling is in "Sourcing the tasks" where it notes specific copyedits are not offered. However this is advised, it should probably be changed to not encourage this. Chipmunkdavis (talk) 23:20, 19 June 2022 (UTC)

For Australian articles, the template is "Use Australian English". We also use the template "Use dmy dates" as well. Again, a problem we encounter (not just from newbies) is the desire to change dates into MDY format. I think the vast majority of articles relating to Australian content will have those templates, and consequently there is a pretty low tolerance of people who choose to ignore them when "Use Australian English" seems to be a pretty unambiguous directive (what else could it mean?!).

And as much as I think it is desirable to be friendly and helpful with newbies, there's just not enough time to hold the hand of every new user, so you need to pick and choose. I tend to take more effort with new users who have a username (I've given up investing time in IPs) who seem to be trying to add good-faith content to Australian articles as I figure I get the best return on the investment of my time with those folk if they stick around contributing to the same topic space (Australia) as I do. However, such people generally don't have a problem writing in Australian English.

This suggests to me that it might be useful to identify a topic area of interest to the newcomer and only point them at articles in that topic space (based on categories or WikiProject tagging). That way, the users who will notice them (typically via their watchlist) will be active in the same topic space and see the benefit of assisting in onboarding this new user who is interested in that same topci space. Kerry Raymond (talk) 04:15, 23 June 2022 (UTC)

The problem is continuing happening. We are critically short of Australian contributors and cleaning up after these newcomers is just a waste of everyone's time (the newcomers and the regulars). Can they kept away from variants of English not their own (ideal solution) or given explicit instructions to check and respect the variant of English. I don't want to just revert them because it's not welcoming but it is unfortunately the most time efficient thing to do. ~ 118.208.211.92 (talk) 23:39, 11 August 2022 (UTC)

The above was sent by me but for some mysterious reason I was not automatically signed in. Kerry Raymond (talk) 23:42, 11 August 2022 (UTC)

This is still happening. What is the value of explicitly encouraging a new editor to make a mistake? Chipmunkdavis (talk) 03:15, 15 July 2023 (UTC)

As we can't rely on tagging for all cases, maybe the best option is to edit the onboarding messages locally to highlight this specific instruction?

This message says

You can fix spelling and grammar errors. This might include sentences that are too long, repeated words, or incorrect punctuation.

It could be edited for:

You can fix spelling and grammar errors. This might include sentences that are too long, repeated words, or incorrect punctuation. If you plan to fix spelling, please carefully look at the article and keep the variant of English.

I let you agree on the best (short and clear) wording for this sentence.

Don't forget that changing this message won't fix all cases of "wrong" English variants being used. Knowing this particularity of English Wikipedia is part of the learning path for newcomers among (too) many other important things. Trizek_(WMF) (talk) 16:12, 17 July 2023 (UTC)

The homepage forces participants to make empty edits

It looks like the participants are starting to make empty edits to remove articles from the list of suggested articles! And because of such empty ones, admins begin to block them (forever)! We need an explanation right on the homepage about how to refuse uninteresting suggested articles (or those in which you tried, but could not do anything) in order to get a new set of suggested articles. e.g. w:ru:WP:Форум/Вниманию участников#Массовое добавление сдвоенных пробелов [2] Sunpriat 17:20, 7 August 2022 (UTC)

Hello Sunpirat, and thank you for reporting this.

Newcomers aren't forced to edit, on the contrary, they can choice which articles to edit. Maybe some users miss a way to exit the article? I agree that the editors don't provide such an option.

In this case, as your other colleagues, I see an user who only adds or removes one space every edit. They are also working on very different topics that it becomes very suspicious. My conclusion is that this user was clearly playing with the system, to artificially increase their number of edits. With or without Suggested edits, this kind of user would have found a different way to increase their number of edits. If I was facing the same situation at my wiki, I would have blocked them as well. Trizek_(WMF) (talk) 13:53, 9 August 2022 (UTC)

You also bring forward the blocking. Different topics or not, but edits were made with the tag "Newcomer tasks" - so part of the responsibility lies with this tool. Something anchored this incorrect behavior and it's something in the tool. If you just close the article, it does not disappear from the list of suggestions - the "exit" simply does not work. If we can make the tool description shown to them better and prevent it, we should do it. Such use of the tool by other participants should be monitored and investigated. In the discussion, they said that they had already blocked other participants for this. We cannot lose participants because of this. In small projects, there are much fewer participants, but they encounter blocks not so much less often. Sunpriat 14:36, 9 August 2022 (UTC)

You say "Something anchored this incorrect behavior and it's something in the tool." What could it be? If you see multiple accounts having the same behavior and being blocked when using Suggested edits, it can indeed be a problem inside the tool. But it can also be the reveal of a different pattern, such as a returning vandal, for instance (I often identify returning vandals at my wiki because they have an editing pattern; a request to Check Users often confirms it). I'm not saying that your are wrong, I'm just asking you if you have considered all possibilities. :)

I agree on the fact that you can't loose participants, but, for the only case you gave me a link to -- a clear vandalism -- I don't think this user is a great loss for your wiki.

If you have other cases of possible misuse, or other strange behaviors, please share them with us. They are very helpful for further investigation. I can't ask the community for now, as I go on vacation very soon, but if you can find some links I can check on when I return back (early September), it would be really, really helpful. Trizek_(WMF) (talk) 14:16, 10 August 2022 (UTC)

"What could it be" - To be a vandal or to increase the number of edits - there are easier ways than to open pages one by one (in the order that the panel suggests) through the list of suggested ones.

He had more than 12 edits per day (12 in total - the number of suggested articles in the set) and "empty" edits were mixed with edits with real small changes to the text.

It looks like "I can make an empty edit if I don't see what I can fix here" and "then I will be able to look at a new article in which I will have a chance to do something" - this is still a constructive approach, since the participant still wants to make good corrections. (for example, if you want to fix something and there is a "special:" pages with a list of problematic articles - you open the articles in order from the list and simply do not make edits where you did not find the location of the problem (for example, in articles from the special:linter errors, the problem place is not always obvious), but here the participant can spend a lot of time on a large list, but he is offered a very small one of 12 elements and he knows only one way to remove articles from this set so that new ones appear in it.) The suggested article will disappear from the list and give a new set of articles. Without this, uninteresting articles remain in the list of 12, but the participant wants to see more other articles and there is no other way to "skip the article" or "change all 12 to completely different" for this.

I think that the button "I've seen this article, I don't like it, I can't do anything in it, don't show it to me again" or the button "I looked at all the articles from the current set and didn't find what I can do in them, hide them all and give others" could prevent this. Or add a mention that in addition to a small list, there is a large one somewhere - to give more opportunities for choice (You become able to process more articles than a list can give you. You cannot (you don't know how, you are not offered further growth) go to a large list, or use this convenient list on a larger scale). Sunpriat 15:02, 10 August 2022 (UTC)

I note that you ask this user to explain why they were making these edits. Their response is not giving us any clue: "I agree with the reason for the block and I am ready to promise not to make any more incorrect edits". It would worth exploring the case, by asking them why they made edits with only a space addition or removal. If the response is "because I wanted to exit the article", then we will be set. :)

When a user publishes a suggested edit, they see a list of edits, but also a link to see more suggestions, that sends them back to their Homepage. They can also just quit by clicking anywhere else. They are not forced to do more edits.

It seems that your lead is that the user hasn't found the link just below the suggested edits to return to the homepage and select a new set of tasks, am I right? This is what would correspond to the "I looked at all the articles from the current set and didn't find what I can do in them, hide them all and give others" action you mention. And it would mean that the user hasn't seen the "Посмотреть все предлагаемые правки" button, just below the short list.

I take your idea of reshuffling the set of suggested articles as something that should be considered. We had this idea but we haven't implemented, waiting for feedback. In full transparency, you are the first person to bring this to the table.

FYI, it is my last response until September. I'll read the developments of this case at my return! See you soon! Trizek_(WMF) (talk) 18:55, 10 August 2022 (UTC)

What was said could be not so right lead. "12" this is shown in my list. This case may be due to the fact that after saving, a panel is displayed on the page offering another article. If you have opened "copyedits", then if you save without changes (put a space, erase the space) or refuse (by switching to reading) to make changes, this panel is not shown. But if you save the added space or line break, then the panel will be shown. This can probably be avoided if some button for calling such a panel will always be visible on the bottom right. Sunpriat 13:46, 11 August 2022 (UTC)

We are considering to display the task suggestions after making an edit to users who haven't used the Homepage yet. Getting a way to show/hide this call to action is something we keep in mind there. Trizek_(WMF) (talk) 14:27, 9 January 2023 (UTC)

Newcomer is making bad edits

New user Luminar021 had been doing edits adding wikilinks to articles, most of which are in violation of MOS:OL, and saying these are newcomer tasks. Since as far as I can tell the newcomer system is opaque, I have no way of checking whether this really is a newcomer task or not. Can someone look into this?

Also I think it's a really unfortunate decision that newcomer tasks are hidden, unlike all other Wikipedia communication. Is there a Phabricator task open for this?

Thanks, ~ Danbloch (talk) 20:17, 12 November 2022 (UTC)

Hello Danbloch

I checked Luminar021's talk page, where someone left them a message. In your opinion, have Luminar021's edits improved since then? If not, it could be good to renew this message, or go further, like it would be done for any other can-be-improved edit.

Regarding the opaqueness, could you clarify? Maybe you are not (yet) aware of the fact that a new onboarding process exists on all Wikipedias?

A special page (the "Homepage") is displayed to newcomers, where they can find tasks to start editing. These tasks go along with guidance.

Tasks given to newcomers are based on templates for most of them. These templates are curated by the community, at en:Special:EditGrowthConfig.

All newcomers tasks are tagged in Recent Changes (direct link), so as at other places (Watchlist, Special:Contributions...).

Let me know if I can help you any further. Trizek_(WMF) (talk) 13:43, 14 November 2022 (UTC)

Thanks for the response, and for the various links.

Luminar021's edits may have improved slightly, say from 90% bad to 75 or 80% bad. It isn't worth going to the effort of undoing the majority of them, but they're certainly not making Wikipedia better.

I have another concern, though. Based on the links you sent and the auto-generated tags in the edit history, Luminar021's tasks are "Newcomer task: copyedit", but the actual edits they're doing are "add a link", so they're not following the newcomer workflow in any case.

And by "opaque" I meant that I wanted to see if the newcomer system was really telling them to make these changes. Now that I've played around a bit with the system I gather that it doesn't have assignments per se. But I also want to see what the instructions were for creating wikilinks, which I would need to know to meaningfully discuss what a newcomer was doing, and there doesn't seem to be any way to see this. Finally, it would be useful if there were a way to find newcomers' mentors, so I could tell them, "Hey, your mentee is screwing up" and not get further involved.

Feel free to incorporate these concerns or not, as you see fit.

Regards, ~ Danbloch (talk) 05:04, 15 November 2022 (UTC)

Most users follow instructions. Some other don't, even if they are asked to change their behavior. If they add links badly, especially when the task they selected (copyedit) is not about adding links, what can be done? It could surprise you as I work on helping newcomers making their first steps, but here I can only advise to be more strict with this newcomer.

If you have turned on the Homepage and the Help panel in your preferences, you are supposed to have the guidance being displayed if you select a task to work on.

Instructions for "Copyedit" are the following, and they aren't about adding more links:

1. Copy editing is about making a small fix to the way an article is written, such as spelling, grammar, or the clarity of the text. Copy edits help articles to be more professional and trustworthy. Reaching Mercury from Earthh poses significant technical challenges.
2. To make a difference, you only need to make one or two small corrections. You do not need to work on the entire article. You also don't need to have any special knowledge about the topic.
3. You can fix spelling and grammar errors. This might include sentences that are too long, repeated words, or incorrect punctuation. Mars has has two small moons.
4. You can also rewrite sentences so that they do not contain opinions. Wikipedia content should be neutral, clear, and encyclopedic. However, be careful not to change the facts in the sentence. Jupiter is the largest, and most interesting, planet in the Solar System. This sentence contains an opinion that should be removed.
5. Once you see a correction you want to make, click "Edit" to get started. Then go ahead and fix issues by deleting and typing as needed.
6. Either find more changes to make, or go ahead and click "Publish changes…" to publish your edit!

Learn more about copy editing

We are discussing on improving newcomers' mentors visibility. However, we are in a particular case with English Wikipedia, where only 10% of newcomers know that a mentor was assigned to them. It could be a bit strange to have a user posting at the newcomer's talk page out of the blue, claiming to be their mentor and providing advice. We are looking for a solution to address this. Trizek_(WMF) (talk) 15:26, 15 November 2022 (UTC)

Kudos to the Newcomer Tasks

As a Newcomer, Newcomer tasks are helping me approach the learning curve in a way that would have been much less smooth and much more difficult otherwise. I can see how the tool helps new users, established editors, and administrators SO Kudos. I wanted to let you know that, in one circumstance, the newcomer tasks pointed me to what I would consider to be a sensitive topic (transgender). I handled a potential kerfuffle with empathy but I think it would be great to remove anything from the edit list that might cause emotions to run hot. -- Anyway.. So I created two articles for submission, edited many articles, and have been keeping notes in talk.. and there is an endless amount of stuff to learn. It's also been great to rub shoulders with many a longtime editor/administrator. That speaks to how well thought out and productive this tool is, at least to me. WELL DONE! Flibbertigibbets (talk) 02:11, 18 November 2022 (UTC)

Thank you for your appreciation, Flibbertigibbets! I shared it with the team.

Regarding removing topics that may cause emotions, we can't create a list as the universality of Wikipedia would lead to an endless list. This being said, we have some improvements for topics selection that could help, such as a more precise way to select topics.

Thank you again! Trizek_(WMF) (talk) 12:53, 18 November 2022 (UTC)

New section 'Newcomer task tag' needed

Can you please add a section on the project page called 'Newcomer task tag', or similar? I am seeing tags on edits at en-wiki with the text 'Newcomer task' which are hyperlinked to this page, but when you get here, there is no explanation about this tag, what it means, how it got applied to that edit, or what anyone else should do, or keep in mind, when they see it. Is this simply a DONT BITE reminder for more experienced editors who might be about to warn or template a user? I expect not; I'm just trying to elicit a response; but I really don't know how to interpret that tag, and since it links here, this is the logical place to have a section about it.

Please also explain the tag 'Newcomer task: copyedit', which also links here, and what the difference is between the two of them.

Clarifying: I'm not asking for an explanation of these tags here on the discussion page in reply. I'm asking for a new section to be created at Growth/Personalized first day/Newcomer tasks where everyone can see it. The only thing I need in this discussion is a ping. Thanks, Mathglot (talk) 21:19, 16 February 2023 (UTC)

@Mathglot Great minds think alike! :) We are actually planning to make a change soon that addresses this: T322813 & T329906.

We'll link each Newcomer task tag to specific section explaining the task.

Examples:

• The Newcomer task tag will link here: Help:Growth/Tools/Newcomer Tasks
• The Newcomer task: copyedit tag will link here: Help:Growth/Tools/Newcomer Tasks#copyedit

If you had been linked to those pages instead of this project page, do you think that would have addressed your questions?

Those tags hopefully serve as "don't bite" reminder, but I also hope that any moderator interested (or frustrated) by those edits will click the tag and learn that newcomer tasks are helping increase the number of new account holders that try editing for the first time AND improve new editor retention. Perhaps that's something we need to highlight more on that page. Do you have any suggestions for how we should improve the new Newcomer Tasks page? KStoller-WMF (talk) 22:33, 16 February 2023 (UTC)

KStoller, I think the Newcomer tasks may have a downside which I just ran into. I haven't seen the instructions aimed at NCs yet, but I think it may have led one editor astray, with the consequence that I spent a good deal of time undoing their edits, then analyzing what was wrong with them, so I could give some concrete feedback on their UTP, resulting in two of the longest messages I've ever placed on a UTP, and both of them to the same user. The irony here is, that this user only seemed to be doing what you told them to do in a newcomer task (or at least, I'm assuming so; will check further when I see what you tell them). Have a look at the edits at en-wiki of user Jonathan9898, and my extensive messages to them at them at their UTP. Kind of a waste of their time, and mine, also. It's hard to know how much of this is due to whatever the direction they are getting from Newcomer tasks, and to what extent this might have happened anyway, and was probably a confluence of several things, including whatever that particular user brings to the table. I feel sorry for having had to undo a dozen of that editor's edits, when all they were doing, I can now see, is what they were told to do. (Had I known about Newcomer tasks before I saw their edits, I still would have undone them just the same; the only thing that would have changed, would be my edit summaries, and my explanations on their UTP for why they were undone.)

As a related issue, I'd like to be able to read somewhere, how you pick or suggest the articles for them to edit. (I assume you're doing that, right? I find it hard to believe two new editors would have turned up at the w:Battle of Khresili without a link to it.) In the case of the Battle article, there are essentially zero reliable sources in English books, journals, or magazines; the stuff on the web is all social media, youtube, blogs, and SPSes. The point being, that had this been a Newcomer phase 2 task of adding content with new assertions of fact requiring inclusion of citations, unless your Newcomer speaks Turkish or Georgian, they would be SOL, or rather, they would very likely be tempted by the junk sources on the web (because there isn't anything else), add possibly bad content based on unreliable sources to the article, and fail that task, too. So I think it's important, if you also have a "sourcing" newcomer task in the hopper, to think about how you pick the articles for that. Is it automated, or a pool of curated article titles and then randomly distributed? Already another newcomer has hit w:Battle of Khresili, and I wonder how they ended up at this incredibly obscure topic.

I haven't really had a chance to look at the pages you linked to yet, but I will tomorrow. I'll try and remember to respond then (pls ping me if I don't). I think these tasks are an attempt to address an important goal that needs addressing, and I'm glad you're working on it, and if I can contribute in improving that in any way, that will be very gratifying. Let's keep in touch. Mathglot (talk) 10:54, 17 February 2023 (UTC) edited for clarity at 22:25, 17 February 2023 (UTC) Mathglot (talk) 10:54, 17 February 2023 (UTC)

@Mathglot, thanks for spending the time to provide feedback to the Growth team and such extensive feedback to a new user! After reading your detailed feedback for this new editor I was excited to suggest that you join Mentorship, but I just checked and I see that you already are a Mentor. :) Thanks for taking the time to help new editors!

I wanted to let you know that our team is discussing this example and your feedback separately as well. There are actually several different topics you've brought attention to here that are worth consideration.

I haven't seen the instructions aimed at NCs yet, but I think it may have led one editor astray

It looks like this user would have received our "copy edit" guidance, which you can read here: Help:Growth/Tools/Newcomer Tasks#copyedit. Let me know if you think there is something in that onboarding that you think could lead a new editor astray. Unless an article needs clear spelling or grammar fixes, copy editing is actually a rather challenging task. We hope to eventually work on a more structured task around copy editing that might provide better guidance.

I'd like to be able to read somewhere, how you pick or suggest the articles for them to edit.

Newcomer tasks compiled by maintenance templates. Communities can decide which maintenance templates to include and adjust settings here: https://en.wikipedia.org/wiki/Special:EditGrowthConfig. You can see that we also provide the option to exclude articles containing certain templates or categories (although it appears that's not currently in use on English wikipedia). Unfortunately there is always the possibility that we are suggesting articles that aren't really appropriate for newcomers. It sounds like w:Battle of Khresili is one of those cases. It would be removed from the Newcomer task list if the `Peacock` template was removed or if that template was removed from the EditGrowthConfig. I've had conversations with others about how articles with that template might be especially challenging for newcomers, so perhaps that's something the English community might want to change?

It's worth noting that we also attempt to show newcomers topics that they are interested in. You can read more about that and Newcomer tasks as a whole here: Growth/Personalized first day/Newcomer tasks#Version 1.1: topic matching

I think these tasks are an attempt to address an important goal that needs addressing, and I'm glad you're working on it, and if I can contribute in improving that in any way, that will be very gratifying. Let's keep in touch.

Yes please!

The Growth team hopes to continue to iterate and improve on the existing newcomer tools (while also working on some new features / projects) so feedback is always welcome!

Do you think it's worth having a larger conversation with others about removing the `Peacock` template from English Wikipedia's EditGrowthConfig?

Do you have any suggestions for how we can recruit more Mentors on English Wikipedia? Currently only 10% of new accounts get matched with a Mentor because we don't have enough Mentors. The Welcome template still mentions the Adopt-a-user program despite that page saying "If you are a completely new editor, we’re sorry, but Adopt-a user is not really best-suited to your needs." I think that Mentorship is likely a better fit for brand new editors, but we can't really publicize it more until it's available to all newcomers.

Thanks again for your thoughts and feedback! KStoller-WMF (talk) 23:35, 17 February 2023 (UTC)

Briefly: I'm continuing to discover your pages, and some of my questions seem to be already answered elsewhere, so it's partly because I'm new to your product and am still discovering it.

Part of the issue I see here, reminds me of the old game of "Telephone", where a message gets progressively blurrier and garbled, the more it's passed on. Here, it starts where some editor perceives a problem at an article, and slaps a template on the article. There are a finite number of these templates, and often the template content is only an approximation of what the real problem is. So, that's the first whisper. Secondly, the editor who places it is encouraged to use the |reason= parameter, but the great majority do not. Whisper #2. Then, some part of your software finds the tagged article, and tries to assign it to one of the six tasks, which are only very roughly aligned with maintenance templates: whisper #3. Then, there's the doc page, the on-page guidance, and the understanding of a new editor to take into account. How close to the complaint identified by the original template are we now? I can easily see how a stepwise blurring of this sort could have led two separate editors at w:Battle of Khresili to make good-faith edits that were not helpful.

I presume that you control generation of the edit tags, and can add as many subtypes of copyedit tags as you wish to; is that correct?. If so, I would recommend that the tag, and the task, hew very closely to the maintenance template problem that is identified on the page. Maybe this means several dozen more tags or subtags, and a longer doc page with more subtasks (or a hierarchy of task pages) but I think that would reduce the blurring and keep a newcomer focused on a task that is as closely related to the actual problem identified on the page as possible.

In the case of the {{Peacock}} template, I assume it enables the choice of Battle of Khresili only for editors needing to be assigned a Copyediting task, correct? Imho, that is way too broad, and ideally, it should be only for a specific subtype of copyediting, namely, searching for peacock terms and removing them or altering them. An editor should not be led to an article that has some peacock terms, and told it needs, or could benefit from, general copyediting. A Peacock template is not a sign that the article needs general copyediting, and indeed, imho, w:Battle of Khresili does not need general copyediting, so if newcomers were told that it did, they were lead astray, in my opinion. (As a side issue, I don't think the article has any peacock terms, either, and I've raised that at the article talk page, but that's not something you need worry about as is is unrelated.)

I won't have any suggestions about mentorship for you until I have tried it out myself. Haven't yet found the time to even browse the dashboard and see how it works, so I'm still a completely newbie in that respect. Mathglot (talk) 01:10, 18 February 2023 (UTC)

Agreed, there perhaps is a bit of "Telephone" happening here.

I presume that you control generation of the edit tags, and can add as many subtypes of copyedit tags as you wish to; is that correct?

Currently there are only 5 newcomer task types on English wikipedia: copyedit, add links, find references, update articles, and expand short articles. However the community controls which templates populate those tasks. Community configuration for English Wikipedia is here: https://en.wikipedia.org/wiki/Special:EditGrowthConfig.

We've also discussed full community configuration support for suggested edits T291349, but haven't prioritized that work yet.

I agree that the copyediting guidance is perhaps too broad / vague for articles with the {{Peacock}} template. A quick solution would be to remove that template from the EditGrowthConfig. I had a similar conversation with community members about the copy edit task previously, and suggested the following:

• If it seems like there is a certain copyedit template that is especially challenging for newcomers, then perhaps it should be removed from the configuration.  
• People could also spend time cleaning up the application of certain templates that are included in the Growth Configuration; if maintenance templates are no longer relevant, then they should be removed from the article.
• Or perhaps there is a new template that should be created? A new maintenance template could be created that is especially geared towards newcomers, and the Growth Configuration could be updated to only pull suggestions from that maintenance template.

Do you think any of those ideas could help? KStoller-WMF (talk) 23:32, 22 February 2023 (UTC)

So, I've had a glance at Help:Growth/Tools/Newcomer Tasks, and I have a few comments or questions.

As far as organizational structure:

• Why are there separate sections for '#Add Links' and '#Suggested: add links'? The main difference I can see is whether the Moon, or Mercury is the example.
• Why is 'Suggested: add images' a "suggested" one, and not a task like the others? I don't see anything special about it.
• The tasks are all top-level (H2) sections currently. If they were H3 subsections, you could nest them under a new H2 'Tasks', and then the ToC section numbering would start at '1', and they'd be conveniently grouped. On the 'cons' side of it, en-wiki would disapprove, because of en:MOS:NOBACKREF, but that's guidance only and I think it works here, plus, this is not en-wiki.

Purpose section: good start, but it lacks mention of the intended audience. From the page title, newcomers might assume that this page is directed at them, but it seems clear to me that this is not the case; the organization seems to imply that it is directed more at people like me, trying to get a handle on what it is about, perhaps because I want to understand the tags, perhaps because I want to act on it and help out the newcomer who made a tagged edit, and I don't want to just jump in uninformed. Or maybe it isn't; that should be made clearer. (If, in fact, it is intended at newcomers, then I would overhaul the page completely; that is a more involved topic for a separate discussion.)

Project audience: individual sections make it clear to me that this is directed at en-wiki users only (such as #Add_links step 3, clearly referring to en:MOS:OL). But my (limited) understanding of mediawiki is that it is cross-project and in general, applies to all Wikipedias and other sister projects, is that correct?. If the newcomer page applies to en-wiki only, this should be stated somewhere. If it is intended to apply cross-project, then either remove en-wiki based guidance (such as MOS:OL), or else change the verbiage to either give multiple wiki examples, or deal with it some other way. If this page is destined to be translated, like meta pages often are, then the verbiage tied to an individual wiki like that MOS:OL example should not be translated, but transformed, into whatever fr-wiki or es-wiki, etc. have to say about linking, not what en-wiki says about it (if they say anything at all; many probably don't, in which case, remove that step, or replace it with something else). Fr-wiki, for example, regularly links years, and century ordinals (they even have a template for the latter).

Introduction: seems like there's a missing introduction section ('About' covers some of this, but is more purpose-oriented). In it, you could describe the six tasks very briefly; bullet items with on-page section links might be a quick and easy introduction:

• #Copyedit – minor fixes like typos and grammar; easy
• #Add links – how to add wikilinks to a word or expression; easy

and so on.

Section Add links:

• the purpose is stated as 'demonstrate to newcomers that it is possible to edit the wiki.' I don't think you meant that; that seems like copypasta from the 'Copyedit' section. Also, there isn't anything about the different edit s/w; this operation is very different in VE or the source editor; not saying this page should detail the steps, but it should say whether it's targeting NCs using VE or source code editors, and whether mobile view or desktop figures into this at all (and I think there's maybe an iOS app as well, or am I mistaken?).
• unless I missed it, there isn't any actual link (or brackets, if this is a source-code example) in the examples in the section; so I don't see how it shows them how to add a link. I'm assuming that's because this is just a draft/work in progress.

That's as far as I got, for now. Mathglot (talk) 22:13, 17 February 2023 (UTC)

Thanks for the feedback!

I'll ask @Trizek (WMF) to take a look at your suggestions next week. KStoller-WMF (talk) 23:38, 17 February 2023 (UTC)

Hello Mathglot, and thank you for your questions and suggestions regarding Help:Growth/Tools/Newcomer Tasks.

'#Add Links' and '#Suggested: add links' are two different features. The first one encourages users to add links, while the second suggests links that can be added, based on an algorithm. Only first feature is offered to newcomers at English Wikipedia.

'Suggested: add images' is based on an algorithm, which suggest images used at other Wikipedias for local addition. Again, this task is not available at English Wikipedia.

Regarding these suggested edits, the page introduction documents it: "This page lists all existing newcomers tasks. Some of these tasks may not be available at your wiki. Check the Deployment table to know which tasks are available where."

As you edit French Wikipedia, you can test Suggested Links and Suggested images there, by visiting fr:special:Homepage.

I added a new section to separate the tasks from the rest of the page. Good idea, thank you!

RE: purpose -- actually, this page is not for newcomers. It is meant to be discovered when experienced users click on tags on Recent Changes or Watchlist. The goal is to show the instructions displayed to newcomers, as most experienced users aren't well aware of newcomers tasks. I added a small clarification regarding the audience.

Re: audience -- the targeted audience are all experienced Wikipedia users (not sister-projects), no matter which language they speak. The instructions have been written to cover most common and universal cases. Of course, some local rules might apply; they are then covered by communities who can either edit the local message or explain how the edit can be improved.

In the case of a step where a link is provided, the rule is to edit this link to match the language. In Update#5, the instruction link goes to en:Wikipedia:Verifiability at English Wikipedia, while it goes to fr:Wikipédia:Vérifiabilité at French Wikipedia. Due to translations limitations, the current link on the help page at mediawikiwiki goes to a mediawikiwiki page.

RE: section Add links -- The purpose of this task is to demonstrate to newcomers that it is possible to edit the wiki. :) It is simple and easy to achieve. Communities often say "Be bold", and this task is precisely about it, especially with Suggested links (the idea is to see the Add links feature to be replaced bu Suggested links). In all cases, we are in a "Visual editing first" approach, as this editor removes the technical barrier of learning wikitext. They aren't available at Android and iOS apps. Trizek_(WMF) (talk) 14:46, 21 February 2023 (UTC)

Back to the Battle of Khresili article. A second new editor is now working on this obscure battle article, and appears to have gotten there via the Newcomer tasks (see copyedit tag on revision 1139890459 (11:17, 17 Feb.). Although there are some minor improvements (notably, sentence initial number spelled out) most of this is just moving words around ("every year" ⟶ "yearly"; "full independence" ⟶ "complete independence"; "Ottomans were eventually forced to sign" ⟶ "Under force, the Ottomans eventually signed"; "which was successfully achieved" ⟶ "which they achieved successfully"; "but soon Abashidze was killed by a Georgian soldier" ⟶ "Although, Abashidze was soon killed by a Georgian soldier") and on balance, not an improvement, or makes the article worse. One could revise this, keeping 20% and adjusting 80%, but in reality it's burdensome, and my first reaction is to just undo it. Which then, presumably, would have to be followed up by a section on this user's Talk page, explaining why I reverted their edit, when they were just following instructions. The bottom line is, if a new editor's changes are not an improvement to an article, they should be adjusted or removed; no special quarter is or should be given, just because they are following newcomer instructions. (The Wiki Edu program faces similar issues, and is fully supportive of the fact that although student editors are brand new, no special dispensation should be given to poor edits, just because they are student editors trained through the Wiki Edu program. The same thing should apply to newcomer tasks and the edits resulting from them.)

While we all make mistakes, especially at the beginning—I certainly remember a lot of reverts when I first started out—nevertheless, those errors were mine alone. My feeling here, is that some of the newcomer tasks (in particular, the 'copyedit' task) is worded in such a way, as to encourage new editors to make pointless, word-salad edits which do not improve the article. I spend a fair amount of time with new editors, and I'm always willing to help them, but I wouldn't be happy if that burden was increased due to instructions to new editors from Wikimedia whose result was to generate a higher proportion of poor edits which have to be examined, and then reverted or adjusted, followed ideally by an explanation to the user. It feels to me at this point, that live articles are being used as a test bed for newcomer copyedit tasks, instead of the sandbox. If they are doing word-salad changes merely to see that they can edit Wikipedia, and not keeping in mind the need to improve the article, then that is not a valid reason to edit the article, and if there's no improvement, the edit should be undone, or they shouldn't be applying that edit to a live article. And it's not good for the newcomer, either, probably leaving them confused about why their edits were removed, when they apparently just did what they were told to do. This could be a real hit on editor retention; I know I'd feel discouraged under those circumstances. (Maybe they should be directed toward the Talk page instead, and introduce themselves there, first. That will give them the feeling of changing a live page on Wikipedia, requiring all the same learning tasks, without changing a public-facing page.)

As far as the newcomer task, it may just be a matter of changing the verbiage presented to the user, making sure relevant policies and guidelines are linked, and perhaps even advice about not changing verbiage solely for the purposes of the task. One way I word this sometimes to users, is: "every change must improve the article in some way, no matter how small". Mathglot (talk) 23:03, 17 February 2023 (UTC)

It sounds like w:Battle of Khresili is one of those cases.

Somewhere in your Growth pages, I had found a JSON page showing the conditions for a task being shown, but I can't find it again. Now I can't remember if there was an "exclusions" list array, where you could list articles to exclude, even if they met the template condition. (Assuming not, as the list could get pretty long.) Then it occurred to me, that since those conditions looked very simple, maybe it could be beefed up to do something like Petscan does, so it could interact with a lot more conditions, including categories, and all manner of other conditions. If we had that, I imagine we could define some condition that would exclude articles like w:Battle of Khresili. I'm guessing that is not on the table, but it would be a powerful addition. Mathglot (talk) 09:18, 18 February 2023 (UTC)

@Mathglot Thanks again for all of the feedback! I think I likely answered some of this above, but I think https://en.wikipedia.org/wiki/Special:EditGrowthConfig is the page you are thinking about? It basically serves as an easily editable version of our JSON configuration: https://en.wikipedia.org/wiki/MediaWiki:GrowthExperimentsConfig.json KStoller-WMF (talk) 23:36, 22 February 2023 (UTC)

"Difficulty" adjustments

There was recently a case on en-wiki where a new editor using this growth tool in good faith was universally agreed to have made a selection of articles equally or more promotional by selecting the "easy" task of copy-editing.

There's a growing consensus at en:WP:ANI that no, copy-editing is not "easy": good copy-editing requires a native-level proficiency with the target language, and a strong feel for proper encyclopaedic voice in a world where most people consume orders of magnitude more writing that is promotional, forum-esque, or instructional.

Granted there's a substantial subset of editors (myself included, having evidently forgotten my password again) whose first foray into wiki editing was fixing a typo or obvious error from in punctuation, spelling, or grammar. I think articles that are tagged as needing copy-editing for grammar alone may be an easier task, but in the general case it's significantly more difficult than improving sourcing or expanding a very brief stub article.

Anyway I'm not going to propose a bunch of ideas here because it looks like en-wiki are going to have an RFC about it, but I did want to loop in the team here from the very outset, in the hopes that we'll all be able to engage each other and come to an agreement on what best serves everyone's goals, instead of springing the results of an RFC on you once it's already been decided without yall's inputs, which seems like it would lead to frustrations on everyone's part.

No discussion specifically about this growth tool and the any proposed modifications that will improve everyone's experience has yet been opened at the time of this edit, so please consider this post as generating awareness. I'll follow up with a link to any RFC once one exists. Thanks for your time. 71.238.71.105 (talk) 18:46, 7 May 2023 (UTC)

obvious error from in ... grammar 😅 good times 71.238.71.105 (talk) 18:49, 7 May 2023 (UTC)

Hello, and thank you so much for taking the time to include the Growth team in this conversation!

I'm sorry to hear that the copy edit task is leading to frustration. Can you point me to where the original conversation about this started?

I see more people are adding thoughts to this "Copy editing is not always easy" thread, so I’ll respond over there.  Thanks! KStoller-WMF (talk) 22:41, 8 May 2023 (UTC)

Help with translation

https://translatewiki.net/w/i.php?title=MediaWiki:Growthexperiments-homepage-suggestededits-difficulty-filters-intro/en: Suggested edits are designed to help you learn to edit and become more skilled as you work on larger types of edits.

What do you mean by "larger types of edits"? Iniquity (talk) 14:34, 1 June 2023 (UTC)

@Iniquity, thanks for asking! Hmmm, perhaps that's slightly awkward language. By "larger types of edits" we really mean "more difficult kinds of edits" or "more complex editing tasks".

The idea being we encourage new editors to make very small edits (fix spelling, add a link, etc.) but eventually we hope editors level up to make larger and more complex edits. But perhaps we should adjust that language? KStoller-WMF (talk) 21:41, 2 June 2023 (UTC)

Thank you! I thought so :) Perhaps this is some kind of local turnover, but I would replace "larger" with "more difficult". Iniquity (talk) 12:02, 3 June 2023 (UTC)

categorise pages to match the topics preferred by the editor

"We want to have an algorithm that says what the topic is of each article, and use that to filter the articles that have maintenance templates."

question: why dont we use the page category ? At page creation the editor sets himself the category for example "french cuisine" so you dont need to sort. Of course (sub) categories should be ordered like with a kind of heritage. I know then that a Xmas pudding has nothing common with a viola, And the topic (thèmes) proposed can be selected at different levels of precision using the category value : cuisine, music... english cuisine, french cuisine... desserts, instruments,,,, --Christian 🇫🇷 FR ⛹🏽 Paris 2024🗼 (talk) 15:30, 11 August 2024 (UTC)

banner End of translations

Banner "The sections below may be changed...," pretend to stop the translations but messages are translated below. So either remove the banner and translate all, or push it at the end of last pseudo complete paragraph to keep coherence. --Christian 🇫🇷 FR ⛹🏽 Paris 2024🗼 (talk) 17:11, 11 August 2024 (UTC)

I've removed the banner, thanks for pointing this out. KStoller-WMF (talk) 22:22, 12 August 2024 (UTC)

ok translations in progress with time. --Christian 🇫🇷 FR 🚲 Paris 2024🗼 (talk) 09:26, 24 August 2024 (UTC)

Unintentional disruption by newcomers at newly released articles

This is the second time I am getting slammed by new editors editing at a newly released article moved from draft space, where it is rapidly discovered and then hit many times, *always* in the lead section, where newcomers should rarely, if ever set foot, and almost always detrimental to the article, through no fault of their own, violating various guidelines as they add pointless or incorrect links to the lead of an article. In the meantime, I have various articles and other drafts and templates and requests pending, none of which I have gotten to, because 100% of my time is now fighting fires at one article. This is disruptive, halts my editing, and doesn't help new editors, either. If I had only one or two or three such edits, I would leave longer edit summaries and stop by their UTP to provide additional guidance, but at this point, I just have time to stick my finger in the hole in the dike and stop the hemorrhaging.

Please do something about this. At a minimum, set up throttling, and limit newcomer tasks per article. There are 6.9 million of them, please don't send all the new editors to one article I am trying to maintain. Secondly, please do not send any newcomers to fix or add links that are not needed per the guideline, improperly formed, or piped when they should not be. Thanks, Mathglot (talk) 02:31, 3 October 2024 (UTC)

You can use w:Template:No newcomer task to disable newcomer tasks on a specific article. This of course doesn't excuse the system's behavior, merely works around it. * Pppery * _{it has begun} 05:26, 3 October 2024 (UTC)

@Mathglot Thanks for reporting this, and sorry to hear that this is happening!

My guess is that this is likely happening because English Wikipedia generally only has a few articles with templates that match the "Add links between articles" task, and so many newcomers get funneled into only a few articles. Looking right now, it appears that English Wikipedia only has 1 task suggested for that "Add links between articles" task: Special:NewcomerTasksInfo

There are several options that are available right away:

• As Pppery suggests, an immediate fix is to use w:Template:No newcomer task to disable newcomer tasks on a specific article.
• Remove maintenance templates from articles that are associated with the Newcomer task if they are no longer relevant. You can find the templates used to surface Suggested Edits here: Special:CommunityConfiguration/GrowthSuggestedEdits
• Add `Underlinked` or `Dead end` templates to articles when it makes sense so there are more articles in the "Add links between articles" task queue.
• Admins can enable the "Add a link (Structured task)" at any time, and this Structured task will replace the current "Add links between articles" open-ended task. This should ensure there are thousands of "easy" Newcomer tasks available, so newcomers aren't being directed to a limited number of articles. This should entirely fix the issue, and is also likely to help more new account holders start editing: Add a link/Experiment analysis.

And there are changes the Growth team can consider to help improve Suggested Edits to prevent scenarios like the one you mentioned:

• I created this task: Suggested Edits: Decide how to avoid scenarios where one article receives excessive #Newcomer Task attention (T364350). The Growth team discussed this task recently, and there are many different ways we could approach this. Perhaps the simplest is to avoid displaying a certain task type if there are less than a certain number of suggestions in the task pool. Does that seem like an adequate solution? Let me know if you have any feedback on how we should approach this problem. Thanks! KStoller-WMF (talk) 21:27, 3 October 2024 (UTC)

Thank you, everyone for this great support. I was going out of my head, as this has continued and I am floundering, and was going to comment again, but these replies have saved the day. The no-newcomer-tasks will let me breathe again, and Kstoller's phab and ideas may lead to improvements down the road; I hope so.

I'll use the no-newcomers template (thank you for that) but I have to say that goes against the grain for me, as I am a big booster of new users: I help them out, I start off their UTP with a welcome message, I have created or updated a bunch of welcome templates at en:WP:WT, and it hurts to turn newcomers away, and is the opposite of what I want to do. But I just feel I have no choice in this situation. It's hogtying me, and setting my teeth on edge, and it means I have less time to help each individual newcomer, because it is just a flood of them and I have no time.

As an additional remark for Kstoller (besides thanks for that), is that in this case, afaict almost all of the myriad edits made since release are all to the lead. It is commonplace that new editors head straight for the lead, often the first sentence. New editors are new editors, so they are not going to know all the MOS guidelines about links, or about making edits to the body first and not the lead, but anything that could be done (in addition to throttling) to maybe pop up a "Linking Do's and Dont's" (if the newcomer tasks is "Add links", and analogously for other tasks) would be a help. Maybe a newcomer-task Edit notice? When things calm down, maybe I could even help think what it should say, and how it could be formatted, or some other means of conveying to the new user after telling them to add links, what links are beneficial and what ones are not. (Keep in mind as a future goal for this, that AI-assistance would probably work very well here. I have no doubt that Chat GPT is already at the level where it could digest several paragraphs of article content as well as our Links guideline, and suggest what terms should be linked, albeit not which ones would end up red, but imho that does not matter.)

Again, thanks for the support, and ping me here or at en-wiki if you want assistance with more ideas about this. Mathglot (talk) 03:21, 4 October 2024 (UTC)

@Mathglot, thank you for your feedback and your appreciation.

Do you have a few diffs to share of newcomers adding links where they shouldn't, so that we can document the case?

Bouncing on what Kstoller said, preventing newcomers from adding links to the lead section is not possible with the current add-links task at English Wikipedia. The only way is to change the instructions for that open-ended task, but instructions aren't always read.

All issues caused by add a link current state at English Wikipedia (including this one) will be fixed with Suggested links and its step-by-step process, which is based on machine suggestions. It is the process you describe in your last message.

And if you want to help more newcomers, I really encourage you to join mentorship! :)

Thank you again. Trizek_(WMF) (talk) 14:47, 4 October 2024 (UTC)