Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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 10 days.

« Archives, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76

Commentary ability for Good Article reviewers

Hi everyone. Having just started my first Good Article review, I've found there to be quite a great deal of difficulty in citing material that needs significant correction outside of the talk page. What I mean is that information like that can often be missed amid long discussions over necessary changes, complicating the process on both ends and only delaying it further.

I have a sense that it could be useful to have an option for editors (with some degree of authority granted to them by nature of their having taken on a review, or received a request for comment/second-opinion amid that review process) to leave commentary or flags at specific points in the article they're evaluating. The only such system that exists at present is invisible comment feature, which is restricted to the source code and complicated by the fact that it may mess up that source coding or leave unnecessarily long blocks of white space in between sections (if the editor wants to make certain that it's visible).

Having searched through the noticeboard, the only such proposal I could find was from 2008, wherein the majority of participants expressed concerns over the potential for such a system (if left unchecked and provided with equal access to all editors) to wreak havoc, particularly on articles dealing with current events or significant controversies. What differs with this proposal is that the editor in question would have to be vested with specific permissions from an authority at WP:GA (or WP:FARC), from what authority I'm not entirely sure, nor how this would be done (hence my bringing this to the idea lab). This would only occur at the time of nomination, at which point very few divisive topics are still as heated as they were when the controversy first began (spurring the creation of the article, in some cases).

I'm curious to hear what others' thoughts are. Any assistance with the technical side of such a proposal (if deemed worthy of passage) would be greatly appreciated. I'll look forward to the discussion to come.

Best, CSGinger14 (talk) 14:46, 13 January 2026 (UTC)

It’s difficult to have a discussion about such comments, I’d opt to keep it in talk page which isn’t perfect either but most collaborative. ~ 🦝 Shushugah (he/him • talk) 12:28, 14 January 2026 (UTC)

Hi Shushugah, thanks for the response. I'm curious, why would such a discussion be difficult?

Best,

CSGinger14 (talk) 22:54, 17 January 2026 (UTC)

I dunno, @CSGinger14. If we tried something like that, we'd probably have editors making misstatements like if it's not cited, then it's OR[1], even though the Wikipedia:No original research says that information can be 100% compliant with the NOR policy even if no source is currently named in the article. And if that commentary system is only editable by someone who has been vested with specific permissions from an authority, then 99% of editors aren't going to be able to reply in the same place with a comment like "They've got the jargon mixed up, and anyway you only have to cite information once in an article, so go look at the #Transportation section if you want sources about rail and bus." WhatamIdoing (talk) 01:42, 18 January 2026 (UTC)

Touché @WhatamIdoing, always glad to have your input in a discussion. Do note per the talk page that I'd noted I hadn't yet had a chance to do a full pass over of the article on account of injury (comment was made in haste for preservation), if you'd like an explanation for the misstatement. Was planning on returning to that process tonight.

'

Building off your point, I figure that's exactly the sort of risk that could be worked out here. Editors assisting in bringing the article up to GA status could have a means of requesting or acquiring access (perhaps automatically for those with the top 4 highest attributions (i.e edits / authorship %), or requested based upon recent activity (combined with evident participation in the review process).

'

Frankly, and evidently, the same sort of misstatements can be made on talk as well; your having located the invisible comment on the main page shows that such mistakes can be located by experienced editors and corrected, but that the process might be cumbersome for those who are new to the game. Alerts might be included on the transcluded discussion to notify involved editors of such changes. I'll wait to hear your word, but do honestly feel that such a change would be greatly beneficial, and assist with the visibility of exactly the sort of errors you've pointed out. Best wishes, CSGinger14 (talk) 03:26, 18 January 2026 (UTC)

If we're going to have such a system, I wouldn't restrict it very much. I definitely wouldn't want to see a comment from an editor that sits there forever, complaining about something in the article, or a couple of editors arguing in the mainspace. But maybe something vaguely like a custom {{info}} or {{fix}} template would serve the purpose – not that we would exactly want {{info|reason=This stuff about rail and bus service isn't cited here – should it be?}} to be visible to readers, but similar in the sense that you can place them in particular parts of an article, and anyone can change them or remove them later.

In terms of the GA workflow (because you need something that works now, not in the magical future), you might consider copy/pasting the whole article to a word processing doc, so you can highlight and comment as you read. That would make it easy to take notes as you go along, and to close them as they get resolved/you decide they're not worth it, and of course to walk away mid-process whenever you need to without losing your place. It's not a great workaround, but it's the only one I can think of right now. WhatamIdoing (talk) 05:27, 18 January 2026 (UTC)

So based on my understanding, you want a comments feature for a mainspace article when it's under a GAN review, akin to a Google Docs / online document software commenting feature? I do like the idea, but for a different reason; I think this would save reviewing time for the reviewer. Typically for a GAN review, I use something like Template:tq or any colour-text template to highlight specific phrases in an article that need resolving. I haven't encountered any issues with this system, though I must say that the articles I usually review are relatively small. For Editors assisting in bringing the article up to GA status could have a means of requesting or acquiring access (perhaps automatically for those with the top 4 highest attributions (i.e edits / authorship %), or requested based upon recent activity (combined with evident participation in the review process), can't they just circumnavigate the waiting time by leaving comments on the article's talk page? And how would we know that the reviewer truly left comments on the nomination if it's restricted to them and the nominator? Probably go with a general permission like AFCH. Icepinner (Come to Hakurei Shrine!) 13:40, 18 January 2026 (UTC)

Hi @Icepinner, you make several good points. I'll push back though in reference to @WhatamIdoing's earlier comment, as well as the discussion that took place here about two decades ago which pointed out the dangers of having open permissions for editors, as such a system could essentially be used as a means of advertising their disagreements with the page outside of talk. Visibility restrictions weren't my primary concern, mainly edit restrictions, to ensure that the system couldn't be abused.

'

I don't disagree that there should be a well deliberated breakdown of the article in talk alongside commentary in the main-space (which I'd argue should be restricted to the edit window (with notices similar to that of Refideas or Pp-semi to allow editors actually involved in the GA process to turn their attention towards it, but not crowding out the view for Gnomes or other editors that only intend to be there in passing (Would it make sense for visibility to appear as an option in extensions like HotCat?)). I'd ask other editors for their thoughts on how such a system would work. Best wishes, and best of luck to those in the US facing the storm this weekend. CSGinger14 (talk) 01:08, 24 January 2026 (UTC)

Adding a brief note here to re-up for another week of preservation. Hoping to get enough feedback to make a proposal soon.

Best, CSGinger14 (talk) 10:34, 31 January 2026 (UTC)

Signpost on Main page

I have an idea to (propose to) include a dedicated box on the Main Page for The Signpost similar to that Today's Featured List/Picture etc. I'm thinking it should displayed on the Main Page for 3/5 days after each issue is published; Any thoughts/suggestions regarding it would be appreciated..! Vestrian24Bio 12:24, 18 January 2026 (UTC)

The Signpost may be too inside baseball for such general-reader exposure. Randy Kryn (talk) 12:54, 18 January 2026 (UTC)

I agree with Randy. The Signpost is also facing a bit of heat right now regarding a "Special report" published by them where the author used an LLM "to help write and copyedit" the piece. I started a talk page discussion about this (Wikipedia talk:Wikipedia Signpost#LLM and the Signpost) to get some clarification. Some1 (talk) 13:13, 18 January 2026 (UTC)

Just for clarification's sake (for everyone else if not yours), that article was republished from Meta probably because it was previously already a major topic of discussion on Wikimedia-l and elsewhere. I haven't seen evidence that the Signpost knew AI was involved in writing/copyediting it, probably because that was buried on the Meta talk page, and they added a disclaimer to the article when they learned. That "bit of heat" is at best a flickering candle; give them a break. Ed ^{[talk] [OMT]} 15:57, 21 January 2026 (UTC)

I didn't select it, but I'm the one who did the final copyedit on it, albeit with a lot of what I did reverted (it happens). It was kind of late on in publication, and I thought it was incredibly dense, about twice or three times longer than it needed to be, and hard to follow, but I was under the impression this was brought over from one of the WMF publications, so reluctantly passed.

I could probably edit it into a more coherent document of half its size. But it wouldn't be the author's words at that point, and I'd be co-author of a paper I didn't believe in the argument of. But if we're only publishing articles that don't challenge readers, what are we doing as a newspaper? Sometimes, you just throw it out there, don't under any circumstances state that it's an official view of the Signpost, and let the debate go where it may.

That said, if I had known it was AI slop, I'd have suggested spiking it immediately. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 03:31, 22 January 2026 (UTC)

If you're unable to even see it's made with AI, then it's probably not AI "slop". The word has lost all meaning already and now just serves to signify overt AI aversion without ability for any nuance. I don't know if it was good that it has been featured mainly because it has some flaws like at least one misleading and possibly inaccurate data which I had asked about before signpost publication with basically no response. A reason to include it nevertheless is that has been read by very many and had substantial impact and got a lot of feedback by the community on its talk page – it could be reasonable to feature it for that reason alone but with proper warning notes at the top. People may be interested to read about essays have had major internal impact/audience. Prototyperspective (talk) 12:59, 22 January 2026 (UTC)

As I said, I personally found it barely readable and overly dense without ever saying much, while being technically gramatical. I didn't suspect it was AI because I didn't think there was any possibility someone would publish AI in what I thought was an official WMF publication. Once it came out it was AI, my first reaction was "Oh, that explains it", replacing my previous judgement of "corporate writing".

Humans and AI are both capable of writing in that rather awful corporate style. Humans and AI can write overblown claims of disaster. Humans and AI can get me to give up and say "this was already published, I'm just going to copyedit the opening and let the WMF have their place in this issue; it's not my job to speak for them."

Just because humans can also write corporate slop doesn't make it less slop. Adam Cuerden ^(talk)_{Has about 8.8% of all FPs.} 14:12, 22 January 2026 (UTC)

Thanks for explaining. I misread your comment thinking you were basically just referring to excessive length and maybe some grammatical issues here and there. Prototyperspective (talk) 14:24, 22 January 2026 (UTC)

Absolutely not while the Signpost is running chatbot output - David Gerard (talk) 14:17, 18 January 2026 (UTC)

I think if we had some more staff, this could be nice, but as it stands stuff is broken pretty often (e.g. some image gets deleted or some template breaks and then it's just cooked for a while until I can fix it). Currently, I am employed at a job that does not give me a lot of free time, so I cannot spend as much time as I think would be required to make it be consistently Main Page material (e.g. every article of every issue). jp×g🗯️ 14:18, 18 January 2026 (UTC)

Honestly, even when I do have enough time, the task of technical maintenance for the Signpost is so abjectly unpleasant that I would prefer to minimize my responsibilities as much as possible. For example, routine maintenance of templates and redirects will often be subjected to weeks-long bureaucratic review processes. A redirect that hasn't been wikilinked to anywhere since 2007 might be useful, according to somebody, so it needs to go through RfD and can't be CSDed and has to clog up the PrefixIndex until the RfD is processed; a template to black out text for crossword answers has the same name as a template that people got mad about in 2008, so even if it is hard-coded to be incapable of ever doing the thing that people got mad about the different template doing, it will be nominated for deletion, with a TfD notice breaking all the crosswords until it's resolved, et cetera. An image that we used in an article to discuss a hoax that was found and deleted gets nominated for deletion on Commons... for being a hoax. Somebody thinks an article from last year should have been titled something different, so they just edit the page to have a different title, which breaks a bunch of stuff in Module:Signpost. Oh, now some WMF guy slopped the copy in his essay that he submitted, so that's an ethical issue or something, because maybe the LLM was incorrect about what his own opinions were. Now some famous blogger is going to come call me a dipshit on the Village Pump over it. The whole tag system is busted because it was maintained entirely by force of Chris Troutman tagging the articles by hand every issue, and then he decided to go on some crazy tirade and get himself indeffed, so now the tag lists and the article series templates don't really work right, and even if we started tagging them again somebody still has to go through and add all of the articles from the last couple years. The archive pages and the main page still use totally different templates for some reason even though they basically do the same thing. There are about eight bajillion CSS classes that haven't been migrated into the master stylesheet, and also a bunch of them are just inline from random articles. Nobody knows what all the layout templates are or what they do. Also the commons delinker bot just fucks up old articles basically every day, and then you can't even go through to try to make a list of redlinked images to...

You get the point. jp×g🗯️ 14:35, 18 January 2026 (UTC)

Thank you for your service, @JPxG. You've made it so that the average reader doesn't realize any of this, which is most likely a double-edged sword. :) JuxtaposedJacob (talk) | :) | he/him | 17:58, 18 January 2026 (UTC)

No. It's internal and much of what's written would be incomprehensible to people outside the project. Also, there are serious unresolved issues regarding the use of LLMs in Signpost articles. It's antithetical to Wikipedia's mission to put LLM content in front of humans. Mackensen (talk) 16:49, 18 January 2026 (UTC)

Ignoring the current "scandal" about LLM use, this is not going to happen, because the Signpost is internal and of next to no interest to the reader. Cremastra (talk · contribs) 18:29, 18 January 2026 (UTC)

This is also hardly the first “scandal” to hit the publication; they’re a recurring feature and a leading cause of turnover in the editors contributing to the Signpost’s publication. It also generally fails to contact editors for comment when it covers topics they’re involved with, which is a failure to follow basic journalistic practices. This latest issue also included reporting on the Baltic birthplaces story that I believe seriously misrepresented the events in question; I haven’t made a big deal about it because the Signpost getting it wrong currently doesn’t really matter, any productive discussion towards resolving the actual underlying dispute will not come from such a complaint, and I don’t expect the Signpost to meet professional journalistic standards. If this were something we were advertising to all readers, however, I would have objected to its publication directly. TLDR, the signpost isn’t ready for prime time (even though I do think it’s worthwhile as an internal newsletter), and unless there’s a huge shift in the amount of editor effort and interest going into preparing its issues, it isn’t going to be ready in the foreseeable future. _signed, Rosguill ^talk 16:35, 21 January 2026 (UTC)

Strong oppose. The Signpost is a mixture of original reporting with opinion articles. It is not held to the same sourcing standards as mainspace articles. Putting it on the main page with our mainspace content will lead to confusion. Apocheir (talk) 19:47, 18 January 2026 (UTC)

The Signpost is a big part of why I signed up for Wikipedia in the first place! Having some more visible insight into the community would not be a bad idea per se, although putting The Signpost on the Main Page might be a bit much. And there is a bit of heat right now regarding the LLM generated article, too. MEN KISSING (she/they) T - C - Email me! 22:39, 18 January 2026 (UTC)

Support. The main page is boring and not engaging. There is only a very small chance the user is interested in what happens to be interested in the one daily featured article; the DIYs are mostly meaningless mundane trivia; featured pictures are nothing of importance to society and not really educational but just aesthetically pleasing which is a type of photos people see tons of online already; on this day is an arbitrary selection of events that happen to have occurred on the same day; the In the news tile is imo the only interesting changing content but gets just very rarely. Adding the signpost there would make it things more interesting.

Additionally, people would develop more interest and excitement about Wikipedia and become more interested in becoming a contributor themselves or a more active contributor if they've already signed up if they read the internal news there.

and of next to no interest to the reader. not true imo. Wikipedia news are or can be of interest to the Wikipedia reader. Wikipedia readers also read news about Wikipedia in external sources, there's no reason why they wouldn't be interested in some internal news as well. Additionally, a fraction of Wikipedia readers are contributors. An option would be to only display it for users who are logged in but it would I think probably be best to include at least some visible link to the latest issue also for logged-out users. Prototyperspective (talk) 18:02, 19 January 2026 (UTC)

The problem is many readers will expect a "Wikipedia newsletter" to be some kind of official newsletter about interesting facts and upcoming changes, not an internal newsletter about the latest WMF scandals. Cremastra (talk · contribs) 18:25, 19 January 2026 (UTC)

This doesn't sound like a good idea, far to much of signpost is opinion posting to give it any hint of official backing. -- LCU ActivelyDisinterested «@» °∆t° 19:29, 20 January 2026 (UTC)

I don't know why putting sth about the Signpost on the Main page would be interpreted by readers for it to have "official backing" but one could also clarify that it's nothing official at the top of the Signpost or at the top of whatever page is linked to. Prototyperspective (talk) 20:50, 20 January 2026 (UTC)

I'd rather it's opinions weren't on the main page at all, it's already pushed via notifications on the watchlist any interested editors can find it there. Even if labelled as unofficial it's presence on the main page would suggest it's articles have community support. -- LCU ActivelyDisinterested «@» °∆t° 21:32, 20 January 2026 (UTC)

No. The Signpost is mostly an internal project newsletter that thinks of itself as, and tries to be, a tabloid newspaper doing it's best to amplify minor scandals and division. The main page is focused on showcasing the best parts of the encyclopaedia to the readership, and The Signpost is neither part of the encyclopaedia nor our best work in project space. We do want to encourage readers to become editors, but not all readers - we want those who want to and can contribute collaboratively and collegiately. The Signpost will drive away many of those folk while attracting more of those looking for drama - the exact opposite of what the project needs. Thryduulf (talk) 16:06, 21 January 2026 (UTC)

Signpost is by wikipedians for wikipedians. It is of little interest to the general public Dronebogus (talk) 00:43, 31 January 2026 (UTC)

The Main page is read by a lot of Wikipedians. An idea would be to only show some tile / brief info with link about it for registered logged in users. The general public does read about Wikipedia from time to time as well and there's a bigger chance for that if they're browsing the WP Main page exploring around. Prototyperspective (talk) 19:45, 31 January 2026 (UTC)

I Support what has already been suggested here, a link in Template:Other areas of Wikipedia replacing the link to the obsolete portal space. Template:Other areas of Wikipedia/sandbox Guilherme Burn (talk) 22:02, 29 January 2026 (UTC)

I oppose that suggestion for two reasons, firstly all the reasons I oppose putting the signpost on the front page, secondly portals are not obsolete. Thryduulf (talk) 23:34, 29 January 2026 (UTC)

Re-evaluate long-duration protections

When looking through the articles of the top-importance medical articles, I noticed that about 1/3 were protected, often WP:Semi-protected and in a few cases extended protected. Many of these protections were placed over a decade ago, for disruption that might not always be considered enough for protection now, or were leftovers from the hottest part of the COVID pandemic. I've since unprotected a couple per WP:TRYUNPROT, and asked for ECP to be lowered to semi, but I wonder if a wider evaluation would be beneficial. If new editors, who mostly read highly-read articles, face barriers to editing so often, we might lose out on new editors during a period we really need them.

So, a bit of a brainstorm on how to tackle this:

• We could trial a large-scale reduction to WP:Pending changes protection of articles protected over 10 years ago, and evaluate in a year which articles still got vandalism (removing protection altogether). Say, reduce the protection in 500 or 1000 articles.
• We could start a project with a couple of admins to re-evaluate protections to our highly-read articles, and use common sense to trial a reduction in protection levels where it seems sensible
• We could add some guidance about applying protection of 2-5 years more often, rather than jump from a few weeks/months to indef.

—Femke 🐦 (talk) 17:41, 19 January 2026 (UTC)

As a reviewer I'd support systematic reduction of certain pages to pending changes protection. The PC backlog is almost always very small, and PCP is just smoother on both ends compared to edit requests. The only snag is that PCP is canonically only to be applied for persistent vandalism, BLP vios, and copyvios. The issues with the medical articles you mentioned I suspect were more in line with WP:V or FRINGE. I still think PC could work in practice, but there would probably need to be a wider discussion before implementing it. —Rutebega (talk) 19:23, 20 January 2026 (UTC)

Hoping to get initial reactions here + new ideas before proposing it at WP:VPPr. The medical articles mostly suffered from vandalism, in terms of reason for protection (COVID was more to keep FRINGE out I imagine). —Femke 🐦 (talk) 19:29, 20 January 2026 (UTC)

Maybe a mass reduction of protection for articles whose reason is vandalism related, or for pages with low daily pageviews? 45dogs (they/them) (talk page) (contributions) 20:07, 20 January 2026 (UTC)

I don't support indiscriminate reduction in protection across the board, that's just going to lead to problems. However, something more focused that allows for a quick and easy reduction without too much hassle would seem to be useful. Thryduulf (talk) 20:11, 20 January 2026 (UTC)

I think it's a good idea to restrict it to vandalism-related protections. Overall, there are about 10,000 articles indefinitely semi-protected, while Category:Wikipedia pages semi-protected against vandalism has about 2300 pages. Curious to see how big the union of those two categories is. Maybe an experiment with the following parameters might work:

• Get a list of all articles that were indefinitely semi-protected for vandalism more than five/ten years ago
• Allow time for people to remove articles from the list where it's obvious that they will be vandalised again
• Lower protection to PCR of remaining articles
• A year later, re-evaluate with two goals:
  • Find out what share of article got reprotected to semi
  • Find out what share of articles had any instance of vandalism
  • Remove protection altogether for articles.

I'm most keen on lowering protection on articles that need updating + that might attract new editors (=high pageview articles). —Femke 🐦 (talk) 20:48, 20 January 2026 (UTC)

Only 48x articles are in both "Wikipedia pages semi-protected against vandalism" and "Wikipedia indefinitely semi-protected pages", though I don't think pages are consistently tagged with the two different templates, so this may not add much information. I think you'd have to go digging in Quarry to find how old the protections were. Andrew Gray (talk) 21:41, 22 January 2026 (UTC)

@Femke I looked into Quarry, and here's a start - all pages with indefinite semi-protection, and the last timestamp in the protection log - not necessarily the time it was originally semiprotected, but it is the last time someone did something that affected the protection, which seems a reasonable proxy.

Of the 11796 permanently semi-protected non-redirect articles, 23% were last logged more than ten years ago (2015 or earlier), and 30% 5-10 years ago (2016-2020).

This query is the same as above, but only those pages in the "Wikipedia pages semi-protected against vandalism" category. Of 1726 non-redirects, 24% were from more than ten years ago, and 37% from 5-10 years ago.

That makes for about 2700 pages which have been protected indefinitely for more than ten years, of which a little over 400 are explicitly marked as protected due to vandalism. So that might be a good first batch to look at. Andrew Gray (talk) 18:03, 23 January 2026 (UTC)

And for completeness: all articles indefinitely edit protected of all types (adds 8800 indefinite extended-confirmed and a tiny handful of full-protected); and all indefinitely pending-changes protected articles (3700 indefinite). Andrew Gray (talk) 18:44, 23 January 2026 (UTC)

If the goal is to attract new editors by removing page protection, then the focus shouldn't be on unprotecting highly-vandalized articles; instead, we should start by getting rid of restrictions like WP:ECR and allow new editors to contribute to contentious topic areas/articles (e.g. PIA or Donald Trump). Some1 (talk) 20:29, 23 January 2026 (UTC)

PIA the purview of the arbitration committee. I'm generally quite skeptical of ECR and ECP, and think we can lower the protection on some pages in other CTOPs where they are discretionary. Many covid pages do not require ecp anymore for instance. —Femke 🐦 (talk) 20:52, 23 January 2026 (UTC)

Support – this makes sense. Also note that if there's better tools like Automoderator and Cluebot quickly reverting or flagging/spotting vandalism, then there's less need for such prevalent protection. I generally think the requirements for these protection levels are easy to meet but on the other hand, people have to start somewhere and often it's probably some article that is protected where they first find sth that needs to be edited.

An alternative or complementary approach would be to get more new users to post about the change they'd like to make on the talk page when the article they'd like to edit is protected – e.g. directly redirecting them to the talk page with the new thread input fields opened (maybe prefilled with a text like "Please describe the change you'd like to make and other editors will do it for you if they agree") after for ~5 seconds the notice about the page being protected is displayed. Prototyperspective (talk) 13:19, 22 January 2026 (UTC)

The protection policy essentially already has that guidance and I think that's how most administrators handling protection requests do things nowadays. Most of the indefinite durations that should be revisited are older protections.

I am in favor of revisiting protections, but I don't support lowering the protection level of any category of articles "across the board". More specifically, I would be in favor of trialing pending changes for articles that haven't experienced a significant number of reverts recently. Most articles that are semi-protected indefinitely where it's warranted still receive some disruptive edits from relatively new accounts.

We could stack rank articles that were indefinitely protected more than ten years ago by a metric like "percentage of edits that are reverts or reverted edits in the last two years" and trial unprotecting the bottom 10% first. I would also filter out any articles that have had any higher-level protections in the last five years. If that goes well for six months, we could extend that to the next 10% or 20%, and so on. If there's interest in trying this approach or one similar to it, I would be happy to help on the technical side. Daniel Quinlan (talk) 22:44, 23 January 2026 (UTC)

When is the last time the foundation looked at creating a search engine?

Wikia Search? Given the increasing enshitification of corrupted engines like Google and Bing, what obstacles exist to creating a language independent Wikipedia-favorable search tool? BusterD (talk) 12:00, 21 January 2026 (UTC)

Regarding the question in the section title, possibly Knowledge Engine? Anomie⚔ 13:18, 21 January 2026 (UTC)

So a long time ago. Thanks for the history. Nice to know they saw it coming. I'll do my reading. Seems like we'd want to utilize one of the best known internet knowledge brands for more than just fund raising... BusterD (talk) 14:00, 21 January 2026 (UTC)

See mw:Readers/Information Retrieval and c:Commons:Media search. If that's what you're saying, I'd agree that they should do more technical development of the Wikimedia search engines. It's super important. See also c:Category:Wikimedia search.

-

If this is exclusively about an entire Web search engine like Google or DuckDuckGo, I think it's not so simple any may be well outside scope for now – are you referring to a whole Web search engine? When it comes to that, imo the better approach would be to make the existing widely-used search engines better index/incorporate Wikimedia things – this is what m:Community Wishlist/Wishes/Do something about Google & DuckDuckGo search not indexing media files and categories on Commons is about which had some major successes already. Prototyperspective (talk) 13:08, 22 January 2026 (UTC)

This is an interesting idea. Worth the WMF thinking about. Perhaps you can find a place to share this idea here: Meta:Talk:Wikimedia Foundation Annual Plan/2026-2027 - Wil540 art (talk) 21:17, 22 January 2026 (UTC)

That page is just for the discussion of the annual plan. Proposals for things not yet in it I think fit much better into the m:Community Wishlist. That could then maybe be linked on that talk page. Prototyperspective (talk) 22:27, 22 January 2026 (UTC)

Spoiler alert: Things did not go swimmingly. GMG^talk 21:37, 22 January 2026 (UTC)

• Please take a look at the technical village pump. The first item is about a project on semantic search, in very early days. I think starting a general search engine like Google would require far more funds than available. Yesterday, all my dreams... (talk) 12:23, 23 January 2026 (UTC)

That's a very expensive and complicated endeavor and would require some strong reason to greenlight it... stronger than just baseless conspiracy theories. Cambalachero (talk) 14:58, 23 January 2026 (UTC)

"baseless conspiracy theories" You can search Google to get reliable sources saying Google is getting worse. Have fun working out that contradiction. LightNightLights (talk • contribs) 23:34, 23 January 2026 (UTC)

Come on, is that the best you got? "Find youself my arguments somewhere in the internet"? Cambalachero (talk) 12:34, 24 January 2026 (UTC)

Lucky for you, I actually checked Google before I commented. Here are three. There is more where that came from.

Is it not standard practice to research before forming your opinions? I would have thought that the curators of truth that are Wikipedians, like you, would have done that. I did it so easily, so what is your excuse? LightNightLights (talk • contribs) 13:00, 24 January 2026 (UTC)

The burden is on the person making such claims to substantiate them with sources, especially when it comes to active editors who have enough other things to do with their time. Prototyperspective (talk) 13:12, 24 January 2026 (UTC)

Let's dissect your comment.

• Cambalachero made the claim with no sources that, paraphrased, "'Google is getting worse' is a baseless conspiracy theory." Where is your rage about that?
• Point taken about the burden of proof, but how much effort was it to open a new tab and type "google search worse"? Also, Wikipedia does not fully operate with the burden of proof; we expect AfD nominators to search Google before nominating article deletions on notability.
• My 50th-to-last edit was on 16 January. BusterD's was on 12 January. Cambalachero's was on 1 January. Let's keep telling ourselves that Cambalachero is the "active editor" here. (And I do not even intend to make myself look good on whatever edit metrics there are!)
• Did you actually read my comment? The one that linked to three sources and a Google search, therefore fulfilling my burden of proof? The one that is above your reply?

All in all, effective ragebait. Congratulations on the achievement. LightNightLights (talk • contribs) 13:44, 24 January 2026 (UTC) (edited 13:50, 24 January 2026 (UTC))

Asking me to be enraged is a bad thing to do. Meta discussions are supposed to be calm deliberation with rational arguments and again the person who should provide sources that explain and substantiate is the one making the respective claim(s) and this is all I said. Prototyperspective (talk) 13:53, 24 January 2026 (UTC)

That would be kinda nice, especially if it's just indexing pages linked in wikipedia articles (whether as sources or infobox things) I might be interested in doing that if the wmf isn't. It could even plug into wolfram alpha for actual questions instead of trying to find things mgjertson (talk) (contribs) 19:05, 26 January 2026 (UTC)

Proposal to create new categories for escape lines

Thousands of people from France, Belgium, and the Netherlands were involved in escape and evasion lines during World War II. The escape lines were devoted to helping downed allied airmen and others evade capture by the Germans and return to England, most commonly via neutral Spain. Wikpedia has nearly one hundred articles about the escape lines and prominent escape line leaders -- and more are being created. At present, articles about escape lines and escape line leaders are categorized as Category:French Resistance, Category:Belgian Resistance, etc. A category titled "Escapes and rescues during World War II" exists but it is little used and perhaps also too broad to focus on the very specific activities of escape and evasion lines.

I believe the escape lines and personnel merit their own category (or categories) -- as some escape lines already are in the French-language Wikipedia. The escape lines were distinct in their function and they avoided contact with armed and violent resistance groups. Thus, I hope that whoever is dealing with categories will create "Category:Escape and evasion groups (World War II)" and "Category:Members of escape and evasion lines". Separate categories might also be created for the most important of the escape lines, the Comet Line and the Pat O'Leary Line. Smallchief (talk) — Preceding undated comment added 16:15, 26 January 2026 (UTC)

This seeems like a great case for WP:BOLD, unless you have technical questions about how to do it. Wikipedia talk:WikiProject Categories might be a good place to ask about whether your idea is reasonable if you want to discuss before trying it. DMacks (talk) 19:54, 26 January 2026 (UTC)

Big popup when trying to edit with recent LLM cookies or links with an LLM referral link

This will likely be thrown out as a bad idea but we should have a big popup with a 1 minute timer for any new editor (less than 50 edits or not logged in) if they have cookies from llm services or use references with llm referral links. Something that makes it very very clear that they should not, under any circumstance, use an llm for anything when editing, especially if they think they can or are the exception to the rule because they 'know what they're doing'. mgjertson (talk) (contribs) 18:51, 26 January 2026 (UTC)

This would contradict the multiple recent community consensuses against a complete ban on using LLMs. Thryduulf (talk) 19:00, 26 January 2026 (UTC)

Just because it isn't completely banned doesn't mean we shouldn't stop people who don't know what they're doing from doing it (for example, writing about yourself isn't technically banned but so heavily discouraged it might as well be) mgjertson (talk) (contribs) 19:10, 26 January 2026 (UTC)

We should just make an edit filter for any edit that adds a URL with LLM metadata, set to disallow for any user, admins included. I generally agree with Thryduulf's view, and reluctantly acknowledge that there are some tenuous use cases for LLM-assisted editing when a human reviews before submitting, but there aren't any for these sorts of links, and having them disallowed by a filter also populates a handy log if we need to investigate a user. Ivanvector (^Talk/_Edits) 19:09, 26 January 2026 (UTC)

Links found by LLMs fall into all the following categories:

1. Reliable and relevant
2. Reliable and irrelevant
3. Unreliable and relevant
4. Unreliable and irrelevant
5. Of unclear reliability and/or relevance
6. Non-existent

Obviously we don't want links of types 2, 4 and 6, however we definitely do want links of type 1. Types 3 and 5 are sometimes good and sometimes bad, depending on the context (for example an unreliable source is often a useful way to locate a reliable source or determine the plausibility of given claim). A blanket disallow would prevent additions we do want as well as those we don't. Thryduulf (talk) 19:48, 26 January 2026 (UTC)

Wikipedia's servers (and its JS) has no access to cookies from other sites, unless the WMF would convince chatbot sites to make requests to Wikipedia in order for us to set the cookies.

Having an edit filter warn (maybe warn maybe block but then have instructions about how to remove the tracking params) and link to whatever our best at the time policy related to LLM use might have some advantages. Not to be "scary" but to inform. Although I do admit the few times I recall accidentally trying to save an edit with a blacklisted URL I got a bit of a fright. Skynxnex (talk) 21:29, 26 January 2026 (UTC)

Yes, I've run into URL blacklisting issues a few times in discussions and it's frustrating and disruptive. I wouldn't be surprised if it results in lost edits (I know this is tracked for some things, but I don't know if it is for this - WhatamIdoing is often knowledgeable about stuff like this). If so it is likely that something related to LLMs would also result in lost edits - for some edits that wouldn't be a significant loss to the project, but for others it absolutely would be. Thryduulf (talk) 21:45, 26 January 2026 (UTC)

What the abuse filter looked like yesterday

Yes, pretty much any interruption at all loses edits, and "scary" interruptions like blacklist and abuse filter triggers lose a lot of edits (including some that we want to be discarded). This is hardly surprising.

In fact, I've been meaning to ping @PPelberg (WMF) and ask him whether they've done anything to the save dialog in mw:Extension:VisualEditor recently, because what you can see in this screenshot from about 12 hours ago is not helpful. I'd guess that even most experienced editors would struggle to understand what's going on here.

I've also run into a problem for the last two weeks with saving without an edit summary produces an error message (I have "Prompt me when entering a blank edit summary (or the default undo summary)" enabled in Special:Preferences#mw-prefsection-editing-editor, but this is a different "Something went wrong" generic error message). WhatamIdoing (talk) 22:01, 26 January 2026 (UTC)

I'd be less annoyed by the blacklist filter if the notice was actually small enough to read in its entirety. Cremastra (talk · contribs) 23:39, 29 January 2026 (UTC)

(Note: I had this comment drafted before the above one by Skynxnex.) Please clarify on what you mean by cookies from llm services. While on certain websites it is possible to identify if a user is logged in using tricks with images, random websites (like wikipedia.org) cannot just steal cookies from other sites (like chatgpt.com, claude.ai), and using the image method (if even possible) would be a HUGE privacy violation, outweighing any benefit earned from identifying potential LLM users, not to mention false positives (just because someone is logged in to ChatGPT doesn't mean they will use it on-wiki). As for the ?utm_source=chatgpt.com "referral links", someone could just be using an LLM to search for sources but not to write any of the actual content. OutsideNormality (talk) 22:31, 26 January 2026 (UTC)

Wouldn't Wikipedia get into legal problems if it started messing with other pages' cookies? Cambalachero (talk) 02:38, 28 January 2026 (UTC)

Wikipedia cannot on a technical level interfere with other site cookies. It is possible, similar to ad servers, have cooperative methods to track users across sites. Firefox (and to a lesser extent Chrome), and other browsers, block many attempts however. Skynxnex (talk) 03:50, 28 January 2026 (UTC)

Browsers only send cookies back to servers in the same domain as the server who originally created the cookie. So Wikipedia servers will never see the cookies from other sites. isaacl (talk) 04:16, 28 January 2026 (UTC)

replacement symbols

what im saying is there could be a option in settings where you could remap certain text actions to other symbols, ot wouldn't literally make the symbols act like the normal counterparts, just replace them when you use them, for example, you could remap the template function from {{ to { but in source, it would still be {{, its just that all instances of { are replaced with {{, of course, this would only work on visual editor, nor source editor, by default it has the regular wikitext markup symbols we have now Misterpotatoman (talk) 20:38, 26 January 2026 (UTC)

This is feasible in a user script, but UI designers who remember the 1990s would tell you that it's probably a bad idea. A lot of people thought that single-character "commands" were great, until the commands started executing whenever the person bumped a key, typed the wrong one, thought they were in a different window, etc.

If you want to poke around with it, then you might start by looking at mw:VisualEditor/Gadgets/Creating a custom command. WhatamIdoing (talk) 22:05, 26 January 2026 (UTC)

what Wagon fossil gala (talk) 21:49, 27 January 2026 (UTC)

Note you can use the keyboard shortcut mechanism supported by your device's operating system (or use a third-party program). However it would probably apply across all apps, or at best, within one app, so it wouldn't distinguish between Visual Editor and the source editor. isaacl (talk) 02:45, 28 January 2026 (UTC)

What if some articles could add a comment section?

Like for example, what if an article on a fiction book or series could be commented on by people who feel like the article is missing something? Any thoughts if this is unreasonable? — Preceding unsigned comment added by ~2026-57372-0 (talk) 21:14, 27 January 2026 (UTC)

All articles have a talk page. Phil Bridger (talk) 21:26, 27 January 2026 (UTC)

This is what a talk page is for. EatingCarBatteries _{(contribs | talk)} 00:46, 28 January 2026 (UTC)

Entertaining this idea a bit, it could be nice to make a place that served as a forum for some topics, as talk pages are NOT a forum. Honestly makes it hard to collaborate when you can't shoot the shit with other editors. There are some unofficial places for Wikipedia in general, like Discord or Reddit, but "You will never find a more wretched hive of scum and villainy." GeogSage ^{(⚔Chat?⚔)} 02:13, 28 January 2026 (UTC)

I do get it, but the #1 issue with "forum pages" is moderation. There won't be WMF content moderators, it'll be Wikipedians. It's just gonna spiral into being a Facebook comment section. I think if a feature like this were to be implemented, it would have to be turned on for uncontroversial pages.

Here are some examples of pages that shouldn't be allowed to have these pages:

• BLPs and recent deaths
• Anything subject to WP:ARBCOM measures, broadly construed
• Anything relating to race, ethnicity, sexual orientation, disability, etc.
• Top-level country pages (i.e. USA, Pakistan, D.R. Congo) and their relations
• etc.

Also, it violates neutrality. By allowing anyone to talk about the topic of the article and shove their own (often bad) opinions on the subject, Wikipedia will shift away from being a neutral encyclopedia.

TLDR: It might be cool, but it's not worth the effort for a volunteer community to set up and moderate for civility. even trillion dollar companies struggle doing it. EatingCarBatteries _{(contribs | talk)} 02:31, 28 January 2026 (UTC)

yeah, comment sections are at odds with our purpose as an encyclopedia User:Bluethricecreamman (Talk·Contribs) 02:35, 28 January 2026 (UTC)

Wikinews has a separate comments section. It does not attract many comments, but Wikinews gets many, many fewer readers. WhatamIdoing (talk) 02:59, 28 January 2026 (UTC)

Maybe the relevant Wikiprojects could host a metaphorical "water cooler" if appropriate. That said, with a few exceptions, I find the participation in Wikiprojects a bit disappointing. There isn't much collaboration, and when new people stop by to find people they are often met with silence. GeogSage ^{(⚔Chat?⚔)} 03:43, 28 January 2026 (UTC)

Wikiproject talk pages are often used to discuss broader topics within the remit of the project, but even there I think such discussions need to be about improving the encyclopedia. As others have mentioned, there are plenty of other venues on the web for general discussions about topics. As for your last complaint, while many projects have low participation, others still have useful discussions. I participate at Wikipedia talk:WikiProject Indigenous peoples of North America, Wikipedia talk:WikiProject Archaeology, and Wikipedia talk:WikiProject Tree of Life, and am aware of other active projects. Donald Albury 14:16, 28 January 2026 (UTC)

I know there are exceptions, but a lot of them feel pretty dead. Wikipedia:WikiProject Geography and Wikipedia:WikiProject Maps are the two I'm most familiar with, and unfortunately they have been fairly dead. I've tried to find collaborators on articles there, and yet to really get anyone to help. I've seen a lot of other topic specific projects like this. GeogSage ^{(⚔Chat?⚔)} 17:05, 28 January 2026 (UTC)

Article talkpages can be used to suggest improvements to a WP-article. If it's not about that, places like Reddit are available. Gråbergs Gråa Sång (talk) 07:50, 28 January 2026 (UTC)

controversial pages Misterpotatoman (talk) 19:54, 2 February 2026 (UTC)

Signer The News

Wikipedia should have a place to make humorous essays (Signer the News). With gamification and a user analytics dashboard. Gamification with points and badges. Goal - to teach new users to make articles soon. Signer made articles will have the humor tag by default. Does this sound like a good idea. Wagon fossil gala (talk) 21:48, 27 January 2026 (UTC)

The problem it solves : Low newcomer retention Wagon fossil gala (talk) 21:49, 27 January 2026 (UTC)

Are you thinking that this would teach new users how to edit (e.g., to make links or italics)? I don't think it would do much for teaching them about notability, sourcing, and neutrality. WhatamIdoing (talk) 03:01, 28 January 2026 (UTC)

from what I understand, you are suggesting a non serious tutorial, like how to add images or even something as simple as switching modes at the first test, i support of this! pretty much every editor has the same questions at the beginning and it would take alot of work off mentors, there are also alot of rules and things outside of how to write like what to write and not, when to and not link and cite, how to upload images and what belongs on other wikis, id imagine direct instructions and not actually writing your own things because then someone would have to grade them then Misterpotatoman (talk) 19:52, 2 February 2026 (UTC)

Repetitive editors

Do we have rules or policies for editors who systematically do the same thing repetitively? Like changing which/that or killed/murder or any number of examples. Like splitting/merging paragraphs. They are some of the most irritating editors. Some are banned and they never go away turning into decades-long zombie LTA cases. They start out in good faith, become true believers, irritate the hell of everyone, get banned, and keep coming back with socks and IPs. There should be some kind of rule that can quickly stop it. Call it WP:REPETITIVE, a noticeboard where the community can discuss cases brought there. This often comes up at ANI, but usually not until they have already caused a lot of disruption. Repetitive editing is neary the same as bots, which have strong regulations. Human editors doing the same have no checks, except ANI which is inconsistent and difficult. -- GreenC 04:20, 28 January 2026 (UTC)

Are you talking about stuff like that one issue with the mass changing of BLP's places of birth from "Estonia" to "Estonian SSR, Soviet Union"

I mean, those kind of editors are textbook WP:DISRUPTIVE editors. I think exact scenario might specifically warrant a section in here.

Disruptive editing is a pattern of editing that disrupts progress toward improving an article or building the encyclopedia. This may extend over a long time on many articles.

Depending on the case, it could fall under WP:TENDENTIOUS (essay of WP:DISRUPTIVE)

Tendentious editing is a pattern of editing that is partisan, biased, skewed, and does not maintain an editorially neutral point of view. It may also involve repeated attempts to insert or delete content in the face of the objections of several other editors, or behavior that tends to frustrate proper editorial processes and discussions. This is more than just an isolated edit or comment that was badly thought out.

EatingCarBatteries _{(contribs | talk)} 05:07, 28 January 2026 (UTC)

Some of these might fall under WP:MEATBOT and require permission in advance. However, some of these are helpful edits, even if you don't like seeing the change happen. For example, people who change which to that for restrictive clauses in American English articles are doing a good thing and should be encouraged. Small improvements are still improvements. WhatamIdoing (talk) 20:36, 2 February 2026 (UTC)

Return to IP editing

wp:deny The following discussion has been closed. Please do not modify it.

Can we tell WMF to return to IP editing and discontinue TA editing? How is this a good idea of TAs replacing IPs? ~2026-64012-0 (talk) 19:50, 29 January 2026 (UTC)

TAs are intended to enhance privacy. Please see WP:TA for a fuller explanation. 331dot (talk) 21:33, 29 January 2026 (UTC)

reported as a ChronicleBooks885 sock. Meters (talk) 21:41, 29 January 2026 (UTC)

I like TAs because IPs are becoming increasingly arbitrary and non-static anyways. Aaron Liu (talk) 21:41, 29 January 2026 (UTC)

We could ask the WMF, but we can't tell them. The chances of them saying "yes" if we did ask are extremely low for all sorts of good reasons, including those mentioned by 331dot and Aaron Liu. Thryduulf (talk) 21:49, 29 January 2026 (UTC)

Named Preference Sets ("Editor Profiles") for Task Switching & Accessibility

The Problem: Currently, MediaWiki preferences are monolithic. If you want to switch between different editing tasks — for example, from patrolling recent changes (which might use the Vector legacy skin, Twinkle, and specific watchlist settings) to writing a new article (which might use Vector 2022, the VisualEditor, and a distraction-free gadget setup)— you have to manually change multiple settings across several tabs in Special:Preferences. This is time-consuming and creates friction for task-based editing.

More importantly, this system creates barriers for:

1. New editors, who face analysis paralysis with dozens of complex options. An option could be created called New Editor

2. Neurodivergent editors (e.g., those with Asperger's, ADHD, or sensory sensitivities), who benefit greatly from predictable, customized interfaces and the ability to switch contexts with minimal executive function load.

3. Change - My analysis of why UX and UI changes fail to get community support, because is because it is imposed on wikipedians, rather than giving them an option, or differentiating between the needs of editors and readers.

4. New preference options are not used - Dev creates new options, but because they aren't known, people don't add them to preferences. An option could be to create a preference set - called early adopter

5. The experienced editor case above. Wakelamp (talk) d[@-@]b 08:11, 2 February 2026 (UTC)

i approve of this idea! Misterpotatoman (talk) 19:43, 2 February 2026 (UTC)

I wonder whether this could be done via user script. WhatamIdoing (talk) 20:37, 2 February 2026 (UTC)

I think it could - scripts can change settings, can't they? It just needs someone knowledgeable to write it. Phil Bridger (talk) 09:38, 3 February 2026 (UTC)

A script would be a great way of trying it out, but if it was done as a script would it be able to address the cases above? (have added 5 above for experienced editors). I was also hoping that there could be a way of sharing profiles. Wakelamp (talk) d[@-@]b 10:25, 3 February 2026 (UTC)

addition of favorite pages

almost all the pages on my watchlist, i dont actually add to because i want to watch them, but because i want a easy way to access them and remember them, so i propose favorites, specifically for pages you want to remember, plus, a average user of wikipedia probably only uses it for checking pages, they may have a particular or multiple pages they need to a easy way to access, for example, a person might need to write something on topic like color theory, they could add it to their favorites and not their watchlist as they have no plans to edit it Misterpotatoman (talk) 19:41, 2 February 2026 (UTC)

Fortunately, the WMF’s developers are actually working on adding such a feature (though personally I don’t like that they’ve opted to move the watchlist icon into the Tools menu to do so).  novov talk edits 20:02, 2 February 2026 (UTC)

I do have to wonder why they're reinventing bookmarks. Anomie⚔ 00:21, 3 February 2026 (UTC)

a addition of a blogs to wikipedia

by what i mean is articles you can create with no strict laws of how and what to write and what needs sourcing, there would be no quality standard, blogs would show up below the search results when you search up, for example you can make a blog about your favorite but niche topic that cant happen because its actually apart of another topic, or just make a list you want to share, i would add a absolutely massive amount of content and user accessibility, having something users can actually do other than editing thats not serious, i say theres a separate button to browse only blogs Misterpotatoman (talk) 09:20, 3 February 2026 (UTC)

There are plenty of sites that do what you want. Why do you feel that it's appropriate for an encyclopedia to have blogs? Phil Bridger (talk) 09:27, 3 February 2026 (UTC)

@Misterpotatoman can you clarify your idea a bit further. I think having a shared blogs (what editors are working on now) as part of a project could be interesting and build community, especially if we could somehow grab project members edit summaries to do with articles that are part of the project Not certain about on article as we try and avoid diverting people, but diverting high conflict editors from protected pages could be good.. (With fun, I find wiki meetups and pages to do with Wikipedia on FB and Reddit and mastadon helped.)