Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63

The prominence of parent categories on category pages

The format of category pages should be adjusted so it's easier to spot the parent categories.

Concrete example:

I happen to come across the page: Category:Water technology

I can see the Subcategories. Great. I can see the Pages in the category. Great. No parent categories. That's a shame --- discovering the parent categories can be as helpful as discovering the subcategories.

Actually, the parent categories are there (well, I think they are --- I'm not sure because they're not explicitly labelled as such). But I don't notice them because they're in a smaller font in the blue box near the bottom of the page: Categories: Water | Chemical processes | Technology by type

I think the formatting (the typesetting) of the parent categories on category pages should be adjusted to give the parent categories the same prominence as the subcategories. This could be done by changing: Categories: Water | Chemical processes | Technology by type to: Parent categories: Water | Chemical processes | Technology by type and increasing the size of the font of `Parent categories', or, perhaps better, by having the parent categories typeset in exactly the same way as the subcategories. D.Wardle (talk) 22:21, 22 December 2024 (UTC)

Parent categories are displayed on Category: pages in exactly the same way that categories are displayed in articles. WhatamIdoing (talk) 04:26, 26 December 2024 (UTC)

The purpose of an article page is to give a clear exposition of the subject. Having a comprehensive presentation of the categories on such a page would be clutter --- a concise link to the categories is sufficient and appropriate.

The purpose of a category page is to give a comprehensive account of the categories. A comprehensive presentation of the categories would not clutter the subject (it is the subject).

Therefore, I do not expect the parent categories to be presented the same on article and category pages --- if they are presented the same, that only reinforces my opinion that some change is necessary. D.Wardle (talk) 20:15, 27 December 2024 (UTC)

I think the purpose of a category page is to help you find the articles that are in that category (i.e., not to help you see the category tree itself). WhatamIdoing (talk) 21:40, 27 December 2024 (UTC)

Is there any research on how people actually use categories? —Kusma (talk) 21:48, 27 December 2024 (UTC)

I don't think so, though I asked a WMF staffer to pull numbers for me once, which proved that IPs (i.e., readers) used categories more than I expected. I had wondered whether they were really only of interest to editors. (I didn't get comparable numbers for the mainspace, and I don't remember what the numbers were, but my guess is that logged-in editors were disproportionately represented among the Category: page viewers – just not as overwhelmingly as I had originally expected.) WhatamIdoing (talk) 22:43, 27 December 2024 (UTC)

I'm fine with parent categories being displayed the same way on articles and categories but I think it's a problem that parent categories aren't displayed at all in mobile on category pages, unless you are registered and have enabled "Advanced mode" in mobile settings. Mobile users without category links probably rarely find their way to a category page but if they do then they should be able to go both up and down the category tree. PrimeHunter (talk) 15:39, 28 December 2024 (UTC)

Am I missing something? Is there a way of seeing the category tree (other than the category pages)?

If I start at:

https://wiki.riteme.site/wiki/Wikipedia:Contents#Category_system

... following the links soon leads to category pages (and nothing else?). D.Wardle (talk) 20:20, 28 December 2024 (UTC)

I'd start with Special:CategoryTree (example). WhatamIdoing (talk) 20:49, 28 December 2024 (UTC)

You can click the small triangles to see deeper subcategories without leaving the page. This also works on normal category pages like Category:People. That category also uses (via a template) <categorytree>...</categorytree> at Help:Category#Displaying category trees and page counts to make the "Category tree" box at top. PrimeHunter (talk) 20:59, 28 December 2024 (UTC)

Now there are three words I would like to see added to every category page. As well as `parent' prefixing `categories' in the blue box (which prompted this discussion), I would also like `Category tree' somewhere on the page with a link to the relevant part of the tree (for example, on:

https://wiki.riteme.site/wiki/Category:Water_technology

... `Category tree' would be a link to:

https://wiki.riteme.site/wiki/Special:CategoryTree?target=Category%3AWater+technology&mode=categories&namespaces=

).

I can only reiterate that I think I'm typical of the vast majority of Wikipedia users. My path to Wikipedia was article pages thrown up by Google searches. I read the articles and curious to know how the subject fitted into wider human knowledge, clicked on the category links. This led to the category pages which promised so much but frustrated me because I couldn't find the parent categories and certainly had no idea there was a category tree tool. This went on for years. Had the three additional words been there, I would have automatically learned about both the parent categories and the category tree tool, greatly benefitting both my learning and improving my contributions as an occasional editor. Three extra words seems a very small price to pay for conferring such a benefit on potentially a huge fraction of users. D.Wardle (talk) 03:43, 30 December 2024 (UTC)

I think it would be relatively easy to add a link to Special:CategoryTree to the "Tools" menu. I don't see an easy way to do the other things. WhatamIdoing (talk) 07:33, 30 December 2024 (UTC)

It's possible to display "Parent categories" on category pages and keep "Categories" in other namespaces. The text is made with MediaWiki:Pagecategories in both cases but I have tested at testwiki:MediaWiki:Pagecategories that the message allows a namespace check. Compare for example the display on testwiki:Category:4x4 type square and testwiki:Template:4x4 type square/update. PrimeHunter (talk) 18:01, 30 December 2024 (UTC)

How much evidence of community consensus do you need to make that change here? WhatamIdoing (talk) 19:16, 30 December 2024 (UTC)

I've looked at what you've done (and hopefully understood). MediaWiki:Pagecategories puts some of the words in the blue box at the bottom of all category pages. But what code makes the category pages (what code calls MediaWiki:Pagecategories)? I think the changes I'm suggested should be made to that calling code... D.Wardle (talk) 23:35, 9 January 2025 (UTC)

Is the answer to your question "MediaWiki"?

Every page has certain elements. You can see which ones are used on any given page with the mw:qqx trick, e.g., https://wiki.riteme.site/wiki/Category:Water_technology?uselang=qqx WhatamIdoing (talk) 01:58, 10 January 2025 (UTC)

I looked at the MediaWiki Help and Manual. How the formatting of namespaces is controlled might be discussed somewhere, but, at the very least, it's not easy to find (I didn't find it). I've requested this be addressed (https://www.mediawiki.org/wiki/Help_talk:Formatting#The_formatting_of_namespaces) but, thus far, no one has volunteered.

Returning to the issue here, my inference is that `normal' Wikipedia editors would not be able to implement the changes I'm suggesting (adding the word `parent' and a link to the category tree) assuming the changes were agreed upon. I therefore also conclude that the changes I'm suggesting do need to go to Village_pump_(proposals). Do you agree? D.Wardle (talk) 23:29, 17 January 2025 (UTC)

@PrimeHunter already worked out how to do this change. Go to testwiki:Category:4x4 type square and look for the words "Parent categories:" at the bottom of the page. If that's what you want, then the technical end is already sorted. WhatamIdoing (talk) 00:12, 18 January 2025 (UTC)

You are right that PrimeHunter's solution works but (not wishing to criticize PrimeHunter in any way --- I'm grateful for their input) I don't think it's the right way to do it. To explain: When an editor adds a section to an article, the edit box is initially blank. There is no code to specify e.g. the font, the size of the font, the colour of the font, the indentation from the margin, etc. These things must be specified somewhere but they are hidden from the editor. And that's a good feature (it enables the editor to do their work without having to wade through a whole heap of code specifying default formatting which isn't relevant to them). PrimeHunter's solution goes against that principle --- it's adding formatting code to the editor's box. You might argue that it's only a very small piece of code, but, if changes are routinely made in this way, over time the small pieces of code will accumulate and the editor's boxes will become a mess. D.Wardle (talk) 21:00, 18 January 2025 (UTC)

Look at the page history. PrimeHunter has never edited that page. It does not add any code to the editor's box. WhatamIdoing (talk) 21:12, 18 January 2025 (UTC)

Would a simpler cat page be easier for you to look at? Try testwiki:Category:Audio files or testwiki:Category:Command keys instead. All of the cats on that whole wiki are showing "Parent categories" at the bottom of the page. WhatamIdoing (talk) 21:18, 18 January 2025 (UTC)

Agreed. And (I think you already understand this) that is because PrimeHunter's edit of testwiki:MediaWiki:Pagecategories affects all pages on https://test.wikipedia.org.

Comparing:

https://wiki.riteme.site/w/index.php?title=Category:Wikipedia&action=edit

and:

https://test.wikipedia.org/w/index.php?title=Category:Wikipedia&action=edit

...adds weight to two of my previous comments:

• The test.wikipedia page has this text:

Categories: Root category

...at the bottom of the edit window (my apologies --- it's not actually in the edit window) --- this is not helpful for novice editors --- they could be confused and/or deterred by it --- it should be hidden from them.

• The en.wikipedia page has nothing analogous to the just mentioned text, suggesting that PrimeHunter's solution might not actually work in en.wikipedia.

D.Wardle (talk) 23:59, 20 January 2025 (UTC)

If editors can't see the list of categories that the page is in, how will they add or remove the categories?

On the testwiki page, the example has only one category, so this is what you see in wikitext:

[[Category:Root category]]

The analogous text in the en.wikipedia page you link is this:

[[Category:Creative Commons-licensed websites]]
[[Category:Online encyclopedias| ]]
[[Category:Virtual communities]]
[[Category:Wikimedia projects]]
[[Category:Wikipedia categories named after encyclopedias]]
[[Category:Wikipedia categories named after websites]]

I thought your concern was about what readers see. You said "But I don't notice them [i.e., the parent categories] because they're in a smaller font in the blue box near the bottom of the page: Categories: Water | Chemical processes | Technology by type".

Now you're talking about a completely different thing, which is what you see when you're trying to change those parent categories. WhatamIdoing (talk) 02:10, 21 January 2025 (UTC)

The "pre" formatting doesn't appear to play well with ::: formatting. WhatamIdoing (talk) 02:12, 21 January 2025 (UTC)

Break

Perhaps I don't understand what PrimeHunter has done. It's hard for me to follow: If I explore the https://wiki.riteme.site domain, I find that one of PrimeHunter's references (https://wiki.riteme.site/wiki/MediaWiki:Pagecategories) has been deleted, while, if I explore the https://test.wikipedia.org domain, I find that I cannot see what's in the edit box of one of the pages (https://test.wikipedia.org/wiki/Category:4x4_type_square) because `only autoconfirmed users can edit it'.

Given that https://wiki.riteme.site/wiki/MediaWiki:Pagecategories has been deleted, maybe PrimeHunter's solution only works in the testsite? D.Wardle (talk) 23:14, 20 January 2025 (UTC)

PrimeHunter's solution has only been created in the testsite. Nobody has ever posted it here.

You do not need to be autoconfirmed to see what's in the edit box. You just need to scroll down past the explanation about not being able to change what's in the edit box.

That said, I suggest that you stop looking at the complicated page of 4x4 type square, and start looking at a very ordinary category page like testwiki:Category:Command keys, because (a) it does not have a bunch of irrelevant stuff in it and (b) anyone can edit that cat page. WhatamIdoing (talk) 23:33, 20 January 2025 (UTC)

Maybe I'm naive, but I think it must be easy to do the two things I'm suggesting. There is a piece of code somewhere that takes the content entered by a Wikipedian using `Edit' and creates the category page. It's just a case of modifying that code to add one word and two words which are also a link. It must be similar to changing a style file in LaTeX or a CSS in html.

Again, maybe I'm naive, but it would seem to me appropriate to move this discussion to Village pump (proposals). Any objection? D.Wardle (talk) 21:07, 4 January 2025 (UTC)

If @PrimeHunter is willing to make the change, then there's no need to move the discussion anywhere. WhatamIdoing (talk) 23:19, 4 January 2025 (UTC)

More options for the Suggested Edits feature

Hi All,

I'm finding the Suggested Edits feature very useful for what to work on, but I'd like to be able to refine what it suggests more. Specifically:

- I want to be able to opt out of any BLP suggestions.

- I would like to be able to dismiss pages I've looked at and decided I'm not going to edit, so they don't come up in suggested edits for me anymore.

Those are the two things I'd like but I feel that having more ways to narrow what comes up in suggested edits would be a useful feature all round. Daphne Morrow (talk) 11:03, 28 December 2024 (UTC)

Notified: mw:Help talk:Growth/Tools/Suggested edits Aaron Liu (talk) 15:04, 28 December 2024 (UTC)

Daphne Morrow, you may wish to bring your suggestions to Wikipedia talk:Growth Team features, where the people able to effect change participate with some frequency. Folly Mox (talk) 17:17, 30 December 2024 (UTC)

Hi @Daphne Morrow

Folly Mox shared the link to the page where we have discussions around Suggested edits and all other features for newcomers. Feel free to join us there; we can move this topic there as well!

Regarding your requests, briefly:

• While it is possible to select various topics, it is not possible to exclude others. We tested a model to combine searches, but it narrowed down some topics so much that no suggestions were made available (in particular at smaller Wikipedias).
• In theory, an article you visited but you decided not to edit is not supposed to return into your suggestion list. I'll document the issue. Thank you for reporting it. :)

Trizek_(WMF) (talk) 09:59, 9 January 2025 (UTC)

Thank you for this.

It's good to know that pages I visit are supposed to disappear, it's possible I got this wrong, I'll look out for it. I don't remember this being mentioned at any point in the tutorial, it's possible I missed it. Daphne Morrow (talk) 11:10, 9 January 2025 (UTC)

Well, I was partially wrong: pages you visited and didn't edit disappear only for specific task types, such as Add a link. This task is only available to 5% of users at English Wikipedia.

Would your idea be:

• to expand this feature to all task types?
• to specifically select tasks you don't want to appear again (meaning that non selected pages would appear back later)? For this specific point, what would be the rationale?

Thank you, Trizek_(WMF) (talk) 16:51, 10 January 2025 (UTC)

Project once-over

I have an idea to do a project-wide initiative to review all Wikipedia articles through a fresh set of eyes. Basically, as we are approaching seven million articles, the top 500,000 editors in good standing would each be given a list of 14 articles which those editors had never edited on before. The recipients would be asked to give the articles on the list just a fairly quick glance to see if everything looked in order, no glaring errors or issues or vandalism on the page. The list would exclude the ~50,000 good/featured articles and lists, as well as articles currently nominated for deletion, since those are likely to have been recently critically reviewed. The recipients would be asked to signify somehow that they had or had reviewed the articles on their list. BD2412 T 23:09, 2 January 2025 (UTC)

That sounds like an interesting experiment, I think it'd be fun. Are there 500,000 active editors? Schazjmd (talk) 23:14, 2 January 2025 (UTC)

Not really, but it can't hurt to ask. For the ones who don't respond, perhaps we wait a few weeks and send out new lists of articles to those who did. BD2412 T 23:23, 2 January 2025 (UTC)

It's an interesting idea. There would need to be some sort of matching between article and reviewer. I am perfectly capable of evaluating an article about e.g. rail transport, British history or most geography, for articles about e.g. mathematics anything much beyond "are there swear words or broken templates?" is beyond my ability. You would also need to avoid matching someone with an article they are topic banned from, have a COI regarding or are simply too biased to edit neutrally - e.g. there is a reason I have never edited the article about Nigel Farage. Most active editors would know this wasn't an invitation to deviate from good practice, but I'm not confident that applies to everyone. Thryduulf (talk) 00:48, 3 January 2025 (UTC)

Actually, I was thinking that we would have people look at articles completely outside their normal go-to zones of interest. You, for examples, should be able to glance at a mathematics article and see if something is seriously awry (or looks seriously awry). The idea is to have a really quick process that allows us to get through millions of articles in the course of a few days by just looking for the sorts of issues that would be obvious to anyone. In fact, I started thinking about this because, in the course of my own punctuation-spacing project, I came across this fourteen-year old instance of an IP adding "nbhvjhb,jnbkjbiukjn" to a reference, which apparently no one ever looked at again. BD2412 T 02:58, 3 January 2025 (UTC)

While I would be able to tell someone adding "nbhvjhb,jnbkjbiukjn" to a maths article was an an error, but I would not give my stamp of approval to the article because that would imply there are no glaring errors because something that would be nearly as obvious to a mathematician (e.g is says "integrate" when it should say "subtract") I'm not going to see (for all I know "integrate" is correct). :::::This partitions the interval [a, b] into n sub-intervals [x_i−1, x_i] indexed by i, each of which is "tagged" with a specific point t_i ∈ [x_i−1, x_i]. might as well be written in Basque for all it means to me. There is a difference between articles I don't normally read or edit because they are outside my area of interest, and articles I don't normally read or edit because they are outside my area of competence. Thryduulf (talk) 05:41, 3 January 2025 (UTC)

A sweep for undetected vandalism is something that we have needed for over 20 years (which is how old the oldest undetected vandalism is) Gnomingstuff (talk) 16:49, 9 January 2025 (UTC)

There are currently 48,582,392 Wikipedia accounts, of which 117,824 have made at least one edit during the last month. Hawkeye7 (discuss) 03:17, 3 January 2025 (UTC)

About 800K registered editors make an edit each year. As a general rule, about half of those only made one edit.

BD, given that the most articles only get looked at once a week (see Wikipedia:Statistics#Page views), maybe we don't need to review every article. WhatamIdoing (talk) 08:03, 3 January 2025 (UTC)

I really like this general idea ꧁Zanahary꧂ 04:59, 3 January 2025 (UTC)

I do in theory, but not in practice. I can foresee potential user talk page spam issues, plus the problem of topic relevance (as discussed above) and the willingness and ability (or lack thereof) of each reviewer (I'd honestly want an invite list for something like that to be relatively exclusive, like, say, people with at least a couple of thousand edits; I wouldn't just be concerned about false-positive or false-negative reviews, but while "reviewing" an article, some neweditors might make good-faith but ultimately disruptive edits to it, and I wouldn't want a watchlister of some obscure page to be alarmed by editors like this). Reviewing articles like this would be a great task for some new users but certainly not all, and it'd be impossible to differentiate the good and bad kinds automatically; compare what I said about newcomers and copyediting in my Signpost piece about my desysop; bad experiences from certain users (including those I dealt with before) bleed in to my cynicism here. It'd be better that interested parties do random page patrol from time to time. Graham87 (talk) 05:56, 3 January 2025 (UTC)

Like others, I think this is an interesting idea, but I'm very sceptical that it's a practical one. Never mind active editors, how many editors do we have that are at all interested in doing systematic maintenance work on arbitrary topics? My gut feeling is no more than a couple of hundred, and they are already spread thin. But wasn't there a WikiProject started a few years ago that had a similar concept... basically new page review in reverse? I can't remember the name. – Joe (talk) 08:37, 3 January 2025 (UTC)

I remember that project - to look at the longest untouched pages. I think I created it, but now I can't remember the name. BD2412 T 04:36, 4 January 2025 (UTC)

There's WikiProject Abandoned Articles. Graham87 (talk) 10:42, 4 January 2025 (UTC)

Which eventually leads to Wikipedia:Database reports/Forgotten articles. From a quick look, that report includes redirects, small DABs, and a lot of very short stubs about insignificant places and things. Donald Albury 19:19, 4 January 2025 (UTC)

Wikipedia:WikiProject Sweep is what I was thinking of. Sadly never got off the ground. – Joe (talk) 09:20, 9 January 2025 (UTC)

Pages that use multiple images for the main image need a "randomizer"

Lots of articles have main or primary images to show their topic but editors may be in dispute about which particular image best serves the article topic. For example, the Cold War article has had a number of different images to illustrate this topic, and they change from time to time.

My thought is to have a list of images, one of which will appear on page load at random. That way, every time the page is reloaded, a single image from the list will show up as the main image. If there are only two, then it will flip back and forth, but there could be 10 images in the list. This lets more editors have a say in what shows without having too much conflict. Hires an editor (talk) 03:12, 4 January 2025 (UTC)

Would this be feasible from an accessibility standpoint? JJP_Master (she/they) 03:48, 4 January 2025 (UTC)

If you mean having it work on without JS enabled, yes—just make the "default" behavior be to show all pictures. – Closed Limelike Curves (talk) 04:17, 4 January 2025 (UTC)

It seems like this already exists over at Template:Random slideshow, but for some reason it's not enabled in mainspace (only on portals). I'd ask on the talk page for it to be enabled elsewhere (or you can modify the code to let it work elsewhere). – Closed Limelike Curves (talk) 04:30, 4 January 2025 (UTC)

If all of the images are relevant, forcing reloads to see them all is silly. We need to illustrate articles in a way that works for readers, not just editors. —Kusma (talk) 05:55, 4 January 2025 (UTC)

Usually, all of the images are already included in the article to illustrate the specific things they illustrate instead of the topic. But the infobox only has one image
To Hires: the usual way to solve this is {{photo montage}}. Aaron Liu (talk) 15:52, 4 January 2025 (UTC)

Another option worth considering is to go without an infobox image. —Kusma (talk) 17:54, 4 January 2025 (UTC)

My thought is that some pages may choose this route rather than a photo montage - it's simply another way to do a main photo. Hires an editor (talk) 01:59, 11 January 2025 (UTC)

My intention is that a given reader be presented what whatever happens to be the "next" image when that page is loaded. it's not meant to be a series of images that will load/reload via a script while the rest of the page is static.

A similar analogy is like the Disney ride for Star Tours: you get on the ride, and one of about 5 beginnings is the first part, which then seamlessly integrates with a second middle part, which could also be one of 4, and finally, the end has a similar number of endings - each time you go on the ride, you get a random mix of beginning/middle/end. I think that each time you get to a page, you could potentially see a different image. Hires an editor (talk) 01:58, 11 January 2025 (UTC)

This used to be done on India with Template:Switch. CMD (talk) 07:46, 4 January 2025 (UTC)

Implemeting "ChatBot Validation" for sentences of Wikipedia

Hi, I propose to define a "Validation process" using Chatbots (e.g. ChatGPT) in this way:

1. The editor or an ordinary user, presses a button named "Validate this Sentence"
2. A query named "Is this sentence true or not? + Sentence" is sent to ChatGPT
3. If the ChatGPT answer is true, then tick that sentence as valid, otherwise declare that the sentence needs to be validated manually by humans.

I think the implementation of this process is very fast and convenient. I really think that "ChatBot validation" is a very helpful capability for users to be sure about the validity of information of articles of Wikipedia. Thanks, Hooman Mallahzadeh (talk) 10:34, 6 January 2025 (UTC)

While it would certainly be convenient, it would also be horribly inaccurate. The current generation of chatbots are prone to hallucinations and cannot be relied on for such basic facts as what the current year is, let alone anything more complicated. Thryduulf (talk) 10:48, 6 January 2025 (UTC)

@Thryduulf The question is

Is Wikipedia hallucinations or ChatGPT is hallucinations?

This type of validation (validation by ChatGPT) may be inaccurate for correctness of Wikipedia, but when ChatGPT declares that "Wikipedia information is Wong!", a very important process named "Validate Manually by Humans" is activated. This second validation is the main application of this idea. That is, finding possibly wrong data on Wikipedia to be investigated more accurately by humans. Hooman Mallahzadeh (talk) 11:02, 6 January 2025 (UTC)

The issue is, ChatGPT (or any other LLM/chatbot) might hallucinate in both directions, flagging false sentences as valid and correct sentences as needing validation. I don't see how this is an improvement compared to the current process of needing verification for all sentences that don't already have a source. Chaotic Enby (talk · contribs) 11:13, 6 January 2025 (UTC)

If there was some meaningful correlation between what ChatGPT declares true (or false) and what is actually true (or false) then this might be useful. This would just waste editor time. Thryduulf (talk) 11:15, 6 January 2025 (UTC)

@Chaotic Enby@Thryduulf Although ChatGPT may give wrong answers, but it is very powerful. To assess its power, we need to apply this research:

1. Give ChatGPT a sample containing true and false sentences, but hide true answers
2. Ask ChatGPT to assess the sentences
3. Compare actual and ChatGPT answers
4. Count the ratio of answers that are the same.

I really propose that if this ratio is high, then we start to implement this "chatbot validation" idea. Hooman Mallahzadeh (talk) 11:24, 6 January 2025 (UTC)

There are many examples of people doing this research, e.g. [1] ranks ChatGPT as examples accurate "88.7% of the time", but (a) I have no idea how reliable that source is, and (b) it explicitly comes with multiple caveats about how that's not a very meaningful figure. Even if we assume that it is 88.7% accurate at identifying what is and isn't factual across all content on Wikipedia that's still not really very useful. In the real world it would be less accurate than that, because those accuracy figures include very simple factual questions that it is very good at ("What is the capital of Canada?" is the example given in the source) that we don't need to use ChatGPT to verify because it's quicker and easier for a human to verify themselves. More complex things, especially related to information that is not commonly found in its training data (heavily biased towards information in English easily accessible on the internet), where the would be the most benefit to automatic verification, the accuracy gets worse. Thryduulf (talk) 11:38, 6 January 2025 (UTC)

Have you read, for example, the content section of OpenAI's Terms of Use? Sean.hoyland (talk) 10:53, 6 January 2025 (UTC)

@Sean.hoyland If OpenAI does not content with this application, we can use other ChatBots that content with this application. Nowadays, many chatbots are free to use. Hooman Mallahzadeh (talk) 11:04, 6 January 2025 (UTC)

I'm sure they would be thrilled with this kind of application, but the terms of use explain why it is not fit for purpose. Sean.hoyland (talk) 11:17, 6 January 2025 (UTC)

Factual questions are where LLMs like ChatGPT are weakest. Simple maths, for example. I just asked "Is pi larger than 3.14159265?" and got the wrong answer "no" with an explanation why the answer should be "yes":

"No, π is not larger than 3.14159265. The value of π is approximately 3.14159265358979, which is slightly larger than 3.14159265. So, 3.14159265 is a rounded approximation of π, and π itself is just a tiny bit larger."

Any sentence "validated by ChatGPT" should be considered unverified, just like any sentence not validated by ChatGPT. —Kusma (talk) 11:28, 6 January 2025 (UTC)

I get a perfect answer to that question (from the subscription version of ChatGPT): "Yes. The value of π to more digits is approximately 3.141592653589793… which is slightly larger than 3.14159265. The difference is on the order of a few billionths." But you are correct; these tools are not ready for serious fact checking. There is another reason this proposal is not good: ChatGPT gets a lot of its knowledge from Wikipedia, and when it isn't from Wikipedia it can be from the same dubious sources that we would like to not use. One safer use I can see is detection of ungrammatical sentences. It seems to be good at that. Zero^talk 11:42, 6 January 2025 (UTC)

It's a good example of the challenges of accuracy. Using a different prompt "Is the statement pi > 3.14159265 true or false?", I got "The statement 𝜋 > 3.14159265 is true. The value of π is approximately 3.14159265358979, which is greater than 3.14159265." So, whatever circuit is activated by the word 'larger' is doing something less than ideal, I guess. Either way, it seems to improve with scale, grounding via RAG or some other method and chain of thought reasoning. Baby steps. Sean.hoyland (talk) 11:51, 6 January 2025 (UTC)

I do not think we should outsource our ability to check whether a sentence is true and/or whether a source verifies a claim to AI. This would create orders of magnitude more problems than it would solve... besides, as people point out above, facts is where chatbots are weakest. They're increasingly good at imitating tone and style and meter and writing nicely, but are often garbage at telling fact from truth. Cremastra (u — c) 02:22, 7 January 2025 (UTC)

Writing a script that would automatically give a "validation score" to every article—average probability of True vs. False across all sentences—would be helpful. (Even if it completely sucks, we can just ignore it, so there's no harm done.) Go ahead and do it if you know how! However, WMF's ML team is already very busy, so I don't think this will get done if nobody volunteers. – Closed Limelike Curves (talk) 04:41, 11 January 2025 (UTC)

Using ChatBots for reverting new edits by new users

Even though the previous idea may have issues, I really think that one factor for reverting new edits by new users can be "the false answer of verification of Chatbots". If the accuracy is near 88.7%, we can use that to verify new edits, possibly by new users, and find vandalism conveniently. Hooman Mallahzadeh (talk) 13:48, 6 January 2025 (UTC)

Even if we assume the accuracy to be near near 88.7%, I would not support having a chatbot to review edits. Many editors do a lot of editing and getting every 1 edit out of 10 edit reverted due to an error will be annoying and demotivating. The bot User:Cluebot NG already automatically reverts obvious vandalism with 99%+ success rate. Ca ^{talk to me!} 14:11, 6 January 2025 (UTC)

@Ca Can User:Cluebot NG check such semantically wrong sentence?

Steven Paul Jobs was an American engineer.

instead of an inventor, this sentence wrongly declares that he was an engineer. Can User:Cluebot NG detect this sentence automatically as a wrong sentence?

So I propose to rewrite User:Cluebot NG in a way that it uses Chatbots, somehow, to semantically check the new edits, and tag semantically wrong edits like the above sentence to "invalid by chatbot" for other users to correct that. Hooman Mallahzadeh (talk) 14:22, 6 January 2025 (UTC)

Can Cluebot detect this sentence automatically as a wrong sentence? No. It can't. Cluebot isn't looking through sources. It's an anti-vandalism bot. You're welcome to bring this up with those that maintain Cluebot; although I don't think it'll work out, because that's way beyond the scope of what Cluebot does. SmittenGalaxy | talk! 19:46, 6 January 2025 (UTC)

I think you, Hooman Mallahzadeh, are too enamoured with the wilder claims of AI and chatbots, both from their supporters and the naysayers. They are simply not as good as humans at spotting vandalism yet; at least the free ones are not. Phil Bridger (talk) 20:46, 6 January 2025 (UTC)

The number of false positives would be too high. Again, this would create more work for humans. Let's not fall to AI hype. Cremastra (u — c) 02:23, 7 January 2025 (UTC)

Sorry this would be a terrible idea. The false positives would just be to great, there is enough WP:BITING of new editors we don't need LLM hallucinations causing more. -- LCU ActivelyDisinterested «@» °∆t° 16:26, 7 January 2025 (UTC)

Dear @ActivelyDisinterested, I didn't propose to revert all edits that ChatBot detect as invalid. My proposal says that:

Use ChatBot to increase accuracy of User:Cluebot NG.

The User:Cluebot NG does not check any semantics for sentences. These semantics can only be checked by Large Language Models like ChatGPT. Please note that every Wikipedia sentence can be "semantically wrong", as they can be syntacticly wrong.

Because making "Large language models" for semantic checking is very time-consuming and expensive, we can use them online via service oriented techniques. Hooman Mallahzadeh (talk) 17:18, 7 January 2025 (UTC)

But LLMs are not good at checking the accuracy of information, so Cluebot NG would not be more accurate, and in being less accurate would behave in a more BITEY manner to new editors. -- LCU ActivelyDisinterested «@» °∆t° 17:24, 7 January 2025 (UTC)

Maybe ChatGPT should add a capability for "validation of sentences", that its output may only be "one word": True/False/I Don't know. Specially for the purpose of validation.

I don't know that ChatGPT has this capability or not. But if it lacks, it can implement that easily. Hooman Mallahzadeh (talk) 17:33, 7 January 2025 (UTC)

Validation is not a binary thing that an AI would be able to do. It's a lot more complicated than you make it sound (as it requires interpretation of sources - something an AI is incapable of actually doing), and may require access to things an AI would never be able to touch (such as offline sources). —Jéské Couriano v^_^v ^{threads critiques} 17:37, 7 January 2025 (UTC)

@Hooman Mallahzadeh: I refer you to the case of Varghese v. China South Airlines, which earned the lawyers citing it a benchslap. —Jéské Couriano v^_^v ^{threads critiques} 17:30, 7 January 2025 (UTC)

@Jéské Couriano Thanks, I will read the article. Hooman Mallahzadeh (talk) 17:34, 7 January 2025 (UTC)

(edit conflict × 4) For Wikipedia's purposes, accuracy is determined by whether it matches what reliable sources say. For any given statement there are multiple possible states:

1. Correct and supported by one or more reliable sources at the end of the statement
2. Correct and supported by one or more reliable sources elsewhere on the page (e.g. the end of paragraph)
3. Correct and self-supporting (e.g. book titles and authors)
4. Correct but not supported by a reliable source
5. Correct but supported by a questionable or unreliable source
6. Correct according to some sources (cited or otherwise) but not others (cited or otherwise)
7. Correct but not supported by the cited source
8. Incorrect and not associated with a source
9. Incorrect and contradicted by the source cited
10. Incorrect but neither supported nor contradicted by the cited source
11. Neither correct nor incorrect (e.g. it's a matter of opinion or unproven), all possible options for sourcing
12. Previously correct, and supported by contemporary reliable sources (cited or otherwise), but now outdated (e.g. superceded records, outdate scientific theories, early reports about breaking news stories)
13. Both correct and incorrect, depending on context or circumstance (with all possible citation options)
14. Previously incorrect, and stated as such in contemporary sources, but now correct (e.g. 2021 sources stating Donald Trump as president of the US)
15. Correct reporting of someone's incorrect statements (cited or otherwise).
16. Predictions that turned out to be incorrect, reported as fact (possibly misleadingly or unclearly) at the time in contemporary reliable sources.

And probably others I've failed to think of. LLMs simply cannot correctly determine all of these, especially as sources may be in different languages and/or not machine readable. Thryduulf (talk) 17:44, 7 January 2025 (UTC)

I believe someone else had a working implementation of a script that would verify whether a reference supported a claim using LLMs - I think I saw it on one of the Village Pumps a while back. They eventually abandoned it because it wasn't reliable enough, if I remember correctly. — Qwerfjkltalk 16:46, 20 January 2025 (UTC)

It probably struggles to understand meaning. On the other hand, I reckon you could get a working implementation to look for copyvio. CMD (talk) 18:02, 20 January 2025 (UTC)

It could be great to have an LLM-supported system to detect potential close paraphrasing. —Kusma (talk) 18:06, 20 January 2025 (UTC)

Even professional-grade plagiarism detectors are poor at that, generating both false positives and false negatives. That's fine in the environment where they are used with full understanding of the system's limitations and it is used only as one piece of information among multiple sources by those familiar with the topic area. Very little of that is true in the way it would be used on Wikipedia. Thryduulf (talk) 18:49, 20 January 2025 (UTC)

AfD's taking too long

I've noticed that a lot of AfD's get relisted because of minimal participation, sometimes more than once. This means that in the instance where the article does get deleted in the end, it takes too long, and in the instance where it doesn't, there's a massive AfD banner at the top for two, sometimes three or more weeks. What could be done to tackle this? How about some kind of QPQ where, any editor that nominates any article for deletion is strongly encouraged to participate in an unrelated AfD discussion? -- D'n'B-📞 -- 06:59, 7 January 2025 (UTC)

I feel WP:RUSHDELETE is appropriate here. I don't understand why the article banner is a problem? Am I missing something? Knitsey (talk) 07:41, 7 January 2025 (UTC)

The banners signal to a reader that there's something wrong with a page - in the case of an AfD there may well not be. -- D'n'B-📞 -- 06:30, 8 January 2025 (UTC)

There's often a concern, and all relisted nominations seem to have reason to debate that concern, whether because someone registered an objection or the article was already nominated in the past. Aaron Liu (talk) 12:25, 8 January 2025 (UTC)

We already have WP:NOQUORUM which says that if an AfD nomination has minimal participation and meets the criteria for WP:PROD, then the closing admin should treat it like an expired PROD and do a soft deletion. I remember when this rule was first added, admins did try to respect it. I haven't been looking at AfD much lately—have we reverted back to relisting discussions? Mz7 (talk) 08:10, 7 January 2025 (UTC)

From what I've seen when I was active there in November, ProD-like closures based on minimal participation were quite common. Aaron Liu (talk) 22:47, 7 January 2025 (UTC)

Based on a recent samples, I think somewhere over a quarter of AfD listings are relistings. (6 Jan - 37 / 144, 5 Jan - 35 / 83, 4 Jan - 36 / 111, 3 Jan - 27 / 108). -- D'n'B-📞 -- 06:43, 8 January 2025 (UTC)

Those relisted have more than minimal participation in the soft deletion sense. Aaron Liu (talk) 12:22, 8 January 2025 (UTC)

so more than allows for soft deletion but not enough to reach consensus then. -- D'n'B-📞 -- 02:53, 11 January 2025 (UTC)

yes. IMO that means they have reason for discussion and debate. Aaron Liu (talk) 23:31, 11 January 2025 (UTC)

Okay, and I'm talking about encouraging that discussion to actually happen rather than fizzle out - so we're on the same page here? -- D'n'B-📞 -- 08:58, 12 January 2025 (UTC)

And that's why there's a banner on the article. Aaron Liu (talk) 16:35, 12 January 2025 (UTC)

Add an infobox template for those who won the world chess championship

Either that or at least have it included in the infoboxes of the World Chess Champions. What do you guys think? Wikieditor662 (talk) 19:19, 7 January 2025 (UTC)

To clarify, I think we should redesign the world champion thing from just the years to a more formal title, and there's a place in the infobox to include what years they were world champions (rather than just when they played), as well as who their predecessors and successors were. If I don't get a response, I'll move this to the talk page of the chess player infobox. Wikieditor662 (talk) 21:32, 9 January 2025 (UTC)

Template use outside of Wikimedia editor / offline

The current wiki editor only contains the templates for web, news, book, and journal. I have found using my sandbox with offline editors (such as Notepad++ ) to be a convenience editing choice. Are there any tools/plugins that can work with offline editors that grab template bases , which can then be filled in offline? DarkStarHarry (talk) 17:06, 8 January 2025 (UTC)

What do you mean "grab template bases"? Aaron Liu (talk) 19:26, 8 January 2025 (UTC)

Template base = the template with parameters provided, blank & free of any text; ready to be populated by the human editor for the page.

Example: Template:Americanfootballbox#Blank Go to the subsection Blank and there's an empty template in the box/frame/I don't know the HTML control DarkStarHarry (talk) 17:29, 9 January 2025 (UTC)

Featured lists on front page

So the question here is posed: What does the community think of incorporating featured lists onto the main page in some, yet-to-be determined way? IvoShandor 03:26, 14 October 2007 (UTC)

The question shall be posed again, because there is really great lists out there, like these ones for example:

List of fighter aircraft List of accidents and disasters by death toll List of macropodiformes

Also Tony the Tiger liked it already back in 2007. Come on, you want to argue with Tony the Tiger??

I would like just one featured weekly-list under the picture of the day tab.

Qdajet22 (talk) 20:42, 8 January 2025 (UTC)

We already have this at Wikipedia:Today's featured list? (on Mondays and Fridays) Chaotic Enby (talk · contribs) 20:59, 8 January 2025 (UTC)

Is it possible to start the process of sunsetting the "T:" pseudo-namespace?

In the sense that, with the creation of the [[TM:]] alias in early 2024 from T363757, I can't think of a single reason why a new "T:" space redirect would ever need to exist.

Back in the day, well, "T:" has always been controversial even from 2010 and the several RfCs. There was Wikipedia:Redirects for discussion/Log/2013 November 18#T:WPTECH and multiple RfCs since regarding pseudonamespaces. And per WP:Shortcut#Pseudo-namespaces, the "T:" space is listed as "for limited uses only", but even that was added to the info page in that location a decade ago or so.

Nevertheless, even from the 2014 RfC at Wikipedia:Village pump (policy)/Archive 112#RFC: On the controversy of the pseudo-namespace shortcuts, there was consensus that "new "T:" redirects should be strongly discouraged if not prohibited in all but exceptional cases". It's been over a decade now and we still get a potluck assortment of new T: titles every year.

The difference is though, now we have the TM: alias. Just as it makes little sense to foster a "W:" shortcut for "WP:" titles, it really does not make sense to keep "T:" around when "TM:" is just another character more. H for Help and P for Portal don't have that luxury of an alias at this time, but templates do. There's hardly anything left on Special:PrefixIndex for T: titles. And I don't think we should necessarily delete everything at once. But it might be nice to make a hard rule that we don't need any more T: titles, especially so when TM: is the vastly preferable option at this time, from my POV.

I would suggest this as a proposal, but wanted to get feedback to see what else might need to happen in order to start sunsetting? Many of these have little to no links, but a lot of them do. Should these be replaced? Would it be worth the editing cost? I think the payoff is phenomenal - allowing easier navigation to actual articles that start with "T:", of which there are several. Utopes _{(talk / cont)} 16:00, 9 January 2025 (UTC)

I wouldn't be strongly opposed to this, but I'd suggest keeping the most-used ones, like T:CENT and T:DYK, for at least a few more years. Cremastra (u — c) 23:33, 9 January 2025 (UTC)

For sure. As it happens, T:CENT only has 112 incoming links which almost entirely consist of archives, and it seems like there could be a bot (or a person, honestly) who could run through and fix the links to TM:CENT instead. Because this would be a sunset, I predict that really the only two functions that might actually want to hold onto these for a bit would be DYK and ITN. But even then, I don't necessarily want to delete every single T: title we have right now, but maybe slowly over time we could get to that point. In the interim, anything that T: does, TM: does better in a less harmful way, as TM: works for 100% of templates while T: works for 0%. Creating a note in WP:Shortcut#Pseudo-namespaces that "Newly created T: titles from the years 2025 and later are no longer permissible / are against consensus" could be a start. If it's indeed true that that is the case, of course, I have no idea. Hence a proposal to see where people are at re: T: titles. Utopes _{(talk / cont)} 00:54, 10 January 2025 (UTC)

I would support at least preventing the creation of new ones, so that the burden doesn't keep increasing and it is made clear that TM: is the recommended one. Chaotic Enby (talk · contribs) 01:16, 10 January 2025 (UTC)

Some might be used as type-in shortcuts (I search for CAT:CSD almost every day) but page view statistics should tell you how common that is. —Kusma (talk) 18:10, 20 January 2025 (UTC)

Regarding DYK, it currently has a few different T: shortcuts for the preps and queues as well. A sunset might have to exclude potential fiddling in this area. CMD (talk) 19:05, 20 January 2025 (UTC)

If we turned the pages into soft redirects, that would discourage further use. WhatamIdoing (talk) 04:37, 21 January 2025 (UTC)

Category loops

A category loop is a sequence of subcategories that forms a directed cycle under the subcat relation, i.e. where a category has itself as a subcategory at some level. This is mentioned in WP:SUBCAT, but as far as I can tell nothing has been written about them. However, they tend to occur where two similar and broad topic areas overlap, e.g. in an example mentioned at Wikipedia:Categories_for_discussion/Log/2023_July_18#Category:Arab. Do you have any other experiences worth sharing about category loops, so that an essay can be written about the topic?

There should be a database report for category loops — I discovered and fixed two with length 2 in the past 24 hours (Category:Infographics → Category:Scientific visualization → Category:Infographics and Category:Multimedia → Category:Digital media → Category:Multimedia). Currently, we have only Wikipedia:Database reports/Self-categorized categories for categories that are direct subcategories of themselves — that is, loops of length 1. –LaundryPizza03 (dc̄) 03:09, 10 January 2025 (UTC)

Reminds me of Wikipedia:Bot requests/Archive_39#c-Anomie-2010-11-07T05:09:00.000Z-Ayceman-2010-11-06T20:21:00.000Z, although that particular loop is long gone now. If you search archives of various discussion boards you can probably find more examples. Anomie⚔ 13:03, 10 January 2025 (UTC)

An anonymous user points me to User:SDZeroBot/Category cycles, which was last updated in January 2024. I have posted a request to have this list updated periodically. –LaundryPizza03 (dc̄) 01:49, 11 January 2025 (UTC)

Reworking WP:NBAND

Per this discussion at WP:Village pump (proposals), there was a nearly an almost unanimous consensus to not constrain WP:BAND to WP:GNG requirements, but there did seem to be a strong consensus to revisit criterion 5, and possibly some consensus to revisit criterion 6. I've got an updated draft at Wikipedia:Band notability proposal where I tried to reflect this consensus. I basically just re-worked criterion 5 a bit. It now reads: # Has released two or more albums on a major record label, or one of the more important indie labels[note 5], before 2010. The note is the importance of the indie label should be demonstrable from reliable independent coverage indicating that label's importance. The exact cut-off date was debated, but it was around 2006 to 2010. I went for 2010, as that seems to be when streaming really took off. I'd like some input to see if there's any modifications or suggestions before I put this forward at Village pump (proposals). Thank you!--3family6 (Talk to me | See what I have done) 13:24, 10 January 2025 (UTC)

Remove 5 and 6 entirely. Graywalls (talk) 02:21, 11 January 2025 (UTC)

The problem with removing 5 entirely is because that would affect older groups that might not yet have articles. That's why the cut-off date of around 2010 was proposed in the previous discussion.--3family6 (Talk to me | See what I have done) 23:12, 12 January 2025 (UTC)

Remove #6 entirely. Why? I Ask (talk) 03:53, 11 January 2025 (UTC)

Names of command-line tools in monospace

Websites such as the Arch Linux wiki frequently use inline <code> tags to indicate that text is either entered into or read from the command line. I did some searches of the MOS and FAQ here on Wikipedia, but I was unable to find any policy or guideline formalizing the use of monospaced fonts for command line input and output. Does anyone else actually care about this, and if so does anyone think this should be formalized? Thanks for the input, /home/gracen/ (they/them) 18:50, 10 January 2025 (UTC)

I feel I should also mention the issue of using <code> tags for bold page names (cf. grep and fdisk). /home/gracen/ (they/them) 18:54, 10 January 2025 (UTC)

If you WP:Boldly do something and nobody objects, that's consensus. That said, we actually do ask for such markup at MOS:CODE. Aaron Liu (talk) 19:04, 10 January 2025 (UTC)

I'm aware of both of these, though I appreciate the consideration. I'm more asking about things that are in a gray area between "code" and "natural language" and whether this gray area should be standardized so we have more consistent style.

I'll elaborate more if necessary once I get back to a computer; I dislike writing longer messages on mobile. /home/gracen/ (they/them) 19:10, 10 January 2025 (UTC)

FWIW I use <kbd> in discussions when documenting my search term, e.g. "bright green" cake -wikipedia, I'm not sure what the direct relevance of that is to mainspace but is it the sort of grey are you are thinking of? Thryduulf (talk) 19:16, 10 January 2025 (UTC)

Yup, that's pretty much what I was thinking of (also, thanks for the introduction to <kbd>, I think I prefer this for inline stuff because it doesn't have the annoying gray box)! An example that I just thought of could be error messages. For example, would an inline 404 Not Found be preferred over 404 Not Found? (Of course, you wouldn't be seeing this much in a CLI, but I feel 404's the most recognizable error message.) I feel this should be standardized. /home/gracen/ (they/them) 19:22, 10 January 2025 (UTC)

For that one you might wanna consider using <samp> instead since kbd is semantically "keyboard input". I don't think there's any guidelines about what you mentioned, so probably just Bold it in until someone hates it. Aaron Liu (talk) 01:35, 11 January 2025 (UTC)

Alright, thanks! I'll revive this discussion if/when someone takes issue with this. /home/gracen/ (they/them) 15:58, 13 January 2025 (UTC)

Something like <syntaxhighlight lang="shell" inline>ls -alF (with an closing </syntaxhighlight> tag) provides both quoting behaviour and (theoretically) syntax highlighting, so it's what I would prefer, but of course it's more typing. (For shell, there isn't much syntax highlighting that could happen anyway, and I can't seem to get any to appear.) Otherwise, <kbd> is appropriate markup to use for text entered as input. isaacl (talk) 22:41, 10 January 2025 (UTC)

<kbd>...</kbd> or {{kbd}}? <pre>...</pre> or {{pre}}? <samp>...</samp> or {{samp}}? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:37, 13 January 2025 (UTC)

Does it matter? Isn't this just a WP:COSMETIC difference? /home/gracen/ (they/them) 16:49, 13 January 2025 (UTC)

Apparently not quite, the template:kbd indicates that it applies some styling to it, namely a faint grey background [...] and slight CSS letter-spacing to suggest individually entered characters. The output of the others also differs

• example using none of the elements or templates
• example using the <kbd> html element
• example using the {{kbd}} template
• example using the <samp> html element
• example using the {{samp}} template

• example using the <pre> html element

• example using the {{pre}} template

It seems {{pre}} really doesn't play nicely with bulleted lists, I've not looked into why. I've also not looked into why the templates apply the styling they do. Thryduulf (talk) 14:33, 14 January 2025 (UTC)

Better methods than IP blocks and rangeblocks for completely stopping rampant recurring vandals

So, I intend for this thread to be about the discussion of various theoretical methods other than IP blocks / rangeblocks that could be used to mitigate a persistent vandal highly effectively while causing little to no collateral damage.

Some background

Wikipedia was founded in 2001, a time when a good majority of residential IP addresses were relatively all static, due to the much lesser number of internet users at that time. IP blocks probably made a lot of sense at that time due to that fact - you couldn't just reboot your modem to obtain a new IP address and keep editing, and cell phones pretty much had no usable web browsing capability at the time. Today, the only type of tool used to stop anonymous vandals and disruptors, despite dynamic IP addresses and shared IPs being very common, is still the same old IP address blocks and range blocks. While IP block are effective at stopping the "casual" / "one-off" type of vandals from editing again, when it comes to the more dedicated disruptors and LTAs, IP blocks simply don't seem to hinder them at all, due to the highly dynamic IP address nature. Okay, but range blocks exist, right? Well, unfortunately not all IP address allotment sizes are the same, and it varies a lot from ISP to ISP - some ISPs just seem to put literally all their customers on one gigantic (i.e. /16 or bigger for IPv4, /32 or bigger for IPv6) subdivision, making it straight up impossible to put a complete stop to the LTA vandal without also stopping all those thousands and thousands of innocent other people from being able to edit.

I've always had these thoughts in my mind, about what the Wikimedia team could potentially do / implement to more accurately yet effectively put a complete halt to long-term abusers. But I felt like now's the time we really could use some better method to stop LTAs, as there are just sooooo many of them today, and soooo much admin time/effort is being spent trying to stop them only for them to come back again and again because pretty much the only way to stop them is to literally block the entire ISP from editing Wikipedia.

The first thing that might come to one's mind, and probably the most controversial method too, is disabling anonymous editing entirely and making it so only registered editors can edit English Wikipedia. Someone pointed out to me before that the Portuguese Wikipedia is a registration-only wiki. I tried it out for myself, and indeed when you click the edit button while not logged in, you are brought to an account login page. I'm guessing ENwiki will never become like this because it would eliminate a large and thriving culture of "casual" type of editors who don't want to register an account and just simply want to fix a typo, update a table's data or add a small sentence. It's probably not 100% effective either, as a registered-only wiki still wouldn't stop someone from creating a whole bunch of throwaway accounts to keep vandalising, and account creation blocks on IP addresses could still be dodged by, you know, the modem power plug dance or good ol' proxies/VPNs.

I've noticed some other language wikis like the German Wikipedia have "pending changes" type protection pretty much enabled on every single page. I imagine this isn't going to work on the English Wikipedia because of the comparatively high volume of edits from anonymous editors compared to DEwiki, as it would overload the pending changes review queue and there just will never be enough active reviewers to keep up with the volume of edits.

Now here are some of my original thoughts which I don't think I've seen anyone discuss here on Wikipedia before. The first of which, is hardware ID (HWID) bans or "device bans". The reason why popular free-to-play video games like League of Legends, Overwatch 2, Counter-Strike 2 etc aren't overrun with non-stop cheaters and abusers despite them being free-to-play is because they employ an anti-cheat and abuse system that will ban the serial numbers of the computer, rather than just simply banning the user or their IP address. Now, I have heard of HWID spoofing before, but cheating isn't rampant in these games anyway so I guess they are effective in some form. Besides replacing hardware, one could theoretically use a virtual machine to evade the HWID ban, but virtual machines don't provide the performance, graphics acceleration and special features needed to get a modern multiplayer video game to work. However though, I could see virtual machines as being a rather big weakness for Wikipedia HWID bans, as a web browser doesn't need a dedicated powerful video card and any of those special features to work; web browsers easily run in virtualised environments. But I guess not a great deal of LTAs are technologically competent enough to do that, and even if they did, spinning up a new VM is significantly slower than switching countries in a VPN.

The second, and probably the most craziest one, is employing some form of mandatory personal ID system. Where, even if you're not going to sign up and only edit anonymously, you will be forced to enter a social security number or passport number or whatever ID number that is completely unique to you, to be able to edit. In South Korea, some gaming companies like Blizzard make you enter a SSN when signing up for an account, which makes it virtually impossible for a person to go to an internet cafe ("PC bang") and make a whole bunch of throwaway accounts and jump from computer to computer when an account/device becomes banned to keep on cheating (see PC bang § Industry impact). One could theoretically get the IDs of family members and friends when they become "ID banned", but after all there are only going to be so few other people's IDs they will be able to obtain, certainly nowhere near on the order of magnitude as the number of available IP addresses on a large IP subnet or VPN. I'm guessing this method isn't going to be feasible for English Wikipedia either, as it completely goes against the simple, "open" and "anonymous" nature of Wikipedia, where not only can you edit anonymously without entering any personal details, but even when signing up for an account you don't even have to enter an email address, only just a password.

A third theoretical method is that what if, the customer ID numbers of ISPs were visible to Wikimedia, and then Wikimedia could ban that ISP customer therefore making them completely unable to edit Wikipedia even if they jump to a different IP address or subnet on that ISP? Or maybe how about the reverse where the ISP themselves ban the customer from being able to access Wikipedia after enough abuse? Perhaps ISPs need to wake up and implement such a site-level blocking policy.

Here's a related "side question": how come other popular online services like Discord, Facebook, Reddit, etc aren't overly infested with people who spam, attack, or otherwise make malicious posts on the site everyday? Could Wikimedia implement whatever methods these services are using to stop potential "long-term abusers"? — AP 499D25 (talk) 13:29, 12 January 2025 (UTC)

I just thought of yet another theoretical solution: AI has gotten good enough to be able to write stories and poems, analyse a 1000 page long book, make songs, realistic pictures, and more. Wikipedia already uses AI (albelt a rather primitive and simple one) in the famous anti-vandal bot User:ClueBot NG. What if, we deploy an edit filter based on the latest and greatest AI model, to filter out edits based on past vandalism/disruption patterns? — AP 499D25 (talk) 13:37, 12 January 2025 (UTC)

I'll preface this by saying that I have quite a few problems with this idea (although I may be biased because I'm strongly opposed to the direction that modern AI is going); but I'd like to hear why and how you think this would work in more detail. For instance, would the AI filter just block edits outright? Would they be flagged like with WP:ORES? What mechanisms would the hypothetical AI use to detect LTA? How would we reduce false positives? And so on. Thanks, /home/gracen/ (they/them) 17:24, 13 January 2025 (UTC)

The AI idea I have in mind is a rather "mild" form of system, where it only works on edits based on past patterns of disruption. Take for example, MAB's posts. They are quite easily recognisable from a distance even with the source code obscuring that makes it impossible for traditional edit filters to detect the edits. Maybe an AI could perform OCR on that text to then filter it out?

The AI will not filter out new types of vandalism, or disruptive edits that it isn't "familiar" with. There will be an "input text file" where admins can add examples of LTA disruption for the AI to then watch for any edits that closely resemble those examples. It will not look for, or revert edits that aren't anywhere near as being like those samples. That way I think false positives will be minimised a lot, and of course there shall be a system for reporting false positives much like how there exists WP:EFFP. — AP 499D25 (talk) 22:44, 13 January 2025 (UTC)

Ah, thanks! I'm immediately hesitant whenever I hear the word "AI" because of the actions of corporations like OpenAI, among others. However, given what you've just said, I actually think this might be an interesting idea to pursue. I'm relatively new to WP and I've never looked at WP:SPI, so I'd rather leave this to more experienced editors to discuss, but this does seem like a good and ethical application of neural networks and is within their capabilities. /home/gracen/ (they/them) 16:16, 14 January 2025 (UTC)

The second, and probably the most craziest one, is employing some form of mandatory personal ID system. Where, even if you're not going to sign up and only edit anonymously, you will be forced to enter a social security number or passport number or whatever ID number that is completely unique to you, to be able to edit.

This means that editors will have to give up a large amount of privacy, and the vast majority of people casually editing Wikipedia aren't ready to give their passport number in order to do so. Plus, editors at risk might be afraid of their ID numbers ending in the wrong hands, which is much more worrying than "just" their IP address.

Here's a related "side question": how come other popular online services like Discord, Facebook, Reddit, etc aren't overly infested with people who spam, attack, or otherwise make malicious posts on the site everyday?

They are, it's just that the issue is more visible on Wikipedia as the content is easy to find for all readers, but it doesn't mean platforms like Discord or Reddit aren't full of bad actors too. Chaotic Enby (talk · contribs) 13:38, 12 January 2025 (UTC)

Portuguese Wikipedia is not a registration-only wiki. They require registration for the mainspace, but not for anything else. See RecentChanges there. (I don't think they have a system similar to our Wikipedia:Edit requests. Instead, you post a request at w:pt:Wikipédia:Pedidos/Páginas protegidas, which is a type of noticeboard.) I'm concerned that restricting newbies may be killing their community. See the editor trends for the German-language Wikipedia; that's not something we really want to replicate. Since editors are not immortal, every community has to get its next generation from somewhere. We are getting fewer new accounts making their first edit each year. The number of editors who make 100+ edits per year is still pretty stable (around 20K), but the number of folks who make a first edit is down by about 30% compared to a decade ago.

WMF Legal will reject any sort of privacy invasion similar to requiring a real-world identity check for a person. A HWID ban might be legally feasible (i.e., I've never heard them say that it's already been considered and rejected). It would require amending the Privacy Policy, but that happens every now and again anyway, so that's not impossible. However, I understand that it's not very effective in practice (outside of proprietary systems, which is not what we're dealing with), and the whole project involves a significant tradeoff with privacy: Everything that's possible to track a Wikipedia vandal is something that's possible to track you for advertising purposes, or that could be subpoenaed for legal purposes. Writing a Wikipedia article (in the mainspace, to describe what it is and how it works) about that subject, or updating device fingerprint, might actually be the most useful thing you could do, if you thought that was worth pursuing. If a proposal is made along these lines, then the first thing people will do is read the Wikipedia article to find out what it says.

I understand that when Wikipedia was in its early days, a few ISPs were willing to track down abusive customers on occasion. My impression now is that basically none of them are willing to spend any staff time/expense doing this. We can e-mail their abuse@ addresses (they should all have one), but they are unlikely to do anything. A publicly visible approach on social media might work in a few cases ("Hey, @Name-of-ISP, one of your customers keeps vandalizing #Wikipedia. See <link to WP:AIV>. Why don't you stop them?"). However, if the LTA is using a VPN or similar system, then the ISP we claim they're using might be the wrong one anyway. WhatamIdoing (talk) 03:58, 13 January 2025 (UTC)

I dont know exactly what is meant by hardware id (something like [2]?), but genrrally speaking most things that come under that heading require you to be using a native app and not a web browser. Web Environment Integrity is a possible exception but was abandoned. Bawolff (talk) 00:13, 14 January 2025 (UTC)

I was thinking that it might be something like a MAC address (for which we had MAC spoofing). WhatamIdoing (talk) 08:00, 21 January 2025 (UTC)

Page for ABBA's I have a dream links to the wrong year in the UK Charts

I don't know if this is the correct place to post this or not, I am only doing so because I am not sure how to fix it myself. EmDavis158 (talk) 02:57, 13 January 2025 (UTC)

@EmDavis158, is this about I Have a Dream (song)? Which bit exactly in there? WhatamIdoing (talk) 04:04, 13 January 2025 (UTC)

Yeah, the citation link for the UK Charts links to december 1969 and not 1979. EmDavis158 (talk) 05:02, 13 January 2025 (UTC)

It looks like the citation is built into Template:Single chart, so let's get some help from people who are familiar with that template. Dxneo or Muhandes, are either of you around? I think the goal is to have this link to https://www.officialcharts.com/charts/singles-chart/19791223/7501/ WhatamIdoing (talk) 06:38, 13 January 2025 (UTC)

I might have fixed it (diff). It seems the UK chart functionality requires YYYYMMDD date formatting. Sean.hoyland (talk) 07:58, 13 January 2025 (UTC)

Oh Sean beat me to it. Like they mentioned above, the problem was |date= You cannot use "23 December 1979" for the date, next time use yyyymmdd, thank you. dxneo (talk) 08:02, 13 January 2025 (UTC)

It's alright to find random places to help, though the usual forums for this are Wikipedia:Village pump (technical) for technical help or Wikipedia:Help desk. Aaron Liu (talk) 12:35, 14 January 2025 (UTC)

Give patrollers the suppressredirect right?

As part of New Page Patrol, a lot of articles are draftified, which is done by moving the it to the Draft: or User: namespace. The problem is that without page mover rights, patrollers are forced to leave redirects behind, which are always deleted under speedy deletion criterion R2. Giving patrollers the suppressredirect right would make the process easier and reduce workload for admins. What do you think? '''[[User:CanonNi]]''' (talk • contribs) 11:02, 13 January 2025 (UTC)

Draftifying is happening far too much. But the idea has merit, as then the last log entry will say the page was moved, rather than a redirect deleted. Graeme Bartlett (talk) 11:11, 13 January 2025 (UTC)

Note: This has been proposed before. See Wikipedia:Village pump (proposals)/Archive 203 § Give NPR additional rights? JJP_Master (she/they) 14:55, 13 January 2025 (UTC)

The other option would be to not have it automatically given, but to make it easy to grant to new page reviewers frequently doing draftifications, and encourage them to apply. Chaotic Enby (talk · contribs) 15:36, 13 January 2025 (UTC)

I don't think this is a good idea. Suppressing the redirect right away (whether you're an admin or not) makes it harder for people to find the page they were editing. WhatamIdoing (talk) 18:52, 13 January 2025 (UTC)

Opening up the page will show the log entry that the page was moved (allowing people to easily find it). Current policy does not place a time limit on when to delete pages that qualify for WP:R2 (beyond the standard wait an hour before draftifying). Once that happens, it's nominated for speedy deletion if the patroller isn't a page mover or an admin. R2s are usually dealt with immediately, so it's not like forcing people to nominate them for speedy deletion is going to accomplish much other than make their workflow slightly longer. Clovermoss🍀 (talk) 23:18, 17 January 2025 (UTC)

This is de facto already the case. It's quite easy for an NPR to become a page mover on those grounds alone. JJP_Master (she/they) 19:16, 13 January 2025 (UTC)

Reluctantly oppose not per WhatamIdoing but because the suppressredirect right has too much ancillary power for me to be comfortable bundling it in like this. * Pppery * _{it has begun...} 18:59, 13 January 2025 (UTC)

I also oppose bundling it with anything else beyond pagemover, per both Pppery and WAID. I'm also minded to agree with Graeme Bartlett that drafifying is happened too often (but I realise that it's been a while since I looked at this in detail). Nobody should be granted the suppressredirect right without it being clear they understand the policy surrounding when redirects should and should not be suppressed specifically. Thryduulf (talk) 14:21, 14 January 2025 (UTC)

I agree with JJPMaster that NPPers that qualify for the right don't much trouble gaining it. I think each case should be examined individually because draftifying on a frequent basis isn't required to be a new page patroller. User right requests also provide a chance to double check that such drafticiations are actually being done correctly. Clovermoss🍀 (talk) 23:25, 17 January 2025 (UTC)

Using a Tabber for infoboxes with multiple subjects

There are many articles that cover closely related subjects, such as IPhone 16 Pro which covers both the Pro and Pro Max models, Nintendo Switch which covers the original, OLED, and Lite models, and Lockheed Martin F-35 Lightning II which covers the A, B, C, and I variants. Most of these articles use a single infobox to display specifications and information about all of the covered subjects, leading to clutter and lots of parentheticals.

I propose that a tabber, like Tabber Neue, be used to instead create distinct infobox tabs for each subject. This would allow many benefits, such as clearly separating different specifications, providing more room for unique photos of each subject, and reducing visual clutter. An example of good use of tabs is one of my personal favorite wikis, https://oldschool.runescape.wiki, which uses tabs effectively to organize the many variants of monsters, NPCs, and items. A great example is the entry for Guard, a very common NPC with many variants. It even uses nested tabs to show both the spawn location grouped by city, and the individual variants within each city. While this is an extreme example in terms of the raw number of subjects, it provides a good look at how similar subjects can be effectively organized using tabs. Using Wikipedia's system instead, it would be substantially more cluttered, with parentheticals such as: Examine: "He tries to keep order around here" (Edgeville 1, Edgeville 2, Falador (sword) 1...) If you tried to save space using citations, it becomes very opaque: Examine: "He tries to keep order around here" [1][2][7][22]...

Overall I think this would make infoboxes more easily readable and engaging. It encourages "perusing" by clicking or tapping through the tabs, as opposed to trying to figure out what applies where. DeklinCaban (talk) 18:42, 16 January 2025 (UTC)

That would be an interesting idea! To go back to you iPhone 16 Pro example, a lot of information gets repeated in both tabs – maybe there could be a way to have it so that it only has to be added to the article in one place (even if shown in both tabs) to make them easier to keep in sync? Chaotic Enby (talk · contribs) 18:46, 16 January 2025 (UTC)

If it can print and display without JS effectively. From my testing under these environments, Tabber(Neue) makes these awkward line/paragraph-breaks that don't display the header at all. $wgTabberNeueUseCodex may be promising, but at least with the examples at wmdoc:codex/latest/components/demos/tabs.html, it's even worse: the tabs don't expand for the printing view at all, and the info under the other tabs will just be inaccessible on paper. Aaron Liu (talk) 20:21, 16 January 2025 (UTC)

A couple points at first blush: first, having a tabbed infobox seems like it's a usability nightmare. Secondly, it seems to be doing an end run around the overarching problem, which is that the infobox for iPhone 16 Pro is terrible. Software and tech articles are often like this (bad) where they try and cram an entire spec sheet into the infobox, and that's a failing of the infobox and the editors maintaining it. Trying to create a technical solution rather than the obvious one (just edit what's in the infobox to the most important elements) seems like a waste of everyone's time. Der Wohltemperierte Fuchs ^talk 20:33, 16 January 2025 (UTC)

I suspect that our users would not even realise that they could click the tabs to see other info. So it will make it harder for our readers. Alternatives are to have multiple infoboxes, but this does take up space, particularly on mobile. Another way is to use parameter indexing as in the Chembox. Parameters can have a number on the end to describe variations on related substances in the one infobox. Graeme Bartlett (talk) 20:37, 16 January 2025 (UTC)

Tabs are widely used even on amateur wikis like 90% of Fandom Wikia. I'm sure readers know how to use them. (In fact, the "Article/Talk" "Read/Edit/View history" thing on the top is a tab.) Aaron Liu (talk) 21:27, 16 January 2025 (UTC)

Judging by how few readers understand we have or ever see the talk pages, I'm not sure that's exactly a good argument. Der Wohltemperierte Fuchs ^talk 22:10, 16 January 2025 (UTC)

for that. I started out processing semi-protected edit requests and there were a ton of clueless readers' requests. Aaron Liu (talk) 00:00, 17 January 2025 (UTC)

Readers and potential editors don't know what the protection, good article, featured article, and other icons mean. I'm just one person but I'd never heard of tabs like that until I read this. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 01:35, 17 January 2025 (UTC)

Sorry. That should read "Some readers..." CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 01:37, 17 January 2025 (UTC)

dissensus as an alternative to consensus

For contentious pages, from what I can tell, there is no way in Wikipedia to come to a consensus when both camps are not making a good faith effort, and maybe even then. My proposal is: an expert could start an alternative page for one that he thinks is flawed, and have the same protections from further editing as the original? Then there could be a competition of narratives Iuvalclejan (talk) 19:32, 17 January 2025 (UTC)

We call those WP:POVFORKs and we try to prevent them from happening. Simonm223 (talk) 19:42, 17 January 2025 (UTC)

Honestly, the consensus system works especially well on contentious pages, even if the discussions can sometimes get heated. Having content forks everywhere would not really be preferable, as, not only would you not have a single place to link the reader to, but you would quickly end up with pages full of personal opinions or cherry-picking sources if each group was given its own place to write about its point of view. A competition of narratives could be interesting as a website concept, but it would be pretty far from an encyclopedia. Chaotic Enby (talk · contribs) 19:43, 17 January 2025 (UTC)

The competition would not be the last step. Selection of alternatives could happen by votes, with some cutoffs: if a fork does not get votes above a cutoff, it is eliminated. That would prevent proliferation of narratives. Or you could have the selction criteria be differential instead of absolute: if one narrative gets 2x (for example) more votes than another, the other one is eliminated. Consensus does not work if pages become protected but the disagreement is still strong. Iuvalclejan (talk) 19:48, 17 January 2025 (UTC)

Honestly, the consensus system works especially well on contentious pages,
I'd agree, but I'd also say we don't actually use the consensus system for contentious pages in practice—the more controversial the topic, the more I notice it devolving into straight voting issue-by-issue. (Even though that's the situation where you actually need to identify a consensus that all sides can live with.) – Closed Limelike Curves (talk) 21:42, 20 January 2025 (UTC)

Interestingly, it's been theorized ([3], pg 101) that we already have a "community of dissensus" whereby contentious and poorly-supported claims are weeded out from our articles until only that which can be verified remains. _signed, Rosguill ^talk 19:45, 17 January 2025 (UTC)

The problems I see are not due to poorly supported claims. They are due to a biased reporting, that is technically correct (e.g. "hostilities erupted", rather than side A attacked side B), or outright omissions (e.g. the leader of said group is not mentioned because of his shady associations with Nazis, whereas the leader of the other group is mentioned many times). Iuvalclejan (talk) 20:29, 17 January 2025 (UTC)

In that case, we should stick to what sources say, rather than making multiple versions trying to please each editor. If sources mention the names of both leaders, then we should have them both in the article, rather than hiding one in a separate article. Chaotic Enby (talk · contribs) 20:36, 17 January 2025 (UTC)

So that addresses one issue, but evern there, if the page is protected, you can't "mention them both". What about the way of presenting a phenomenon, that while technically correct, is misleading by omission of important details? Iuvalclejan (talk) 20:42, 17 January 2025 (UTC)

For both cases: page protection doesn't mean that no one can propose any changes, it just means that you have to go to the talk page and discuss them with other editors (usually, to avoid someone else coming just after you and reverting it). If you feel like the discussion isn't going anywhere, we have channels for Wikipedia:Dispute resolution. Chaotic Enby (talk · contribs) 20:49, 17 January 2025 (UTC)

That said, there are special restrictions on articles related to Palestinian–Israeli conflicts, and you shouldn't attempt to edit them or discuss them until you have made 500+ edits elsewhere. This will give you a chance to learn our processes, jargon, and rules in a less fraught context. WhatamIdoing (talk) 08:13, 21 January 2025 (UTC)

This might be a good idea for social media, but this is an encyclopedia. Phil Bridger (talk) 20:45, 17 January 2025 (UTC)

Even more important then, so as not to deceive Iuvalclejan (talk) 20:48, 17 January 2025 (UTC)

Making categorization more understandable to the average editor

See Wikipedia talk:Categorization#When to diffuse large categories?. There is an underlying dispute that caused this but what I'm more interested in finding out how to make Wikipedia:Categorization more helpful to the average editor trying to learn about categorization and when to diffuse/not diffuse because the current text isn't as clear as I think it should be. I suck at RfCs and I don't think discussion is near the point where one should be started yet, so more input really is welcome. Clovermoss🍀 (talk) 23:03, 17 January 2025 (UTC)

I've tried understanding Wikipedia:Categorization and it hurt my brain so I gave up, but kudos for attempting to tackle it. Schazjmd (talk) 15:48, 18 January 2025 (UTC)

It makes my brain hurt too, but I'm hoping enough editors who find it confusing can come together and make this process less of a maze. Clovermoss🍀 (talk) 23:32, 18 January 2025 (UTC)

One good start might be to move the section on creating categories below that of categorizing articles - there are far more article categorization changes than category creations Jo-Jo Eumerus (talk) 08:05, 19 January 2025 (UTC)

More levels of protection and user levels

I think the jump from 4 days and 10 edits to 30 days and 500 edits is far too extreme and takes a really long time to do it when there are many editors with just 100, 200 edits (including me) that are not vandals, they do not have strong opinions on usually controversial opinions and just want to edit. Which is why I want the possibility for more user levels to be created. For example one for 200 edits, and 15 days that can be applied whenever vandalism happens somewhat, in that case normally ECP would be applied however I that is far too extreme and a more moderate protection would be more useful. Vandals that are that dedicated to make 200 edits and wait 30 days will be dedicated enough to get Extended Confirmed Protection. Though I want to see what the community thinks of sliding in another protection being ACP and ECP. 2 levels should suffice to bridge the gap between 4 edits and 500 edits would allow low edit count editors to edit while still blocking out vandalism. This is surprisingly not a perennial proposal. SimpleSubCubicGraph (talk) 02:19, 21 January 2025 (UTC)

It's more that editors who have 500/30 generally have been in enough situations to hold Wikipedian knowledge that's in-depth enough. That doesn't necessarily hold true for those you've proposed. Time is part of the intention. Aaron Liu (talk) 02:28, 21 January 2025 (UTC)

possibility for more user levels to be created I had thought about this before and think more levels (or at least an additional level with tweaks to the current ones) would be a good idea. Something along the lines of:

1. WP:SEMI - 7 days / 20 edits

2. WP:ECP - 30 days / 300 edits

3. WP:??? - 6 months / 750 edits (reserved for pages with rampant sockpuppetry problems, such as those in the WP:PIA topic area). Some1 (talk) 02:50, 21 January 2025 (UTC)

@Aaron Liu Yes, that may be apart of the intention but I feel like there are editors with under 500 edits who can make just a good enough edit to not get it instantly reverted. Also protection is there mainly for vandalism, if we lived in a perfect society anyone could edit wikipedia pages without needing accounts and making tons of edits.

@Some1 I think 180/750 would be far too harsh, not even the most divisive topics and controversial issues get vandalized often with ECP.

My idea generally was keeping ECP the same but inserting another type of protection level in-between for mildly controversial topics and pages that are vandalized infrequently. SimpleSubCubicGraph (talk) 03:25, 21 January 2025 (UTC)

Can you give some specific examples of "controversial topics and pages that are vandalized infrequently"? Is there a particular article you want to edit but are unable to? Some1 (talk) 03:29, 21 January 2025 (UTC)

There is not too much utility to creating a variety of new levels, as it generally gets clunky trying to define everything, and it makes the system less easy to grasp. What differentiates 100 edits from 200 from 300? ECP is not usually for vandalism, it is deployed for topics that receive particular levels of non-vandalistic (WP:VAND is very narrow) disruption. These are topics where experience is usually quite helpful, where editors who just want to edit are more likely to get in trouble. However, it is also a very narrow range of topics, apparently only affecting 3,067 articles at the moment, or less than 0.05% of articles. CMD (talk) 03:39, 21 January 2025 (UTC)

Isn't EC protection just for contentious topics? I didn't think we were using it just to protect against common or garden vandalism. Espresso Addict (talk) 05:59, 21 January 2025 (UTC)

@Espresso Addict even though there are 3,000 articles that have ECP protection, many articles are often upgraded to ECP in light of infrequent vandalism (once a day, few times a week, etc). I know Skidibi Toilet was upgraded to ECP when the page was vandalized a few times. It was quite hilarious but it demonstrates a wider problem with liberally putting ECP on everything that gets even remotely vandalized. SimpleSubCubicGraph (talk) 07:06, 21 January 2025 (UTC)

Now, are there that many people that care for Skidibi Toilet? No. But it is also liberally applied to other wiki pages that are infrequently vandalized and editors can be there, wanting to edit, but they have to wait until an admin removes the protection which can vary depending on how active they are. It can be a day, to a week, and up to a month if you are really unlucky and the article is not that well known/significant. Which is why another type of protection can allow these editors to edit their favorite subject while still preventing vandalism. There are very few ECP users and that is with counting alternate accounts. So this change will affect a lot with how wikipedia works. SimpleSubCubicGraph (talk) 07:09, 21 January 2025 (UTC)

ECP is not liberally applied. Admins are usually very cautious about applying it, and if there is a particular case where you think it is no longer needed, raise it and it will very likely be looked at. CMD (talk) 08:11, 21 January 2025 (UTC)

500 edits is also when you earn access to Wikipedia:The Wikipedia Library.

Editors who make it to about ~300 edits without getting blocked or banned usually stick around (and usually continue not getting blocked or banned). So in that sense, we could reduce it to 300/30 without making much of a difference, or even making the timespan a bigger component (e.g., 300 edits + 90 days). But it's also true that if you just really want to get 500, then you could sit down with Special:RecentChanges and get the rest of your edits in a couple of hours. You could also sort out a couple of grammar problems. Search, e.g., on "diffuse the conflict": diffuse means to spread the conflict around; it should say defuse (remove the fuse from the explosive) instead. I cleaned up a bunch of these a while ago, but there will be more. You could do this for anything in the List of commonly misused English words (so long as you are absolutely certain that you understand how to use the misused words!). WhatamIdoing (talk) 08:36, 21 January 2025 (UTC)

[to SimpleSubCubicGraph] Sorry, I must have missed the various RfCs that extended the use outside contentious topics. SimpleSubCubicGraph, if you finding pages that could safely be reduced in protection level, and that don't fall within contentious topics, then you should ask the protecting admin to reduce the level on their talk page. But if you have an urge to edit Skibidi Toilet then the simplest thing to do is make small improvements to mainspace for a couple of hundred edits. If you don't have a topic you are interested in that isn't protected just hit random article a few times or do a wikilink random walk until you find something that you can improve. Espresso Addict (talk) 08:47, 21 January 2025 (UTC)

Ways to further implement restricting non-confirmed users from crosswiki file uploading

The whole community unanimously approved restricting newest, i.e. non-(auto)confirmed, users from transferring files to Commons. How else to implement such restrictions besides an abuse filter that's already done and hiding the "Export to Wikimedia Commons" button from non-confirmed users (phab:T370598#10105456)? Someone at Meta-wiki suggested making ways to implement this, so here I am. George Ho (talk) 06:01, 21 January 2025 (UTC)