Wikipedia talk:Growth Team features

Should English Wikipedia enable the Suggested Links newcomer task?

According to the thread just above, the new algorithm based links task will be available and disabled on English Wikipedia in one week. (The current task is template based).

The default rate limit for links added in this way is 25 per editor per day, and three per article per day.

Should we enable this feature? Should we modify the defaults?

Any editor feel free to refactor this, add subheadings / RFC tags if you feel it necessary. I'm just tryna start a conversation to check in on consensus. Folly Mox (talk) 17:57, 15 May 2024 (UTC)

Thanks, @Folly Mox for starting this discussion and @Sdkb for making sure we opened up this discussion to a wider audience!

I just wanted to give you an update and let you know that we have the backend prepared to release the Suggested Links newcomer task.  You will now see two "Add links between articles" tasks in Special:EditGrowthConfig. The one with the 🤖 robot icon is the new "Suggested links" task. However, the task has a "Disabled in site configuration" notice next to the task. This is the first time we are releasing this task in this manner (making the task available but not enabling the feature ourselves).  We ran into some unexpected technical complexities with this approach (T308144#9811861). I think we have two options for how to proceed:

1. The Growth team can enable the task at any time on the server side. Just let me know if you think consensus is reached and we are happy to enable the task.  (We can also disable the task if requested).
2. Or, we can wait until the new version of Community Configuration is released (likely by July 2024), and at that point we can ensure the configuration form is working as intended so any English Wikipedia admin can enable or disable the task.

Sorry for the additional complexity, this release is coming at an odd time as the Growth team is also working to finish up the new CommunityConfiguration Extension. KStoller-WMF (talk) 17:41, 23 May 2024 (UTC)

Sorry for the delay! The new Community Configuration extension is released, and the "Add a link (Structured task)" is now set up so that any English Wikipedia admin can enable it here: Special:CommunityConfiguration/GrowthSuggestedEdits. In other words, the Growth team released the task as "turned off" T370802, and editors will NOT have access to the task until an English Wikipedia admin enables the task.

As @Folly Mox suggests, defaults can also be adjusted. For example, setting the "The maximum number of "Add a link" suggested tasks a newcomer can complete daily" to a lower number might be appreciated by patrollers. Or increasing the "Minimum required link score" should improve the quality of suggestions, but will decrease the number of tasks available.

Let me know if there is anything I can do to help. I could write a Signpost article to share more details so there is more awareness about the task before it's enabled? Or are there any remaining questions I can help answer? KStoller-WMF (talk) 23:10, 6 August 2024 (UTC)

If we need more input or want to adjust some defaults before an admin decides about flipping the switch is it time for those RfC tags @Folly Mox? Perfect4th (talk) 04:11, 7 August 2024 (UTC)

@KStoller-WMF, discussion on this kind of fizzled out, but it looks like no one opposes the idea of trying it, but that we're really hesitant about turning it on for all new users at once. I had a look at the community configuration page, and I only see an option to enable it outright. Is there any way to restrict the number of new accounts that get this feature? Or, if we want to limit the effect in some way as a test, are we stuck with simply reducing the suggestions to, say, 2 per day? -- asilvering (talk) 16:23, 18 October 2024 (UTC)

@Asilvering Thank you for following up! I completely understand your hesitation.

Currently, we don't offer a Community Configurable option to release the task to a limited percentage of users. This is mainly because it's important for all new account holders to have access to the same tools, as variations can create confusion for both newcomers and the experienced editors who support them.

That said, I can see the value in a phased rollout, especially to give experienced editors time to assess the impact and adjust to these new types of edits.

While Community Configuration doesn't accommodate this kind of gradual release, we can likely handle it on the engineering side. I've created a task for this:

T377631 Add a link (Structured task): Release to a subset of newcomers on English Wikipedia

I'll discuss the task with Growth team engineers and provide updates here before any changes are made. In the meantime, feel free to share your thoughts on what percentage of users you think would be ideal for the rollout! Thanks! -- KStoller-WMF (talk) 21:22, 18 October 2024 (UTC)

@Asilvering Growth engineers have reviewed and provided detailed feedback on the task (T377631#10246419). Here's a summary:

• Releasing the "Add a link" structured task to a limited percentage of newcomers will require some effort from the Growth team engineers, but it appears feasible.
• The task would be released as an experiment, initially available only to newly created accounts.
• Community Configuration will not display the percentage of accounts included in the rollout. Instead, it will simply indicate that the task is enabled, with Admins retaining the ability to disable it.

Additional considerations:

• We may want to pause the rollout in late November and resume in January to avoid potential frustration during a busy time of year.
• Our long-term goal is to release the task to 100% of newly created accounts. We cannot continue indefinitely with a partial rollout, as it would affect the newcomer experience and prevent the Growth team from launching any other experiment on enwiki.
• There seems to be general agreement that a 2% release is a safe starting point, and I’ve updated the task to reflect that (T377631).

I’ll provide an update once the experiment setup timeline is confirmed. KStoller-WMF (talk) 21:46, 21 October 2024 (UTC)

Great, thank you! For clarification on the "cannot continue indefinitely with a partial rollout", if it's turned off by an admin on the en-wiki side while it's still not yet at 100%, that won't prevent you from launching any other experiments, correct? You just don't want it turned on indefinitely for only a subset of users, since that would bias your other tests in ways you couldn't easily de-bias? -- asilvering (talk) 22:01, 21 October 2024 (UTC)

Even if the task is disabled, the Growth team would still need to fully "decommission" the experiment before launching a new one. This is because the GrowthExperiments code currently doesn’t support running multiple experiments simultaneously on the same wiki. So, if an admin disables the task on enwiki with no plans to re-enable it, we would likely decommission the experiment eventually to avoid any blocking issues with future releases or experiments.

Additional context: The Growth team developed this experimentation code within the GrowthExperiments extension, but we're aiming to transition to the Metrics Platform over time. The Metrics Platform is expected to provide much more advanced experimentation functionality than what we're able to support on our own right now. KStoller-WMF (talk) 22:34, 21 October 2024 (UTC)

If it's possible to get this started soon, then I'd rather have it turned on at 2% for the rest of the calendar year than to have it available for 0% until next year. Since this is being limited to newly created accounts, most of which only ever edit on a single day, if it were possible to start the 2% this week (and maybe even bump it up to 10% two weeks from now), I would prefer that over doing nothing at all for the next 2.5 months. WhatamIdoing (talk) 22:49, 21 October 2024 (UTC)

I don't think we can get it released this week, but I agree it would be better to release to a small percentage ASAP than to wait. KStoller-WMF (talk) 00:13, 22 October 2024 (UTC)

Notified: WP:VPR. Sdkb ^talk 21:14, 16 May 2024 (UTC)

In general, this looks like a useful feature. The setting is, I believe, the number of link suggestions per article and the number of articles per day. In my experience, more links per article, and fewer articles per day works better: 9×4 seems just fine. What I don't like about the feature is that it does not seem to be learning anything from our feedback. If you tell it not to wikilink month names, it will still wikilink month names. If, say, "Italy, Germany, Poland, and Greece" is somewhere in the text, it will offer to wikilink Poland, but not the other three; manual link addition is not possible in this mode. Can WMF work on these and other issues, or is this their final product - that I don't know. Ponor (talk) 02:49, 17 May 2024 (UTC)

In the thread just above, Trizek describes the "25" value as the number of edits each newcomer can make daily. The parameter at de:Spezial:EditGrowthConfig certainly google translates to "maximum number of link suggestions to display for each suggested task".

As to linking month names, country names, etc., I brought this up last year at Wikipedia talk:Growth Team features/Archive 7 § Usefulness of "Add links" task? A few threads later, Trizek confirmed we aren't using any sort of rejection links lists.

Anyway there doesn't seem to be much engagement with this topic, so for the purpose of establishing consensus, I'll say Sure, let's turn it on and give it a go. It seems like it should be easy enough to turn it back off if the newcomer links become too high maintenance. Folly Mox (talk) 18:46, 18 May 2024 (UTC)

Agreed. I think they misunderstood the setting, they're allowing 25 tasks, 3 links each: https://de.wikipedia.org/wiki/Spezial:EditGrowthConfig?uselang=en Ponor (talk) 13:12, 21 May 2024 (UTC)

The task is not enabled at de.wp. :)

These numbers (25 tasks, 3 links per task) are the default settings we suggest. Most big wikis kept them, except Russian (5 tasks, 3 links per task). Trizek_(WMF) (talk) 15:04, 21 May 2024 (UTC)

Also not opposed to enabling, presumably it will have a tracking tag or consistent edit summary? fr.wiki stats show decent takeup, although as on en.wiki that page does not have ways to see individual examples. CMD (talk) 02:09, 22 May 2024 (UTC)

Good question, @Chipmunkdavis. Yes, these edits are all tagged. Here's an example edit summary and associated tags:

(Link suggestions feature: 2 links added.) (Tags: Visual edit, Newcomer task, Suggested: add links)

You can view example edits on French Wikipedia via this filtered Recent Changes view.

Special:NewcomerTasksInfo will show you task availability, if you want to review metrics on task click through rates, completion, and revert rates, we have a Growth KPIs dashboard here. KStoller-WMF (talk) 19:26, 22 May 2024 (UTC)

I'm speaking from a good deal of ignorance about how this will work, but as an old-hand editor, I do think particular aspects should be monitored, such as reverts to these link edits and how much this will pile up in editors' watchlists (i.e., I have no idea as to how much of these are going to pop up in my watchlist to have to review), and such. I like the idea of experimenting with this, but I also hope this will not be so hardened that we can't possibly ever decide to stop it. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 20:44, 25 May 2024 (UTC)

@StefenTower, we are here to answer your questions. :)

It is possible to monitor the reverted links, using Recent Changes or Watchlist, as both links addition and reverts are tagged. See for French Wikipedia, where I filtered all Add a link edits, with reverted edits highlighted in red. As I post this message, I see 2 reverted edits for 500 links addition. It looks like what I observe on average, at any major Wikipedia. Would it be the same at English Wikipedia? Honestly, I don't know.

Reverted edits are not the only point to consider. Let's imagine an article where three links were added, where one link is not okay. Some users will revert the full edit, or leave it like this. Being myself active at French Wikipedia as a volunteer, I use Diffedit to quickly fix these links.

Also, my watchlist is not really flooded by these links addition. I just checked my watchlist, and I only see three articles edited to add links over the last 500 edits at articles I monitor. ut again, I can't transpose it to English Wikipedia.

We're offering your community the chance to activate the functionality, literally: once you've decided to do so, an admin will be able to turn Add a link on. And the reverse is true: it will be possible to deactivate the feature in the same way. If the prefered option is a test, the Growth team will have to take care of setting it up.

Trizek_(WMF) (talk) 17:04, 27 May 2024 (UTC)

Edit revert rate is something we monitor for all tasks, and in a previous A/B test, we found that the revert rate for newcomers who get Add a Link is 11% lower than the baseline.

Another option is that the daily task limit can be configured to be lower. The default is currently 25, which means any new account holder that has access to the task can complete up to 25 "add a link" tasks per day. Any English Wikipedia admin can update to a lower number via Special:EditGrowthConfig.

But also I just wanted to chime in and second what @Trizek (WMF) mentioned: English Wikipedia is welcome to enable the task and see how it goes. If the task is too disruptive to patrollers and experienced editors, it can be turned off. KStoller-WMF (talk) 17:20, 27 May 2024 (UTC)

Thanks both for your replies. I'm glad this can be adjusted if it gets out of hand. I don't think editors would want their watchlists filling up with a lot more to review. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 21:03, 6 June 2024 (UTC)

• I'm in favor of giving it a go, if any problems arise they can be discussed. Hoping this helps newbies acclimate to Wikipedia! —Ganesha811 (talk) 13:07, 2 June 2024 (UTC)
• +1 I apparently neglected to post my comment any one of the 3+ times I typed it up, but I think we should try it. We can always turn it off again if it causes problems. Happy editing, Perfect4th (talk) 20:47, 2 July 2024 (UTC)

@SebastianHelm: I've just noticed that last November at Wikipedia talk:Manual of Style/Linking § MOS:OVERLINK: Absolute or relative level? you asked me to ping you when there is anything new about algorithmic attempts to determine appropriate internal link density in articles. What's new is that the algorithmic links newcomer task is pretty much ready for activation at en.wp, and only a handful of people seem to care so far.

I have no idea if this is what you meant in your comment or whether you currently care about this, and rather unfortunately I couldn't think of any method of notifying you that wouldn't be considered canvassing, so I figured maximum transparency would be straight canvassing you to the discussion itself. Avoiding work, Folly Mox (talk) 12:44, 30 June 2024 (UTC)

• Enable the feature This sounds really wonderful and has been used on several other language editions of Wikipedia already. I am curious what percentage of linking will either get slightly modified to more specific targets, outright reverted versus "good links", i.e link is retained (particularly on articles where other edits continue). ~ 🦝 Shushugah (he/him • talk) 14:37, 25 July 2024 (UTC)
• I'd like to see this happen. I was manually adding articles to the Category:Articles with too few wikilinks a while ago, and I found that most new editors did a good job, and few of them added more than a couple of links. (The instructions say to only add a small number, and most folks stick to that.) Sometimes I saw the same editors over and over, but mostly it was new folks each day. I remember seeing some impressively specific and precise links getting added, for articles on niche subjects that I'd never have expected us to have an article for.
  I'd also like to see this happen gradually. Maybe only a small percentage gets access for the first few weeks, and the number ramps up slowly from there? Or maybe the per-editor daily limit is reduced (3 links x 5 articles?), so that people can get feedback on their link choices before handling too many articles? WhatamIdoing (talk) 02:19, 31 July 2024 (UTC)

  It is possible to have Add a link for a limited number of users. The Growth team can set it up. Regarding a per-editor limit, the community can set it up anytime in Special:CommunityConfiguration/GrowthSuggestedEdits.

  Speaking of community configuration, we will soon provide the possibility for your community to turn Add a link on. It should be made possible next week. Trizek_(WMF) (talk) 15:40, 31 July 2024 (UTC)

  I think that limiting the number of users at the start would be valuable because it will change the mix of edits in the RecentChanges queue. The English Wikipedia is so big that we get about 50 new editors making their first edit each hour. If we suddenly have 10 extra edits adding links every hour, then patrollers/watchlist users will be surprised by a sudden shift in edit content. I think a gradual introduction will help community on the reviewing end (e.g., who may need time to have conversations about how most first edits are suboptimal, and adding a superfluous link is less destructive than most other mistakes that newbies make). I don't think it will make any direct difference to the individuals making these edits. WhatamIdoing (talk) 16:08, 31 July 2024 (UTC)

  True. Newcomer with no Suggested links shave other tasks to work on. If the community prefers to start with XX% of new accounts getting Add a link, we can implement it. Trizek_(WMF) (talk) 17:24, 31 July 2024 (UTC)

  I have a technical question: at Special:CommunityConfiguration there is a list of section names to exclude from consideration for this task, including examples such as "References" and "See also". If we added "0" to this list, would the lead paragraph be excluded from analysis? (A separate question is whether this is a good idea: most articles seem to display the richest link density in the lead, but many very short articles have no subsections, so excluding section "0" [if even possible] would skip them entirely.) Folly Mox (talk) 11:13, 9 September 2024 (UTC)

  The lead paragraph is not excluded, for the reasons you give. The higher the density of links in an article, the lesser links are suggested.

  Should we explore an option to exclude the lead paragraph? Trizek_(WMF) (talk) 14:21, 9 September 2024 (UTC)

  "Section 0" would be the entire lead section, rather than the just the first paragraph. WhatamIdoing (talk) 16:58, 9 September 2024 (UTC)

  Whatever above the first section header. I used the wrong term for section 0; this happen when you cover multiple wikis, languages and cultures! :D Trizek_(WMF) (talk) 12:08, 10 September 2024 (UTC)

What number of users should be involved in the trial

Okay, we seem in agreement that we should give this a try, with some trepidation about how it might cause significant, unforeseen issues. Limiting the number of users who have access to this feature looks to me like a good idea. So, what number of users should we be limiting this to? And how long a trial do we think is good to have before we increase that limit? My inclination would be to start very, very small, but soon after that ramp up to a larger number that is still a small proportion of the overall number of new users. Thoughts? -- asilvering (talk) 18:23, 9 September 2024 (UTC)

Looks like the first mentorship run was 2% of new accounts. I'd be fine with that (or really any number that gets this going). Maybe a two-week period and then check in? 2% for two weeks, and if everything goes okay go to 5% or something? We could notify the CVU talk/Village Pump/somewhere with recent changes patrollers that the trial is beginning if anyone feels that would help. Happy editing, Perfect4th (talk) 19:18, 9 September 2024 (UTC)

It always helps, because if you will let me indulge in cynicism for a moment, a very typical Wikipedian response to change is to complain that "there's no consensus", and that often begins with claiming "nobody knew about it". I have actually seen this claimed for decisions that were made in CENT-listed RFCs, for things that I personally announced on over 100 pages, in addition to announcements made by others, and even by editors who participated in the discussions that they are now alleging never happened. Some of this is simple forgetfulness (so much happens that we can't remember it all) or because someone really did get missed (we once ran site banners for two solid weeks about something, and the banners happened to coincide perfectly with one editor's two-week summer holiday), but some editors can be convinced by the diffs, so it's well to have them. WhatamIdoing (talk) 19:34, 9 September 2024 (UTC)

Definitely a good idea to tell WT:CVU and WT:TEA about this when it starts. Anywhere else spring to mind as a high-traffic area for recent changes patrollers and so on? -- asilvering (talk) 23:03, 18 October 2024 (UTC)

If you want to start very small, consider a very small percentage of users for the first week/fortnight, and double regularly. you don't want to get stuck limiting it to a tiny percentage for months/years. If there are structural problems (e.g., it selects articles that have a lot of links, but it doesn't notice the links because they're inside templates or tables), then we should discover those problems within the first several thousand edits.

The trickier bit is giving the reviewers time to adjust mentally. The unavoidable fact is that new editors make mistakes. They might make fewer mistakes in this system, but fewer is not none. It's not even almost none. Increasing the number of new editors may ensure Wikipedia's survival in the long term, but right now, new editors == more well-intended but imperfect edits.

If you do RecentChanges patrol a lot, then you develop a feel for what's "normal", and you notice deviations from what you expect. Like: So many people editing about India today. Weird that I've seen this same website several times today – a spam campaign, or just a coincidence? Ugh, I can't wait until that election's over, so this political stuff will let up. If it looks like everyone is "suddenly" adding "a lot of" links, then you'll notice the deviation from normal, and that will subconsciously make you think that there is something suspicious or abnormal about adding links. If we flipped this on for 100%, we could predict now that several patrollers would complain that "too many" newbies are adding "too many" links in "too many" articles. This wouldn't be proof that there are violations of Wikipedia:Manual of Style/Linking (the typical FA has hundreds of links in it), but it would be evidence that the patrollers had noticed a shift in the editing patterns.

A fact that you might want to store in your back pocket, for responding to those inevitable complaints, is that if you divide Wikipedia's non-list articles into "shorter" and "longer" halves, the shorter articles (=stubs and near-stubs) average about two links per sentence, and the longer articles average somewhere around two links per three sentences.

Also, some editors prefer very sparse links in articles, and from their POV, moving from their preferred state towards a purely average level of linking makes the articles worse. We should not be surprised by complaints about this. WhatamIdoing (talk) 19:26, 9 September 2024 (UTC)

Okay, we've got a request for a number up there. If the devs want a rollout plan from us soon, what's the starting number?

I see 2% mentioned above. How do you feel about 2% for two weeks, and then (assuming no serious problems) raise it to 10%, and then steadily upwards by 10 percentage points each time until we reach 100%?

10% every week means it will take three months to roll this out (assuming it's not paused or reverted for any reason). 10% every fortnight will take six months. Is that too fast? Too slow? WhatamIdoing (talk) 02:28, 19 October 2024 (UTC)

2% sounds good to me, and no one has opposed it. As for the speed of the rollout, since I think you're quite right about patrollers, it's probably better to go a bit slower at the start - maybe by doubling (2% to 4% to 8% to 16% to 32%) rather than 2% to 10% and 10% per jump thereafter (which would get us to roughly the same place, 40%, in the same timeframe). I think this will freak people out less if it happens that there are significant changes. By 32% we ought to have a decent idea about what kinds of problems this creates (or doesn't). I expect we might want to pause there and take stock, but if everything seems ok at 32%, we're probably clear to double and then go to 100%, since if the problem is in volume alone, it's easy enough to choke that off at the source by tinkering with the default 25/3 numbers. -- asilvering (talk) 02:50, 19 October 2024 (UTC)

Thanks for the feedback and thinking this through! There seems to be general agreement that a 2% release is a safe starting point; I’ve updated the related task to reflect that (T377631). KStoller-WMF (talk) 21:48, 21 October 2024 (UTC)

Hi all, I wanted to share an update on our progress toward a 2% release. We’re currently focused on testing the new experiment (2% deployment) setup on test wiki:

- T380161 Verify Add Link's readiness for partial deployment

Once QA testing is complete, we’ll proceed with the 2% release (targeting only newly created accounts). I’ll provide a suggested release date here before we move forward. In the meantime, please feel free to share any questions or concerns. Thank you! - KStoller-WMF (talk) 00:31, 19 November 2024 (UTC)

Refining copy-editing newcomer tasks

I have been thinking off an on about how newcomer tasks can best set newbies up for success. A while ago I posted some thoughts at the MediaWiki discussion zone and they suggested talking here for enwiki consensus. So I'd like to pose two suggestions that I think are just a matter of how the tool is configured, to see what others think:

1. Should Template:Tone be removed from the copyediting task list? In my experience, something gets tagged with "tone" (instead of something more specific) when an experienced editor looks at a huge mess, says "yikes", and walks away. Even when the problem is a prose problem (as opposed to a more complex research problem), newbies are often still in the early stages of unlearning essaylike prose styles, and may find encyclopedic tone more challenging than the promised "copy-editing".

1A. I could be convinced that Template:Peacock and Template:Advert are also prone to flagging, 1, articles with research problems and, 2, articles with prose style problems that fall outside of simple copyediting or many newcomers' starting skills.

2. Can tasks be filtered so that newcomers are not shown articles tagged with Template:Notability? These articles also looked deeply flawed to an experienced editor but not in a way where they could fix it easily; they may offer a very poor model of what a wiki article 'should' look like; and they may lead to a dispiriting wasted effort on the newbies' part if the article is later deleted.

In both cases, I'm hoping to avoid sending newbies to complicated, messy articles and telling them they just need the quick "easy task" of copy editing. ~ L 🌸 (talk) 00:21, 9 September 2024 (UTC)

Hah, apparently I did raise some of this here in July (sorry for my patchy memory) but thanks to Pppery's intervention then, I am posing new suggestions this time! I'd love to hear folks' thoughts. ~ L 🌸 (talk) 00:34, 9 September 2024 (UTC)

The "copyediting tasks actually really difficult and dispiriting" problem has come up repeatedly over the past few years (here is me wondering who will bring it up in 2024 - guess that's you). We've had professional writers call them overwhelming. So I'm just... going to go ahead and use these fancy new tools I just got and remove "tone" and "advert". "Peacock" I suspect might be a bit more useful, so I hesitate over that one.

Filtering out articles tagged for notability sounds like a good idea. I have no idea how much this would reduce the pool of tasks - maybe not much? But it doesn't seem likely to me to be harmful. -- asilvering (talk) 00:55, 9 September 2024 (UTC)

I can see the argument that "peacock" works as a newbie copy-editing task, since it's more focused on sentence edits and the problem is explained more concretely. Thanks for removing tone and advert!! ~ L 🌸 (talk) 01:16, 9 September 2024 (UTC)

Finally! Thanks, asilvering, for doing that! Would it perhaps be worth it to request a query of how many articles are both newcomer copyediting eligible and tagged for notability just to check? Happy editing, Perfect4th (talk) 03:07, 9 September 2024 (UTC)

I thought we had already got rid of {{Tone}} last year, but I suppose my memory has failed me again. Thanks asilvering for taking care of that.

A naive and basic search for hastemplate:Notability and hastemplate:"Multiple issues" returns ~30k articles, down from ~58k for {{Notability}} alone, and of course not all {{Multiple issues}} will be in the subset that include an article in the copyedit task. It should be possible to compose a search for the exact quantity without querying the database, but I just woke up so won't attempt.

The root problem, as I continue to see it same as last year, is that the issues that established Wikipedia editors tend to tag with maintenance templates rather than simply solve on sight are typically not easy, and not a good introduction for low editcount junior contributors.

It doesn't particularly help that the minimalist instructions in the Suggested Edits flow still don't include guidance to click through the maintenance template to understand the problem tagged and what a solution might look like, so most people seem to tend towards doing mild copyediting of the lead paragraph, which ends up roughly evenly balanced between not a substantial improvement and a clear disimprovement, with some outliers (although I haven't RCPed for the Newcomer task: copyedit tag for many months now, so my impressions may be outdated like my body and car). Folly Mox (talk) 09:52, 9 September 2024 (UTC)

Yes, that root problem you identify is why I have reasonably high hopes for the structured tasks. We can enable Find A Link now, we just haven't yet. I'll go give that discussion a kick. -- asilvering (talk) 18:20, 9 September 2024 (UTC)

Sorry if this is an aside, but how did this edit come through? There are not tags on the affected text, and I can't find copyedit-related tags elsewhere. CMD (talk) 14:12, 9 September 2024 (UTC)

It's the "needs citations for verification" one. I have no idea why it's tagged with "copy edit" though - should be "references" surely. Hopefully someone from WMF can clarify. -- asilvering (talk) 18:10, 9 September 2024 (UTC)

@Trizek (WMF), is there any chance you can explain this one? -- asilvering (talk) 20:37, 9 September 2024 (UTC)

There is one {{verify spelling}} in the "Current political issues" section. :) I almost missed it! Trizek_(WMF) (talk) 13:07, 10 September 2024 (UTC)

Thanks. I wonder what brought the editing so far from the tag. CMD (talk) 13:36, 10 September 2024 (UTC)

The Suggested Edits flow IIRC (maybe only if you click through the five help snippets) has an animated focus effect on the "edit lead" pencil. There's nothing in the included guidance that suggests editors find a specific maintenance tag (or indeed, click a maintenance tag), and initial article focus doesn't skip to any maintenance tag that may have included the article in the task pool. So almost all copyedit task edits tend to affect the lead, and many exclusively. Folly Mox (talk) 14:11, 10 September 2024 (UTC)

We tag the edit according to the task type the user selected. But as these tasks open the full editor, the user can do what is asked and more. We expect use Edit check at some point to narrow down the focus of the task. Trizek_(WMF) (talk) 15:29, 10 September 2024 (UTC)

Since it was so hard for us to find it, they probably had trouble finding it too, haha. -- asilvering (talk) 17:11, 10 September 2024 (UTC)

Aha! My mistake. -- asilvering (talk) 15:17, 10 September 2024 (UTC)

No worries asilvering, it was a good challenge! :D Trizek_(WMF) (talk) 15:27, 10 September 2024 (UTC)

If a question is asked and nobody is around to answer it, was the question ever asked in the first place?

From general browsing I saw that Ritchie333 had some mentee questions that had stalled for about 3-6 days, so I stepped in to answer them to make sure they weren't left unresolved for too long. One mentee, Gazingo is doing some particularly great history work and asking great questions :)

This is not Ritchie's fault of course, as life can be busy in a second. I got so bad at answering questions in a timely manner that I had to turn them off for example. Do we have a system (or should one be made), where a second backup user is notified of absent responses? I'm not sure what a solution to that would like otherwise, but I think it's important for us to consider these questions getting answered to the earliest convenience for the mentee's sake for the sake of encouragement. The Teahouse is quick to answer usually, so maybe an automated suggestion to ask there if the question stalls could work too? Panini! • 🥪 07:13, 29 September 2024 (UTC)

This relates to phab:T321509, and has precedent at Wikipedia talk:Growth Team features/Archive 7 § Marking inactive editors/mentors as 'Away' and Wikipedia talk:Growth Team features/Mentor list § Marking a mentor as "away".

I think a pretty good solution might be a bot report, since that could highlight unanswered mentee questions sooner than we would ever want to mark a mentor as "away". We could have a bot that ingested the current active mentor list each day, then scanned their talkpages every twenty minutes or so for threads that meet all of the following criteria: title matches "Question from username (full timestamp)", one person in the conversation, initial timestamp at least k hours in the past (for some value k— 12? 24? 6?). Then the bot could update a report that people could subscribe to if they're interested in answering questions posed to busy / inactive mentors. (Or it could post to Wikipedia talk:Teahouse??)

It sounds pretty simple (although not so simple I could code it properly). WP:BOTR might be a next step here. Folly Mox (talk) 17:27, 29 September 2024 (UTC)

Like the idea behind this. * Pppery * _{it has begun...} 17:41, 29 September 2024 (UTC)

Have we defined what a timely manner for answering questions is? Obviously we can’t expect individual mentors to answer as quickly as the Teahouse, but should we want mentors to be active every day for questions (and does that disqualify those who aren’t)? I’ve only seen inactivity quantified at the away setting of the mentorship dashboard, which defines it as ‘more than a week’. Do mentors know the time expectation for answers? And yes, I say this knowing I’ve been bad about this recently.

Also, +1 to liking the bot report idea. Happy editing, Perfect4th (talk) 17:51, 29 September 2024 (UTC)

Disconnect between "goals and culture" on tasks, particularly underlinking

I'm somewhat a new user who still is hitting a wall somewhat on how to contribute, particularly being regarded/accused of being a tag bomber, which is rather confusing to me for the goal of this project/feature. Particularly looking at the stat page for tasks, underlinked tags seem to be chronically empty, this is somewhat due to it being a rather easy task to resolve, but in my personal experience, it just seems that some editors and admins seem to consider it not kosher to use and are reverting that tag in particular on sight, apparently in an overcorrection of MOS:SEAOFBLUE and a belief that it brings unwelcomed edits.

In my time of basically "shepherding" pages I added maintenance tags, yes I saw instances of unconstructive edits but that I must think that would just come with the territory of putting dozens, if not hundreds of eyes on a new page, and short of limiting every page with an underlink template(and newcomer tasks in general) with edit review protections, that's unlikely to stop. But most of the edits I saw were constructive. Overall, I'm just wondering if the culture of Wikipedia is not conducive to adding maintenance tags that then can be addressed by newcomers, how successful this really can be in the long term, as it seems that there is a demand to resolve issues identified instead of pointing them out.

It's rather frustrating seeing this contradiction despite an earnest attempt to build an encyclopedia. Part of the issue seems to be the "scale" of tags added, but again, from my point of view, if there are no tasks for newcomers to dip their toes in, how is this feature expected to work due to editors systematically removing 1/5th of the tasks without resolving them, particularly if that 1/5th is one of the two easiest tasks? Akaibu (talk) 17:03, 17 October 2024 (UTC)

The Suggested Edits feature was designed with all Wikipedias in mind; English Wikipedia is always an outlier. It's true that our project suffers more from overlinking than from underlinking, and an attempt was made to enable the machine-learning links tasks above at § Should English Wikipedia enable the Suggested Links newcomer task?, which went nowhere.

It's also true that most of our maintenance templates are not typically applied to problems that can be resolved by newer editors. Some of the templates associated with Newcomer Tasks are indicative of experienced contributors having given up on fixing an article due to the commitment of time and effort such a fix would entail.

Personally I feel the "maintenance template model" for including an article in the Suggested Edits feature is fundamentally a poor fit for English Wikipedia, and we'd be better off just sending newcomers to random Stub– or Start-class articles, which are likely to have some sort of issue, whether specifically identified with maintenance templates or not. (I think last year I also suggested using {{unreferenced}} as the inclusion template for the copyedit task, since an unreferenced article usually hasn't seen much editing.)

But yeah, the disconnect between the kinds of problems maintenance templates indicate and the kinds of problems we can actually expect newcomers to be able to help out with— this has been discussed multiple times on this very talkpage.

As to the accusations of tag bombing, I can see both sides. It is genuinely helpful to identify problems, but that activity has to be diluted amidst more constructive contributions. Tagging dozens of articles a day without doing much to fix anything is mostly just annoying. And if your intent was mainly to get the articles thus tagged into the Suggested Edits pool, that's an argument for a different model for the feature.

I am in agreement with most everything said by the two admins in your talkpage thread. You've made plenty of edits identifying problems with articles. I'd kindly encourage you to spend some effort fixing problems with articles instead. (See also WP:SOFIXIT) Folly Mox (talk) 10:34, 18 October 2024 (UTC)

Oof, thanks for reminding me about Suggested Links. We don't have anyone disagreeing, so I'll try jump-starting that again. -- asilvering (talk) 16:19, 18 October 2024 (UTC)

@Akaibu, I understand your frustration, and I can't believe you were threatened with blocks for doing this. Have you considered joining WP:NPP or WP:AFC as a reviewer? It's much the same kind of work, high contact with new editors you can immediately start helping, and doesn't tend to set off alarm bells in uninvolved admins. -- asilvering (talk) 16:29, 18 October 2024 (UTC)

@Asilvering I was actually targeting roughly the first million articles created, which were created in 2006 and prior, which as you can imagine were absolutely not held to the same standards as today, and in fact was able to find at around a dozen articles that had been around for that long that I was able to successfully PROD(i don't see a way of linking to those PROD deletions, for probably rather obvious reasons of their nonexistences) . I'm aware of the existence of the Sweep Wikiproject which seems basically defunct at this point, but holds to a similar view as my own goals of basically addressing some of our oldest content, as the existence of at the very least the two major projects with over 1500, to me, shows that new pages much more vetted. Akaibu (talk) 03:40, 20 October 2024 (UTC)

You can enable a "PROD log" in your Twinkle preferences if you're interested in tracking those articles, by the way. -- asilvering (talk) 03:43, 20 October 2024 (UTC)

Growth News, October 2024

Current work

Newcomer Homepage Community Updates module

We will add a new module to the Newcomer Homepage that will allow communities to highlight specific events, projects, campaigns, and initiatives. We have released a simple version on beta wikis and we will soon start an A/B test on our pilot wikis. This module will only display on the Newcomer Homepage if communities decide to utilize it, so learn how to configure the Community Updates module, or share your thoughts on the project's talk page.

One design concept aimed to increase constructive activation

Constructive activation experimentation

After showcasing early design ideas at Wikimania, we conducted user testing of design prototypes. We now aim to engage communities in further discussions and plan to run a targeted experiment, presenting a structured task within the reading view to logged-in new account holders with zero edits.

Community Configuration

This Community Configuration extension was developed to help communities customize wiki features to meet their unique needs. The Growth team is now helping other Wikimedia Foundation teams make their products configurable:

• The Moderation Tools team now provides Community Configuration for Automoderator. (T365046)
• Certain Babel extension settings will be configurable soon. (T328171)

Future work

As part of the Growth team annual plan, we will continue to investigate ways to increase constructive activation on mobile, while also working with Data Products to move forward A/B testing functionality via the Metrics Platform.

Community events

• Growth team members presented Community Configuration: Shaping On-Wiki Functionality Together at Wikimania (slides). The session recording is available to watch on YouTube. This session provided an update on the Community Configuration project and introduced details about the upcoming features that communities will soon be able to configure. Representatives from the Moderator Tools, Editing, Web, and Campaigns teams shared their plans for utilizing Community Configuration in the future. Following these presentations, the WMF Growth team's Benoît Evellin and Martin Urbanec answered audience questions.
• Habib Mhenni gave a presentation of how mentorship works at WikiIndaba 2024. The recording is available.

Stay informed

Growth team weekly updates are available on wiki (in English) if you want to know more about our day-to-day work. If you want to receive more general updates about technical activity happening across the Wikimedia movement (including Growth work), we encourage you to subscribe to Tech News.

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

Trizek_(WMF), 15:43, 22 October 2024 (UTC)