The miscellaneous section of the village pump is used to post messages that do not fit into any other category. Please post on the policy, technical, or proposals sections when appropriate, or at the help desk for assistance. For general knowledge questions, please use the reference desk.
For questions about a wiki that is not the English Wikipedia, please post at m:Wikimedia Forum instead.
Discussions are automatically archived after remaining inactive for 8 days.
Latest comment: 3 days ago21 comments11 people in discussion
Hi all, I'm Nazneen, here for the Communications team at the Wikimedia Foundation. Back in May, we ran a pilot campaign encouraging mobile web readers to download the Wikipedia app, as part of the 25th anniversary work. Thank you to everyone who weighed in on that. I wanted to share how it went and what we're planning next.
In the pilot, there were around 701,000 app installs. That's a strong signal that there's real interest among Wikipedia readers to install the app once they know about it. This lines up with what the Apps team shared in April about why we think the apps could be important in the future: as more people find information through AI summaries instead of visiting Wikipedia directly, we want readers to make Wikipedia an important part of their knowledge diet. The apps are a place where readers can build their relationship with Wikipedia, receive push notifications, interact with a home screen – features that readers love that we can't give in a browser. The thing is (and we’ve seen this a lot in the comments on our social media posts) that when Wikipedia readers find out about our mobile apps, they are really excited – but they just don’t know about them.
Given that response to the campaign, we would like to keep this going. Rather than a single pilot, we're planning an ongoing, lower-key presence encouraging app downloads across the year ahead.
We'll begin with the same simple banner that performed best in May's pilot, so it's a continuation of what already worked, that can be adjusted based on performance and how readers respond. There may be a small number of short periods later in the year where it runs more intensively to test impact, but we'll flag it here if there's a meaningful change to the overall approach.
We know that some other platforms push their mobile apps so hard that it makes their mobile websites difficult to use. We definitely don’t want that – people should be able to happily get the goodness of Wikipedia from the web browser. This plan is about making sure readers who'd genuinely value the app know it exists; it's not a move toward restricting or diminishing the mobile web experience. As with the pilot, this will only show to logged-out readers on the mobile web, for each reader it will be capped at 6 impressions per month and if you dismiss the banner, you won't see it again on that device that month.
We'll also make sure these plans don't crowd out any planned community banner campaigns, adjusting our own scheduling as needed to give those the space they require.
Given the push for mobile users to use the app, I would love it if they could be granted access to the entire platform. As a mobile user I find it really frustrating that I can’t search for categories, or that the search is limited to a finite number of results. ExtantRotations (talk) 15:27, 19 August 2026 (UTC)Reply
I am Amal Ramadan and I support Wikipedia apps team, for search the categories:
If you type Category:<category you want>, you should be able to find the categories you are looking for. Regarding generating a longer list of search results and improving search outside mainspace, at the moment our team is focused on getting semantic search to work well on Wikipedia. Once we have that, we can do much more, and you are welcome to subscribe to the apps newsletter for the full news and updates of the apps' work. ARamadan-WMF (talk) 17:53, 20 August 2026 (UTC)Reply
How about adding more support for editing in app? The mobile web editing experience is problematic as it is, and I was extremely disappointed to find out the app has even less functionality. I have no issues simply reading articles in my mobile browser and I see no added benefit to clogging up my device with yet another app to do the same thing, so I promptly uninstalled it. ChompyTheGogoat (talk) 02:39, 25 August 2026 (UTC)Reply
I'd have to go back and install it again to figure out what exactly is missing or broken. I'd like to know what the thought process was behind releasing a lower functioning app in the first place. What purpose does it serve? ChompyTheGogoat (talk) 22:52, 27 August 2026 (UTC)Reply
Hi @ChompyTheGogoat my name is Jaz, I am a Product Manager on the Mobile Apps Team.
We agree that there is room for improvement with the editing experience in the apps. To make it better, we're currently actively working on a feature to allow people who edit from the app to access the VisualEditor, and we could use your input. And if there are other editing features you'd like to see on the apps, I'm happy to chat about them.
The web still plays a very important role and is the front door to welcoming in the diversity of reader interest. With that said, I do want to be realistic about how we see the apps. We are investing in them primarily as a home for our most engaged readers, and our research indicates that they appreciate features like Year in Review that we can provide only on the apps. The apps are our highest retaining space for readers, which is important when Wikipedia is experiencing declines in pageviews. These highly-retained readers are good candidates to become future editors, so we want them to have a positive experience when they are ready to become editors, hence the attention to meaningful handoffs to desktop/mobile web, where the superior editing experience lives, and where we are focusing all of our effort to continue to improve the desktop/mobile web editing experience. I hope that provides a bit of insight into our thinking. I also welcome you to check out this video from Wikimania which goes into greater detail around this thinking. JTanner (WMF) (talk) 15:49, 28 August 2026 (UTC)Reply
I think that line of reasoning is problematic. You want people who are invested in Wikipedia to download an app, become more invested, find out the app isn't useful for editing, and uninstall it to go back to the website? Or keep swapping back and forth between the app and the website every time they run across something they want to edit? Something like Year in Review is a minor bonus feature, not major functionality. It's the kind of thing commercial corporations use to drive sales while discouraging people from navigating away (and it's a gimmicky fad that will probably die down in a few years). This just furthers my distaste for WMF pursuing the same kinds of tactics. Our purpose is to be educational, not obsessively chase engagement stats. Who cares if someone navigates away to continue learning about the topic somewhere else instead of falling down a wiki rabbit hole for hours? As long as people consider it a reliable source of information that they utilize regularly we're accomplishing that goal. Websites should provide clean basic functionality for their primary purpose, while apps should offer an expanded range of options for more dedicated users via more complex programming that can't be routed through browsers well (especially on mobile). Like all the customizations and workarounds that are currently accessible through a hodgepodge of scripts, gadgets, and beta features, which sometimes interfere and cause glitches but overall improve my experience compared to the default native environment that's already glitchy and not optimized for mobile. The problem I tend to see these days is when programmers turn around and try to stuff that functionality back into a website, and then they don't care if it breaks because their ultimate goal is to funnel everyone to the app anyway. Some sites don't even functional well on my desktop anymore because they've gotten so ridiculously bulky. Here we have the opposite problem where you've distilled it down to basic functionality for a slimmer app, then hung a few bells on to try to make it appealing. It's very bizarre and once again feels more like "keeping up with the Joneses" than a truly introspective view for how an app would support the overall purpose of Wikipedia. If the people who spend the most time on the platform and are the ones who actually maintain it aren't utilizing the app, that speaks volumes for its actual usefulness. ChompyTheGogoat (talk) 03:21, 29 August 2026 (UTC)Reply
If it is expected that users hop between platforms, that makes it all the more baffling that notification dismissal isn’t shared between them. Why make users acknowledge each notification twice? ExtantRotations (talk) 16:07, 29 August 2026 (UTC)Reply
@NNawaz-WMF, @ARamadan-WMF, @JTanner (WMF) I usually read and edit Wikipedia on a tablet, using a browser. The browser interface and the editing tools are fine for me (I use source editing). I use Wikipedia very occasionally on a phone or a desktop pc.
How is the app better? As I said, the Web interface seems great. I don't understand the need for an app. Many apps are useless, in my opinion.
Why does Home Depot, for example, even have an app? Their Web page works just fine on a phone or a tablet, and their app gives no advantages. Many other companies with perfectly good Web pages also have apps... which seems (to me) like useless effort.
One thing the app desperately needs is support for namespaces outside of Articles and Talk pages. For everything else, it just brings you to a web interface. At the moment, I see the customizability and extra tools on mobile web much more useful than the app. Axolitl(talk|contribs)05:27, 31 August 2026 (UTC)Reply
Thanks all. If the web experience works well for how you read and edit Wikipedia, that’s great. We continue to invest in the mobile web. The apps serve an audience with different needs, over 1.5M people daily and the May campaign generated about 701,000 installs of readers continuing to use the Wikipedia app.
I agree that engagement shouldn’t be an end in itself. We care about readers returning because Wikipedia remains useful for learning and exploration, not spending more time in an app. Since about 99% of app users are readers rather than editors, reading is the apps’ primary focus today, but we are also improving the path to contribution, including work to bring VisualEditor access to the apps.
@ExtantRotations, editing notifications are synced between the apps and web, so needing to dismiss the same notification twice sounds like a bug worth investigating;, if you can send a screen recording to our support email (android-support@wikimedia.org or ios-support@wikimedia.org) we can look into it . Some reading-related stats found in the activity tab does remain on-device by design because a large number of app readers have told us they value that privacy – the stats don’t leave their phone. JTanner (WMF) (talk) 14:04, 9 September 2026 (UTC)Reply
99% of app users are readers rather than editorsbecause the app isn't structured for editing. I'm sure some of us would use it if it was any good. As mentioned my mobile web editing experience has NOT been fine - I use it because it's the only option. I was excited to hear there was an app since they're usually more functional, and disappointed to learn that isn't the case. If you're only interested in supporting readers, why ask for editor opinions at all? ChompyTheGogoat (talk) 14:33, 9 September 2026 (UTC)Reply
Is there any particular functionality you keep it around for? I've never found the web reading experience to be deficient in any way, so I only installed it in hopes of having better editing functionality. I have zero interest in platform hopping. ChompyTheGogoat (talk) 23:09, 9 September 2026 (UTC)Reply
If the web experience works well for how you read and edit Wikipedia, that’s great. I wish the app agreed with this. It perches like a vulture, trying to get all on-browser Wikipedia links to open it. Patient, ever watching, ever ready to pull you into its claws. CMD (talk) 23:38, 9 September 2026 (UTC)Reply
In addition to the notification issue, let me mention another couple longstanding app bugs that specifically affect readers.
Section links do not work whatsoever; they only ever deliver you to the start of the page.
Pictures displayed in tables cause the surrounding text to be squeezed into a column 2-10 letters wide.
Templates using the “read more” link are broken and display the entire notification (instead of being hidden behind a link)
Categories and portals are hidden from view and all but inaccessible.
Recommendations are all but nonexistent. Most articles are found by me searching for things, because there is essentially no front page or attempt to hook readers.
In case this (belated) feedback is of any use, I gave the iOS app another try on my clean alt account back in May – it lasted about ten days before I gave up in frustration. Some notes at User:ClaudineChionhDemo §iOS app 2. Disclaimer: I was reading and editing wikis before Wikipedia was created, I joined Wikipedia before "skins" were invented, and I still prefer the command line over all other interfaces, so I am far from a representative modern user. One positive note: "Nearby places" looks really handy for travellers (those who trust Wikipedia enough to enable location services). —ClaudineChionh (she/her · talk · email) 23:56, 9 September 2026 (UTC)Reply
This was apparently tagged as a result of a massive RFC (shortcut: WP:LUGSTUBS2) three years ago. I have barely begun to read through the RFC but it appears that this article meets the criteria for draftification. It's not clear to me why this hasn't been moved to draft space yet. If there's a reason this was spared, and it's not just an oversight or a result of a large backlog, then I would expect that to be clearly documented. Pinging the RFC closer @HJ Mitchell, who might have some insight into what happened and should happen here. —Myceteae🍄🟫 (talk) 17:11, 22 August 2026 (UTC)Reply
What happened is that a lot of editors voted for someone else to do the work, and then got mad that other WP:VOLUNTEERS didn't instantly do their bidding. Voting for someone else to do work that I refuse to do myself has been one of the more unfortunate trends over the last few years. (For clarity: the OP is not one of these people. The OP is only asking about a confusing message on an article.)
Then it turned out that a lot of these articles either shouldn't be moved to the draftspace at all, because they're notable athletes, and nearly all of the rest shouldn't be moved to the draftspace because they should just be redirected to a team roster. More than 95% of the original list has already been handled; just 54 tagged articles remain in the mainspace today. Most of them are in South Asian countries. Wikipedia talk:WikiProject Cricket is the place to post if you want something useful done about this one. WhatamIdoing (talk) 15:58, 27 August 2026 (UTC)Reply
Following Myceteae's request at WT:CRIC, I've restored Akeel Inham from draft, as it should be redirected to List of Burgher Recreation Club cricketers, which I will create. Inham is a notable player, having made some 65 top-class appearances to date, but when the article will ever acquire significant coverage is anyone's guess, so a redirect is the sensible option at present.
I've copied a list of the 54 tagged articles. I'm familiar with Lugnuts' stubs, and I expect to find that all of these are like Inham. I can virtually guarantee they are all notable players, but there won't be any SIGCOV. So, like Inham, they all need to be redirected to a club list. There's a win for CRIC in this as we need lists of all top-class players by club, and we're a long way behind in our Sri Lankan coverage.
I should add that I will do all this in my own time, as and when I feel like doing it. If anyone thinks I will instantly do their bidding (see above), they will be, shall we say, told otherwise. Thanks, Jack (talk) 19:36, 3 September 2026 (UTC)Reply
I've copied the list of 54 articles to one of my sandboxes, and I've checked all of them for a club team list we can use a redirect target. Unfortunately, many of these clubs do not have a List of Someplace Sports Club cricketers, and I'm having to create them. I've so far redirected six articles, and two more have been nominated for CSD because they aren't actually notable (both played for a minor team which made a couple of appearances in List A matches).
I didn't expect this to be an easy job, but I've been hindered by the creation of Wikipedia:Articles for deletion/List of Sri Lanka Air Force Sports Club cricketers, a new list I created a few days ago for one of the redirects. Frankly, the arguments raised in support of this AfD are ridiculous. They apparently oppose the whole concept of players-by-clubs lists, and they do not recognise the RFC which requires these lists to be created and used. Anyway, I'll soldier on.
@BlackJack Thanks again for doing this! I don't personally have any objection to speedy deletion, but since there was a lengthy RFC about what to do with these, with some fallout, I can imagine some of these being denied. If that happens, I'd be happy to move them to draft space without leaving a redirect. —Myceteae🍄🟫 (talk) 14:35, 8 September 2026 (UTC)Reply
Well, the odd thing is that an admin has seen one of these two and raised it at Afd, so it could go either way! Thanks again. Jack (talk) 16:16, 8 September 2026 (UTC)Reply
I've moved most of the remaining articles into draftspace (there were a few that don't meet the requirements now that I removed the tag for and left in mainspace), but feel free to turn any of them to redirects whenever. I'll look to finish off the rest of the list in the coming days. Let'srun (talk) 00:57, 9 September 2026 (UTC)Reply
That's fine, Let'srun. The only stipulation with these is that they are no longer suitable for mainspace. If anyone thinks they should be drafts, please go ahead. Thanks, Jack (talk) 09:53, 9 September 2026 (UTC)Reply
There were only a few left after those were drafted, and I've redirected them. So, it looks as if the list of 54 has been cleared. Jack (talk) 10:43, 9 September 2026 (UTC)Reply
Latest comment: 7 days ago4 comments4 people in discussion
I see a lot of dating using the religious AD and BC while others use the modern secular BCE and CE. As this platform is used by more than Christian readers, I propose standardized CE and BCE throughout. ~2026-46089-12 (talk) 05:47, 23 August 2026 (UTC)Reply
See WP:ERA. Wikipedia is built by people from all over the world, and with many different backgrounds. Therefore, standards for certain issues (BC/BCE, formats of dates, citation style, color/colour, and probably more) are not imposed on everyone. Johnuniq (talk) 06:21, 23 August 2026 (UTC)Reply
No, it's not "fine as a standard", whatever that is supposed to mean, and it is against the WP:ERA policy to change any article without consensus. Changing all articles is no priority at all. Johnbod (talk) 00:57, 6 September 2026 (UTC)Reply
Latest comment: 7 hours ago248 comments23 people in discussion
Please for the love of all that is holy, can we either revamp these to require some degree of human oversight in terms of suggestions, or just remove them entirely? My experience both with peeking at them briefly as a newbie myself and reviewing edits made by others is that they give vague and unhelpful suggestions on articles that need major improvements, so we get these new editors with no understanding of the subject making equally unhelpful (and sometimes nonsensical) changes that other editors then have to review and usually revert. It's creating extra work without actually improving the articles. It would be one thing if the tool was actually capable of identifying truly minor edits needed, like spelling and grammar, but that doesn't seem to be the case. We'd be better off leaving newbies to look around on their own and make edits where they feel they adequately understand both the subject and the changes that are needed, rather than trying to guess what some automation has identified. ChompyTheGogoat (talk) 02:31, 25 August 2026 (UTC)Reply
I'll just dump here what I wrote on my user page a while ago:
"I started editing by going through "Newcomer Tasks". After three days and a handful of edits, I have given up. The vast majority of the "Newcomer Tasks" I was shown were completely unsuited for actual newcomers. I mostly looked at tasks in the history topic. Most of them consist of being asked to improve very poor articles on very obscure topics. In many cases, there seem to be only few books or articles covering the article topic, and they tend to only be available in specialized libraries.
I do not know how these "Newcomer Tasks" are chosen. Based on what I've seen, most of the articles seem to have what I found to be called "maintenance templates". I suspect that these articles are automatically assigned to newcomers based on these templates.
That is a very poor way of introducing newcomers to editing Wikipedia. It feels more like being given the odious tasks that nobody else wants to perform, than tasks tailored to the needs and skills of newcomers. It feels like starting an internship and being given the tasks of making coffee and cleaning up behind the staff.
I expect those "Newcomer Tasks" to drive away a lot of people who might have gone on to become valuable contributors if they hadn't been turned off right at the start. While that isn't the case for me, it seems that I will have to find my own way on Wikipedia." Long is the way (talk) 13:44, 26 August 2026 (UTC)Reply
At least those (IRL) tasks are actually easy to understand, just tedious. These are more like being asked to tidy up and walking into a building actively on fire. The ones I've seen newbies attempting to "fix" lately didn't have maintenance templates that I recall, so I really have no idea how they're being suggested. They suddenly started popping up on a group of related articles that have received attention recently. ChompyTheGogoat (talk) 17:12, 26 August 2026 (UTC)Reply
Nope, no template. The latest was a "revise tone" with the summary "Removed bias and slang", when it fact the only substantial change was a misinterpretation based on lack of knowledge of the subject matter. There was no slang of any kind. ChompyTheGogoat (talk) 17:46, 26 August 2026 (UTC)Reply
Before I settled on the History topic area I also looked at tasks in the Philosophy and Religion area and the Computer (it's been a while, I'm not sure if that was the title) area. In the Philosophy and Religion area, most articles that showed up were about random churches, religious colleges and religious schools in the US. And if that's not bad enough, every time I did a quick search for reliable sources (I won't do a thorough search for an article about a random church that interests me not one jot) came up empty. So what should I do? Nominate article after article for deletion as a newcomer when the author couldn't be bothered to provide proper sources for their edits and someone else couldn't be bothered to do more than tag it? And in the Computer area most articles were about random software and tagged for promotional language. Again, a quick search for proper sources usually came up empty. Once you've wasted a few hours like that it's hard not to come to the conclusion that Newcomer Tasks (if not Wikipedia in its entirety) are thoroughly broken. Long is the way (talk) 18:21, 26 August 2026 (UTC)Reply
I think I was looking at Science - which is incredibly broad, with no way to narrow down my actual interests - and my "1-2 minute copyedit" tasks needed a full top to bottom rewrite (and probably sourcing too). I literally didn't know where to start. Instead I just dabbled with very minor fixes that I stumbled across during my normal reading, or occasionally when someone else mentioned it at Teahouse and didn't know how to do it themselves. Honestly, I think basing it on templates would be better than how it currently is. Even moreso if there was a specific "newcomer level" that could be appended to indicate that it's an easy fix for someone who's still learning - based on actual human judgement - leaving the more complex issues out of the newcomer database. Of course most experienced editors would just fix something that simple, but there could be an active choice to leave it in if it doesn't interfere with the overall reader experience. ChompyTheGogoat (talk) 19:22, 26 August 2026 (UTC)Reply
Thank you for taking the time to describe your experiences. I work with the Growth team, which developed newcomer tasks, so I wanted to let you know that I'm following along and thinking about all of the feedback shared in this thread.
New editors make mistakes, and that's true whether they arrive through Suggested Edits or on their own; our goal is to make those early mistakes smaller and easier to learn from, and we know we don't always succeed. Suggested Edits clearly aren't the right path for everyone, but in multiple controlled experiments they've increased the share of newcomers who make a first edit and who are still editing weeks later (2020 analysis, 2021 analysis, 2025 analysis), so many new account holders do find them valuable.
Two current efforts speak directly to what you've described. Newer tasks like Revise Tone are far more in-context than the broad "copyedit this article" tasks you encountered: they point to specific sentences rather than leaving a newcomer staring at an article that needs a rewrite. ChompyTheGogoat, since your recent example was a Revise Tone edit gone wrong, I'm curious if you've looked at other Revise Tone edits? Although newcomers are still making some mistakes, it seems like this task is helping provide enough structure to support newer editors, while still teaching more valuable skills than a super simple task like Add a Link.
And our Early onboarding / Home experiment is testing whether newcomers do better when they can choose specific interests instead of overly broad topics like "Science", which is exactly the gap several of you have identified. In early testing, this surfaces far more specific suggestions and lets people find the niche topics they actually know something about. Does that sound promising?
Finally, as @Johannnes89 notes, much of this is tunable locally via Community Configuration (which tasks are enabled, which templates feed them).
Like I said, there needs to be actual human oversight for me to consider it viable - not problematic automation, and absolutely not this LLM suggestion crap. We spend far too much of our time fighting LLM content and in no way shape or form do we need it further misleading new editors. The problem isn't just the edits they make using such a tool, but what they would learn from it and apply in the future. And on that note, just the fact that newcomers are more likely to keep editing is not a very useful metric on its own - the edits themselves need to be beneficial. Quality over quantity. How many of the newcomer task edits are actually reviewed by more experienced editors, and what's the reversion rate on them compared to non-suggested newbie edits? How many of those editors continue to be productive over months or years, not just weeks? The automation we need is education - a walkthrough for new editors that covers the basics of editing; both the technical how-to aspect and an overview of the four pillars plus the most crucial guidelines. WP:NOTABILITY, WP:COI, and WP:NOLLM come to mind as the most obvious "read before editing" candidates (with checkboxes for the latter two affirming whether or not they have a COI to disclose up front, and that they agree to not insert LLM content). Actually teach people what they should be doing instead of just tossing them in the deep end and saying "here, change something and wait to see whether you get corrected or not". WikiEdu has been highly successful, right? There's no reason we can't package up the basics for all new editors who don't have time or access to such programs. Add an FAQ in too, and links to various sources for additional help.And as long as I'm ranting - better navigational structure. A site index. If I'm wondering "is there a guideline about this" or "where should I report such and such problem" I should be able to scan a list for anything that sounds relevant, instead of attempting to dig through namespace filtered search results - and newbies may not even know about namespaces yet. Once again, more often than not it comes down to "screw up and get corrected", which is a valid learning method but shouldn't be the primary one, because it gets extremely discouraging. Far better to set people up to succeed. ChompyTheGogoat (talk) 21:20, 26 August 2026 (UTC)Reply
You raise a fair point about quality over quantity, and it's one the team shares. All of the Growth team's experiments account for reverts: when we report that Suggested Edits increase activation and retention, we're counting only "constructive" activation and constructive edits, meaning edits that were not reverted. A newcomer whose changes get reverted isn't counted as a success in that data (definitions in our data glossary). If it would be useful, we can also pull recent English Wikipedia data comparing revert rates on Newcomer Task edits vs. other newcomer edits; just say the word.
I've also filed phab:T436196 asking Movement Communications to share more about newcomer metrics as a whole, because I suspect some of the current frustration may relate to the recent increase in new accounts and new editors. More newcomers means more newcomer mistakes reaching patrollers, even if per-editor quality hasn't changed. Does that match what you're seeing?
On education: this is an active area of work. Together with the Community Development team, we're developing short micro-learning videos based on the Wikimedia Core Curriculum, to help new contributors understand the basics and build confidence before and while they edit. That said, no single onboarding path works for everyone: some people want to read the guidelines first, some learn best from a video walkthrough, and some only absorb things by trying a small edit and getting feedback. If we want an encyclopedia written by a broad, representative group of editors, and one that stays as neutral as possible, we need to support several ways in rather than optimizing for just one type of potential editor.
Where I fully agree with you is that we can do more to set new editors up to succeed, and your navigation ideas are a good example. What would a site index that doesn't overwhelm a newcomer look like to you? Namespaces alone are a bizarre concept for most newcomers to grasp, and we do very little to explain them. As always there's so much room for improvement and limited capacity to "make it so" but I'm committed to doing the best I can to improve onboarding for newcomers on the wikis. Thanks - KStoller-WMF (talk) 00:16, 27 August 2026 (UTC)Reply
Yes, I would like to see the comparison stats. I'm particularly interested in which ones have actually been reviewed and confirmed to be an improvement vs just not noticed, but I realize that's harder to prove. I'm aware that new editors make lots of mistakes, but my personal experience has been that nearly 100% of those flagged as newcomer tasks are at best useless, if they don't actually make things worse, vs more of a dice roll for normal newbie edits. What exactly are the existing criteria for them to be suggested anyway?As far as the education side, I'm someone who prefers text learning over videos, so I'm aware that multiple approaches are needed. What I'm suggesting here is just a very brief intro - a popup (with option to skip) with a few slides mentioning the absolute basics and linking to additional learning resources. <2 minutes to get through. I would hope anyone who wants to edit Wikipedia could handle that amount of text, and the COI/LLM agreements are universal. As mentioned elsewhere, the situations we want to avoid the most are the novice good faith editors who are truly WP:HERE and end up with significant reversions purely because they're unaware. We had a case at WP:AINB recently where a new editor had made substantial LLM changes across numerous articles before anyone noticed and called it out. They were very apologetic and actively participated to help with the cleanup. Those are editors with real potential that we don't want to discourage. And removing plausible deniability would streamline disciplinary actions on other cases as well.For navigation, at minimum we should have top level links in the main menu to WP:List of policies, WP:List of guidelines, WP:Manual of Style, and WP:Noticeboards. Maybe WP:Template index too. I'd also recommend considering a customizable shortcuts section that logged in editors can add any pages they want to reach quickly to; internal bookmarks. And personally I dislike the current structure of internal navboxes such as Template:Wikipedia policies and guidelines - in theory if I'm already on the right overall section I can jump around from there, but my brain has a tendency to skip over them because they feel disorganized, and it's worse the busier they get, like with that example. I think stylistic changes could help with that - maybe color coding, collapsible sections, and some kind of change to the layout of the lists themselves within the cells? It's not something I've given much consideration to, but could be workshopped here at VP. And for the sake of being thorough, there could also be one site directory page linked in the footer with a complete list of all the main internal pages in WP space. Obviously It can't be 100% comprehensive, what with all the subpages and minor pages that are frequently created or deleted, but primary perennial ones. Other projects could implement these ideas too - if I want to go edit on one I'm unfamiliar with it would be helpful to know I can go through the menu to find their own policies and guidelines to ensure I'm in compliance with any standards that are different from here. It's especially difficult to try to track such things down via searches if you're dealing with foreign languages (I swapped out a few images across several foreign wikis the other day to avoid breaking pages via changes made at Commons).I'm probably well over my allotted time here, and it's only tangentially related, but one other idea I had recently was some area for more collaborative work on article creation. Not just the brief feedback from reviewers or general "how to use Wikipedia" questions for mentors, but a longer term partnership aimed at getting articles completed and published together. I'm sure newbies would find it the most useful, but I can also foresee situations where people need a specific type of help - for example, one person might be a subject matter expert while the other can help with translation. It could potentially improve AfC rates as well as the initial quality of articles that are directly published in "notable but needs work" condition. ChompyTheGogoat (talk) 05:11, 27 August 2026 (UTC)Reply
Example pop-up for the "Find references" task
What I'm suggesting here is just a very brief intro - a popup (with option to skip) with a few slides mentioning the absolute basics – that's exactly what each newcomer task offers? Johannnes89 (talk) 05:47, 27 August 2026 (UTC)Reply
Could you reduce "how to edit Wikipedia" to a handful of sentences? In my experience, "how to" depends a lot on the context, and what you're trying to accomplish. How to fix poop vandalism is a completely different skillset from how to add a new paragraph. WhatamIdoing (talk) 17:35, 28 August 2026 (UTC)Reply
Of course - I just mean the very basics that would be most useful to good faith editors with zero experience. Brief references to things like WP: NOTABILITY, WP: RELIABLE SOURCES, WP:NPOV, and WP:MOS as well as the aforementioned WP:COI and WP:NOLLM, with links to all of these places as well as additional resources like WP:TEAHOUSE and WP:HELPDESK. We can't stop vandals from being vandals, and we can't fit all of the educational material into a single popup, but we can inform people that these things exist and help them find them, to hopefully prevent some of the most common genuine mistakes. I couldn't begin to count the number of new editors who come to Teahouse asking about a reversion, warning template, etc based on guidelines that they had no clue even exist, because how would they? Even the welcome templates are only dropped after they make an edit, see the notification, and go read it. We should be offering these resources upon account creation/first attempt to edit to be proactive instead of reactive. We could also include a mention of reversions and why they're a part of the learning experience (even for seasoned editors), not automatically criticism, to help people feel less offended by it. ChompyTheGogoat (talk) 03:35, 29 August 2026 (UTC)Reply
Most newcomers don't try to start an article, so why should they care about our notability rules? Similarly, MOS violations are usually easy enough for editors to fix, and it's thousands of small rules, most of which are either automatic (basic grammar) or irrelevant (e.g., the name of a gene should be italicized, which 99.9% of newbies will never need to know). I wouldn't bother with that. But RS and NPOV and COI and NOLLM all sound like reasonable things for us to educate people about. WhatamIdoing (talk) 04:13, 29 August 2026 (UTC)Reply
I think the definition of "most" is debatable, but certainly so is the specific content that should be included. I'm just trying to get the overall concept across. Which mistakes are good faith new editors most likely to make in their first handful of edits, and what can we offer them that would be the most useful to help avoid those? Collecting a pool of early edits that have been selected for good faith attempts at improvement - filtering out vandalism etc - would help us establish specific targets, and there would probably be some adjustments as we see the results. ChompyTheGogoat (talk) 04:21, 29 August 2026 (UTC)Reply
The last time I saw the numbers, which was some years ago, about 25% of newcomers tried to start and article. Therefore, 75% of newcomers didn't. 75% is "most" under all mathematically sound definitions.
Learning by doing, especially learning from mistakes and feedback, is very effective when the experience is not demoralizing. The challenge is to keep this in balance. And getting corrected, or reverted, is unavoidable.
Newcomer tasks are visible and easy to categorize. This permits testing, tracking, improvement. It can also promote confirmation bias and a (possibly false) sense among experienced editors that newcomer tasks are especially error-producing. Newcomers who get "bitten" for completing a structured learning activity understandably feel let down. Even if the net success rate of these tasks is better it is for newbies left to their own devices the experience can be frustrating.
Related to (1) is figuring out the optimal way to introduce our myriad policies, guidelines, practices, and jargon. Presenting too much "required reading" up front is likely to discourage some newcomers while others feel set up for failure by not having fundamental principles put in front of them. We should make this information visible and accessible in a variety of ways. There will still be problems. I like policies and guidelines but they have to be applied and interpreted in context.Related to (2), it's funny that you mention WikiEdu. My sense is that it is successful but it is a frequent topic of discussion. Some editors feel that it disproportionately generates bad contributions that require cleanup. I haven't seen convincing evidence of that but WikEdu contributions leave a trail and (may) come with a set of expectations, like newcomer tasks, that can increase the frustration. These are good problems to talk about, and it's beneficial to have relatively new editors in these discussions. —Myceteae🍄🟫 (talk) 01:18, 27 August 2026 (UTC)Reply
See my above comment re: 1. My intent for that is just a very brief "Welcome to Wikipedia, here are a few of the most crucial things you should know and places you can go to learn more", not a master's course in editing.I don't have a lot of experience with the outcome of WikiEdu myself - I'm mostly going off what I've seen others say - but what little I have seen usually seems to fall more in the "this is a good start, but here are some more suggestions" where reverting and explaining is helpful, as opposed to "this never should have been suggested in the first place so there's nothing to improve and both of our times were wasted". I definitely could have benefited from more useful suggestions; I was very wary of making any mainspace edits until quite recently and stuck to extremely simple ones (the opposite reaction from LITW). My suspicion - again difficult to prove - is that there's an inverse relationship, where those of us who have a better understanding of Wikipedia from the start and are able to handle the learning curve better look at these tasks and see what's inherently wrong with them, while those who don't know how anything works here assume the suggestions are valid so they just go ahead with changes even when they don't really understand the assignment. ChompyTheGogoat (talk) 05:32, 27 August 2026 (UTC)Reply
The other big differences with WikiEdu is that there are much fewer edits produced by the program, and that when people have pointed out issues with those edits, they actually did make changes to the workflow that seem to have improved the situation. Gnomingstuff (talk) 18:05, 28 August 2026 (UTC)Reply
Yeah, I'm sure it's not perfect, but right now it's our best resource for a more structured program to help support new editors, so I think we should be using what's been learned there to do the same in a more hands off way for others who don't have access to such things. Use what works and discard what doesn't. ChompyTheGogoat (talk) 03:41, 29 August 2026 (UTC)Reply
@ChompyTheGogoat, what does "actual human oversight" mean to you? From where I'm sitting, the newcomers are human, and so if and how they decide to make the edit constitutes "actual human oversight" of the edit already. But I think you mean something else. WhatamIdoing (talk) 16:08, 27 August 2026 (UTC)Reply
Oversight by someone with more experience (hopefully) of what actually gets added to the task database, to ensure the suggestion itself is valid and easy to comprehend. ChompyTheGogoat (talk) 22:49, 27 August 2026 (UTC)Reply
Are you volunteering to check all the pages that are identified as needing work, to make sure that they actually need that kind of work?
We need about a thousand brand-new accounts to not only register, but also to make their first edit every day. Anything that reduces that number risks Wikipedia's future, because I am going to die. Only a small fraction of them will complete a Newcomer task, but the newbies who do those tasks usually do multiple edits to multiple articles. We probably get about 1,000 to 1,500 newcomer tasks completed per day. Some tasks result in multiple edits to the same article, but we also need a buffer in case a pre-screened article doesn't find an interested editor. I estimate that manually pre-screening would therefore require pre-screening about a thousand articles a day. At a sustained rate of one article per minute, that's 16 hours of work, every single day of the year. It would also have the downside of introducing personal preferences (e.g., this editor wants to minimize links, that editor is unusually sensitive to 'promotional' content...). Do you think it would be worth it, in terms of improving the edits? WhatamIdoing (talk) 17:07, 28 August 2026 (UTC)Reply
If only a small fraction of new edits are made through newcomer tasks then yes, I absolutely agree it would be justified to spend more editor time screening tasks instead of going back and fixing bad edits that result from them. Higher quality suggestions would also result in higher uptake by those of us who avoided them because they're problematic. Even if they actually were based on templates, as has been suggested in this conversation but not substantiated by the evidence, that would mean a human editor read the article and chose to add the template - something that already happens and doesn't add labor. Turns out my gut was right and this is a BS LLM doing BS LLM things. Sure took some tooth pulling to get that admitted. ChompyTheGogoat (talk) 04:15, 29 August 2026 (UTC)Reply
My question isn't whether you think somebody else should prescreen the articles for each task. My question is whether you wanted to do that.
Different tasks have different triggers. The tasks also change over time. For example, the Add a link task used to look (only) for Template:Underlinked; now it is based on a statistical calculation.
Related to this, can we please disable the link suggestions feature in mathematics articles? It consistently causes new editors to add links which are either overlinking or even semantically incorrect (i.e. a different concept with the same name). These editors are often not mathematically advanced enough to understand the difference between a good link and a bad link in a mathematical article. It just ends up creating work for others who have to revert these changes. Elestrophe (talk) 00:05, 28 August 2026 (UTC)Reply
Isn't that one of the newcomer tasks also? Same overall issue. They mean well, but the suggestions just aren't good for newbies with no Wikipedia experience or subject matter knowledge. ChompyTheGogoat (talk) 01:28, 28 August 2026 (UTC)Reply
It is a newcomer task. There was a discussion about this quite recently: Wikipedia:Village pump (proposals)/Archive 231#We need to get rid of the "suggested links" tool. Some tweaks were made and other potential interventions suggested or were already being worked on that might improve the fidelity. There's a lot of discussion there of data indicating that links created via the newcomer task get reverted less often than links inserted by newbies going at it alone. There were some questions about the precision of these figures but nothing that suggested to me that the observation was directionally wrong. —Myceteae🍄🟫 (talk) 01:52, 28 August 2026 (UTC)Reply
That statistic doesn't mean the feature is a good thing. It's not like the existence of the feature prevents new editors from adding links they would have already made, so it's still just creating a bunch of bad links that have to be reverted. Elestrophe (talk) 02:58, 28 August 2026 (UTC)Reply
You're correct that the existence of the tool doesn't prevent manual edits, but the numbers show that it does encourage newbies to make that kind of edit. If nothing else, it educates them that this is the kind of thing that Wikipedia wants to have done. WhatamIdoing (talk) 17:12, 28 August 2026 (UTC)Reply
@Myceteae Re "links created via the newcomer task get reverted less often than links inserted by newbies going at it alone", is there? I've seen data on add a link vs overall newcomer edits, but not specifically vs non-task link additions. CMD (talk) 04:21, 29 August 2026 (UTC)Reply
I count 94 edits to the mainspace, of which a total of 50 were newcomer tasks and a total of 63 were reverted. Specifically, I count 34 reversions of newcomer tasks (68% of newcomer tasks) and 29 reversions of ordinary edits (66% of non-newcomer tasks).
Maybe you want to run some proper calculations, but that doesn't sound like a statistically significant difference to me. Therefore, I think it would be difficult to blame the existence of newcomer tasks for those edits. WhatamIdoing (talk) 17:22, 28 August 2026 (UTC)Reply
The reason all of these edits have not been reverted is because I have not slogged my way that far down the list yet, and because several of the edits have been subsequently buried under a deluge of other edits making cleanup even harder.
No, the reason all of these edits have not been reverted is because the community did not consider them worth reverting. For example, picking a "revise tone" example from the middle of their contribs, I see this:
Perhaps the greatest Harbor Dynasty was that of Girls' Soccer who won 9 CCS Championships in 14 years → Harbor High School has seen notable athletic success over the years. The Girls' Soccer team won 9 CCS Championships in 14 years
It may not be perfect (e.g. neither version complies with MOS:SPELL9), but I think that rephrasing it to get rid of puffy "greatest Harbor Dynasty" language constitutes an incremental improvement. Maybe you would agree with me.
Remember that you don't have to clean up after a thousand newbies each day all by all yourself. In fact, you don't have to do any of it, unless you actually want to. WhatamIdoing (talk) 20:58, 28 August 2026 (UTC)Reply
No, the reason all of these edits have not been reverted is because the community did not consider them worth reverting.
But you still have to go through every single one to see whether they are or not. Many of them are.
I do not actually "clean up after a thousand newbies every day all by yourself," because there are not enough hours in the day for that. I don't see why I am the one who is being scolded here instead of the people creating the cleanup work. Gnomingstuff (talk) 22:11, 28 August 2026 (UTC)Reply
I picked one out randomly from the user's contribs, and I found no need for it to be fixed. Why should I assume that all the others need fixing, or even most of them? It's of course possible to find the one outlier, but it's not generally reasonable to assume that the one you found is an outlier.
I checked another, chosen for being a net negative number of bytes (because I thought a reduction in page size would be less likely to be a whole-page re-write, and I didn't feel like looking at a complex diff). That, too, was a good edit – not perfect, but better than what was there before.
My point isn't that the editor is any good. My point is that you don't have to take on reviewing those edits unless you actually want to. Those edits have almost certainly been reviewed by someone else. That someone else will be less adept at your particular skills (we are all less adept at AI detection than you), but they will have been checked for an ordinary level of reasonableness, and determined not to be obviously bad. As a result, it's IMO not necessary to treat this user's contribs as a significant threat to Wikipedia. Review them if you want, and don't if you don't. WhatamIdoing (talk) 20:00, 30 August 2026 (UTC)Reply
It doesn't indicate that they improve edits at all either. That's exactly the point I was getting at all far as editors who use newcomer tasks at all vs the total sum of new editors, which includes vandals, UPE, SPAs and the whole range of LTA sockers. Most people who come in with any form of bad faith won't bother with the tasks, unless it's purely an attempt to game user rights. ChompyTheGogoat (talk) 03:50, 29 August 2026 (UTC)Reply
This person seems to be a WP:SPA. An unorthodox one, to be sure, but their editing pattern is the same: spam out a bunch of newcomer tasks until Number Goes Up enough that they can do what they're really here for. In this case that's a low-quality draft on their favorite math problem rather than a low-quality draft on their marketing startup, but the pattern is the same. They even all but admit here that they mostly care about getting their edit count high enough to get permissions. Gnomingstuff (talk) 18:11, 28 August 2026 (UTC)Reply
It's once again not clear that the newcomer task creates or promotes the problem as opposed to being a thing that can be used in conjunction with extremely common problematic newbie behavior. There are always newbies who try to juice their numbers so they can gain more tools and start working on their pet projects with fewer restrictions. —Myceteae🍄🟫 (talk) 21:09, 28 August 2026 (UTC)Reply
The difference is that it provides them a frictionless way to very quickly spam out edits they don't care about, and one that directs them to articles that already have problems, drowning out the people who actually do care about and are competent at fixing the problems. Gnomingstuff (talk) 22:13, 28 August 2026 (UTC)Reply
It's my experience that most newcomers actually do care about their edits. They may not be competent (yet), but most of us, including me, weren't competent in our early edits. WhatamIdoing (talk) 04:17, 29 August 2026 (UTC)Reply
@Elestrophe, this one looks like a WP:CIR case to me. I'm not sure they'd be any more or less annoying if Suggested Links didn't exist, honestly. If they don't change their tune in the next couple of days, feel free to ping me about it and I'll get them out of your hair. If there are individual math articles that are getting a disproportionate number of bad links, you can add {{No newcomer task}} to the article to keep them away. In solidarity, asilvering (talk) 21:36, 28 August 2026 (UTC)Reply
If Newcomer Tasks are based on maintenance templates then it's not surprising that they are poor because the maintenance templates are usually too vague and stale to be useful. In theory, they should be supported by talk page discussion which goes into detail but this is rarely done. And the actual talk page suggestions are often left dangling without being closed in a formal way.
There is a project called This week's article for improvement which is going to be featured on the main page soon. The idea is to encourage readers to become new editors. This will provide a good focus for improvement in the workflow for such tasks. I reckon that To do lists should be encouraged to provide a list of actionable tasks but I don't often see them on articles currently. The overall structure and workflow needs work.
I checked the latest one that caused me to start this discussion and the page did not have any template in place, nor do I believe the related ones that started to get on my nerves before that did either. They said in the replies that it is an LLM. ChompyTheGogoat (talk) 09:42, 29 August 2026 (UTC)Reply
Per Special:NewcomerTasksInfo, the vast majority of all newcomer tasks are link-recommendation. If I'm reading Special:CommunityConfiguration/GrowthSuggestedEdits correctly, I believe that is the "Add a link (Structured task)", which is not defined by templates - only excluded by them. revise-tone is also not mentioned there at all and therefore I assume that one is AI generated as well. For those tasks that are template defined, I'd recommend improving the suggestions by adding a parameter to define the level of work an article needs - maybe a 1-5 scale, with levels 4-5 automatically excluding them from newcomer tasks based on the level of work required, as Template:No newcomer task is meant to (which I've never seen utilized, and I would imagine most editors don't know it exists). Levels 1-3 could correspond to easy, medium, and hard tasks, instead of just assuming that all copyedit is easy. I would also recommend excluding articles with three or more maintenance templates for the same reason. ChompyTheGogoat (talk) 09:58, 29 August 2026 (UTC)Reply
18,000 articles are tagged with {{Promotional}}. How many of those are you personally willing to add a level-of-work parameter to?
Going back to modify existing templates would certainly be a slog, but there's no reason we can't append a new parameter going forward. If we add a flag that would help editors notice and drop it in if they're doing any work on an article with an existing one. ChompyTheGogoat (talk) 05:56, 6 September 2026 (UTC)Reply
Well, we'd need consensus to update the templates first, and if we don't settle this newcomer task issue there's less point to it. My biggest concern is which tasks are being fed to newbies who expect something simple - advising people who find the article through normal routes of the anticipated workload would be a minor secondary benefit. ChompyTheGogoat (talk) 06:34, 6 September 2026 (UTC)Reply
have also been trying to explain this, as well as the fact that copy-editing skill and Wikipedia familiarity are not the same thing, and training someone to use the Wikipedia UI does nothing to improve their copyediting ability, especially if you are giving them unconditional virtual pats on the back via widget for doing such a good job Gnomingstuff (talk) 21:06, 29 August 2026 (UTC)Reply
Well, it CAN be - I make very minor spelling and grammar corrections all the time, and that's the kind of work I expected to see in the newcomer tasks - not full article rewrites (2 minutes; ha!) IMHO a level 1/"easy" CE task should only require decent English fluency, not a high degree of WP competence. A professional (non-WP) editor (or comparable ability) could maybe do level 2, and level 3 would start getting into more MOS details for newbies who are starting to get the hang of things. It would be a judgement call of course, but it would still help. ChompyTheGogoat (talk) 06:01, 6 September 2026 (UTC)Reply
But which small fix is going to have any measurable improvement on an article that does need a total rewrite? What's the point to me fixing one or two typos when the whole thing is an unsourced disaster? That's precisely why I walked away from them - I literally did not know where to start. I don't have a clue where those estimates come from anyway if CE is indeed template based, because it sure isn't the editors who added it. If we're going to improve the templates, maybe we could have a way to select which specific passage needs work (and indicating the entire article would automatically upgrade the difficulty level). ChompyTheGogoat (talk) 06:40, 6 September 2026 (UTC)Reply
Expanding on that idea, maybe the difficulty level could be calculated by default based on the byte size of the selection, with editors having the option to adjust it as they see fit. That way they would be sorted automatically even if editors don't bother to set it manually. I'm not a programmer so I don't know what would be required on the backend to accomplish that, but it seems like it would be fairly simple. ChompyTheGogoat (talk) 06:44, 6 September 2026 (UTC)Reply
It looks like we do have Template:Copy edit span as well as Template:Copy edit section. I wonder if we might be able to bundle them all into a single template with optional parameters for the sake of simplicity - I've never seen the span one used (and it's displaying the selection in code formatting for me, which is not great in an article body).I know this would need to be workshopped on the actual templates - just spitballing. ChompyTheGogoat (talk) 07:37, 6 September 2026 (UTC)Reply
There is also a practical value in letting a newbie work on a disaster of an article: The odds are higher that if they do anything, they'll make it better. If we invite them to improve an article that is nearly perfect, then the odds are significantly higher that they won't understand what's wrong, or they'll pick the wrong thing to fix. WhatamIdoing (talk) 19:04, 6 September 2026 (UTC)Reply
Not if we're talking CE - find and fix the error. Don't fix things that are correct. If they don't understand the difference that's a WP:CIR issue. Especially if we implement my suggestion to actually flag the specific part that needs work. Tossing disaster articles at them is overwhelming and it's highly likely the part they work on will end up reworked or deleted entirely once the article is actually brought up to snuff (if ever). No one is going to notice there's one less typo when it's still a mess. It might be a statistical improvement if it is correct, but not a meaningful one. (The Revise Tone task that was incorrected by the newbie was then deleted by the patroller who saw it because it was unsourced in the first place and not particularly useful. Neither the LLM that flagged it nor the newbie with no experience realized that.)I believe it was @Gnomingstuff who said their reaction to such a task was to dive headfirst into learning all the relevant guidelines and eventually fix the entire article, but that's obviously not the intended result nor a common outcome. Mine in the same situation was to just leave it and find easier work on my own. Others might give up entirely if they think monumental work like that is what's expected on a regular basis. ChompyTheGogoat (talk) 19:59, 6 September 2026 (UTC)Reply
In my experience this has not happened; the articles just turn into a hundreds-of-edits deep morass that makes reverting a bad edit (of which there are many, with Newcomer Tasks) difficult and tedious. Gnomingstuff (talk) 21:06, 6 September 2026 (UTC)Reply
Which part doesn't happen - the progressive improvements (which I haven't seen either)? It might have been someone else who said they turned the task into a long term project instead. My memory sucks. ChompyTheGogoat (talk) 01:00, 7 September 2026 (UTC)Reply
The progressive improvements.
(It doesn't help that very few people actually remove the tag when they do their changes -- which is completely expected and nonmalicious behavior from a new user, but does mean that the changes don't stop coming and people get increasingly confused at what is tagged.) Gnomingstuff (talk) 15:11, 7 September 2026 (UTC)Reply
It sounds like we need a specific patrol group for any newcomer tasks that are retained. It would be useful to prioritize edits by all new editors, for that matter - are there filters that could pull changes made by non-autoconfirned and non-EC as well? That could be useful work for people who are involved with welcoming/mentorship/etc - sort the bad actors to appropriate noticeboards and offer support to the good faith ones who need help. ChompyTheGogoat (talk) 01:57, 8 September 2026 (UTC)Reply
So I'd recommend such patrollers start with something like this, then expand to the learners group and eventually skim "likely good" edits. Depending on whether they're focused on damage control or outreach they could either look at bad faith filters first, or good faith and newcomer tasks.I checked one at random and found yet another instance of a problem with newcomer tasks: Special:Diff/1373819817 This appears to be a relatively competent new editor making useful contributions who hasn't been reverted yet (with 19 live mainspace edits), but even they failed to comprehend what the "expand" task is meant to be and just did minor CE instead. The edit itself is fine, but it speaks to the larger issue of newcomer tasks not being clear about the objectives. ChompyTheGogoat (talk) 03:52, 8 September 2026 (UTC)Reply
Or they decided that it didn't need expanding, but while they were there, they wanted to make some other changes. Or they decided that they didn't want to expand it. The task isn't your schoolteacher, and you don't flunk if you don't do what you're told. It takes you to an article, makes a suggestion, and lets you do whatever you choose, which might not be what it suggested. WhatamIdoing (talk) 05:52, 8 September 2026 (UTC)Reply
About Not if we're talking CE - find and fix the error. Don't fix things that are correct: Copy editing (which is different from mere proofreading) is not limited to finding and fixing errors. Sometimes what's needed is improvements in clarity, organization, style, wordiness, tone, and so forth. Sometimes you can't actually flag the specific part that needs work because the whole article (or section) needs work. Sure, some people would prefer to fix a single typo and stop. Some people struggle to do even that much. For example, we have many experienced editors, including some admins, who have dyslexia and are happy to leave that part to others, while they get on with the many things they are better at. But others actually do substantial re-writes, and some of us even enjoy the work (e.g., presumably most participants in the Wikipedia:WikiProject Guild of Copy Editors). WhatamIdoing (talk) 21:51, 7 September 2026 (UTC)Reply
And I did say the entire article can be flagged, but again, we should be trying to serve new editors easy tasks. If one particular section or paragraph is problematic flag it so they know what to focus on, with a difficulty rating to filter which editors it gets served to, and potentially even a comment about what needs to be changed. Drive by tagging rarely helps - if someone doesn't want to do the work themselves they should endeavor to make it clear what they think actually needs to happen. You saw the new example I gave below - the editor has no idea what they're supposed to be doing with the task, OR how the "ask your mentor" feature works. AI has no comprehension of the underlying issues and basing tasks on templates that the adding editor never intended to serve up to newbies both fail to grasp the point. It should be seen as training, not a labor source for issues other people skipped over precisely due to the complexity. ChompyTheGogoat (talk) 02:08, 8 September 2026 (UTC)Reply
I'm not referring to all article flags, but simply inserting a standard template with no additional details on an article with complex or confusing issues. It might be enough to alert readers to potential issues with content but isn't always sufficient to inform other editors about what needs to be addressed - and once again, I don't believe most editors who add them have newcomer tasks in mind. If we're going to utilize them for that purpose there needs to be some thought about how they're implemented. Adding things like selections and difficulty levels would be covered in updated documentation, and editors who are aware of the changes could make an effort to notify others when they see templates being added without them. ChompyTheGogoat (talk) 03:19, 8 September 2026 (UTC)Reply
"Maintenance templates should not be used to "warn the reader" that an article needs improvements or that a Wikipedia editor disagrees with the current state of the article."
That sentence includes quite a bit after the bold explaining what purposes they shouldn't be used to warn. The entire purpose of those templates is to alert readers, like you and me, to changes that should be made. CMD (talk) 08:32, 8 September 2026 (UTC)Reply
So the guideline says that they shouldn't be used to warn the reader that an article needs improvements, but you think that the entire purpose is to warn readers that changes should be made? WhatamIdoing (talk) 21:09, 8 September 2026 (UTC)Reply
I think the text you added without disclosing that here is difficult to understand, but the main thing I'm not doing here is trying to force myself into a position where I'm trying to argue that the big orange box with bold for emphasis, and some even with a large exclamation marks, will not alert readers. CMD (talk) 22:51, 8 September 2026 (UTC)Reply
I think it's called the Principle of double effect: We aren't (and shouldn't be) trying to warn the readers, even if it sometimes has that effect.
For years, none of the maintenance templates were displayed on the mobile site. What's changed isn't a desire to warn the readers, but the fact that we now get more editors on the mobile site than we used to.
(If I had to "disclose" every edit I've ever made to a policy or guideline, it'd be impossible to carry on an ordinary conversation. I apologize for not remembering that I edited that guideline a couple of years ago.) WhatamIdoing (talk) 00:27, 9 September 2026 (UTC)Reply
The principle of double effect would be a possible argument for the existence of templates, but it is not reflected by their design. There is even a scale of alertness, from the yellow ones to red. CMD (talk) 00:48, 9 September 2026 (UTC)Reply
Acceptable disclaimers: ... Temporary cleanup templates, such as {{POV}}, {{original research}} or {{cleanup}}. These point to deficiencies in the article that should be corrected promptly.If they aren't for readers to see, they should be hidden. Lots of other things are. ChompyTheGogoat (talk) 09:36, 8 September 2026 (UTC)Reply
And regardless of whether or not it's their stated purpose, my point was about what they actually accomplish. If it's unclear what needs to be fixed it's less likely to happen, meaning the template stays up longer, meaning more readers see it while editors keep skipping it. ChompyTheGogoat (talk) 09:38, 8 September 2026 (UTC)Reply
If you can come up with a programmatic way to tell which logged-out people are non-editors, then we probably would do that more often. We have already done that for a handful of maintenance templates, e.g., {{orphan}}, which used to be displayed by default and is now only displayed under limited circumstances.
But generally speaking, we can't hide them from "readers" because it's impossible to differentiate between a "non-editing reader" and a reader who would use a temporary account, as well as editors who aren't logged in on every device they use. We want potential editors to be able to see these calls to action. WhatamIdoing (talk) 21:13, 8 September 2026 (UTC)Reply
If they don't want non-editors to see something it's usually only displayed in editing mode, like template errors - and like the new edit suggestions mentioned elsewhere. They generally don't show things strictly related to editing to people who aren't trying to edit. Logged in editors can enable display of such hidden messages if it's something they want to see and potentially work on. These templates are visible exceptions to the disclaimer rule for a reason, and they absolutely have that effect - it's one of the things that made me start wondering about what goes on behind the scenes here, because they started showing up a lot more in the last few years, and I have found them useful in my pre-editing days when an article seemed unusually low quality. It helped me take things with an extra grain of salt. ChompyTheGogoat (talk) 22:00, 8 September 2026 (UTC)Reply
You realize this is all completely irrelevant to my original point about templates not telling editors what needs to be fixed, right? In fact, if your argument is that that's the only purpose they're intended to serve then they're doing an even worse job, because as I've stated if the template is vague and no one addresses it then it just continues to sit there as a flag to readers. Improve templates > improve articles > fewer visible templates. ChompyTheGogoat (talk) 14:21, 9 September 2026 (UTC)Reply
500 edits + 30 days is called "extended confirmed". The links task turns off at 150 edits, even if it's still your first day and even if none of your first 150 edits did any newcomer tasks or added any links. WhatamIdoing (talk) 01:22, 12 September 2026 (UTC)Reply
The problem is that my experience has been that the newcomer tasks are not by any stretch of the imagination "an easy way to learn how to make an edit", but an easy way to waste hours looking into an issue (real or imagined) and ending up not making an edit or learning anything other than to avoid newcomer tasks. Yes there should be newcomer tasks. But they need to be very different from the ones I encountered. Long is the way (talk) 20:30, 26 August 2026 (UTC)Reply
They sound good in theory, but they reality is that they aren't good for helping people learn nor improving articles. They're confusing and waste editor time, especially when we have to clean up the "improvements that aren't". Like I said, they either need to be fully overhauled so they DO help, or removed to stop creating more problems. ChompyTheGogoat (talk) 20:57, 26 August 2026 (UTC)Reply
I think that most of them are helpful. But we don't have to wonder about which one of us is correct; we could set up the mw:ORES review tool and get some editors (all of us in this discussion?) to manually do a blind comparison of a random collection of newcomer tasks vs unprompted tasks by new editors. WhatamIdoing (talk) 16:12, 27 August 2026 (UTC)Reply
I'm not familiar with the tool. How exactly does it evaluate "overall quality"? I do believe that most newcomer task edits are good faith non-vandalism attempts to improve, but often not helpful because of the tool giving inappropriate suggestions and new users not having the experience to recognize that (or know what actually needs to be fixed). New editors who are vandals, UPE, etc wouldn't be likely to use the tool at all, so naturally more of those bad faith edits would be found without it. We'd need a narrower pool of test cases to avoid that bias. ChompyTheGogoat (talk) 21:26, 27 August 2026 (UTC)Reply
As a matter of fact, that could easily be skewing the existing metrics - purely the fact that most editors who'd use it are indeed good faith and WP:HERE. Maybe an examination of edits made with and without the tool by the editors who do utilize it? ChompyTheGogoat (talk) 21:28, 27 August 2026 (UTC)Reply
That tool works manually. It shows you a diff, and asks you what you think of it.
So imagine, e.g., that we set up this tool to show (without showing the Special:Tags) 10 edits from newcomer tasks and 10 similar-ish edits from equally inexperienced newbies that aren't from newcomer tasks. Then you rate them based on whether it's (in your best editorial judgement) a good edit or a bad one. WhatamIdoing (talk) 16:42, 28 August 2026 (UTC)Reply
Before ORES could produce those automated assessments (ORES is what color-codes watchlist items for "Likely have problems" and such), we had to feed it the original data. I guess the page I linked you to is more about the end result than about the tool for collecting the data, so that wasn't a very helpful link; sorry. WhatamIdoing (talk) 04:23, 29 August 2026 (UTC)Reply
So for a specific use like this editors determine which tasks are part of the pool to be evaluated, then it crunches the numbers for us - not just scanning and feeding us what it runs across in the wild based on given params? ChompyTheGogoat (talk) 04:35, 29 August 2026 (UTC)Reply
Well, more to the point, if we could resurrect the data-collection software that was used back then, we could feed it any set of diffs we wanted, editors could score them however they wanted, and we could crunch the numbers ourselves. WhatamIdoing (talk) 04:48, 29 August 2026 (UTC)Reply
Ok, so the current implementation of it doesn't allow us to designate a specific pool for evaluation? I thought that's what you were saying in your initial comment. ChompyTheGogoat (talk) 05:06, 29 August 2026 (UTC)Reply
I find it absolutely enraging that WMF would drop an AI feature onto English-WP as some sort of a beta test because somebody got a wack idea, a manager approved it, and engineers made work and developed it. I ran into a driveby "Newcomer Task: Suggested: Revise Tone" editor on a page I was actively working on that was flagged with a CONSTRUCTION template just yesterday. That is how I discovered the feature. That is how little regard that WMF paid staff has for the community and for the decentralized community decision-making process that has served us well for two decades. If it were up to the tech-worshiping, unforeseen-consequences-damning preferences of WMF, Wikipedia would by now approximate Grokipedia-With-Junkets. Something like this should NOT be unilaterally implemented by the engineers without community discussion. And I don't mean displaying notice of the forthcoming change in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of the Leopard," either. Carrite (talk) 16:27, 28 August 2026 (UTC)Reply
The problem is that they were given a tool that encouraged them to spam out over 100 edits at a rate of roughly 1 every 3 minutes. No one fixed them for over two years, despite their very much needing fixing. Gnomingstuff (talk) 21:07, 29 August 2026 (UTC)Reply
The task itself is fairly simple: it highlights a paragraph containing language that the model has identified as commonly being reverted. In that respect, it is not all that different from the machine learning models that have been used for years to flag potentially problematic edits in Recent Changes. Revise Tone is also Community Configurable, so communities retain control over whether they want to offer the task. Any administrator can disable it if there is consensus.
Of course, I hope communities will choose to keep it enabled. Revise Tone, along with the other Newcomer Tasks, is intended to give people who are new to editing a relatively approachable way to make their first contributions. We know that getting started with Wikipedia editing can be difficult, and we need to provide newcomers with accessible ways to take that first step if we want to support the long-term sustainability of the projects. KStoller-WMF (talk) 22:35, 28 August 2026 (UTC)Reply
Community members were involved does not equate to consensus. This comes across (yet again) as "We're going to shove LLM down your throat, and if people protest loudly enough we'll consider removing it after the fact." And you wonder why editors are hostile to WMF involvement. ChompyTheGogoat (talk) 04:23, 29 August 2026 (UTC)Reply
I have asked for Newcomer Tasks to be disabled for several months now. I have done an audit on Newcomer Task quality -- the amount of good ones is dismally low. That's still true. I could do another audit, but I don't even know if that would help, because I have otherwise presented every piece of evidence I can possibly think of. There is no concrete evidence that anyone actually cares. (defined by anything actually being done about it beyond "we're listening") The situation is especially perverse for a number of reasons:
The articles hit by Newcomer Tasks are often articles that people tagged a long time ago. I assume that when they did so, their intent was not to make the articles worse, but that's what has happened.
The justification that we get, over and over, for why these are still around despite being a demonstrable net negative is the sunk-cost fallacy and how so much work has been put in. I don't know how to be any more polite here, but I don't care. If someone comes along and bashes a hole in my roof, I don't care how hard they worked to bash the hole, I care that my house is now being ruined by rain.
The other justification is that "well they're not being reverted so they must be good." The reason so many of them have not been reverted is because A) the firehose is spewing them out too quickly for "reverting" to even happen (in a way that puts the "reverted" tag on), and B) there are so many of them that everyone doing cleanup is swamped. The last time I brought this up I said I had over 100 tabs open with cleanup work. Now it's over 200. Just how fast am I expected to work to be able to make Number Go Down to a point that makes any impression whatsoever on the people who want see Number Go Up?
I don't remember anyone giving a sunk-cost justification.
Looking at Special:RecentChanges right now, I see just under 1,000 mainspace edits from newcomers (1–10 edits) in the last ~6 hours. About 11.5% of them are Newcomer tasks. 14% of them are already reverted. But: Only 3.7% of the Newcomer tasks are already reverted, whereas 16.2% of the non-Newcomer task edits have already been reverted. That's more than a fourfold difference. Newcomer task edits are only 23% as likely to get reverted as non-Newcomer task edits.
It might be that the daily ~4,000 mainspace edits from newcomers is more than our current Wikipedia:Recent changes patrol can handle. But it seems unlikely to me that the community is preferentially ignoring the Newcomer task edits, and if newbies using the Newcomer tasks are "only" as bad at editing as the rest of us were when we started, it would take a very significant level of ignoring edits to produce that big of a difference in the reversion rates. I therefore conclude that Newcomer task edits actually don't need to be reverted as often as other edits from newbies. WhatamIdoing (talk) 20:43, 28 August 2026 (UTC)Reply
Could you please respond to my numerous comments referring to the difference in editors who actually utilize the tool at all before you continue to rely on this logic? ChompyTheGogoat (talk) 04:32, 29 August 2026 (UTC)Reply
Sure: As has been pointed out repeatedly by multiple people in this discussion, Wikipedia:Long-term abuse socks, poop vandals, and other abusive actors might not look at Special:Homepage at all.
And as has also been pointed out, when you compare randomly assigned Group A, with the opportunity to complete newcomer tasks, against Group B, without that opportunity, and you see that Group A does the same or better than Group B on approximately every metric ever checked during the last ~seven years, even though most of the members in Group A never completed a task, then it's fair to assume that "actually using the tool at all" isn't necessary to get a benefit from it. The editors in Group A who use the tool are likely different from the editors in Group A who see the tasks and decide to edit independently (but who may have been influenced by the information they saw), and both of those subgroups are different from the editors in Group A who didn't look at the homepage at all, but there is no reason at all to assume that the randomly assigned members of Group A have a different number of abusive editors than the randomly assigned members of Group B, none of whom had the opportunity to see the page. And since Group A, including its voluntary non-users and its fair share of abusive editors, did much better than Group B, it's reasonable to think that the tool actually improves behavior overall. WhatamIdoing (talk) 05:02, 29 August 2026 (UTC)Reply
The Revise Tone experiment compared two different types of newcomer tasks, not a control group without any access to them at all. And the Add-a-link link is (ironically) broken (404). ChompyTheGogoat (talk) 10:05, 29 August 2026 (UTC)Reply
Yes, the individual subtasks have differing levels of value, which is why proposals, such as yours at the top of this thread, to remove all of them indiscriminately, are a bad idea. We should keep the ones we like, configure the ones we're okay with, and turn off the ones we dislike. WhatamIdoing (talk) 16:30, 29 August 2026 (UTC)Reply
Add a link is probably the only one I've seen that doesn't cause blatant issues, but I have to wonder if the lower reversion rate is simply because it's such a minor change (and a judgement call on whether or not it's appropriate in a given situation) that patrollers often won't bother, in comparison to edit types that are more prone to cause issues in general. Copyedit or revise tone can insert statements that are flat out incorrect (as with the instigating edit I saw), to say nothing of more general edits that add or remove material. The feeling I get from the data in your link is that there's a slight benefit in terms of new editor retention because they feel successful, but not necessarily much benefit to the actual articles. It's essentially busywork. I'd rather have some kind of training module for different types of practice edits, but obviously that's a far bigger proposal. The reason I started out with "just shut it down" is because it's clear there have been ongoing problems with the tasks and discontent among seasoned editors for some time, but there doesn't appear to have been any concerted effort to improve things. If people aren't willing to make one, disabling them entirely is easier and would prevent additional problems going forward. ChompyTheGogoat (talk) 06:24, 6 September 2026 (UTC)Reply
I tried that early on and wasn't impressed.What part of "experienced editors spend a bunch of time patrolling and reverting bad edits" sounds like a net benefit? ChompyTheGogoat (talk) 17:38, 6 September 2026 (UTC)Reply
Because if we've got a thousand edits from newbies, our realistic options are:
We get a higher rate of bad edits, requiring experienced editors to do more reverting, and we end up with fewer editors coming back on a subsequent day/week/month, causing Wikipedia eventually to die.
We get a lower rate of bad edits, requiring experienced editors to do the same amount of patrolling but less reverting, and we end up with more mid-level editors, giving Wikipedia a chance to survive the next 20 years.
The option in which edits from newbies don't require "a bunch of time patrolling" doesn't exist. The thing we can actually affect is the number of reverts and therefore whether the newbie will try again another day. WhatamIdoing (talk) 20:24, 7 September 2026 (UTC)Reply
And I'm not convinced most newcomer tasks accomplish that. In fact, I feel like it's more discouraging to have something reverted when Wikipedia specifically said "this is something that needs to be fixed and we think it's an easy task that you can handle without experience" as opposed to something that a newbie chooses to try to improve on their own. If we're going try offer them specific work, the work needs to actually be appropriate and provide support to maximize their chance of success. It's like starting a new job with no experience and having someone plop a pile of work on your desk with minimal instructions, then come back at the end of the day and tell you you've done all of it wrong. I sure as hell wouldn't be coming back after that. In my metaphor I chose to instead wander the halls looking for things that I felt competent to work on and asking whatever editor happened to be passing by any questions to try to ensure I was doing it correctly, which helped keep my reversion rate down and my confidence up (somewhat). I also spent lots of time dropping into random "meetings" to learn from the discussions instead of diving headfirst into editing without a foundation of knowledge to work from. A successful workplace with low turnover would offer more structured support to new workers instead of this sink or swim philosophy. ChompyTheGogoat (talk) 02:21, 8 September 2026 (UTC)Reply
I don't think that's something you can quantify. The effect it'll have on motivation and retention depends entirely on the editor in question, and of course how often it occurs. If they make a whole mess of edits right away thinking they're doing the right thing because it was recommended and come back to find a large number of them have been reverted that's a far greater impact than my initial "oops, my keyboard inserted a blatant error" reverted edit. I fixed it and went on with my day. If they do something similar with a single newcomer task and get reverted before continuing, maybe they realize things are more complex than they thought but don't get as offended because they didn't devote that much time and effort to it. It's all situational. ChompyTheGogoat (talk) 03:24, 8 September 2026 (UTC)Reply
I think that a good economist would say that everything can be quantified. Actuarial work seeks to quantify just how much worse it is to lose a thumb than to lose a toe, or to die when you're 35 than when you're 55 or 75, so I'm pretty sure that it's possible to quantify whether it's worse to be reverted for a suggested edit in an article you don't really care about vs an organic edit in an article on a subject that interested you. It might be situational, but there will still be an average. And based on that average, we can easily determine just how much better system A has to be, compared to system B, for the benefits to overcome the disadvantages.
Just because capitalism assigns a dollar value to human suffering doesn't mean it's an appropriate approach to life. Still only seen a single clear stat for retention from a valid A/B test on the link suggestions - not other tasks or the newcomer module in general. You cannot extrapolate from the least problematic type. ChompyTheGogoat (talk) 09:43, 8 September 2026 (UTC)Reply
@ChompyTheGogoat We've run several other A/B tests that include newcomer retention stats, a few others are here:
Revise Tone Experiment analysis - this was one of our first experiments using a new testing platform (Test_Kitchen), and if I'm remembering correctly, Newcomer Retention simply wasn't an available metric at the time we tested, which is why we looked at "Constructive Edit Rate" for this experiment. We now have short-term and long-term retention metrics defined and we plan to use them for future experiments.
I also wanted to share that the work the Growth team is doing on Home is aimed to help address some of the gaps you have identified in this thread: newcomers should receive more relevant suggestions, more learning support (including short micro-learning videos), and more opportunities to grow and progress on to more meaningful work on the wikis. I won't pretend that this one project is an answer to everything you raised in this thread. But I think it's another step in the right direction to support newcomers, and should hopefully address some of the Newcomer Task frustrations you've named.
One thing I'd especially like your take on: do you think there a future where junior editors take on more of the reviewing and patrolling of "low risk" newcomer edits? You gestured at something like this above with the patrol group idea. Right now that work falls to the most experienced and busiest editors, so a very basic newcomer edit can end up costing several of them time that could go toward harder cleanup work (or perhaps just more enjoyable wiki work). - KStoller-WMF (talk) 22:51, 8 September 2026 (UTC)Reply
Sure - I don't think it's particularly difficult work. It's not something I'd personally dedicate a lot of time to, but I'll frequently take a quick look through a newcomer's edits and try to address any issues I spot, and I'm sure there are others more involved with welcoming/outreach that wouldn't mind setting aside a bit of time for it. Most editors who are ECP could probably do it. I find work like that useful in small doses for improving my own skills via checking sources and pulling up the relevant guidelines, as well as expanding my horizons on subjects I wouldn't normally look up on my own. I do think it would be helpful to implement a tool that allows said editors to verify a given edit has been reviewed so others can skip over it, although it wouldn't necessarily need to be removed from the list altogether. A checkbox would probably be fine (might be scriptable?) If it's something that needs to be fixed but that editor doesn't feel like addressing it in that moment they just leave it unchecked and it would still show as unreviewed. ChompyTheGogoat (talk) 23:09, 8 September 2026 (UTC)Reply
@KStoller-WMF, I think that patrolling "obvious" edits (both obviously good and obviously bad) is a good way to get started in anti-vandalism and other patrolling efforts.
That said, there's a risk: highly active RecentChanges patrollers don't like doing difficult clean-up work, and if one were to filter most of the easy reviewing work out, they'd feel like a fun, high-speed, usually easy task had become a long, slow slog. Speed appears to a significant motivator for some of the long-time RecentChanges patrollers, and anything that makes them pause or slow down is demotivating. The little dopamine hit from reverting blatant vandalism is important. And no matter what the task, if it's always the difficult question, then that rapidly becomes tiring. This isn't unique to Wikipedia; there was research ~10 years ago about the problems that Facebook's underpaid reviewers had when their filtering system got better, and the review queue that had been a mix of reported posts became endless queues of serious problems. So if most of the easy calls were to be checked by newcomers, we might end up with fewer and fewer experienced editors doing RecentChanges patrolling. WhatamIdoing (talk) 00:21, 9 September 2026 (UTC)Reply
@ChompyTheGogoat Thanks for sharing your thoughts on the idea of reducing review redundancy. We have a software feature that could help with this, but it's currently not enabled on the English Wikipedia. On some other wikis, there's a 'patrol' button for each edit, so users can mark an edit as 'patrolled'. Other editors can then filter this edit out of venues like Recent Changes, and focus on unreviewed edits. There have been some discussions here about the feature, but no consensus to enable it. I'm interested in thinking about how we might be able to update the feature so that it could be enabled, if the community wanted to do so. I've been collecting notes at T409165 - would love to know if you have additional thoughts! Samwalton9 (WMF) (talk) 09:57, 10 September 2026 (UTC)Reply
There's a whole lot more to that story (some of which is under NDA). I don't think a task group focused on good faith newcomer edits would have too much impact on the overall Recent Changes workload though, and reaching out to help newbies who made honest mistakes appears to be one of the things that's lacking. I often see them reverted with only a cursory edit summary that would be sufficient for a more experienced editor, but isn't likely to help newbies learn from it - and I know regular patrollers might not even realize it's a newbie when they revert, but someone who's specifically patrolling for them would know and could take extra time to try to help them improve. ChompyTheGogoat (talk) 14:13, 9 September 2026 (UTC)Reply
@Gnomingstuff Thank you for taking the time to respond and for the previous audit work. I understand the frustration, especially the feeling that the cleanup burden has become overwhelming. Is there a particular task that you think is especially problematic, or do you feel that Newcomer Tasks as a whole are problematic?
I completely agree that we cannot equate “not reverted” with “good.” It is, however, one of the signals we have available. Looking at English Wikipedia article-namespace edits from January through July 2026, among editors with fewer than 30 days of tenure and fewer than 100 edits:
Newcomer edits overall had a 30.1% revert rate (900,292 of 2,994,419 edits). [1]
Edits made through Newcomer Tasks had a 4.7% revert rate (5,416 of 115,188 edits). [2]
There is an important caveat to this comparison: people who choose Newcomer Tasks are likely good-faith editors, while the overall newcomer figure includes vandalism and other clearly problematic newcomers. So this comparison almost certainly overstates the difference. And, as you point out, neither number captures cleanup that happens without a formal revert. Even with those caveats, though, the data suggests that Newcomer Tasks are not disproportionately contributing to the revert workload relative to newcomer editing overall.
The reality is that newcomers will always make some mistakes as they learn. That is part of bringing new people into the project. At the same time, I do think there are several promising projects underway that should help:
Better onboarding and task matching: The Growth team is working on early onboarding changes, including changes to the Newcomer Task feed. We are working toward a smaller, more curated set of tasks that better matches contributors to tasks based on skill level and interests.
More accurate Add a Link suggestions: The Machine Learning team is working to improve the accuracy of Add a Link suggestions, which should reduce the number of poor-quality suggestions reaching newcomers (T434259). The Growth team will also work on an Add a Link improvement soon that will both decrease the quantity of suggestions available and also increase the quality of suggestions (T429417).
More learning support: The Community Development team is working on "micro-learning" videos based on the Wikimedia Core Curriculum, giving newcomers more guidance at the point when they need it.
Catching mistakes before publication: The Editing team's Edit Check work catches some common mistakes before they are published.
Expanding the moderator pool: The Moderator Tools team is working on ways to onboard moderators and patrollers, so that the work of reviewing newcomer edits can be distributed among more people.
None of this clears your 200 tabs today, and I don't want to pretend that it does. But the direction we're investing in is fewer, better-matched tasks, with more support for newcomers and better safeguards around the edits they make, while also helping newer editors develop toward appropriate moderation and patrolling roles.
@KStoller-WMF, would you also consider coming up with some better way to categorize articles for the purposes of showing "relevant to your interests" articles to newbies? There's someone complaining about that upthread, and I recall also finding this pretty useless for the same reason. I was under the impression that those ORES topics were going to be replaced by something much better years ago, and that hasn't happened. Is anyone still working on that? In solidarity, asilvering (talk) 21:42, 28 August 2026 (UTC)Reply
Design showing how newcomers could select articles of interest before arriving to their Homepage
We hope to release an A/B test as early as next month in which we actually allow newcomers to select articles of interest to populate a more limited set of suggestions. Related project page: https://www.mediawiki.org/wiki/Home
@KStoller-WMF, this is much better!! All the articles it gave me are related to my interests, and none are in quite such a horrible state that it's depressing to look at them. And, well, it couldn't have known, but... it suggested one of my own articles (Richard Caudray) for expansion. In solidarity, asilvering (talk) 22:26, 28 August 2026 (UTC)Reply
My suggestions are also much better, but I can't click through to check on anything. The crosslinks and references tasks seem reasonable - I'm not sure what "bring up to date" is looking for, which sounds rather vague. I didn't get any revise tone suggestions, which I honestly feel is better because newbies don't have a good feel for Wikipedia voice and NPOV yet - especially since it's marked an "easy" task, which to me should be the very first edits someone ever makes. Crosslinks and basic copyedit are about as easy as it gets. (Crosslink suggestions aren't always accurate or needed, but very low in terms of the actual problem they cause.) ChompyTheGogoat (talk) 05:01, 29 August 2026 (UTC)Reply
I'm going to WP:AGF and assume that a WMF employee knows better than to use LLMs in discussions - we know these tools aren't fully accurate - but I cannot stress enough that if you're spending so much time engaging with AI that you start to sound like them you should seriously check yourself. ChompyTheGogoat (talk) 04:48, 29 August 2026 (UTC)Reply
All of the tasks are net negatives in practice with the exception of Suggested Links, since the damage an individual editor can do with it is very small and contained, and does not affect the prose.
The type of the task also doesn't matter, as people disregard it all the time. Just a few examples taken from the hundreds of tabs I am slogging through:
Special:Contributions/HelloHop (Note the **Suggested edit-summary (copy-paste into the “Edit summary” box):** chatbot response in one edit summary, an indication of how thoroughly this person reviewed the edits they have spammed out)
Have you looked at the edit trail of new editors to try to classify their intentions? My guess is that some people have rather specific goals, e.g. taking political positions in a specific country. Others become unhappy when they see glaring errors in technical articles and feel they just have to fix them. Others feel that their small town has too little info. Others may be ....? Have you done a survey on this? It would be interesting to know. Thanks. Yesterday, all my dreams... (talk) 02:00, 5 September 2026 (UTC)Reply
Let's not forget that their response to sunk cost concerns is to barge ahead anyway instead of pumping the brakes, so I have zero sympathy for that at this point. If you want to ensure your work will have a lasting beneficial impact, make sure it's something anyone bloody well wants before you ram implementation through. Or eat the consequences. ChompyTheGogoat (talk) 04:30, 29 August 2026 (UTC)Reply
Sunk cost fallacy is one of those power words that power users like to throw around, usually when they have a gut-level revulsion to a change and don't think they'll be able to stop the change. There's a relevant source linked at the end of Wikipedia:You don't own Wikipedia that might prove to be interesting reading, if you haven't seen it before.
But, as a point of fact, the stated response in that discussion (which comes from a long-time Wikipedia editor, BTW) is that they've designed this project so they can easily "abandon" anything that doesn't look promising. A lot of the ideas the WMF evaluates don't see the light of day (e.g., the most recent round of "let's change the font!", which comes up every five years or so – but never from someone who lived through the last attempt), so you probably wouldn't hear about them unless you watch phab: regularly. Consequently, it is important not to assume that the continuation rate for the few projects you've heard of is the overall continuation rate. WhatamIdoing (talk) 05:23, 29 August 2026 (UTC)Reply
Perhaps not, but it seems to be their preferred response on these related subjects. It was clearly communicated that numerous editors are uncomfortable with that project and a desire for consensus was expressed, and the response was "we can always abandon it later", which does nothing to address the underlying concern. Do they believe the community is going to magically change our opinion on LLMs by that point, or are they then going to argue that they should keep going after putting so much work into it? What harm does it do to pause and see whether people really do want this tool at all, instead of "what suggestions can be used going forward because we're definitely going forward"? It feels like they're willing to reconsider specific aspects based on input, but not the project as a whole. Rather WP:IDIDN'THEARTHAT of them, IMHO. ChompyTheGogoat (talk) 05:57, 29 August 2026 (UTC)Reply
No, but they might believe that (a) people who haven't tried the tool don't have the information they need to make an informed decision, and (b) that even if the tool is abandoned, something useful could be learned from it. And, of course, we all know that (c) the ~five dozen people in that discussion, some of whom support the project, are not even remotely representative of the three-quarter million registered editors who make at least one edit in a given year.
More generally, we have the problem that (d), if you reach out to the communities early in a project, when it would be cheap and easy to abandon it, then people don't understand the project or its goals, and even complain that you brought the idea to them so early, when you don't even know how it will behave or whether it works or what it looks like. But if you bring it to them later, when you can provide solid answers to most of their questions, they say "How dare you not involve me early in the process! Nobody asked for this! (Pay no attention to those diffs behind the curtain that prove that someone else in the community did ask for it.) It wasn't discussed! (a common enough complaint that experienced people create lists of prior discussions such as Wikipedia:Vector 2022#List of discussions, but you still get nonsense, like this IP claiming "that nobody saw" an RFC that 344 people participated in) I hate it! (but a couple of months from now, I'll probably have gotten used to it). It was before your time, but the RFCs for Vector 2022 was so predictable (and predicted) that I should have started a betting pool on when the first rollback RFC would be started, measured in hours after deployment.
The WMF product folks who are involved in the project being discussed likely remember my views on anything that sounds like Microsoft's Clippy: I'm not a fan. But I don't think that the work they're doing is useless, or that any editors will be forced to use it. WhatamIdoing (talk) 06:42, 29 August 2026 (UTC)Reply
Consensus is never expected to require input from the entire editor pool, just enough who have interest in the specific proposal to get a solid feel for the overall sentiment based on rational arguments (especially, but not exclusively, made by senior editors who do understand both the relevant guidelines and history of the subject on-wiki). And I don't think early consensus should be the final say on wide scale implementation, but an indication that most people think the general concept has enough promise to be worth developing and evaluating once it's functional. If they built a full Grokipedia style bot to write unreviewed articles and didn't listen to the community until it was in on-wiki testing I expect there would be a few opinions. I also did read your previous reference to Wikipedia:You don't own Wikipedia and I really don't feel it applies in this situation. Obviously not to me - I haven't even been here for a year, but I've seen how much harm AI can do both on wiki and off, and I've seen how the general community feels about its implementation, as reflected in existing guidelines. I've also seen similar sentiments on a smaller scale when it comes to newcomer tasks, which is why I started this, and I'm not at all surprised to learn it's also AI because the randomness and low quality of the suggestions is exactly what I expect from slop that can't comprehend the task at hand because it has no comprehension. An RfC would garner input from a wider variety of editors so no "power users" can attempt to strongarm their opinion through. Obviously the WMF should and does have ultimate authority when it comes to legal issues, finances, etc - but that's not what this is. Individual projects are supposed to have a wide degree of latitude for how to manage content that doesn't cross any legal lines, and English wiki is largely against AI implementation. If they want to develop it for different projects that have wider acceptance, have at (but I suspect they wouldn't devote the resources to it if we reject it from EN). ChompyTheGogoat (talk) 09:38, 29 August 2026 (UTC)Reply
@ChompyTheGogoat, the way WAID's essay applies here is that we desperately need more new editors to step up, to replace those of us who inevitably will wander away from the projects (or die in office). It's going to be a group effort to make the projects more welcoming to newcomers, and this is one possible way. AI has some real promise in surfacing appropriate tasks for newcomers, because of the WP:SOFIXIT attitude that longtime editors have - if we spot something easy, we just fix it ourselves. That means that what's left - the stuff that's tagged - is often an absolutely horrible slog to deal with. That was my own experience of the newcomer homepage, when I started - it was entirely the tasks generated by maintenance templates, and what it sent me to was articles so broken that I felt completely demotivated to try to fix them. The tool was suggesting I get some basic editing experience in, and sending me to articles that needed to be completely rewritten, not things that were a quick job at all. Things like the suggested links task and revise tone can help find spots that need help that are much more within the capabilities and inclinations of newbies. In solidarity, asilvering (talk) 16:58, 29 August 2026 (UTC)Reply
Revise Tone is precisely what I've seen the most problems from. It might look easy to someone who doesn't know what they're doing - because they don't know what they're doing. I'm not sure that one can be fixed either, because "phrases like these often get changed" is in no way shape or form indicative that it's a simple task appropriate for new editors, and just changing it doesn't mean it's been improved. It might be useful as a feature that more experienced editors can utilize, or as a flag that pops up to indicate the problematic phrase when someone is already editing the article in question, but we need to keep newbie tasks simple and more objective (if we keep them at all). ChompyTheGogoat (talk) 06:53, 6 September 2026 (UTC)Reply
Sounds good in theory, except it only applies to visual editor. Most seasoned editors (who would have the skills to handle more complex and subjective situations) use source mode. Hopefully they can expand it with additional implementation.In any case, that's neither here nor there re: newcomer tasks. ChompyTheGogoat (talk) 20:04, 6 September 2026 (UTC)Reply
Most experienced editors use both editing environments, based on what kind of work they're doing. Choose the visual editor for copyediting and table structure edits; choose one of the four wikitext editors for fixing wikitext problems. And, of course, you don't always have a choice: the 'Undo' button always uses the 2010 wikitext editor, no matter what your preferences say (and falls back to the 2003 WTE if you have javascript disabled). WhatamIdoing (talk) 21:54, 7 September 2026 (UTC)Reply
I've spoken to many editors who've been around for a long time and don't know how visual works because they're never felt any need to use it. I hardly ever toggle it myself, despite mostly editing on mobile. I only leave it switched on for diffs. Regardless, if they don't think the work they're doing at the time requires visual and don't see that the flags exist, they're useless in that scenario, so I think wider implementation for as many editors to see them as possible (whether or not they choose to address it in that moment) would improve outcomes. I fix a lot of things that I stumble across at random, and if I had something flagging a wide variety of issues I'd usually at least take a look to see if it's something I felt capable of doing. That's a much better use of such features than serving them up to newbies. ChompyTheGogoat (talk) 02:31, 8 September 2026 (UTC)Reply
Many editors only do a narrow range of tasks. I've never met one that preferred adding a column to a table in the wikitext editor after they've experienced doing it in the visual editor, even among those of us (including me) who can type the wikitext syntax by hand from memory. WhatamIdoing (talk) 03:16, 8 September 2026 (UTC)Reply
And how much of the total editing on all of Wikipedia involves adding columns to tables? That's certainly a narrow focus. As I said, some editors will choose not to address the flag while they're there, and that's fine - but some will. The same people who might not actively seek out the article from some list of such problems might be willing to make additional improvements if they're already there working on whatever they're personally interested in. The more eyes on it (especially experienced ones) the better the odds are that it'll get addressed appropriately. ChompyTheGogoat (talk) 03:28, 8 September 2026 (UTC)Reply
The problem with a non-representative group of editors is that you don't "get a solid feel for the overall sentiment"; you instead "get a solid feel for the overall sentiment within a non-representative group, which may or may not differ significantly from the overall sentiment of the whole community". Sometimes there's no important differences; that's why most RFCs, with a typical participation of 5 to 15 editors, work. But sometimes it does matter.
I suspect that the bigger weakness with the Small language model is that it can't compare article content against source content, so calling William Shakespeare "the greatest writer in the English language and the world's pre-eminent dramatist" will seem puffy, and that saying Martin Shkreli has a "reputation as 'the most hated man in America'" will seem disparaging. But both of these are justified by the sources, and the SLM machine learning tool has no way of knowing that. WhatamIdoing (talk) 17:16, 29 August 2026 (UTC)Reply
What's your definition of a representative group in this context? We're not going to get an even slice of the editor population, because people who don't have an opinion on it (which is likely to be most of them) won't chime in. How do you propose improving said group, except through RfC? We have the tools we have. ChompyTheGogoat (talk) 06:56, 6 September 2026 (UTC)Reply
I'm not at all surprised to learn it's also AI
Just to clarify, the problem is that people are using AI to spam out the tasks. If people weren't using AI to spam out the tasks, there would be less of a problem. But the tool itself encourages this behavior, by design:
The gamification system, by design provides an incentive for them to do so as fast as possible so Number Go Up as fast as possible, and provides repeated praise, implicitly and explicitly, as they do it.
The tool funnels them to articles that have already been identified as problematic, making those articles worse: a slap in the face to everyone who tagged articles for improvement in good faith because they wanted them improved.
The tool funnels multiple editors at a high speed, meaning that those articles' edit histories become so drowned beneath bad edits that none of them can be reverted without painstaking work. Essentially, it gives less-trafficked articles the edit volume of something on the front page, except without the people watching it.
I have the impression that Chompy's concern is that the "Revise tone" task is using a Small language model to find pages for its suggestion list.
I've just done six Revise Tone tasks. Five needed help, sometimes badly. The other was correct. It only proposed changes to a single paragraph at a time. It promptly asked me to switch to a more advanced task. If we're concerned about people doing too many of these in a single day ("as fast as possible so Number Go Up as fast as possible"), then maybe we should ask for daily limits. WhatamIdoing (talk) 00:32, 30 August 2026 (UTC)Reply
Drive-by comment:
I skimmed through the overly tedious conversation. Apparently, the filing editor wants to upgrade the newcomer task feature or remove it, citing concerns over whether the tool is accurate, and how the new editors leave out work for the more experienced editors to fix. While I support a better system, it appears that this is just a WP:Competence is required case. Also, reading through, I am unsure what exactly they want to change. Further, this newcomer system is flawed by design, making a negative feedback cycle.
Is it possible that some PendingChanges type of monitor list shows a subset these edits for human review? Or, change the system so there is a complete Wikipedia course, something that is quite lacking to newbies. 16dvnk (talk) 11:46, 1 September 2026 (UTC)Reply
However, there doesn't seem to be a way to approve or decline the edit, and what you suggested is a very tedious way. Given that PendingChanges has manpower and the backlog is often empty, it would be nice if those had their own place too. 16dvnk (talk) 14:16, 5 September 2026 (UTC)Reply
Well, there is no way to approve or decline the edit, because Newcomer Tasks are not under pending changes protection. They are just edits that anyone can make, which I think is the whole point. You can still patrol them and revert them if you would like to. Cheers, SunloungerFrog (talk) 15:52, 5 September 2026 (UTC)Reply
If you (anyone) want to check them, then this RecentChanges link will give you a list of all newcomer task edits. At the moment, it looks like it's a bit less than half adding links, a third copyedit/revising tone, 10% adding refs, 5% updating outdated articles, and 5% expanding articles. The 'tags' button on the side will let you change the all-encompassing newcomer tasks tag to a specific tag for just one of these, if you want. WhatamIdoing (talk) 00:42, 6 September 2026 (UTC)Reply
That's just it - it is flawed by design, and when the entire purpose is to improve the level of competence we shouldn't have features that require advanced competence to understand how to utilize them correctly. ChompyTheGogoat (talk) 06:59, 6 September 2026 (UTC)Reply
I'm not sure that "the entire purpose is to improve the level of competence". I'm not sure that any of its goals could be fairly described as "the entire purpose". WhatamIdoing (talk) 19:55, 7 September 2026 (UTC)Reply
If we don't want new editors to get better at editing what are we even doing here? Why provide them any support at all? We don't want to retain them if they only continue to make bad edits. We block people who refuse to improve to a basic extent under WP:CIR. Shouldn't the goal of every editor be to always continue improving their abilities? It's a huge learning curve and if we can get them up that initial steep slope they'll be more empowered to continue improving on their own. ChompyTheGogoat (talk) 02:36, 8 September 2026 (UTC)Reply
Which goals would still be relevant even if editors never improve in any way shape or form? If it's "Retaining more users that can improve their competence and make constructive contributions" that's a sub-goal. Would you prefer "The primary goal upon which all others should be contingent"? ChompyTheGogoat (talk) 09:51, 8 September 2026 (UTC)Reply
Yes, that is what I meant (although the use of AI to compose edits is certainly a secondary problem too). Whether or not the tasks are identified correctly is also just part of the issue - it's whether these brand new editors who don't know anything about the subject or how Wikipedia works can actually make a substantial improvement in a very subjective situation.I've also make numerous suggestions regarding expanded introductions to editing for new users that would help them understand the basics before they start editing. I have no idea whether those suggestions are being seriously considered or not. ChompyTheGogoat (talk) 07:02, 6 September 2026 (UTC)Reply
If you think that expanded introductions will help, why don't you draft some suggested content for those expanded introductions somewhere for others, e.g. on the WMF Growth team, to consider? And I couldn't see it anywhere above (may have missed it) but does Help:Introduction cover some of the topics you would expect to see put in front of new editors? I think I remember seeing it early on, but can't quite remember when it was surfaced. Cheers, SunloungerFrog (talk) 08:00, 6 September 2026 (UTC)Reply
Wikipedia:Nobody reads the directions (except Chompy). Seriously, we have three-quarter million registered editors making an edit each year, and the number of people who later say that they read a lot of help/policy/etc. pages before making their first edit appears to be a single digit number. Per year. For typical newcomers, the iron laws of the internet (e.g., WP:TLDR) apply. WhatamIdoing (talk) 20:00, 7 September 2026 (UTC)Reply
And yet I still see so many people saying they had no idea such resources existed. If we smack them in the face with it and they choose to ignore it, then and only then can we hit them with WP:CIR. Much like the AI and COI affidavits would remove plausible deniability. Part of WP:AGF is ensuring people have every possible opportunity to do things correctly. I don't think my particular skillset is so much the willingness to read guidelines, which is required of all editors, but the ability and determination to go to extra lengths to look for things myself. I can't count the number of times I've gone to fix something, then wondered where there's any relevant guidance that would ensure it's both necessary and correct, and proceeded to spend far more time looking for said guidance than it takes to actually make the edit. Once you have some idea of the basics (which would be presented in my pop-up idea) it's easier to know what else you might need to look up in other situations, and I've also made recommendations for improved organization to enable people to find such things easily, but you still have to know they exist in the first place. ChompyTheGogoat (talk) 02:48, 8 September 2026 (UTC)Reply
As an aside, I did not in fact read any guidelines before my very first edit, because I alsodid not know they existed. Fortunately it was a very simple correction to mirror the source that I'd continued my reading on, so I didn't need any specialized WP knowledge. I just wanted to fix that single passage and didn't try to make any more live edits right away, so I got welcome templated and (presumably?) followed that link to Teahouse, and gradually found my way to additional resources before continuing to do any substantial mainspace edits. I think it would be extremely beneficial to encourage other newbies to hit that pause button for anything beyond a single minor correction that motivated them to start editing in the first place. If they come here with the general goal of working on Wikipedia instead of fixing a specific issue they spotted as a reader then taking that time to learn how to be successful shouldn't be a deterrent. ChompyTheGogoat (talk) 02:58, 8 September 2026 (UTC)Reply
Regarding "the tool funnels them to articles that have already been identified as problematic" that can be a serious problem and can also cause chaos in software management. Sometimes new programmers who can not be trusted to write major new pieces of code are assigned the task of "fixing" bugs in the system. In the process they introduce many new bugs, exactly because they are newbies. Only one word can describe the situation: nightmare. Yesterday, all my dreams... (talk) 13:15, 7 September 2026 (UTC)Reply
It's somewhere around here, and I think one of their team was involved with the latest discussion. I want to see a "Welcome to editing" pop-up that appears when you first create an account (or attempt to edit from a TA) that will give a very brief overview of the most critical policies and common mistakes, and links to various other resources for continued learning. The more proactive we can be instead of reactive the better retention is likely to be. It currently feels like you're tossed directly in the deep end and have to keep your head above water while searching for a flotation device - then maybe someone stops by and offers to help. We should loop people from WikiEdu in and try to learn from what's worked for them; condense the basics down for people who don't have access to those programs and need to be able to learn on their own. There's a lot more we could do as far as things like training modules, but I think this is one of the simplest things that could be implemented quickly and would have a huge impact. The goal would be to keep it under 5 minutes reading time (preferably more like 2) but strongly encourage them to follow the additional links. It would also be skippable for people who already know what they're doing. ChompyTheGogoat (talk) 09:43, 6 September 2026 (UTC)Reply
Sorry, I should've been clearer: I meant "I can't remember when I saw Help:Introduction when I first started editing" not "I can't remember when Help:Introduction first came up in this thread".Re your popup, I am trying to think what I would have done had I been faced with such a thing when I started editing, and I'm afraid that I would probably have done whatever I needed to do to make it go away - ticked the boxes, clicked OK, chosen "Skip", whatever - so that I could get on with the edit I wanted to make. I won't generalise from my experience, but it certainly wouldn't have had a huge impact on my editing.
You might have clicked out if you already felt confident that you knew what you were doing, but many wouldn't, and it would start with a splash screen saying essentially "We're glad to have you, but there are a lot of rules and we want to help you avoid common mistakes so we strongly recommend reading the following if you're new here". I probably would have read it - I made a couple TP suggestions before actually creating an account because I was afraid of screwing up if I tried to edit an article directly - and in fact my very first live edit WAS reverted, but only because of a glitch with my phone. The issue isn't necessarily what resources are available, but people being able to find them easily. ChompyTheGogoat (talk) 17:37, 6 September 2026 (UTC)Reply
Help:Introduction wasn't even created until 2015, so I think that it's fair to assume that more than half the admin corps definitely didn't read it before starting. The problem with "if you already felt confident" is that confidence is a poor predictor of knowing what you're doing. WhatamIdoing (talk) 20:14, 7 September 2026 (UTC)Reply
Obviously. We can't force people to read, but we can at least provide them with the opportunity. Isn't your base argument than any improvement is a win? We're obviously not going to see 100% success from literally anything. And I would recommend that the initial splash screen (possibly with additional details on the second slide) try to stress exactly why it's so important to understand how things work, and that we really want them to be successful instead of being reverted because they didn't know something basic. If people can't even be bothered to read a few sentences right in front of their face their chances of making it as an editor are far lower. Some of them are going to wash out - it is what it is. Our target audience is good faith editors who are WP:HERE and truly want to make edits that are constructive and well formed. We can't change their motivations, but we can provide them with the tools to learn if they choose to utilize them. ChompyTheGogoat (talk) 03:06, 8 September 2026 (UTC)Reply
If our target audience is people who "truly want to make edits", we should close up shop now and go home, because we're going to die for lack of editors. Most people don't "truly want to make edits". Most editors start off in the range of "eh, I see a typo, and I heard you can edit" and (just) a few of them find the experience so appealing that they keep doing it. Prior research has shown that even putting a small barrier in between the newcomer and their first edit causes significant reductions in the number of edits. We are operating on a principle closer to "First one's always free, kid" than on "Please read the instructions before you touch the delicate machinery".
As you say, "we can't change their motivations", which is mostly either "I'm willing to help out if it's really easy", but we can avoid putting up barriers. I particularly object to your desire to "hit them" with a complaint that they're incompetent if they don't read, remember, and follow all the directions (most of which will be irrelevant to most of their intended edits) before making their first edit. As I've said before, Wikipedia:Too long; didn't read is one of the iron laws of the internet. If you make people read a bunch of stuff first, they'll quit instead. We need them to try that first edit. WhatamIdoing (talk) 18:00, 10 September 2026 (UTC)Reply
That's a blatant misinterpretation of what I said. Not only did you literally drop the inconvenient part of a sentence, but I specifically said we can only apply WP:CIRif they've had the opportunity to learn. As in, we cannot expect competence if they don't, and I certainly didn't mean for their very first edit. If we could manage to stop more of the editors who will mostly or exclusively make bad edits during their tenure, I'd call that a win. More editors isn't always a good thing. Of course it's significantly harder to track complex stats such as "how many good edits are made over time" instead of just "how many new editors make their first edit", but you can't know what the effects are at all if something hasn't been tried. Testing is important. As I've already stated, using encouraging language and making it easily skippable would both be priorities. I'm definitely the person who skips through tutorials most of the time, because usually what I'm doing is easy and obvious, but this is one situation where I was less sure of what I was doing and would have welcomed more information. When I did find that information later it drew me into editing (particularly Teahouse) instead of pushing me away. If I hadn't found the discussion boards I highly doubt I would have come back. For people who do skip it and make a mistake, we continue to treat them the same way we do now. Really the only difference in how experienced editors respond to newcomers would be if they agree to the COI and AI affidavits and then violate them. Otherwise we're just providing them with more information and hoping it improves their rate of good edits and lowers necessary reversions, which then improves retention of those that are reasonably competent. Washing out those who aren't (despite being offered resources and given multiple chances) is the system working as it should. ChompyTheGogoat[Bleat|Munched]18:41, 10 September 2026 (UTC)Reply
Which is kind of the problem here, because if someone doesn't understand why an edit like Special:Diff/1373682228 does not change the tone at all, then all the Wikipedia training in the world is not going to help a problem that's fundamentally about English writing/editing skills. Gnomingstuff (talk) 15:24, 7 September 2026 (UTC)Reply
I don't mean this to be rude, but this is a strange and overly literal interpretation of what I pointed out. Adding one preposition to anything is unlikely to change its tone. It might change its grammar, or fall into one colloquialism or another ("he found that" vs. "he found out that"), but the edit above doesn't change the tone, and I highly doubt the person can explain why.
Basically, the problem is that this editor is not proficient enough in the English language to do English-language editing tasks, much like I am not proficient enough in the Swedish language to do Swedish-language editing tasks. Newcomer Tasks are not equipped to teach people English, and the English Wikipedia interface should stop encouraging them to do something they currently cannot do well. (Of course, the editor could always recognize by themselves, on their own volition, that this isn't their skill set, but for whatever reason people don't do that.) Gnomingstuff (talk) 05:59, 9 September 2026 (UTC)Reply
I think that plot summaries, particularly in fantasy or other forms of non-realistic fiction, are highly likely to correctly contain phrases that seem to have tone problems. The problem isn't the edit that was made; the problem is that the Revise tone task suggested improving that plot summary in the first place. WhatamIdoing (talk) 18:13, 10 September 2026 (UTC)Reply
They may or may not be capable of doing the actual work, but I still think the bigger issue is not understanding what's being asked for in the first place - just like I wasn't, and not for lack of English skills. I've seen plenty of other fluent editors have the same problem. But we're in agreement on the tasks encouraging them to complete work that they don't actually comprehend. ChompyTheGogoat (talk) 14:04, 9 September 2026 (UTC)Reply
Precisely my point. They don't even understand what the task is meant to accomplish, in addition to not flagging things appropriately. The feature itself is the problem. ChompyTheGogoat (talk) 02:02, 8 September 2026 (UTC)Reply
I've already made my case for "this phrase often gets changed" =/= "this is a simple fix that a new editor with no experience can handle correctly without additional instructions". If this person really understood what the task is asking for they might have made a better change, OR they might have realized they aren't up to it and just skipped it entirely. Both would be a better outcome. ChompyTheGogoat (talk) 03:10, 8 September 2026 (UTC)Reply
But they did "skip the suggestion entirely". And while they were there, they made a small change that wasn't related to the suggested edit.
Do you understand that if it makes a suggestion, then the tag is there, even if you decide that the tag is wrong? "Tags: Revise tone" is not a promise that the edit attempted to revise the tone. It's a paper trail explaining how the editor arrived at the article. WhatamIdoing (talk) 07:22, 8 September 2026 (UTC)Reply
Are you confusing different examples? This editor made numerous good faith edits that are not useful and needed to be reverted, and asked their mentor for help understanding how revise tone tasks are meant to be accomplished numerous times in a row. If that doesn't indicate they don't understand the task then what on earth does?? ChompyTheGogoat (talk) 09:54, 8 September 2026 (UTC)Reply
That's a separate issue that also needs to be addressed, but there's still an overall failure to comprehend the tasks at all. Work that's specifically aimed at newbies should be reasonably self explanatory. After I reverted one and linked to the relevant guideline they came back and made a better edit, so they are capable of figuring it out if the information is provided. I don't really know what to say about the revise tone though because even I don't know what the task is asking. ChompyTheGogoat (talk) 12:49, 9 September 2026 (UTC)Reply
I don't think your examples above are proof that newcomer tasks don't work, it rather shows that some newcomers are doing low-quality edits, regardless of any attempts to guide them. Your first link Special:Diff/1373683524 is their attempt to find references – someone who reads the tutorial on finding references that pops up when doing the task and considers Reddit a good source, is unlikely to ever do good contributions to our projects imo. Johannnes89 (talk) 09:31, 9 September 2026 (UTC)Reply
is unlikely to ever do good contributions to our projects imo I think that's rather a sweeping statement. First, the editor may well have had good experiences outside Wikipedia with the accuracy of information on Reddit, so why would they think off the bat that it is an unreliable source? Second, maybe they missed the note on the fifth slide of the tutorial that social media is generally not reliable, or they might not consider Reddit to be social media - it is certainly user-generated, but the tutorial doesn't talk about the unsuitability of user-generated content. In this case, the edit was reverted with a decent edit summary, plus a corresponding talk page message, helping the editor to learn from the mistake. That is, I think, how we encourage and retain new editors, rather than dismissing them out of hand after they make a mistake on their fourteenth edit. Cheers, SunloungerFrog (talk) 10:07, 9 September 2026 (UTC)Reply
And I do understand that such reversions are a necessity sometimes, but I think the more proactive we can be with learning resources to try to keep reversion rates down, especially on the first handful of edits, the better retention will be. ChompyTheGogoat (talk) 12:53, 9 September 2026 (UTC)Reply
They literally came back and added a better source to that article after I reverted and linked to the relevant guideline. Clearly the task did not provide adequate support for them to understand it. ChompyTheGogoat (talk) 12:50, 9 September 2026 (UTC)Reply
Also, this is my experience with most newcomer task edits - I'm not cherrypicking bad ones. I literally just ran across this editor at random while this discussion was ongoing. I've seen very few newcomer task edits that were actually good, and it's almost always the suggested links because those are idiot proof (and cause no real harm even if they're incorrect). ChompyTheGogoat (talk) 14:25, 9 September 2026 (UTC)Reply
How strange. When I go through RecentChanges for newcomer tasks, I find that most of them are helpful, and some cause no real harm even if they're unnecessary. I find that only a small minority are actually "incorrect". WhatamIdoing (talk) 18:55, 10 September 2026 (UTC)Reply
How true is that if you skip link suggestions and only look at revise tone or the templated tasks? There's a lot less uptake on the templated ones, but when I do see an expansion done it often boils down to "more words must be good". There are occasionally good ones, but out of all the ones I've seen (not actively looking for them) they've been few and far between, from editors who seem competent enough that they would have done fine without the tasks. ChompyTheGogoat[Bleat|Munched]19:01, 10 September 2026 (UTC)Reply
Special:Diff/1374235678: The new URL works but the edit itself is promotional puffery (e.g., "a base camp" becomes "providing protection to allow them to rest and strategize)" that also changes meaning (the walnut trees got lost in the edit, RIP walnut trees)
Special:Diff/1374235831: Gets rid of low-hanging fruit but also changes meaning, the original text did not imply the battle was "swift" or rule out it being slow
I'm not sure I agree with all of your assessments.
I defer to you about the AI, but I think it is a very slight improvement.
I agree with you; it's a clear improvement.
I defer to you about the AI, but I think it is an improvement in terms of framing the religious claims as religious claims rather than facts in wikivoice.
I agree with you (pointless at best).
The source didn't support the claim about walnut trees (or "base camp", though that might be within the range of Wikipedia:Use our own words). Also, the source does support a claim of shade, safety, and strategizing. Therefore this is an improvement that makes the article stick to the source.
This is a description of how a soldier earned the Victoria Cross for Australia. A "promotional" tone should be expected. You don't earn a "decoration for according recognition to persons who in the presence of the enemy, perform acts of the most conspicuous gallantry, or daring or pre-eminent acts of valour or self-sacrifice or display extreme devotion to duty" by doing things that can sound boring.
This edit got rid of an unencyclopedic exclamation mark. I'd rather have the one extra word than the exclamation mark.
The main problem here is that the paragraph is unsourced, so it's not easy to determine whether the "swift" claim is verifiable. I wouldn't be surprised if it were true, however.
Can you take another look at that? That edit turned 117 words into 74 words, but your note says it's wordier.
By "wordier" I mean that Cottage restoration has led to a renewed urban environment and overall visual aesthetic. is no different in tone than Most of the old cottages have been fixed up, so much so that the area has a newer look than it did just ten years ago except for the "bigger words," and arguably it is worse because it now has an abstract, promotional, real estate brochure-like slickness.
As far as changing meaning, if someone is "revising tone" in a way that changes the factual meaning of a sentence, and gives no indication that they understand that they are changing meaning (or worse, give an indication that they didn't, as with calling factual changes revised language to be more concise) then they didn't understand the task, and any improvements are basically accidental. Gnomingstuff (talk) 19:03, 11 September 2026 (UTC)Reply
That reduced a 26-word-long sentence to a 13-word-long sentence. That's the opposite of wordier.
We can't afford to let AI edits slide even if they are improvements. When newcomers start making a large number of formal/promotional sounding revisions across a wide variety of articles they likely have no subject matter knowledge on that's an immediate red flag. In some cases it's edit count gaming for nefarious purposes - in others, it just encourages them to keep inserting more slop. ChompyTheGogoat[Bleat|Munched]06:58, 12 September 2026 (UTC)Reply
I said it's a red flag, not automatic proof of anything. AGF doesn't mean we ignore potential problems - it means we investigate further before taking action. Like leaving an initial warning, then reporting after they respond to the warning with more slop. Which happens on a regular basis. If they have a viable human written explanation then we let it go and move on. ChompyTheGogoat[Bleat|Munched]07:23, 12 September 2026 (UTC)Reply
I think that your making unfounded assumptions that newcomers don't have subject matter expertise on a wide variety of things is entirely failing to assume good faith. Cheers, SunloungerFrog (talk) 07:45, 12 September 2026 (UTC)Reply
Ones that just so happen to pop up on newcomer tasks, including highly niche topics with poor sourcing (if any)? I did not say "Editors who are active in numerous subject areas must be using AI." It's a specific pattern that includes how the edits are composed. If I was still a newbie myself and hadn't seen it so many times I wouldn't think anything of it. The above example literally just happened, from one of the newcomers mentioned in this discussion that I was watching - before intervening - to see whether there would be additional proof. My spidey senses are rarely wrong. ChompyTheGogoat[Bleat|Munched]08:04, 12 September 2026 (UTC)Reply
I think that assigning a motivation other than doing their best to help ("edit count gaming for nefarious purposes") is the opposite of assuming good faith. I don't know if you've ever read Wikipedia:Assume good faith, but the main story there is a reminder to experienced editors (especially RecentChanges reviewers) that the people who are completely screwing up are genuinely motivated by a desire to help Wikipedia. They're not "gaming" anything, and they don't have "nefarious purposes".
In some cases does not translate to "all of the time". It means I have literally seen that happen on some occasions, meaning it was eventually proven. Some even turned out to be LTAs. I'm not assuming anything and I've had quite enough of the disingenuous misinterpretations. Do you have any relevant points to make that haven't already been discussed, or are you just going to continue arguing over increasingly pedantic minutiae? Because I know you aren't trying to imply we should allow AI slop simply because it comes from a new account. Good faith mistakes do happen also (albeit far less often), and my proposals attempt to minimize those as well so such editors don't get discouraged when they're reverted. ChompyTheGogoat[Bleat|Munched]18:42, 12 September 2026 (UTC)Reply
I am not assuming anything, I am classifying the edits as they exist in the world right now. At which point the need for assumptions is over, the edits are there and anyone can plainly see their quality or lack thereof.
More to the point I don’t really think it matters what the intent is, as this is a content issue caused not by any one person but by an overarching system. To which the only reasonable response should be to disable the system so it stops producing the problem. The purpose of a system is what it does, and this system is slowly rotting Wikipedia more and more every day. Gnomingstuff (talk) 00:12, 13 September 2026 (UTC)Reply
Of course. I've always said our target audience for newcomer support is the good faith editors who are WP:HERE. Those are who we want to retain. Ideally having well designed infrastructure can help with both - other things I've proposed like the AI/COI affidavits and newcomer patrolling would also help us identify and address the problematic ones. Some might learn and clean up their act while others just need blocked, but either way the sooner we notice and intervene the better.Btw, which edit are you referring to? I don't see that they've touched Angela (Trials of Mana). Ironic that a slopper is doing a better job at "revise tone" than any organic editors I've seen. ChompyTheGogoat (talk) 13:52, 9 September 2026 (UTC)Reply
@ChompyTheGogoat Thanks for sharing your thoughts on the idea of reducing review redundancy. We have a software feature that could help with this, but it's currently not enabled on the English Wikipedia. On some other wikis, there's a 'patrol' button for each edit, so users can mark an edit as 'patrolled'. Other editors can then filter this edit out of venues like Recent Changes, and focus on unreviewed edits. There have been some discussions here about the feature, but no consensus to enable it. I'm interested in thinking about how we might be able to update the feature so that it could be enabled, if the community wanted to do so. I've been collecting notes at T409165 - would love to know if you have additional thoughts! —User:Samwalton9 (WMF)09:57, 10 September 2026 (UTC)
Patrolling isn't required for edits to be live, correct? My biggest suggestion would be to show the reviewed status on the feed even if someone chooses not to use it as a filter option. They can still decide whether or not it's something they want to check out for themselves. Nonbinary statuses and/or counts of reviews could be useful too. The concern about backlog is valid, if that's what the tool currently does - I don't think it's reasonable to expect all edits to be reviewed; it should just be additional information to help patrollers do what they're already doing. If a specific newcomer patrol is created (especially one focused on good edits/newcomer tasks instead of vandalism) I expect they'd have a significantly lower workload so it might be more realistic to clear their feed - or it might not. More flexibility for them to implement it however they find the most useful is most likely to be successful. My idea was something very lightweight that would just indicate another patroller has had eyes on it, but given the previous difficulties it may take more work to get RCPatrol into a form that EN editors are willing to pass. ChompyTheGogoat[Bleat|Munched]10:16, 10 September 2026 (UTC)Reply
Correct! This feature is different from Flagged Revisions (called Pending Changes here), which is the software that gates edits being live behind the patrol requirement. The native MediaWiki Recent Changes Patrol feature is all about the patrolling workflow, enabling users to filter out edits that have already been patrolled by others. Thanks, this all makes sense. I think this is a solveable problem with some software improvements, I just need to gain some clarity and put some definition on what changes exactly! Samwalton9 (WMF) (talk) 11:16, 10 September 2026 (UTC)Reply
I think that plot summaries, particularly in fantasy or other forms of non-realistic fiction, are highly likely to correctly contain phrases that seem to have tone problems. The problem isn't the edit that was made; the problem is that the Revise tone task suggested improving that plot summary in the first place. —User:WhatamIdoing18:13, 10 September 2026 (UTC)
And adding one single exception (when some of them really do need to be fixed) doesn't change the fact that the task is inherently problematic, and even if it does correctly identify a passage that needs work it doesn't offer new editors the necessary support to actually understand how to fix them. This one sounds like it was ripped straight from the blurb on the cover, not actually a proper summary of the sources - which aren't cited in any case, so there's additional legwork needed to figure out what it really should say. ChompyTheGogoat[Bleat|Munched]18:51, 10 September 2026 (UTC)Reply
Latest comment: 5 days ago19 comments9 people in discussion
Tamzin marked this page as historical in 2015 because it hadn't been edited since 2012. I just came across it yesterday and added an entry, but I was reverted because the page had been marked as historical. Per {{Historical}}, I should seek broader input at a forum like this one in order to revive discussion there. – MrPersonHumanGuy(talk) 17:57, 2 September 2026 (UTC)Reply
Historical is right. It may have once made sense to maintain this page, but even that is dubious (it was created by somebody who is now perma-banned by the WMF). There's certainly no value in it now. RoySmith(talk)18:20, 2 September 2026 (UTC)Reply
No, the wording the fine. It is saying that historical pages should be left alone unless there is at least some discussion at a central noticeboard suggesting that adjusting them is worthwhile. The last substantive edit to the page in question was in June 2010. Johnuniq (talk) 00:15, 3 September 2026 (UTC)Reply
@MrPersonHumanGuy, since you added an entry, and are opening discussion here, you presumably see some purpose in reviving this tracking. What is that? And do you have any suggestions how it could/would be updated sufficiently comprehensively to be used for that purpose, without being a burden on closers or other editors. It seems to have died out of disinterest, so a natural question is: why the interest now? Martinp (talk) 16:43, 3 September 2026 (UTC)Reply
Asides from the fact that the page has been marked as historical since 2015, I personally didn't see why it should be left outdated for good. If new entries shouldn't be added to it anymore, it should be deleted. If anyone wants the page back, they can ask for it back, but they should be encouraged to explain why they want it back. – MrPersonHumanGuy(talk) 17:01, 3 September 2026 (UTC)Reply
I personally would not be upset if it were deleted, but sometimes people find value in seeing how things used to be done, hence the historical tag. RoySmith(talk)17:15, 3 September 2026 (UTC)Reply
It seems to me no action is needed. One of many historical pages that are kept around, duly marked as historical, with editing it (as you experienced) discouraged. If you wish, you can take it to MFD to discuss deletion, but I suspect you'll get a number of reactions along the lines of "what's the problem? why bother?". Martinp (talk) 11:47, 5 September 2026 (UTC)Reply
Marking pages as historical and keeping them help preserve institutional memory. It's often useful to remember what initiatives didn't work out, and to preserve the discussions that were part of the initiatives, for future understanding. isaacl (talk) 16:07, 5 September 2026 (UTC)Reply
I just read the lead again, where it says Currently this covers DRVs between 16 August 2008 and 18 January 2009, which means that, when I added a recent example of an overturned speedy deletion, that outlier had made that sentence inaccurate. – MrPersonHumanGuy(talk) 16:15, 5 September 2026 (UTC)Reply
Yes, and? Ledes can be changed - and maybe a minor tweak would be appropriate since there were a few later additions, but since there's no point to reviving it there's also little point to changing the description. You don't appear to have any argument for why it should be kept up to date. If it's been untouched for over a decade that's a pretty solid indication that no one finds it useful. ChompyTheGogoat (talk) 07:15, 6 September 2026 (UTC)Reply
I've boldly removed the lists. If nothing should be added to them anymore, they shouldn't remain in the current revision. The lede can stay because it describes how things used to work, but not the part that says Feel free to add your own overturned speedy deletions if they're not listed here. which could've encouraged other contributors to violate the page's historical status as well. – MrPersonHumanGuy(talk) 10:34, 6 September 2026 (UTC)Reply
There's no reason to keep the lists either. Keeping historical information about it is justifiable. If it's so important to show what had been done and not just tell, one or more examples of list entries may suffice for a current revision to a project page about it. The preservation of the entire list (so we won't have to go into the page history to see it) is unnecessary. – MrPersonHumanGuy(talk) 18:33, 6 September 2026 (UTC)Reply
It's useful if people are trying to learn from it. Precisely what problem do you think it causes to leave them if people actually read the part about it being historical and not maintained? We don't go around deleting content just for the heck of it, historical or otherwise. ChompyTheGogoat (talk) 19:41, 6 September 2026 (UTC)Reply
I agree with Chompy, removing the lists removes the entire point of keeping the page but brings no value at all over retaining them. I strongly recommend reinstating them. Thryduulf (talk) 20:48, 6 September 2026 (UTC)Reply
Though I'm ambivalent about the current page version having the lists, I disagree that removing them removes the entire point of keeping the page. There are other examples of pages being kept for historical purposes where the main content was removed. The lists remain accessible in the page history. isaacl (talk) 23:02, 7 September 2026 (UTC)Reply
Why do you expect anyone to get excited about such a long-lasting and basic error in our coverage of African geography when a couple of sections below there's a question about American film trivia (or at least I think that's what it is about). Phil Bridger (talk) 20:02, 10 September 2026 (UTC)Reply
Noticeboard header maintainers: new option to add additional text
Latest comment: 3 days ago2 comments1 person in discussion
Hello. Noticeboards that use template {{Noticeboard header}} (typically in a subpage named /Header) with the |newsection=yes param (these 12boards) now have the option to add additional text next to the 'Click here to start new discussion' link at the bottom of the header. Specify new param |addltext=Your text here to use it.
An example is worth a thousand words, so please see the links at the bottom of the WP:Mentorship noticeboard/Header. (Attention:AN3, ANI, CEN, EFN, EFR, ENB, IANB, IMP, MCQ, MNB.) Thanks, Mathglot (talk) 22:55, 9 September 2026 (UTC)Reply
But both are sufficiently sourced to make a page specifically about them. That would remove a lot of length from the Minecraft Move and Rise of Gru article that is not directly about the movies. Lemurik the Historian (talk) 14:13, 10 September 2026 (UTC)Reply
I am not suggesting Chicken Jockey merits an article, but that movie-related phenomena deserve their own shared article, which would give extremely long pages like the Minecraft Movie page some breathing room. It occured pretty often too. Minion and Yoda memes, for example, date back to the 2000s. It would definitely be a good thing to make this an article. Lemurik the Historian (talk) 16:13, 10 September 2026 (UTC)Reply
You're the one who wants to create this article, so it's on you to locate appropriate sources to support notability. A web search can find a lot of results, but most of it is not from reliable sources. Schazjmd(talk)17:45, 10 September 2026 (UTC)Reply
It's not clear that this is a coherent, well-defined, and notable topic. It's possible that this could survive as a list. I would suggest starting this as a draft and submitting it through WP:AFC. I'll be honest and say that I'm skeptical but it's hard to evaluate since I don't have a clear sense of wha the scope of the article would be. I would not support removing massive amount of content from articles like A Minecraft Movie and placing it in a separate article about "movie-related phenomena". The chicken jockey content is best covered in the parent article and I suspect the same will be true for "phenomena" related to other movies. A Minecraft Movie is <5,000 words long and A Minecraft Movie §"Chicken jockey" trend is just 580 words. Neither the total article length nor the section length is problematic. —Myceteae🍄🟫 (talk) 16:57, 10 September 2026 (UTC)Reply
A Minecraft Movie is long for a movie about a game. It is only popular because it has trends around it. I am suggesting to organize the page by moving all stuff not directly movie-related and creating an internet and social movie-related phenomena page. Lemurik the Historian (talk) 16:58, 11 September 2026 (UTC)Reply
I oppose that suggestion. But again, this isn't really the right venue. I think this is a bad idea and a dead-end. But you're free to work on a draft and see if it survives. —Myceteae🍄🟫 (talk) 17:03, 11 September 2026 (UTC)Reply
Well, again, the split proposal was already rejected! So really I suggest dropping the stick and moving on. I realize this is an amended proposal but I still think it's wrongheaded for the same reasons people objected to the prior proposal and additionally because the vague subject of "movie-related phenomena" is of questionable notability and coherence. —Myceteae🍄🟫 (talk) 17:06, 11 September 2026 (UTC)Reply
