Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• This is a high-visibility page intended for proposals with significant impact. Proposals that affect only a single page or small group of pages should be held at a corresponding talk page.
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for 7 days.

« Archives, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228

A new system of permissions for article creation

Inspired by discussion at Wikipedia:Teahouse#how do you change your profile picture on the wikepedia?

As was so eloquently stated by a commenter there; On a related note, this user, who wrote Draft:Two dollar mouse is almost auto-confirmed. When are we going to increase the threshold for auto-confirmed accounts?

So, what's the problem? Well, that editor is almost autoconfirmed, and when they reach autoconfirmed status, they would be entirely within their rights to publish Draft:Two dollar mouse directly to mainspace, a prospect which speaks for itself. Sure, it'd likely be promptly speedy-deleted, but what if it slips through the cracks of RC patrol or the already massively backlogged NPP? Even if it doesn't, why should we have to waste productive editor time cleaning it up? As I stated in that same thread, the idea that the average editor is ready (i.e., familiar enough with our PAGs, norms and standards) to write articles directly in mainspace after 4 days and 10 edits is already laughable. We already expect people to put a fair bit more time into the project before they take on that sort of task; so why is our hard-limit threshold so low? Purely to serve a hypothetical Wikiprotegé who might be ready to write articles in such a short period of time? If our goal is to prevent low-quality content from being posted to mainspace and requiring editor time to cleanup, the autoconfirmed threshold is practically as good as no threshold at all. Sure, it might prevent only the most passing of drive-by trolls, but anyone with even an ounce of patience can pretty easily make an account, leave it for a few days, then game AC and do whatever it is they want to do. Ten edits is nothing. The same goes for COI/PAID editors. Sure, we want them to go through the AfC process, but there's essentially nothing forcing them to do so if they have even a modicum of patience. Again; make the account, wait a few days, perform some perfunctory edits to get AC, and then you can go ahead and extrude your promotional slop straight into mainspace, forcing some poor editor to spend their time doing WP:BEFORE on your nonnotable company article so it can be AfDed.

Tl;dr, the autoconfirmed threshold for article creation is much lower than the level of experience and Wikiknowledge that we typically expect somebody to have in order to create articles.

What's the solution?

I'm not actually in favour of raising the threshold for autoconfirmed. I think autoconfirmed as it stands does a good job of preventing vandalism on semiprotected pages, for example. Autoconfirmed should be left as-is, but it should no longer be the permission that determines whether you can create articles directly into mainspace. Instead, as my title says, I believe we should create a new permission somewhere between AC and ECP which one needs to achieve before they can create articles in mainspace. Frankly, I wouldn't be opposed to limiting this to ECP, because I think by the time someone achieves ECP they're certainly ready to write articles; but I'm sure many people would find that to be too extreme, and it would result in the AfC backlog being even worse than it is now. So, I think there should be a middle compromise; Autoconfirmed is too low, extended confirmed is too high, we need a 'creation-confirmed' permission somewhere in the middle.

With 4 days and 10 edits being AC, and 30 days/500 edits being ECP, I think something like 10/100 would be a sensible threshold for creation-confirmed.

Bonus proposal

In the interest of cutting down on the AfC workload a bit, particularly the endless wave of COI biographies and corporate articles, I might also suggest that we should limit draft creation or at least submission to AfC to autoconfirmed users. Half of the time when AfC reviewers decline these kinds of articles, we're telling people to read the same old, same old absolute basic information; notability, verifiability, etc, etc. If we required users to be AC before they could even submit a draft, they'd be forced to spend at least some time familiarising themselves with Wikipedia, and we'd hopefully get rid of a lot of the worst offender draft-creators who constantly and repeatedly try to force their promotional drafts through the system. I'm calling this a 'bonus proposal' because I know it's likely to be a bit more controversial than the above.

How would we implement this?

We wouldn't need to go all in right away. We could model the implementation on the Wikipedia:Autoconfirmed article creation trial back in 2011. A 6-month interventional phase where we implement the change, a 1-month non-interventional phase where the changes are reversed and the community has the chance to discuss the changes' effects, and a final RfC if necessary on whether the changes should be permanently implemented.

Please grant this some serious thought and discussion. I think this could be a hugely positive change to the way that editor time is being spent, and massively increase the average quality of newly-created articles. Athanelar (talk) 14:57, 4 April 2026 (UTC)

Limiting draft creation to autoconfirmed would completely defeat the purpose of the draft: namespace, which exists specifically for that reason. —Jéské Couriano v^_^v ^{threads critiques} 15:05, 4 April 2026 (UTC)

What are your thoughts on the main proposal? Athanelar (talk) 15:07, 4 April 2026 (UTC)

A bloody waste of time, in an age where people are willing to hire users who meet the requirements and/or XC-bust in order to get their puff piece onto Wikipedia. Coupled with requiring autoconfirmed to start drafts - which are NOINDEXed and thus cannot be seen by search engines and completely misses the concept of (also NOINDEXed) userspace drafts - you're more apt to replace the firehose of COI drafts nobody can see with a firehose of payola everyone can see. —Jéské Couriano v^_^v ^{threads critiques} 15:16, 4 April 2026 (UTC)

Anything that raises the level of effort required to get in will reduce the number of people who try. Sure, there would no doubt be some companies that'll just pay a creation-confirmed editor to publish their article; but no doubt that number will be much lower than the number that are willing to tell an intern to get 10 edits and post it themselves, or to try to get it through AfC as they currently do. Besides, a creation-confirmed editor suddenly publishing a paid promotional article out of nowhere is likely to raise the same UPE red flags as always, and will be caught anyway. It's all just about reducing the number of editor-hours that have to be spent dealing with this sort of thing. Athanelar (talk) 15:39, 4 April 2026 (UTC)

Let's stipulate that "Anything that raises the level of effort required to get in will reduce the number of people who try". But:

• Is reducing the number of people who try one of Wikipedia's goals? Does that serve our educational mission?
• Will the reduction be evenly distributed, or will the people who give up be the people we most want to contribute?
• Does adding complication turn companies away from the "tell an intern model" and towards the "pay a UPE scammer model"?

WhatamIdoing (talk) 20:45, 4 April 2026 (UTC)

1. I do not think our educational mission is served by allowing anyone with an attention span longer than a goldfish to put whatever they want in mainspace. In the best case scenario, people who put in exactly 0 effort will have their article speedied/draftified by a RC patroller or NPPer. In the worst case scenario, people who put some degree of effort in waste a bunch of actually productive editor time on BEFOREs and AfDs. Our educational mission is furthered by the efforts of people with real interest in learning and contributing; and those people will not be scared off by a slightly-more-than-perfunctory threshold that they need to pass before being able to publish things directly into mainspace. As for the bonus proposal about raising the threshold to contribute drafts to AfC; once again, I do not think the people who we want to contribute will be scared off by the very-perfunctory autoconfirmed threshold, which any interested editor could immediately pass simply by completing The Wikipedia Adventure, for example.

2. This is the sort of thing that a 6-month trial period would allow us to determine; at this stage we can only offer conjecture.

3. Sure, but UPE scammers are probably harder to come by than pliable interns, and the effort required to deal with them is really no more than the effort required to deal with the intern - in fact, it's probably less. When dealing with the good faith intern, we've got to make the effort to try to teach them to do better. When dealing with the UPE scammer, we block them and delete their output; job's done. Athanelar (talk) 20:58, 4 April 2026 (UTC)

1. I believe that this is still called "The encyclopedia that anyone could edit", and "anyone" would include people whose attention span is longer than a goldfish's. (Goldfish, BTW, says nothing about their attention spans, and the sources I found said that it's definitely not the 9 seconds claimed in social media, though nobody seems to know what it actually is.) Unfortunately, your belief that people will not be scared off by higher requirements is not supported by the facts. I know people (including, e.g., a professional journalist) who opened the editing window to make one small change, looked at the wikitext code, and gave up on the spot.
2. Every previous attempt to reduce UPE and COI garbage has failed. What makes you think that the outcome would magically be different this time?
3. I suggest a quick trip to any gig jobs board. Most organizations don't have interns, but anybody can (and many people do) go to a gig jobs site and post "I'll pay $n for a Wikipedia article about my company". Or try putting something like buy a wikipedia page into your favorite web search engine and seeing if "hard to come by" is how you'd describe all those businesses. I agree with you that we should be gentler to the intern than to serial abusers.

WhatamIdoing (talk) 21:54, 4 April 2026 (UTC)

1. "The encyclopedia that anyone can edit" need not be "the encyclopedia where anyone can do any task they wish." We've already acquiesced to the fact that article creation should be limited in some way; what we're now negotiating is how limited it ought to be, so "this is supposed to be the free-as-in-libre encyclopedia" is a non-argument here. For every one of the people you know who was scared off by opening the source editor, there is one of the rest of us who was eager to figure it all out and stuck around. I just think that pandering to the lowest common denominator is rarely successful in any community-driven project. For example, the existence of the Simple English Wikipedia is entirely because of the fact that we've decided to accept that sometimes, we require a certain amount of English proficiency/reading comprehension/background knowledge from our readers; because to do the alternative and try to make every article accessible to every reader would ultimately do a disservice to the encyclopedia part of this community-driven encyclopedia. In the same way that our goal is to be "the free encyclopedia that anyone can read" rather than "the free encyclopedia that is readable by everyone," I think it is similarly sensible that we are aiming to be "the encyclopedia anyone can edit" and not "the encyclopedia that is freely editable by anybody". Wikipedia is NOTANARCHY, after all; there are plenty of fancruft wikis on Fandom for people who just want to write an article as soon as possible.

2. I am never convinced by arguments that amount to "we haven't come up with a solution before, so no solution will ever work."

3. Sure, but how many of the people on those gig boards etc have an account which would already meet my proposed new creation-confirmed threshold, and if they don't, how many of them would be willing to put in the genuine effort to get it? It's a lot easier to game 10 edits over 4 days without it being flagged as gaming than it is to game 100 edits. Someone who makes 10 low-level copyedits and that sort of thing before going on to write an article could plausibly be a person who's just trying to familiarise themselves with the editing window. Someone who copyedits for 100 edits and then suddenly plops out a fully-fledged article about TechCorp Ltd, not so much; same for someone whose creation-confirmed account suddenly reappears from months or years of inactivity to create that same TechCorp article; that raises a red flag which is easily detectable and easily dealt with. It's the Swiss cheese model of security. You can't prevent 100% of loopholes and incursions, sure, but the more obstacles you add, the less gets through. Athanelar (talk) 22:17, 4 April 2026 (UTC)

1. Sure, we're already "the encyclopedia that anyone who understands the norms, socializes himself or herself, dodges the impersonal wall of semi-automated rejection, and still wants to voluntarily contribute his or her time and energy can edit." [1] But why should we try to make contributing more difficult? Also, the Simple English Wikipedia was created 19 years before you created your (this?) account, so I'm now curious why you believe you know what the rationale was for its creation.
2. I'm never convinced by the argument that if we keep doing what failed last time, it will eventually work. Past results are one of the best predictors of future results that we have.
3. I think you underestimate the "genuine effort" part. It's pretty easy to game 100 edits if you have an unflagged bot, and UPE scammers have every incentive to create such tools if we require it. However, it's a lot harder for the unfortunate intern or the non-paid volunteer to reach that threshold. Also, if we make the bar high enough, people will just bypass it. Who cares if I need 100 edits to create a page directly in the mainspace, when 10 edits and a quick WP:MOVE will do the same thing?

WhatamIdoing (talk) 22:48, 4 April 2026 (UTC)

But why should we try to make contributing more difficult? We shouldn't, and I don't believe that this would make contributing more difficult. It would make charging headlong into tasks one isn't adequately prepared for more difficult. We have very strict requirements for things like pagemover and AfC reviewer rights for this same reason, and those are arguably easier to be proficient at than article creation is. Why is it that with 4 days and 10 edits I'm apparently ready to create my own articles directly into mainspace, but to determine whether somebody else's article is ready for mainspace I have to have 500 undeleted mainspace edits, at least 90 days of account age, and demonstrable understanding of the deletion policy?

Who cares if I need 100 edits to create a page directly in the mainspace, when 10 edits and a quick WP:MOVE will do the same thing? is it technically infeasible to restrict editors from moving pages into mainspace without the correct user permissions? Genuine question. Athanelar (talk) 22:56, 4 April 2026 (UTC)

Well, it's all bits, so in theory a dev could make the bits do anything that we wanted. At the moment, AFAIK the only way to allow autoconfirmed editors to move pages normally but not move non-mainspace pages into the mainspace is with the Special:AbuseFilter, but I don't know if that would make the edit filter admins grumble about expensive calls, and there are also non-page-move ways to get content into the mainspace, so it wouldn't actually help much. WhatamIdoing (talk) 04:35, 5 April 2026 (UTC)

WP:AFC/R, then pasting your desired article content to the redirect is the standard way of gaming that. GreenLipstickLesbian💌🧸 04:39, 5 April 2026 (UTC)

@Athanelar, I think this proposal is coming from some misunderstanding of how WP:NPP works? Every article is patrolled by NPP, unless the creator has autopatrolled (as you do). This two-dollar-mouse article wouldn't last hours. -- asilvering (talk) 15:30, 4 April 2026 (UTC)

NPP is itself massively backlogged (~18,000 articles right now), and I think reducing the load on the NPP system is also admirable. My point isn't necessarily that this is some urgent problem that Wikipedia will collapse without addressing, just that I think the number of people who are actually ready to write mainspace articles at the moment they gain autoconfirmed is incredibly low, and thus it makes more sense to raise the requirement to a level where we might actually expect people to have some success. Athanelar (talk) 15:35, 4 April 2026 (UTC)

Yes, NPP is backlogged. But you need to understand what that 'backlog' means. For example, you've created your second-ever article, Hindu theology, a month ago. You created the article in your sandbox on 5 March and you moved it to the mainspace on 7 March. The day you moved it to the mainspace, there were 26 page views. Most of those were you and NPP folks. NPP didn't mark the page as reviewed for another two weeks, but they were looking at it. You can be sure that if you had put something like the "two dollar mouse" content in the mainspace, it would have been tagged as {{db-test}} on the same day. By the time it was finally marked as reviewed, to kick it out of the Special:NewPagesFeed, it had racked up 126 page views.

One of our structural problems is that editors can't see the invisible NPP work. Many NPP folks are only concerned about quick checks for brand-new pages: Is it a hoax, an attack page, or otherwise worthy of a WP:CSD tag? If not, then they move on to look at other pages. You can't see them (and they can't see each other, so they duplicate a lot of work), but that work is still happening. WhatamIdoing (talk) 20:56, 4 April 2026 (UTC)

This is useful insight, and no doubt bears some thought and proposals to deal with in its own right. Athanelar (talk) 20:59, 4 April 2026 (UTC)

We've collected some ideas. For example, phab:T356826 proposes being able to see how much of the backlog is actually unviewed (by patrollers), as opposed to the reviewing process having been started but still being unfinished.

By way of reducing duplicative work, I've suggested splitting the single "reviewed" button into individual points of reviewing, e.g., instead of/in addition to a single "Mark as Reviewed" check mark button, offer multiple buttons: not vandalism; not a copyvio; not a test page; and so forth, through all the WP:CSD requirements. Then if your goal as an NPPer is to check for vandalism, you could filter for articles that haven't been checked for that yet, or if you love finding copyvios, you could filter for those. It should eliminate the problem of an article getting checked six times for vandalism but never for copyvios, because when you get there, you can see that the article still needs someone to check for A, B, and C, and that D and E have been completed. WhatamIdoing (talk) 21:34, 4 April 2026 (UTC)

This topic of more vs less restrictions on article creation (and whether draftspace is good or bad) is a third rail (politics) on enwiki. There's a group of editors that want to make it easier to create articles for WP:BITE reasons, and there's a group of editors that think we need more quality control. The current equilibrium we've arrived at is stable, and I think it unlikely that we can nudge it in either direction at this time. –Novem Linguae (talk) 15:52, 4 April 2026 (UTC)

In terms of carrots and sticks, we should be working on our carrots first: Helping new editors with a structured environment. We have the WP: article creation wizard, which I don't think is mandatory or the default new editors get. Getting the basics right means that more editors get a positive first human interaction. The foundation is working on their own article creation guidelines with this seemingly early prototype. That together with paste check to warn against AI might alleviate the urgent issue without having to impose more restrictions. —Femke 🐦 (talk) 16:23, 4 April 2026 (UTC)

I think the second group also misses the fact that, to a certain extent, NPP doesn't always promote quality control -- I clean up old NPP tags sporadically. Currently I'm working on cleaning a lot of articles, created in the 2000s by copy-pasting entries from an old dictionary. A lot of these articles just have one source -- the dictionary. The number of tags these have for being under referenced is striking. And these were placed by good faith editors -- not the UPEs gaming NPR (whose tags and draftifications are, pretty universally, shit). I also get to revert "more primary sources needed" tags on articles where the only sources are book reviews, because, um, well, the editor who placed the tag didn't know the difference between a book and a book review. Or a "this biography of a living person needs more citations for verification" when the biography subject is very long dead, and was at the time the tag was placed. And sometimes there's more than a little bit of entitlement fron NPPs -- take, for example, from this post: forcing some poor editor to spend their time doing WP:BEFORE on your nonnotable company article. But when an NPP tags something inappropriately, or sends a notable articles to AFD, suddenly it's still the article creator's fault for not being perfect, not theirs. Or it's the person's fault for removing the unreferenced BLP tag for not magically knowing which tag you meant to place so, quick, drop a templated warning on their page. I've said this before, but there's a funny David Mitchell sketch on the real world version of this. [2] And it goes, basically, that there's reckless children and timorous children. And we, as a society, tend to calibrate ourselves to the reckless -- the result of which is that the timorous live in a state of perpetual terror. Rules on this, to a certain extent, go the same way - we calibrate our new editor help pages at the reckless, which terrifies the good, productive, yet more nervous new editors. And, in doing so, drive them off, while keeping the reckless. Which isn't a good thing, I don't think. And, conversely, some of the limits on NPR rights come from this - there's many editors who I'd trust to draftify any article, or unilaterally delete one. But, well, there's also people with NPR who do things like yell at you for reverting their BLP tags on the articles off dead people, or who CN tag everything without a inline citation at the end of the sentence, even when it's material that doesn't need an inline citation. (Like the author of a book, in an article about said book). Our NPR standards get built around them. GreenLipstickLesbian💌🧸 18:29, 4 April 2026 (UTC)

I'm surprised to hear there's this much drama over maintenance tags. I would hope that if they're discovered to be incorrect, that they could just be swapped out or removed with a minimum of drama.

I sympathize with NPP reviewers who are frustrated over having to do WP:BEFORE. That takes a lot of brainpower. New page reviewing is much easier when all relevant GNG-passing sources are included in the article. –Novem Linguae (talk) 00:13, 5 April 2026 (UTC)

You'd hope, @Novem Linguae, but that isn't my own experience either. -- asilvering (talk) 00:23, 5 April 2026 (UTC)

I don't think it's at all 'entitled' to suggest that it's structurally unfair for a reviewing editor to have to spend more time looking for sources than the article creator ever did, and that the onus should always be on the creator to carry out that research.

And, for what it's worth, I'm not a NPP. Athanelar (talk) 01:12, 5 April 2026 (UTC)

@Athanelar Sorry, to the best of my recollection, new page patrollers used to just mean people who patrolled new pages -- I tend to use NPR when referring to the rights-holders.

And I think that assumption - "more time looking for sources than the article creator ever did" is, perhaps, not made in the best of faith. Searching for sources is hard, and I, as an editor with TWL access and experience, who got subjected to IRL classes on how to search databases and google scholar, know how to do a more efficient job of finding sources, selecting them, and formatting them than somebody without that experience. We also do put the onus on the article creator -- it always has been.

And even when the article creator provides a wonderfully easy to review, Citehighter-green GNG sources linked and formatted, article, it can still break down. Just pinging @Novem in on these examples, so he can see part of what I'm talking about:[3][4]

This isn't a new phenomenon, either. Though controversial, even now, the results of WP:NEWT is a very worthwhile read for anybody interested in writing policy in this area. GreenLipstickLesbian💌🧸 01:39, 5 April 2026 (UTC)

This would take some pressure off the perennially backlogged NPP, and shift it to the slightly-less backlogged AfC, therefore with my NPP hat on I'm very much in favour, but somewhat less so wearing my AfC one. I do think that the bar for new page creation should be raised, both in the main space as well as the draft one (even if I know this view isn't shared by many and am not holding my breath waiting for things to change). Ideally I would like to see the current AC status (4/10) as requirement to create drafts in the draft space, which obviously wouldn't solve all the problems but should at least reduce the worst of what we see in the newly-submitted end of the AfC pool (attack pages, obvious 'late night after one too many' nonsense, mindless vandalism, etc.). It would also make things at least a little bit harder for the worst sock farms and LTAs using burner accounts. As for creating new articles directly in the main space, the current XC (30/500) limit would be my preference. I don't expect that to pass, though, so as a fallback I could also live with a new status along the proposed 10/100 lines. -- DoubleGrazing (talk) 16:13, 4 April 2026 (UTC)

I start with the assumption that new users have no idea what the requirements (or purpose) of a Wikipedia article are - not always a correct asssumption, but mostly - and I don't want them rushing to get AC so that they can put something in main space that doesn't belong there. I think this will be frustrating and demoralising for them.

Whenever I see somebody asking "why aren't I AC yet?" (usually because four full days haven't elapsed), I want to answer "What's your hurry? Just because you have the technical ability to do something doesn't mean you should do it yet!" But I don't.

I wish there were a way to tell new users "Don't even try to create an article until you have understood WP:42, and found several sources that meet it". But that's not germane to this discussion. ColinFine (talk) 17:17, 4 April 2026 (UTC)

Well, the cool thing about the article creation wizard is that it teaching you notability basics in a very clean way.

New editors often become editors because they want to create an article. That self-motivation is something we should cherish, by setting up software so the good-faith ones can succeed. —Femke 🐦 (talk) 17:36, 4 April 2026 (UTC)

I don't think I necessarily agree with this philosophy. A lot of people become military pilots because their end goal is to be astronauts. A lot of people join acting schools because they want to be the next world star. Article creation is the most difficult and most complex editing task on Wikipedia (I'm not counting coding bots or what have you) and is also arguably the most important and load-bearing task since, you know, our articles are kind of what the entire project is about. Just because Randy from Boise gets into editing because he wants to write articles doesn't mean we should aim to get him doing that as soon as possible. Sure, we want to nurture that tendency and encourage them to pursue that goal, but the responsible way to do so is to make sure they gain the necessary experience and appreciation for the task, and that they treat it with the importance and responsibility it deserves; and that usually means spending at least a few weeks and getting a hundred or few edits under their belt. Is there going to be the occasional protégé who is able to write fantastic articles right from the get-go? Sure; but once that person submits a few successful articles through AfC, we can always allow them to manually request the new creation-confirmed permission (if they didn't anyway gain it in the course of their editing) Athanelar (talk) 17:43, 4 April 2026 (UTC)

This is a little off topic but I'm really not a fan of "article creation is analagous to [effectively impossible goal]" that I see a lot. Like I get what you're saying, but most succesful editors will make at least one article unlike most pilots who will not become astronaughts (or most violinists will not play a solo at carnegie hall, or most mechanics will not build an entire car from scratch - those are some variations I've seen). I think the hyperbole is unhelpful to someone just joining in. I think a more apt comparison might be DM'ing before you've ever been in a TTRPG as a player. -- D'n'B-📞 -- 18:08, 4 April 2026 (UTC)

There are two reasons why article creation is difficult: notability is difficult and sourcing is difficult. The notability issue is to a large extent solvable if we roll out the WP:article creation wizard as a default (not sure how that works technically).. It also gives information about sourcing. There is another idea going around of making AfC a two-step process, where first sources need to be approved before drafting can start. —Femke 🐦 (talk) 19:17, 4 April 2026 (UTC)

The wizard is very useful, but it helps only those who want to be helped. If, for whatever reason, you just want to bash out a draft ignoring all the rules, the wizard won't stop you.

That two-step-process idea does sound interesting. -- DoubleGrazing (talk) 19:31, 4 April 2026 (UTC)

I dont like the idea of having sourcing be approved first; well, I do in theory, but in practice a)we don't have enough manpower to actually deal with offline/paywalled sourcing b)it wouldn't mesh well with NCORP/NEVENT, or any of the notability guidelines that you can't rule of three your way through c) it would probably promote further bias towards the rule of three and d)see previous rant about reverting primary source tags by people who can't tell the difference between a book review and the book itself. GreenLipstickLesbian💌🧸 20:05, 4 April 2026 (UTC)

I think the same AGF will have to be applied as the current system does on offline and pay-walled sources. Perhaps we can ask new editors to describe concisely what's in them.

I would hope that a system like this is more efficient, as you'd just be evaluating 5 sources or so and a majority of topics never progress. Output from an equivalent of the article creation wizard can show both reviewers and new editors what the expectations are for this specific topic to meet notability —Femke 🐦 (talk) 06:59, 5 April 2026 (UTC)

I am assuming good faith; I'm not assuming that this means all editors will be good at describing sources. That's sort of the issue we're dealing with, in a way - at the end of the day, a concise description of what is in each source is what's we're looking for our articles to be. If they struggle with one, they're probably going to struggle with the other. Don't get me wrong, I know framing can make things appear easier -- my favourite piece of advice for writing content is to tell people to take notes for articles like they're taking notes in a classroom, then rewrite those notes into an article (like so), which is quite similar to what you're describing. And I do ask people to think about the source, the publisher, the author, the time period it was written in, ect., when evaluating it. But I'm not sure about enforcing it via an "approved sourcing" check.

Full disclaimer: for better or worse, I have seen enough people float around ideas like this, then announce they'll be checking the sources against NPPSG or RSN/P, to fully trust that this wouldn't happen to submissions under this system. So that's colouring my view a little. I mean, I'm sure that form of automation happens with current AFC reviews or NPP reviews, and I'm not saying that using those lists is a bad idea, as a sniff test -- but I'd like to think that the editor making a claim as to what fact this source is meant to be backing up at least prompts people to think further about the relationship between the source and the claim. And, from a completely different perspective - from an anti-BITE perspective, having the article's fate be this long, drawn-out affair that you have to keep checking back on can feel a bit crummy when it turns out you put in all that extra work, formed all the emotional attachment, for nought. If somebody does put in 5 wire reports on a wildfire, and it gets, not one, but two stamps of approval, probably over a long period of time (if we had enough manpower to give a near-instant source analysis, I'd probably feel a bit different), only to end up at AFD because, ooops, those sources were all from the week after the fire, and then coverage dropped off? Well, I don't think prolonging that is very helpful. And, from the part of my heart that lives in a little deletionist world, the fact that the article went through two positive reviews.... yeesh. AFD nightmare. GreenLipstickLesbian💌🧸 08:28, 5 April 2026 (UTC)

Paywalls are no big deal for a lot of subjects. I only rarely need to read (e.g.) a medical journal article to know whether it's about the subject, in a reputable journal, etc. The same is true for books (Oh, look: a whole independent book on this person. Well, that's WP:SIGCOV right there...) and many other sources. The only time you need significantly more information than the basic title/author/publisher content that is if the source might be very short, or if only a small portion of the source is related to the subject. WhatamIdoing (talk) 19:11, 5 April 2026 (UTC)

It's those in-between subjects, when you're not sure about whether or not it's just a small portion of the source that I'm worried about. Even putting aside the Raj-era sourcing based Indian military history articles, where a passing mention of a skirmish sometimes gets spun out into a Wikipedia article on a full battle, take Shem Pete's Alaska(Full access available to users of The Wikipedia Library.) Does that provide independent SIGCOV of its subjects? Well, yes and no-- the book is set up so that it alternates between material written and researched by James Fall and James Kari, and transcriptions of interviews Kari and Fall did with Dena'ina elders, to document the language and culture of the Upper Inlet Dena'ina before the last native speakers died. As such, Shem Pete is listed (and advertised) as an author -- but the biography sections written by Kari and Fall are, as far as article-writing is concerned, fine. Now, I can explain that now -- but I wrote my first article as a teenager. I definitely couldn't have explained that nuance then. And I actually went to a high school where we had actual field trips and full-day classes on analyzing sources, media literacy, ect. But that's a very different experience than Wikipedia writing, and it didn't transfer as well as you might expect. I was desperately consulting RSN, looking up the names of sources in Wikipedia space, to determine if they'd be acceptable here. If I'd been graded on my ability to describe the sources, how much detail they provided, how in-depth it was, then I'm not sure if, under this system, I'd have even been given permission to try and write an article from them. Which, maybe that's the goal of this proposal. My article certainly wasn't Good or good -- it's serviceable. I'd have certainly been driven off it the first article I'd made about a borderline-notable event had prompted the AFC reviewer to reject it, then write an entire essay complaining about me, my work, and the fact I'd made them waste my time reviewing it.[5] And then, when I asked for information about what type of sources I should be looking for, been told to read the decline notice.[6] GreenLipstickLesbian💌🧸 08:53, 6 April 2026 (UTC)

cc @Athanelar, last two sentences are about you. I suspect we're going to disagree about my description of the essay, but a Wikipedia space essay with the line moment of reflection will lead to the conclusion that nobody's going to remember or care about the story a week from now, and with an example section that lists a singular draft is, well, WP:BITEY to say the least. GreenLipstickLesbian💌🧸 09:01, 6 April 2026 (UTC)

I see your stance. I was going to pull in some more news stories for the examples section, but I wanted to try to keep the examples limited to stories that people had actually tried to make articles about. I remember another a little while ago where an editor made a draft about a man based on one of these same sorts of stories; he rescued a dog and then the dog travelled miles and miles to show up at his house or something, but I couldn't recall it. My intention was to add to the examples in the future as and when applicable cases come up. I think it's worth noting for example WP:AISIGNS which also keeps a great many links to drafts for examples of the problems it's talking about. My intention isn't to shame the editor for daring to ever think this was an appropriate subject to write about, just to give myself a new tool to direct people to in future similar cases.

If you think it seems overly targeted, it's in projectspace, feel free to remove the name of the draft. I do think it's incredibly discharitable to suggest that the moral of the essay is that I "wasted my time" reviewing that article; considering I don't believe that to be the case at all, and if my concern was wasting my time then I wouldn't have bothered writing an article to elaborate on my point, surely. Athanelar (talk) 10:24, 6 April 2026 (UTC)

@Athanelar, I understand your intent wasn't to be bitey, but I do think both the decline notice and the listing on this essay are very bitey. The link to this draft will also expire, as it will be G13'd, and unlike with the AI drafts we've preserved for reference purposes, I don't think we have very good reason to maintain this one. -- asilvering (talk) 12:35, 6 April 2026 (UTC)

I've removed the link to the draft in the essay, and consider me trouted for the decline notice (although, my sentiment stands, I should've been more cautious with my wording) Athanelar (talk) 12:48, 6 April 2026 (UTC)

a) AGF as Femke says. b) there'll have to be some sort of Wizard that adjusts based on the notability criteria you're claiming, so if you're claiming notability based on an award, there's space for one link for verification, if GNG, space for 3-5 links, etc. c) not under a system like this. d) not much anyone can do about that unfortunately. JustARandomSquid (talk) 07:55, 5 April 2026 (UTC)

I think that I don't agree that Article creation is the most difficult and most complex editing task on Wikipedia. Article creation is difficult for some people and easy for others. I'd rather create several articles than to deal with one serious WP:CTOP dispute. I hope that other people feel the opposite. WhatamIdoing (talk) 21:03, 4 April 2026 (UTC)

I thank @Athanelar for raising the topic. My thoughts, as an AFC reviewer (but not NPP), are more on the carrots. What carrots can we offer?

• AFC acceptance leads to a modest bit of publicity and some terrific gnome work - the new entry is listed, lots of people look at it, some rapid edits often result.
• NPP leads to Google indexing, which is a huge bonus for some editors.

So why not

• Create a new Fast Track for AFC - with reviewing done in days not weeks
• Give more razzmatazz on acceptance (e.g. list 20 new articles rather than 10, put that around the parish noticeboards more than now).
• Some way of auto-patrolling / fast / bot patrolling of this stream, so indexing happens quickly - there can still be random manual checks here
• Entry only allowed to those who have spent a few weeks onboard, an explicit statement from the submitter that it is neither COI nor LLM, no more than 20 sources, no more than 2,000 words, submitters identify their WP:THREE on the template and with a drop down on precise notability ground(s).
• In this stream allow the French Wikipedia "checklist" to be added, where AFC can be accepted, but some suggestions are made for further improvement, and perhaps even a timeline as to by when completed.
• AFC resources to be heavily biased to this stream, supporting those who should have that bias. And as things stand it will be that COI / $2 rodents will be waiting a long, long time.

ChrysGalley (talk) 18:33, 4 April 2026 (UTC)

Limiting draft creation to autoconfirmed would defeat a purpose of AFC, but limiting draft submission might be something to consider, although it would have only a minor effect because many newbies who create drafts may end up being autoconfirmed simply by making 10 edits in 4 days to the draft.

I think there are two other possibilities, maybe mutually exclusive:

• Redefine the threshold for autoconfirmed to 10 mainspace edits, and those edits must be spread out over 4 days to prevent WP:GAMING by making 10 edits over the span of a few minutes and then waiting for the 4 days to elapse. A similar redefinition could be done for extended-confirmed, which I always felt was a pretty low bar as it is now. This encourage editors to gain actual experience, and they'd get feedback from reverts and user talk page messages.
• Create a new user right, like "mainspace page creator", which kicks in automatically when a user becomes extended confirmed (or threshold in between autoconfirmed and EC).

I'm uneasy about ChrysGalley's fast-track proposal, although many of the points are reasonable. I disagree with fast-tracking patrolling. I do agree with fast-tracking drafts based on user experience and other criteria that are easy to check. ~Anachronist (who / me) (talk) 19:50, 4 April 2026 (UTC)

So long as WP:Moving a page is possible for autoconfirmed editors, then none of the proposed page-creation restrictions matter. WhatamIdoing (talk) 21:13, 4 April 2026 (UTC)

I am suggesting that "mainspace page creator" be restricted to mainspace, and moving a page to mainspace would be prohibited by autoconfirmed editors who don't have that user right. ~Anachronist (who / me) (talk) 00:12, 5 April 2026 (UTC)

taking out the move right from ac group might be an easier implementation technically as I don't think Wikimedia wikis have the right extension(s) installed or feature for per namespace restrictions. – robertsky (talk) 05:12, 6 April 2026 (UTC)

@Athanelar Thanks for starting this discussion. The AfC article process is almost sabotaged by the low autoconfirmed numbers. After someone has edited a draft 10 times, they can technically move it to mainspace and some do after getting frustrated about being declined. (Although these attempts are often quickly caught.) More worrying, a person who has written a barely coherent draft, or who has copied something from AI, can now also create other articles. In serious cases, it takes time to connect the dots and work out that articles by the same author has issues - like copyvio issues aren't easily picked up across multiple articles. Or where numerous people are leaving similar messages on the talk page but the editor is still revising Wikipedia unimpeded. Increasing the limit for creating an article doesn't stop this being the encyclopedia that anyone can edit - they can still amend a page. If anything, it says we're serious about AfC. A threshold of 50 edits, for example, would have a number of benefits. It would deter some new trolls and vandals. It would give legitimate users a bit more time to learn about aspects of WP-writing like SIGCOV and tone. It would mean that 2-4 of a new user's drafts would go through the AfC process rather than just 1. We see a lot of the same issues in AfC review and the Teahouse - people creating a page about themselves, people who claim they don't know why they've been declined, people who simply don't understand SIGCOV. If I were any of them, the most sensible place to start would be to make 10 edits, then create your single purpose article. If it weren't immediately a candidate for speedy deletion, it might survive NPP, be templated, and take years to be nominated for AfD. 50 edits is a reasonable limit that shows that you are serious about contributing constructively to WP. MmeMaigret (talk) 23:04, 4 April 2026 (UTC)

Yeah, I agree that auto-confirmed being the mainspace article creation threshold definitely has its issues, but I feel perhaps 50 is too little. 75 could work, being the middlepoint between Athanelar’s 100 and MmeMaigret’s 50.

Trolls inclined to create things such as the two-dollar mouse are unlikely to have enough determination to put random things in mainspace to go so far as to make 75 more or less constructive edits. Furthermore, the ones that do would be better handled by people than automated filters, as I think at that point it’s a case-by-case issue.

I would put a 15-day time constraint on it, so that these trolls can’t just mass-edit their way to this permission in 10 minutes. I suspect that the urge to make these sorts of drafts is a sort of random whim that wouldn’t last a week, let alone over 2. And for those who genuinely wish to edit constructively and contribute to the amount of enwiki articles, 15 days seems good to learn the basics of creating an article that won’t immediately get deleted while they learn more about how to improve their article after obtaining this permission and creating it.

Thoughts? 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯 ^{(𝔱𝔞𝔩𝔨)} -⃝⃤ (they/he) 01:02, 5 April 2026 (UTC)

A new auto-confirmed Wikipedia who would make suitable new articles, can also do very well to continue working on their draft and ideally also make collaborative edits on existing articles in mainspace or project spaces.

I believe we can tweak the minimum edit count/days of activity after an experiment. I am convinced that WP:AUTOCONFIRMED should not have page mover from non-mainspace to main-space ability. It is silly, and technically allowed but seldom a good idea or good experience for all involved. The main argument I see in favor of allowing page-creation early on, is that Wikipedians are most motivated to work on articles they believe is missing/important, but I don't see how this is negatively affected by mid-confirmed (my suggested name between auto-confirmed and extended confirmed permissions) ~ 🦝 Shushugah (he/him • talk) 12:09, 5 April 2026 (UTC)

The first article you created was about a person. It was your 21st edit. You clearly had it figured out by then; do you think other editors should be trusted the same as you were? WhatamIdoing (talk) 19:16, 5 April 2026 (UTC)

@WhatamIdoing indeed. I think the edit count was not the biggest factor, but rather having time and carefully reading different discussions by other editors. I technically made 3 edits in 2015/2017 but basically my 20 edits were within a month in 2018. Reflecting back I even violated WP:ARBPIA. Had I not been able to publish Johann Kremenezky I still would have had time to make meaningful edits and learn. My learning contributions were not solely limited to English Wikipedia, as I was researching and reading sources in other language editions and came across Wikidata as well and challenges of right to left/left to right encoded file-names. Which is all very different from the too common case of someone make a biography as their first edit and then asking why it is not reviewed within 12 hours. ~ 🦝 Shushugah (he/him • talk) 19:46, 5 April 2026 (UTC)

As a general rule of thumb, we expect half of our "new" accounts to have made one or more edits before registering, and we do get a lot of editors who start off on a different wiki. WhatamIdoing (talk) 20:47, 5 April 2026 (UTC)

I completely support raising the threshold for Mainspace article creation, because I see absolutely no reason not to.

I dont think there's much reason for editors, especially new ones, to directly create mainspace articles. AfC not only ensures quality control, but also helps the new editors by giving them feedback and helping them learn the relevant guidelines.

I don't know why a new editor would ever need to bypass AfC. 🍅 fx (talk) 12:26, 5 April 2026 (UTC)

I usually recommend promising users to skip AfC as soon as they can. AfC van be quite conservative with accepting imperfect but decent articles, which is demoralising. I also don't want to increase the burden on reviewers even more —Femke 🐦 (talk) 12:40, 5 April 2026 (UTC)

Honestly, I don't feel there is all that much of a 'burden on reviewers' at AfC, and I say that as an AfC reviewer. Sure, it's backlogged to hell, but there's really not all that much I can do about that. We just don't have enough reviewers - when there was a backlog drive about two months ago, the review queue was as low as 500 articles or so by the time it was over. The solution to the AfC 'burden' is just to find a way to recruit more reviewers. There's currently about ~200 AfC reviewers including fully-approved and probationary reviewers. For us to clear the backlog right now we'd each have to review over 10 articles each right this second.

If we could get that number up to like 500, and if we could get at least half of those people reviewing 1 article per day, we'd be through the current backlog in 2 weeks. It's really not that bad.

That said, I fully agree the goal should be for the people who are able to do so to skip AfC - but that's why we need to up the requirements for mainspace creation, so that we know the people skipping AfC are the ones that have the required skills to do so. If that increases the AfC burden, so be it -- it's better that there be a few (hundred) more articles in the queue rather than a few hundred more junk articles in the mainspace for the way-more-backlogged NPP queue to deal with. Athanelar (talk) 12:52, 5 April 2026 (UTC)

AfC van be quite conservative with accepting imperfect but decent articles - I'd say this is mostly an issue with the current reviewer instructions. As someone who did AfC review for the first time recently, it was somewhat confusing to me at first what I should and shouldn't reject. I don't think it is an inherent issue with the process. 🍅 fx (talk) 13:39, 5 April 2026 (UTC)

There are some structural reasons why AfC is conservative as well. If you accept something that is later deleted, you might get flak from experienced users. If you decline an article, you usually don't. Might only play a subconscious role, but I do think it matters and is difficult to combat. —Femke 🐦 (talk) 14:38, 5 April 2026 (UTC)

It's also a lot easier to decline an obviously bad article than it is to properly assess and accept a middling one. My AfC stats are probably something like 99% decline, because most of what I do at AfC is to weed the queue of obviously unfit drafts. Athanelar (talk) 15:26, 5 April 2026 (UTC)

98%. Someone was saying recently that even the most strict AFC folks usually accept 30% of articles, but if you're cherry-picking obvious declines, that won't apply to you. It might, however, give you the kind of skewed view of submitted articles that would lead to proposals to discourage the creation of articles. WhatamIdoing (talk) 19:20, 5 April 2026 (UTC)

My proposal here is only partially based on my experience at AfC; and given that there is agreement here from other editors (and even the undeniably tenured and decorated ColinFine in the teahouse thread linked at the top of my proposal) I would appreciate if we could avoid the sideways aspersion as to my depth of perspective here. Athanelar (talk) 19:26, 5 April 2026 (UTC)

I think that it's helpful to understand the context. Wikipedia:STiki users see Wikipedia as being full of vandalism, because that's what they see all day long. A long stint at WP:COIN makes many editors see COIs behind every edit. AI-focused editors see signs of AI around every corner. CCI editors can develop extreme views of WP:CLOP. You've spent the last three months seeking out ~100 pages of garbage in the Draft: space, and you're here asking how to reduce the submission of garbage to the Draft: space and to prevent people from doing something they're not doing much of in the first place (namely, creating articles directly in the mainspace).

This matters because when someone is deep in a niche area, they usually lose track of the big picture. For example: Is this the most pressing problem facing the community? (LLMs might be a bigger problem right now.) If we tighten restrictions in this area, what are the knock-on effects? (If a quarter of newbies are here to create a missing article, and we discourage them, will Wikipedia die when we do?) WhatamIdoing (talk) 20:00, 5 April 2026 (UTC)

Sure, but this counterpoint is coming from the assumption that I believe bad articles being created in mainspace is a pressing or existential issue that needs to be solved right this second. I don't think it is; I think the project would be better off as a result of my proposal, that's all. This isn't a matter of me having my head down in fighting bad articles and therefore seeing bad articles everywhere, it's just that I've identified something which, if implemented, would make it harder for bad articles to end up in mainspace, and would not cause any appreciable decrease, I should think, in the amount of good articles ending up in mainspace. I'm not trying to plug a leak, I'm identifying what I think is a win-win change to the way we operate. Athanelar (talk) 21:58, 5 April 2026 (UTC)

Why do you believe it would not cause any appreciable decrease, I should think, in the amount of good articles ending up in mainspace?

Start with this: If someone's making an edit, and we ask them to login first, we lose editors immediately. Registration takes maybe 30 seconds, and it's usually for an edit that is simple and obviously good/wanted, like reverting vandalism. So why do you think that all of the good contributors would spend a week and a half making 100+ edits, when we know that many these same good contributors will not spend 30 seconds creating an account if that's required to fix an obvious problem in an article they're reading? WhatamIdoing (talk) 23:07, 5 April 2026 (UTC)

My contention is;

1. There are not all that many people who are ready to make articles directly in mainspace after 4 days and 10 edits.

2. The people likely to be successful article creators are also likely to be people willing to spend 10 days and 100 edits on something else first; because they're likely to be people with a general interest in the project.

3. The specific Venn diagram overlap of people who would otherwise be successful at creating an article if given the chance to do so after 4 days and 10 edits, but would be scared off by a requirement of 10 days and 100 edits, is not likely to be very many people. Athanelar (talk) 23:32, 5 April 2026 (UTC)

I don't think that "scared off" is the right description. "Decide that it's not worth it" is probably more realistic.

Do you hope to prevent them from creating redirects as well? People in the 10–500 edit range created about 500 mainspace redirects last week, and about 750 articles that are presently in the mainspace (or were created there and moved out recently). A quick check of 10 articles found three created by people you would restrict here. I suspect that one has a COI (recreation of a previously deleted page). Another has more than 6,000 edits at the Arabic Wikipedia. The third is Battle of Ganzak (363), which appears to be an undeclared partial translation (probably a machine translation) of hy:Գանձակի ճակատամարտ (363) (a good deal of which the editor wrote, and you don't have declare translations of your own work, because you can re-license your own work). The probably COI case is outside the scope, because we've agreed they'll just spam a hundred edits in. That leaves us with one editor who has a lot of experience at another wiki, and one editor who has a little bit of experience at another wiki. Are those the people you think are doing terrible work and ought to be restricted? WhatamIdoing (talk) 01:06, 6 April 2026 (UTC)

Seeing as I doubt it would be technically feasible to allow redirect creation in mainspace but not article creation; sure, limiting redirect creation by people under the 10/100 threshold might be collateral damage here. WP:AFC/R exists for the particularly determined in that regards. I'm confused why you choose 10-500 edits for your range, though, since the limit I'm proposing is 100 edits. A better question would be how many redirects were created by editors with 10-99 edits, since those are the editors that would now be forbidden from creating redirects under my proposal. Or even 10-49, if we wanted to go with a lower threshold as has also been proposed here.

Cases where people have extensive experience in other wikis and the likes are cases where those people could, if they so desired, apply for early creation-confirmed permission, just like people can apply for early XC too. It'd be as simple as "here's a link to my contribs page showing I have 6,000 edits at the Arabic Wikipedia, please give me CC perms."

The translating editor might be an example of a good faith editor creating a genuinely good article who would be caught by this new restriction; again, I'm not at all claiming that would never happen. I think the benefit outweighs the cost, though, and I would hope that as I've said, the people who have the determination and ability to write a good article are anyway the people who have enough patience to stick around until they can hit the higher threshold. Athanelar (talk) 01:18, 6 April 2026 (UTC)

I chose 10–500 because that's what's feasible to filter for in RecentChanges. Then I did a quick spot check of 10 non-redirects, and found that three out of 10 were created by people with edit counts in the 10–100 edit range. A quick back-of-the-envelope calculation suggests that we're talking about roughly a third of the articles created, which means something like 150 redirects per week and 250 articles would be restricted.

Whether redirects can be exempted depends on the implementation method, but remember what @GreenLipstickLesbian told us above about whether that's really different from creating an article.

It's this bit that worries me: I would hope that as I've said, the people who have the determination and ability to write a good article are anyway the people who have enough patience to stick around. Yes, you hope that. But from where I'm sitting, it feels a bit like hoping that pigs will fly. It's certainly possible, but every bit of evidence we have says it's unlikely, and we shouldn't design a process around the assumption that it will happen, or that if it happens, that it wouldn't have unfortunate side effects to bystanders.

----

One of the distinctions that some tech folks make is between bringing a problem and bringing a solution. You've brought your solution to the table: Just stop less-experienced people from contributing that way! Can you spend a while thinking about the problem? Is the problem "Ugh, he polluted my wiki", or is the problem "Ugh, I have to go to all this trouble to get rid of it" or "Ugh, everyone over there is so stressed" (←IMO a quite serious problem) or something else? Maybe if we all understood and agreed on the problem, we could come up with another way of alleviating the pain point. WhatamIdoing (talk) 04:55, 6 April 2026 (UTC)

The problem is, to my mind, what I stated as my tl;dr in the proposal above. the autoconfirmed threshold for article creation is much lower than the level of experience and Wikiknowledge that we typically expect somebody to have in order to create articles.

It seems contradictory and self-defeating that we have long-time editors in good standing telling people on help forums "you probably shouldn't even bother trying to create an article until you've got some more experience" but they're mechanically permitted to do so essentially right from the start. The software's telling them they're ready, the community tells them they probably aren't. Athanelar (talk) 10:37, 6 April 2026 (UTC)

No, that's the solution, lightly re-phrased.

Is the problem "Newbies produce low-quality articles"? "Newbies don't know how to decide whether a subject qualifies for an article"? "People are allowed to make mistakes"? WhatamIdoing (talk) 23:43, 6 April 2026 (UTC)

What I think WhatamIdoing is trying to get at is the question ‘but why is the autoconfirmed threshold too low? What is the reason behind that? What issue causes you to (correctly, I think) believe that AC is too low of a requirement?’ If we can see the specific problem, perhaps we can all agree on some different solution; us trying to guess what the issue is from the proposed solution and attempting to offer some more widely agreed-upon idea is just a game of blind men and an elephant. 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯 ^{(𝔱𝔞𝔩𝔨)} -⃝⃤ (they/he) 19:00, 7 April 2026 (UTC)

And, again, what I believe is the problem is the difference between the autoconfirmed threshold and the community-expected level of experience. To quote myself from above; It seems contradictory and self-defeating that we have long-time editors in good standing telling people on help forums "you probably shouldn't even bother trying to create an article until you've got some more experience" but they're mechanically permitted to do so essentially right from the start. My solution, therefore, is to raise the mechanical barrier, rather than to lower the community's expectations.

Or, if you want it another way, the problem is that the kind of knowledge we expect people to have before they make an article is not the kind of knowledge a person can realistically acquire in 4 days and 10 edits, unless they dedicate a workday's worth of time every day to reading PAGs. So, the most elegant solution to that, I think, is to extend the minimum requirements to a timeframe where we might more realistically expect someone to have gained that knowledge. It's either that, or we need to make the level of knowledge required to successfully create an article lower; but that sounds rather like saying we should lower our standards. Athanelar (talk) 19:17, 7 April 2026 (UTC)

So the problem is:

People who have reached autoconfirmed usually do not know something (unspecified) that, if they knew it, would help them be successful at creating an article.

What are the unspecified "somethings" that they need to know?

I'd say Wikipedia:Notability is the main one. What would you say? WhatamIdoing (talk) 20:01, 7 April 2026 (UTC)

Certainly notability, also WP:V and the information covered in WP:42. Athanelar (talk) 21:33, 7 April 2026 (UTC)

I would be happy with any number of solutions:

• increasing auto-confirm even to just 25 edits
• requiring your first 3 drafts to go through AfC
• requiring your second article to go through AfC if the first one was declined X amount of times and so on.

As I think any of these wouldn't trouble people who actually intend to stick around, would require a little more effort to publishing non-notable articles and would get you a little more familiar with GNG. MmeMaigret (talk) 07:32, 8 April 2026 (UTC)

Which problem would it solve?

You created two articles on your first day as a registered editor. Do you think that was a problem? What do you think would have happened, if you had been told not to contribute that way on your first day? WhatamIdoing (talk) 19:45, 8 April 2026 (UTC)

I agree with Femke that the AFC approach has structural challenges. I don't know of a better way to run it, but I do know that if you follow the primary directive (i.e., accept articles that are notable/won't be deleted at AFD), that experienced editors will occasionally yell at you. WhatamIdoing (talk) 19:22, 5 April 2026 (UTC)

@Athanelar I agree 100% with your porposal. David10244 (talk) 15:13, 5 April 2026 (UTC)

Oops. "proposal", of course. David10244 (talk) 15:13, 5 April 2026 (UTC)

Don’t worry; for all intents and porpoises, we knew what you meant. :) 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯 ^{(𝔱𝔞𝔩𝔨)} -⃝⃤ (they/he) 01:56, 6 April 2026 (UTC)

Image Requests/Bounties

Here's an idea I had a while back. Images greatly help comprehension of Wikipedia articles. But sometimes, especially with niche articles, there simply aren't enough (or any) copyright-free images. Therefore, I propose Image Requests/Bounties. When creating or editing an article, Wikipedians can make a request for an image. Then, someone who lives nearby can fulfill that request.

For example, let's say someone is editing an article about Chambers Street in Manhattan. They'd really like another picture of Chambers Street itself, since the article's sole image barely shows it. They post a request on the page. Since I live in New York, I can easily head down there, take the picture, and upload it.

Therefore, I propose we make a page for this purpose. Targets (talk) 21:25, 5 April 2026 (UTC)

What are you proposing for 'bounties'? AndyTheGrump (talk) 21:27, 5 April 2026 (UTC)

Oh, I don't know. Maybe make a leaderboard or something. But we don't even need a bounty at all, that was just a suggestion. Targets (talk) 23:11, 5 April 2026 (UTC)

Why not just barnstars but for a year? MmeMaigret (talk) 07:33, 8 April 2026 (UTC)

We have this template to add to talk pages of articles that lack images: Template:Image requested. Some1 (talk) 21:29, 5 April 2026 (UTC)

Hmm, well I know this exists, but unless you specifically visit that talk page you wouldn't know of them. I propose a consolidated location for all image requests by location. Targets (talk) 23:10, 5 April 2026 (UTC)

It's not on-wiki, but WP:Wiki Shoot Me is a great tool along these lines. nil ^nz 23:26, 5 April 2026 (UTC)

It would be nice if articles listed at Special:WhatLinksHere/Template:Image requested could be organized by location / topic, etc. Some1 (talk) 23:36, 5 April 2026 (UTC)

Just by location, there are about 2000 articles using the "photo requested" template. I don't think a page listing all of those articles would be any more navigable than going through the category system. Schazjmd (talk) 23:38, 5 April 2026 (UTC)

WP:Reward board CMD (talk) 19:52, 8 April 2026 (UTC)

Discontinue “Baby globe”

I would like to propose that we discontinue the use of the “baby globe” animations on Wikipedia. I find them childish and distracting. Please discuss. Blueboar (talk) 23:06, 5 April 2026 (UTC)

You can always turn them off in your settings. But Baby Globe is adorable and I love it. Targets (talk) 23:11, 5 April 2026 (UTC)

At best, cutesy crap like this should be “opt-in” not “opt-out”. Blueboar (talk) 02:17, 6 April 2026 (UTC)

I guess you missed the RfC that was advertised on WP:CENT and open for five weeks. ClaudineChionh (she/her · talk · email · global) 02:22, 6 April 2026 (UTC)

I must have, yes. Targets (talk) 14:41, 6 April 2026 (UTC)

I missed it too. Glad it is ending. Blueboar (talk) 15:20, 6 April 2026 (UTC)

Isn't it opt-in? Sure, I don't mind changing it, I agree with you hear. Targets (talk) 14:40, 6 April 2026 (UTC)

GRAMMAR CristianA.Castillo (talk) 00:41, 8 April 2026 (UTC)

Per Special:CommunityConfiguration/WP25EasterEggs and Meta:Wikipedia 25/Easter egg experiments, birthday mode will be removed on April 6th, which includes the baby globe. 45dogs (they/them) (talk page) (contributions) 00:09, 6 April 2026 (UTC)

NO!! YOU MEAN I'LL NEVER SEE HIM AGAIN??? EVEN IF I TURN ON BIRTHDAY MODE??? Targets (talk) 01:55, 6 April 2026 (UTC)

You will alway be able to find Baby Globe at c:Category:Baby Globe (the animations are at c:Category:Animated GIF files of Baby Globe). ClaudineChionh (she/her · talk · email · global) 02:04, 6 April 2026 (UTC)

Oh, okay that's fair. Targets (talk) 14:40, 6 April 2026 (UTC)

There is also a way to have him replace the Wikipedia logo! I don't exactly remember who made it, but I have it in my common.css! Chaotic Enby (talk · contribs) 16:10, 6 April 2026 (UTC)

Just found it, it is here from @sapphaline! Chaotic Enby (talk · contribs) 16:20, 6 April 2026 (UTC)

Chaotic Enby, could you possibly turn off Birthday Mode, or at least make it not on by default? The RFC specified an end date of March 16th and its been 22 days since then without the mode being turned off. 45dogs (they/them) (talk page) (contributions) 01:27, 8 April 2026 (UTC)

With a heavy heart, it has been done. He will be dearly missed. Chaotic Enby (talk · contribs) 06:50, 8 April 2026 (UTC)

 :( At least we still have the userscripts. 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯 ^{(𝔱𝔞𝔩𝔨)} -⃝⃤ (they/he) 07:24, 8 April 2026 (UTC)

yep, we didn't have a "permanent" mascot the wiki community promised. CristianA.Castillo (talk) 11:52, 8 April 2026 (UTC)

And here's another customization from me. This one allows to have the Birthday Mode turned on indefinitely (only for Vector-2022 though). Note that this will appear on all pages across all namespaces, including non-view ones (e.g. ?action=edit). sapphaline (talk) 20:29, 8 April 2026 (UTC)

By the way, any help with reducing the resolution of the official gifs and reuploading them would be greatly appreciated, because currently most of them work only with the original resolution (1080x1080px), which would mean downloading a ~10-20 MB file if they were in the script. sapphaline (talk) 20:46, 8 April 2026 (UTC)

For what it's worth, I really enjoyed seeing Baby Globe on Wikipedia, and was saddened by seeing Birthday Mode turned off. I've left one comment already about the Baby Globe Browser Extension, but I wanted to ask another: How difficult would it be to keep this feature to users that would like to explicitly keep Birthday Mode enabled?

Looks like some people are making customizations, but I am a Wikipedia newbie, and I'd like a toggle in the settings (similar to dark mode) to enable Baby Globe. From a purely technical perspective, would this be difficult to implement? Ilmikko (talk) 18:22, 12 April 2026 (UTC)

It would be very easy to implement, I've started a subsection just below to gain consensus for it, given the apparent support! Chaotic Enby (talk · contribs) 18:23, 12 April 2026 (UTC)

Hi folks, I was surprised to see that there was no option to keep Baby Globe around after April 6th.

I really liked the way I could keep Baby Globe on different Wikipedia pages, and decided to take a try at creating a web extension that adds Baby Globe back onto webpages, with a similar interactivity as seen on wikipedia.org. The extension is currently being reviewed by Mozilla, but once it is published, I can share a link here to those who would like Baby Globe back. Ilmikko (talk) 18:10, 12 April 2026 (UTC)

This will be the fastest successful pump proposal of all time. CMD (talk) 04:05, 6 April 2026 (UTC)

So… April 6 came and went… and the animation has not been discontinued. So, next step? Blueboar (talk) 11:06, 7 April 2026 (UTC)

Badger an admin to toggle the toggle. CMD (talk) 11:46, 7 April 2026 (UTC)

EXPAND UNTIL MAY 6^TH! CristianA.Castillo (talk) 23:03, 7 April 2026 (UTC)

GRAMMAR Targets (talk) 01:14, 8 April 2026 (UTC)

I definitely disagree with you because it is a way to celebrate 25 years of the collaborative online encyclopedia, and many people share that they support the feature, and they unlike you, should keep birthday mode longer. CristianA.Castillo (talk) 13:39, 7 April 2026 (UTC)

I don’t mind celebrating 25 years, I do think we should celebrate in a more mature way. Blueboar (talk) 16:19, 7 April 2026 (UTC)

What’s a bit of fun here and there on Wikipedia? I think it’s nice to play around a little bit sometimes; nothing immature about enjoying yourself. If that means you want a little animated globe guy to replace the official Wikipedia globe, have at it!

(P.S. What specifically do you imagine when you say to celebrate in a more mature way?) 𝔰𝔥𝔞𝔡𝔢𝔰𝔱𝔞𝔯 ^{(𝔱𝔞𝔩𝔨)} -⃝⃤ (they/he) 20:22, 7 April 2026 (UTC)

Drawing a baby Bishzilla (unbearably cute)? bishzilla _ROARR!! pocket 20:36, 8 April 2026 (UTC).

It's adorable. No. Mrfoogles (talk) 15:29, 13 April 2026 (UTC)

Opt-in Baby Globe

As many people (me included) dearly miss Baby Globe, would there be consensus to bring it back as an optional feature that people can choose to enable? Chaotic Enby (talk · contribs) 18:20, 12 April 2026 (UTC)

Yes please! I wholeheartedly support the feature. I think the Baby Globe is a fun and engaging way to get more people involved in the project. :) Ilmikko (talk) 18:31, 12 April 2026 (UTC)

I think making it opt in is fine. Though, it appears the community config option for birthday mode is gone. 45dogs (they/them) (talk page) (contributions) 19:33, 12 April 2026 (UTC)

Yes, the idea is to bring that option back as an opt-in! Special:CommunityConfiguration/WP25EasterEggs gives us an option for it. Chaotic Enby (talk · contribs) 19:40, 12 April 2026 (UTC)

I think I didn't properly read the opening statement. My apologies. 45dogs (they/them) (talk page) (contributions) 20:04, 12 April 2026 (UTC)

As I mentioned in a different thread (though for slightly different reasons), personally I prefer for a user-script approach for this type of decorative enhancement. It allows for more flexibility in implementing an enhancement that supports most users interested in it, without having to spend the extra effort needed to ensure universal support. It also allows for crowd-sourcing any ongoing sustaining work. For example, users could create and share their own lists of where Baby Globe would serendipitously appear, and they could update the lists over time as needed or desired. (I designed my custom logo replacement user script to enable this type of collaboration.) isaacl (talk) 20:41, 12 April 2026 (UTC)

I would support mentioning one or two scripts at WP:BABYGLOBE. CMD (talk) 03:14, 13 April 2026 (UTC)

Enable OWID template gadget

Hi everyone! Following up on this Aug 2025 thread, I'd like to propose enabling the OWID template gadget on the English Wikipedia. The gadget allows users to load interactive charts from Our World in Data after asking the user for explicit consent to share their IP address with them. The gadget has gone through a security review by the WMF and a data-sharing agreement between WMF and OWID. More recently, OWID created versions of their charts specifically for use by Wikipedia, without any third-party tracking (like Google Analytics). As a consequence, the gadget has already been enabled in the Spanish Wikipedia and a couple other wikis.

While the English Wikipedia already has {{owidslider}} which creates similar charts from SVGs uploaded to Commons, the functionalities are more limited and it is very labor intensive.

Thoughts? Support? Objections? Comments? Questions? Thanks! Sophivorus (talk) 16:01, 6 April 2026 (UTC)

• Support As one of the folks that has been involved in its development. Would be good to have both methods of data visualization as the other method does not handle the more complicated Explorer graphs. Doc James (talk · contribs · email) 16:08, 6 April 2026 (UTC)
• While there has been a security review, can we have more visibility regarding the amount of data that will be shared with OWID, and the security risks? There have been some updates regarding the agreement in March and August 2025, but I would be more comfortable knowing which data is at risk and which measures are in place, especially as disclosure (and potential leaking) of personal information and phishing/spoofing were identified as major risks back in May 2024. Chaotic Enby (talk · contribs) 16:16, 6 April 2026 (UTC)

  @ACooper-WMF @Mark Bergsma (WMF) As the Director of Product Security and the announcer of the agreement with OWID (respectively), perhaps you can answer this concern? Thanks, Sophivorus (talk) 18:19, 6 April 2026 (UTC)

  ACooper hasn't worked at the foundation for a while now, i think his nearest equivelent would be Eric Mill. Bawolff (talk) 22:00, 6 April 2026 (UTC)

  Thanks, pinging Eric Mill then. Sophivorus (talk) 22:55, 6 April 2026 (UTC)

  Hey all, jumping in here as I was closer to this work while we were forming the agreement. Our team ultimately identified the security risks as being low. The main privacy risk is the servers hosting the OWID charts would have access to the user's IP address when the popup is loaded, although OWID claim not to be intentionally storing or logging this IP address anywhere (@DanyX can maybe elaborate more here). While it does not eliminate these risks, the agreement formalizes the accountability for both parties if something were to go wrong (e.g. a data breach or other security incident) that could have an impact on our users. CCiufo-WMF (talk) 21:25, 14 April 2026 (UTC)

  Hi! Thanks a lot for the clarification! I am quite happy to hear that the security risks are estimated to be low. Regarding OWID's data storage, which reassurances do we have beyond the agreement, and how does this accountability take shape in practice? I would be more than happy to trust you at your word on this matter, but I believe that some more skeptical editors might need stronger guarantees to be convinced. Chaotic Enby (talk · contribs) 21:59, 14 April 2026 (UTC)

  While I appreciate WMF involvement in this matter, I'm in the same boat that I'm less than certain about the assurances provided through the agreement. Until recently, the "approved" version of the gadget contained Google Analytics scripts when the iframe was loaded (this has now been removed), and still uses Cloudflare as CDN and a proxy (meaning that Cloudflare definitely stores some of the data being transmitted here). I understand that this is probably done to mitigate bot-traffic to OWID servers, but it calls into question who will be liable if Cloudflare hypothetically leaks user data. (For transperancy, I was involved in a mail thread regarding this gadget, which is why I have not voted) Sohom (talk) 23:08, 14 April 2026 (UTC)

  In case anyone is unfamiliar with the technical aspects of what's happening, I'll try to explain without any technical jargon (if someone from the WMF can validate or correct my summary, it would be appreciated). In short, the OWID charts are loaded via iframes, which are basically "nested browser tabs". iframes can be configured in several ways, but the way these iframes are configured, the child website (in this case, OWID) has access to the following information:

  • The IP address of the user loading the iframe (which often allows to infer the city)
  • The brand and version of the browser of the user (to adjust the content to different browser capabilities)
  • The size of the iframe (to adjust the content to the size it is viewed)
  • The preferred language of the user (as configured in the user's browser, not in Wikipedia)
  • The website (Wikipedia) from where the iframe is being loaded (actually no, but because we're loading the charts from the custom subdomain OWID has set up for us, they can guess)

  In other words, OWID (and Cloudflare) does not have access to the user name of the user, their password, their email, their name, their exact location (only the city, as inferred from the IP), their gender, their age, the exact URL from where the iframe is being loaded, the cookies of the user, their Wikipedia preferences, their browsing or search history, or really nothing except the information listed above. So in case of a data breach (by OWID or Cloudflare), the data that would be compromised would be something like: on this date, this IP address, using this browser and preferring this language, came from Wikipedia and requested this chart. For context, this is the same information that we routinely give when we visit any website by clicking an external link on Wikipedia. Sophivorus (talk) 13:10, 15 April 2026 (UTC)

  i.e. CheckUser-level information. Yes, this is equivalent to clicking a link, but you need to keep in mind that "clicking a link" disassociates a user from Wikipedia. In it's current state, the gadget affords less protection to the user than that placed on hCAPTCHA or Kartographer's OSM endpoint. Some folks might be okay with it, some might not. Sohom (talk) 13:40, 15 April 2026 (UTC)

  Hence the request for consent by the user. Sophivorus (talk) 14:01, 15 April 2026 (UTC)

  Which doesn't mention Cloudflare. (note that this isn't "OWID should move off Cloudflare" but rather why I have low confidence in this specific security review assuages community concerns) Sohom (talk) 14:38, 15 April 2026 (UTC)

  In addition, while these pieces of data don't identify a user individually (besides the IP address), they are in aggregate able to determine a single endpoint, and lead to immediate de-anonymization concerns, tracking an individual user's browsing history on Wikipedia. While other websites may be okay with this, Wikipedia has historically been cautious with tracking its users' browsing patterns or giving access to them to other companies, which is what this would enable (and what makes it fundamentally different from an external link situation). Chaotic Enby (talk · contribs) 17:03, 15 April 2026 (UTC)

  This is all correct. I thought I could describe the OWID side in a bit more detail in case this helps.

  After a user gives consent, what is loaded is a page from a dedicated Wikipedia OWID archive inside an iframe. These are static HTML pages hosted from a Cloudflare R2 bucket (Cloudflare's version of the S3 file storage).

  This Wikipedia archive is the same as our normal archive, except that we removed Google Analytics (archived life expectancy page in the wikipedia archive and the normal archive). On our normal archive, we do use GA to understand traffic patterns and user behaviour. For the Wikipedia use case, we understood that this would be problematic, so we created a separate mirror specifically for Wikipedia without that tracking.

  If you look at the outgoing requests, you will see one request that hits our main domain (instead of the wikipedia-archive subdomain) at https://ourworldindata.org/api/detect-country. This uses a Cloudflare Worker to map the source IP to the user’s country, and the visualization component then uses that to place that country at the top of the selection list. This is purely for usability.

  The source code for this, and for the website and visualization component generally, is available on GitHub for anyone who wants to inspect it.

  As you can see, we actively tried to minimize any potential privacy concerns.

  It means that only after users actively consent to loading external content, this content is retrieved from Cloudflare servers. I think that the risks that come from loading content from Cloudflare are pretty small, and the benefit that users get seems large in comparison - but of course, others might disagree. If so, it would help me to understand more of the threat model they have in mind.

  Happy to answer any further questions! DanyX (talk) 15:12, 15 April 2026 (UTC)

  • Really...that sounds implausible – I kind of doubt it was 'approved' in any way fitting that term if it had Google Analytics code in it. So probably what was approved is further work on this script or the WMF acceptance that the gadget can be added in principle (or sth of that sort), not the specific version of the code for implementation as is.
  • Additionally, I heard there was a functional version of the OWID content on some Wikimedia server where it wouldn't load the data directly, maybe things relating to that could be clarified.
  • In any case, currently one has to click a button to make it load which is similar to how one is clicking an external link to load a page. To better protect anonymity of contributors (the issue is not so much readers as far as I can see), ideally the IP of the user requesting the visualization data would be shielded from OWID & Cloudflare. Note that unlike with Wikipedia where editing while using a VPN is generally not possible, VPNs would shield the IP if one is using one.

  Prototyperspective (talk) 13:20, 15 April 2026 (UTC)

  • I'm fairly certain that previous versions of the gadget opened a page that loaded Google Analytics tooling, I have no idea how/why that was approved.
  • I've been a proponent of "put it behind a toolforge proxying tool" for a while. Toolforge shields the IP from anyone/everyone.

  Sohom (talk) 13:45, 15 April 2026 (UTC)

• Hi! I’m the Head of Engineering at Our World in Data — happy to answer any technical or clarifying questions.

To clarify our role: OWID did not develop the gadget itself, and we see it as something for the community to evaluate and decide on. That said, we have been closely involved in enabling its use. In collaboration with the Wikimedia Foundation, we worked through the legal and data-sharing framework, and we also adapted our infrastructure to support this use case, including creating a dedicated version of our charts for Wikipedia without third-party tracking.

We’ve coordinated on this with members of the community (including Doc James and Sophivorus), and we’ve tried to make the integration as straightforward and transparent as possible. Our code for the chart rendering and the Iframe being rendered is open and available on GitHub for anyone who wants to review it.

From our perspective, this approach offers a meaningful improvement in how readers can explore data on Wikipedia, and we know there is demand for more interactive ways of engaging with these topics. But we also want to be clear that our role here is to support, not to steer the discussion. I'm very happy to help answer questions and provide context as needed.

Thanks to everyone involved! DanyX (talk) 17:25, 6 April 2026 (UTC)

• Strong support – a) lots of research or surveys found readers would like more visual media such as images and charts b) few things would be more educationally useful in articles than interactive charts about the subject (interactive in that eg one can select country/ies one is interested in such as the one the reader is living in) c) there are various disadvantages to the owidslider such as it not showing the precise number when hovering over countries or being able to select countries to compare and things like that. Relevant interactive charts should be directly within the article instead of dispersed across the Web and hard to find or discover and articles shouldn't have old outdated charts so would benefit from embedding sth that gets dynamically updated.

Some things could be improved about the gadget, such as adding a toggle button to display the precise numbers even without hover on the countries and making chart contents better discernable and clearer and better comparable by the tool zooming in on the segment with data points – e.g. c:File:Life expectancy at birth in Portugal, Spain, etc over time, OWID.svg should not start at 0 years but at 38 years. The tool is open source so volunteers could help add such improvements. I'll list such feature requests, ideas, etc in bundled form at the talk page of Wikipedia:WikiProject Data Visualization some time soon. People interested in this broader subject or in discussing the gadget long-term are welcome to join it. Also, I almost missed this post and just found it by chance – would be good if a notification about this VP/P post was added to that talk page. Prototyperspective (talk) 16:15, 13 April 2026 (UTC)

@Prototyperspective I just posted a link to this discussion there. Regarding your ideas for improvements, I wholly agree and would be happy to implement some of them if the gadget starts getting used. Sophivorus (talk) 12:57, 14 April 2026 (UTC)

Strong support OWID charts are great and well worth it. Security-wise: it's a nonprofit, it's working with Wikipedia, I'm not worried about it. Most people don't have to worry that much about their IP given they're sending it to most websites, and those who do can refuse to share and/or use a VPN. It's not really that much different than providing a link to OWID as far as I can tell. Mrfoogles (talk) 00:01, 16 April 2026 (UTC)

Removing Template:Wikinews and similar from articles?

I'm proposing removing the remaining transclusions of {{Wikinews}} (3.3k), {{Wikinews category}} (321), and {{Wikinews inline}} (251) as part of the looming closure of that sister project.

Wikinews links have long had a dicey foundation on the English Wikipedia. To name two prominent RfCs, eight years ago we had a near-unanimous consensus for significantly restricting where/when we could link to Wikinews, and 13 years ago we had an "obvious, overwhelming" consensus to remove a prominent main page link to it. For these templates specifically, seven years ago an editor proposed depreciating {{wikinews}} because the project was even then "essentially dead."

Now that Wikinews will no longer be a sister project, we should probably not continue giving special prominence to the links that remain. I am thinking that there will be broad agreement on this, but it could become a RfC if needed. Ed ^{[talk] [OMT]} 03:17, 7 April 2026 (UTC)

Since Wikinews is no longer a sister project, I agree that they should be treated the same as any non-Wikimedia external links of their quality. Chaotic Enby (talk · contribs) 08:48, 7 April 2026 (UTC)

I see no reason not to. Feeglgeef (talk) 02:25, 12 April 2026 (UTC)

UTC: Format & Conversion

Given that the 2026 Iran war has theaters spread across four time zones, and arguably involves a fifth, I propose a conversion mode that takes the much-vaunted, local time, say Kuwait at 8:00 a.m., and outputs it in the format of 8 a.m. Arabia Standard Time (UTC+03:00). A standard is called for, if not a daylight saving. kencf0618 (talk) 01:45, 9 April 2026 (UTC)

Discussion at Wikipedia talk:WikiProject United States § Specifying National Association of Counties citations

 You are invited to join the discussion at Wikipedia talk:WikiProject United States § Specifying National Association of Counties citations. Staraction (talk · contribs) 22:38, 9 April 2026 (UTC)

Widening the timelines

Palaeotherium Temporal range: Middle Eocene – Early Oligocene PreꞒ Ꞓ O S D C P T J K Pg N PreꞒ Ꞓ O S D C P T J K Pg N
Scientific classification
Kingdom:	Animalia
Phylum:	Chordata
Class:	Mammalia
Order:	Perissodactyla
Family:	†Palaeotheriidae
Genus:	†Palaeotherium Cuvier, 1804
Type species
†Palaeotherium magnum Cuvier, 1804

The current {{Phanerozoic 220px}}, shown at the top of most fossil taxoboxes and used in {{Geological range}}, is, well, 220 pixels wide. This slight increase from the original 200 pixels took place back in 2010, and monitor resolutions have greatly increased since. In fact, the default thumbnail size has climbed up to 250 pixels, leaving some unused space on each side of the range, while the comparatively thin Silurian and Neogene are cramped.

The equivalent Precambrian template, {{All time 250px}}, already uses a wider resolution, and I don't see why this can't work for the main timeline (and the period-by-period {{Period fossil range/rangebar}} which also uses 220px).

I've made a 280 pixels demo at User:Chaotic Enby/Phanerozoic 280px, inspired by what is currently being done on the Hebrew Wikipedia. You can see a comparison to the right in "real conditions", inside a taxobox with bold text and 88% font size, although without the range or the timeline zoom. This width gives some breathing space to the Silurian and the Neogene, while also allowing us to add a white highlight to blue links for readability (instead of having to alternate blue and white links depending on background color).

Should we go ahead and widen the timeline templates to 250 or even 280 pixels? Chaotic Enby (talk · contribs) 02:34, 11 April 2026 (UTC)

CE you are always cooking. Yes, that looks good, though I have a harder time reading the blue links with white shadow. I wonder if altering the back colors to make the links white instead of blue would be easier to see? 3df (talk) 08:18, 12 April 2026 (UTC)

Yep, that's feasible too! My hope was that the shadows would make reading easier without having to alternate link colors, although we could very much keep the existing link colors and still widen the timeline.

Sadly, the period colors we're using are the "official" ones (from the International Commission on Stratigraphy) which are used virtually everywhere and do serve as a useful shorthand for people familiar with paleontology, so I'm not sure they can be changed.

(also, I just added slightly brighter outlines, tell me if that's more readable!) Chaotic Enby (talk · contribs) 20:20, 12 April 2026 (UTC)

Definitely approve of expanding the width, it looks better. New link colors are imperfect, but pretty good. Mrfoogles (talk) 23:56, 15 April 2026 (UTC)

Banning product comparison articles

There's been some discussion at WP:ANI#Return to potentially POINTy editing regarding an editor who's been mass-nominating "Comparison of X" articles like Comparison of 3D printers for deletion. The general standpoint seems to be that indeed most of these 'comparison' articles are dubiously notable, and even the arguments for notability seem to mostly point to things like tech blogs hosting such comparison articles.

The more I think about it, the more it seems to me that the concept of an article comparing products seems to be inherently unencyclopedic. We are not a product catalog, after all. Why is it that we say Listings to be avoided include, but are not limited to... products and services... Wikipedia is not a price comparison service to compare prices and availability of competing products or a single product from different vendors. But we are, apparently, a quasi-tech blog where one can see comparisons of the technical specs of phones or 3D printers or cars or what have you? The technical aspects of these things can always be discussed in the main article dedicated to them, perhaps even inclusing some limited comparative discussion; are standalone articles for this purpose really within scope?

Should we have a blanket ban on these kinds of articles? Athanelar (talk) 20:39, 14 April 2026 (UTC)

If the comparison of products is commonly done in reliable sources, including a discussion on those differences, such as the case for home video game consoles, that makes it fair for us to include. But if that comparison is just because we have specs for each and just putting them into a table, and RSes dont discuss these differences, that's likely beyond our scope. Masem (t) 21:08, 14 April 2026 (UTC)

My suggestion is that such comparison is out of scope even if it's being done in RSes. We don't necessarily need to include articles about everything that any RS writes about; we have carveouts everywhere for things like WP:CORPTRIV for example. I think product comparison articles should be out of scope per se regardless of whether someone else is already doing it. Athanelar (talk) 21:24, 14 April 2026 (UTC)

I'd argue that even if a comparison is covered in reliable sources, an article starting with "Comparison of" would be about the comparison and how they've historically been compared by others. Not comparing them ourselves. Thebiguglyalien (talk) 21:47, 14 April 2026 (UTC)

I agree. Actually listing the properties of products and performing the comparison comes under the "not a product catalog" rule, I'd think. But if there are sufficient sources for an article about the comparisons, not about the products, then that would be OK. I doubt many (or even any) would qualify, though. Mike Christie (talk - contribs - library) 23:29, 14 April 2026 (UTC)

I'm not a great fan of blanket bans (or, indeed, blanket anything) but I agree that most such articles are inherently unencyclopedic. Phil Bridger (talk) 21:11, 14 April 2026 (UTC)

I'd go a bit further than that; which such articles are encyclopedic, and which would meet the required SIGCOV element of discussing the topic itself? Ravenswing 21:59, 14 April 2026 (UTC)

Comparison of lions and tigers isn't... A sad day for anyone looking to invest in that market. Chaotic Enby (talk · contribs) 11:45, 15 April 2026 (UTC)

I strongly oppose any sort of blanket ban. Very often these comparison articles are the best way for readers to understand how two similar encyclopaedic subjects differ - a necessary part of providing complete encyclopaedic coverage of those topics. Thryduulf (talk) 22:06, 14 April 2026 (UTC)

As long as that comparison is done by RSes, or at least routinely done in RSes. If not RSes makes these comparisons, then that's OR for us to make them. Masem (t) 22:22, 14 April 2026 (UTC)

How is it be OR to list characteristics of products if characteristics are reliably sourced, as long as we don't judge one "better"? Hyperbolick (talk) 00:30, 15 April 2026 (UTC)

Which features are we picking to make a comparison? Just that choice itself can implicitly bias one of the products over another if we include or exclude certain features. Letting RSes show how they make comparisons removes that possible OR bias. Masem (t) 11:29, 15 April 2026 (UTC)

Comparisons are secondary source material, so that's partway to the WP:GNG right there. WhatamIdoing (talk) 00:45, 15 April 2026 (UTC)

Can you give some examples of good comparison articles? Orange sticker (talk) 07:14, 15 April 2026 (UTC)

Definitely not encyclopedic. Among other things, such articles would be ephemeral. Who is going to care a year later which printer some magazine or other rating service recommended? Donald Albury 23:19, 14 April 2026 (UTC)

I'm not sure that's such comparisons are ephemeral. Sure, "ExpertsRUs recommended X from 1994 to 1997" is unimportant, but I thought the point of the comparisons was less ephemeral.

For example, the Comparison of 3D printers compares these points:

• Year released
• Print technology
• Max build volume (mm)
• Max build volume (in)
• Min layer resolution (μm)
• Print speed (mm/s)
• Kit or assembled

We might agree or disagree on what's important, but none of that feels ephemeral to me. It sounds like stable, objective facts. WhatamIdoing (talk) 00:51, 15 April 2026 (UTC)

This can lead to bias by omission though, if criteria are left out it can be impossible for a reader to judge, say, which printer is the most efficient or high spec. But really, although "provider of retail advice editorial" isn't under WP:NOT I don't think it's our role to provide comparisons of consumer products. I'm less bothered about the articles that compare languages, road signs or alphabetic country code, but nearly every other "Comparison of" article is about a tech product. We're not CNET. Orange sticker (talk) 07:24, 15 April 2026 (UTC)

Which criteria are used in a comparison is not relevant to this discussion, the question here is only whether to have these sorts of comparisons at all. Detail about what is compared is something that can only be determined at the individual article level. Thryduulf (talk) 10:18, 15 April 2026 (UTC)

But the fact is there's nothing stopping editors cherry picking criteria and, by the nature of the article, using them as comparison indicators, if we allow these types of article. This is what's happened and why it's WP:OR specifically WP:SYNTH - though that's not to imply bad faith. It's just inevitable. Orange sticker (talk) 10:22, 15 April 2026 (UTC)

We do not and should not ban whole categories of articles because they might contain OR or SYNTH, we fix and/or delete specific articles that do contain OR or SYNTH. It is not at all inevitable. Thryduulf (talk) 10:46, 15 April 2026 (UTC)

I'm not arguing in favour of a carpet ban, but certainly a policy or guideline that discourages their creation and ensures no OR. Preventative measures are better than having to fix large volumes of problematic content which is the position that's been created now. Orange sticker (talk) 10:52, 15 April 2026 (UTC)

We don't need or want a policy or guideline that discourages the creation or adding of encyclopaedic articles or content, we already have policies and guidelines against creating or adding non-encyclopaedic articles/content, including original research. You haven't yet identified any content that is actually problematic, nor any evidence that there is a large volume of such that can't be handled by normal editing. Thryduulf (talk) 11:15, 15 April 2026 (UTC)

There's currently an ANI complaining about that an editor is nominating these at too large a volume, and those AfDs discuss the matter of OR and unencyclopedic content in them. This is a case where policy could be more explicit to save editors' time and improve the project. Orange sticker (talk) 12:37, 15 April 2026 (UTC)

Doing anything in “large volume”… be it creating articles, or nominating them for deletion… is always a negative behavioral issue. Our policies, guidelines and procedures don’t handle “large volume” well. Blueboar (talk) 21:06, 15 April 2026 (UTC)

there's nothing stopping editors cherry picking criteria ...except for our anti-cherry-picking policy, Wikipedia:Neutral point of view. WhatamIdoing (talk) 02:12, 16 April 2026 (UTC)

I think there are a limited set of product comparison articles that are worthwhile: those that compare generations of a single product. Often these end up embedded in the products main page, but if there is enough text, it makes sense to break it out. Examples: List of iPhone models, List of Intel processors. Note they're labelled "lists", but the body is primarily comparison information. Sometimes the same product is produced by multiple companies: the comparison is still useful: Comparison of ARM processors. Note that I'd differentiate this from comparison of unrelated products with the same functions (e.g., Comparison of server-side web frameworks), which I wouldn't see as appropriate for Wikipedia. That said, there are some heterogenous categories where the comparison page appears useful, e.g., Comparison of programming languages. Note that the programming languages comparison is going over the various attributes that we'd normally use when describing a programming language, so it's not a marketing comparison, rather a look at the inherent characteristics of programming languages that differentiate one from another. — rsjaffe 🗣️ 02:15, 15 April 2026 (UTC)

Agree, I don't have a big problem with Comparison of Google Pixel smartphones in terms of WP:OR because there's been no curation by editors, it's an exhaustive list and the specs also seem comprehensive (much of the sourcing isn't independent though). However I don't see why "Comparison" is in the title. "List of Google Pixel smartphones" would be fine or "Technical specifications of Google Pixels" would be more accurate. Comparison implies we are telling readers which is better/worse, faster/slower, bigger/smaller etc. These articles just present the information for readers to use how they see fit. Orange sticker (talk) 07:28, 15 April 2026 (UTC)

Comparison implies we are telling readers which is better/worse, faster/slower, bigger/smaller etc. Why do you think that? With the exception of better/worse, why is it a problem if we tell readers objective facts about them? Thryduulf (talk) 09:49, 15 April 2026 (UTC)

It's just that laying out objective facts isn't making a comparison, so those articles should just be called lists. It stops being objective when the (rankable) categories of facts are curated and someone selects which criteria to use to describe a product. It's like me creating a "Comparison of UK Cities" article and using "Number of Beatles born there" as a ranked category :) Orange sticker (talk) 10:04, 15 April 2026 (UTC)

But we've got to make some "selection" of criteria, because there is eventually a hard limit of how much content can be put in a single page. WhatamIdoing (talk) 02:14, 16 April 2026 (UTC)

If product comparisons are to be banned (which imo they should not be, per my above comments) it will be necessary to define what a product is in this context. Obviously Comparison of word processor programs is (although given that it compares software currently underground active development with programs with a most recent release date in 1986 how much it is a "marketing" comparison is debatable) and Comparison of graphics file formats is not, but what about Comparison of text editors, Comparison of operating system kernels, Comparison of open source wireless drivers, Comparison of North American ski resorts or Comparison of orbital launch systems? Thryduulf (talk) 02:52, 15 April 2026 (UTC)

I'm less bothered about the articles that compare languages, road signs or alphabetic country code, but nearly every other "Comparison of" article is about a tech product. I categorised every article starting with a title starting "Comparison of"

Category	Count
Software (inc. operating systems, libraries)	185
Computer, smartphone, digital camera, etc hardware	37
Protocols, standards, encodings, formats, etc	33
Websites and online services	23
Languages, writing systems, accents, etc	33
Sports	15
Programming, scripting and markup languages	13
Medicine and biology topics	10
Vehicles	11
Other technology (e.g. battery types)	9
Religion topics	5
Other	34

Even if everything in the first top two categories is a product (which they very much aren't) then they only account for 57% of comparison articles. Thryduulf (talk) 11:04, 15 April 2026 (UTC)

wikt:every other is usually taken to mean "every second" or "half of", so that number does check out. Some software might not count as products, but that might also be offset by some online services and other technologies, although we'll need more details to be sure. Chaotic Enby (talk · contribs) 11:47, 15 April 2026 (UTC)

It all goes back to my earlier question of what is a product? And even within things that are clearly products there is a big difference between e.g. Comparison of iOS devices, Comparison of DVD ripper software, Comparison of HTML parsers and Comparison of early word processors. I suppose it depends what the exact problem you have with these articles is, as all the reasons given above are vague gestures towards non-specifics and complaints that some articles might contain things that are already not allowed. Thryduulf (talk) 12:57, 15 April 2026 (UTC)

I don't personally have any problem with these articles, I was just hoping to clarify the terminology matter! Chaotic Enby (talk · contribs) 17:07, 15 April 2026 (UTC)

Adding to the point about defining products, when is a list a comparison? List of battery electric vehicles is not a "comparison of" but includes lengthy tables through which readers can ... compare various aspects of each. Is any table of [products] with more than their name a comparison? If it makes sense to include more than the name of something, is the key just not putting the information in a table? — Rhododendrites ^talk \\ 13:00, 15 April 2026 (UTC)

Making the the categories rankable makes the list a comparison because it implies some factors are > than others and means entries can be easily grouped into the haves and have nots. But it would be petty not to allow users to rank tables. My solution would be to ensure the title says "list", otherwise we risk putting into Wikivoice "product A ranks higher than product B according to Wikipedia's comparison". Orange sticker (talk) 13:09, 15 April 2026 (UTC)

Eh? You want to ban whole categories of articles because some people might choose to compare encyclopaedic information about encyclopaedic topics in way that might suggest something was better or worse than something else? This is screaming WP:IDONTLIKEIT and trying to police the way readers use our content. Thryduulf (talk) 13:21, 15 April 2026 (UTC)

Eh indeed. I've already replied to you directly saying I'm not arguing in favour of a carpet ban. I'm saying we shouldn't be making unsourced comparisons in Wikivoice, and I'm explicitly arguing that readers be allowed to read and manipulate the tables how they see fit. However, it's up to us to ensure WP:NPOV and no WP:OR and we're currently failing to do that. Orange sticker (talk) 13:26, 15 April 2026 (UTC)

What unsourced comparisons are being made? If product X has a sourced list of features, and product Y has a sourced list of features, neither become magically unsourced by placing them in a table. This proposal completely fails to demonstrate that product comparisons are a failure of NPOV or OR in and of themselves and completely fails to demonstrate that any such problems that do exist would be solved by adopting it. Thryduulf (talk) 13:42, 15 April 2026 (UTC)

If no independent third party expert has ever published a work that compares product X to product Y, we are introducing WP:OR. If an editor decides to create a table and chooses which criteria should be included for comparison and what is left out, that is WP:SYNTH. And beyond hypotheticals, a lot of the existing articles have vast amounts of unsourced info, e.g.: Comparison of genealogy software, Comparison of CRM systems, Comparison of DVD ripper software. Orange sticker (talk) 13:53, 15 April 2026 (UTC)

Absolutely none of this is a problem with the type of article itself, its a problem (and I'm not convinced on the OR or SYNTH claims) with the individual articles. Thryduulf (talk) 13:57, 15 April 2026 (UTC)

And yet its evident on so, so many of of them. I chose those three at randon from Category:Software comparisons and they all had glaring problems. It's clear allowing this type of article without any clear guidelines has lead to vast amounts of unsourced, original research being added to the project over the years. We have the opportunity here to improve Wikipedia. Orange sticker (talk) 14:01, 15 April 2026 (UTC)

Even if that is true, you still need to show that this will actually improve Wikipedia, and removing or discouraging whole swathes of encyclopaedic content is not an improvement. Thryduulf (talk) 14:02, 15 April 2026 (UTC)

In re If no independent third party expert has ever published a work that compares product X to product Y: And yet the complaints focus on tech subjects, for which comparing product X to product Y is the everyday normal form of the reliable sources. WhatamIdoing (talk) 02:17, 16 April 2026 (UTC)

@Orange sticker, Does "Making the the categories rankable" mean "making it possible to sort the table by columns"? WhatamIdoing (talk) 02:16, 16 April 2026 (UTC)

I'm rather surprised to see that count being used to say that not many such articles are about tech products. It shows that about 70% of them are directly related to computers. It may surprise some Wikipedia editors to know, but the world is not made up of 70% computers and 30% everything else. The table shows just how bad the systemic bias is that's caused by young first-world males being vastly over-represented among us. Phil Bridger (talk) 21:50, 15 April 2026 (UTC)

Not all of the first two categories are directly related to computers, unless you take a very broad definition of "computer". For example graphical calculators and digital cameras are included in the hardware category, and not everything related to computers is a product, even by a broad definition. Tech products are probably the largest single thing, but they don't account for 70%. It's also worth stressing that this only considered articles named "Comparison of", not "list of", "table of" or anything else, even if there was a redirect from a "Comparison of" title. Thryduulf (talk) 22:02, 15 April 2026 (UTC)

My take is that they are important but appear to be WP:SYNTHESIS. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:11, 15 April 2026 (UTC)

We can compare topics frequently compared in reliable sources but that doesn't mean that all comparison-cruft has a place in this encyclopedia. As you point out, the choice of comparison-criteria itself should be reliably sourced to avoid WP:OR. A ban seems over-the-top and like rule-creep. However, it may help to articulate your arguments against comparison articles in an essay and cite that in relevant discussions. Joe vom Titan (talk) 00:24, 16 April 2026 (UTC)

Addition of important policies and MOS to the community portal

The community portal only offers to ask for help, but it should also link to important policies like the core content policies and assume good faith along with MOS, this makes it so new users can read the important policies and guidelines of wikipedia relatively quickly without asking for them from someone else. Misterpotatoman (talk) 22:22, 15 April 2026 (UTC)

Not opposed… however, most new editors don’t know that the Community Portal even exists… so first we would have to point them there (say in a welcome message). And as long as we are pointing them to places, we might as well skip a step and just point them directly to these core policies. Blueboar (talk) 23:18, 15 April 2026 (UTC)

The community portal is right on the left sidebar. I'm not sure but I imagine new editors will eventually think "Ooh, what's that?". Don't remember exactly how I found it myself. I think the core content policies worth adding. Mrfoogles (talk) 23:58, 15 April 2026 (UTC)