Theproposals section of thevillage pump is used to offer specific changes for discussion.Before submitting:
Check to see whether your proposal is already described atPerennial proposals. You may also wish to search theFAQ.
This page is forconcrete, actionable proposals. Consider developing earlier-stage proposals atVillage pump (idea lab).
This is a high-visibility page intended for proposals with significant impact. Proposals thataffect only a single page or small group of pages should be held at a correspondingtalk page.
to celebrate wikipedia's 25th anniversary, a toggleable "birthday mode" has been created. it consists of easter eggs involvingbaby globe, such as having it scroll a phone in the top right of an article while the reader scrolls down an article. more details can be found on the linked page. if the feature is enabled, by26 january, administrators can configure the mode throughcommunity configuration; and the mode will be public from16 february to16 march (an administrator will have to turn on the feature on the day itself).
enabling the feature requires "a consensus from your community", so i have brought it here to ascertain the community consensus. (there was some previous discussion onWikipedia:Village pump (miscellaneous)/Archive 86 § Easter eggs, but it was archived without further action.)
should english wikipedia enable the 25th anniversary birthday mode, and if so, should it be on by default?
option 1: enable birthday mode, and have it on by default
option 2: enable birthday mode, and have it off by default
Hello everyone :) Since this discussion is still ongoing, I wanted to share a fairly big update we are making to how the feature will work. Please check it outon the project meta-wiki page. The main change that’s relevant to previous conversations I’ve had here, is on how we solve for where Baby Globe shows up.
The new plan is to limited Baby Globe to 2500 articles, instead of having Neutral Baby Globe showing up all the time. Each of the 2500 articles will show one of the “special” versions, for example:Confetti,Balloon,Synthesizer,Camera,Headphones,Space. This makes the feature more manageable from a technical perspective. It also means when you find Baby Globe, it will feel more like an easter egg. Please let me know if you’ve got questions! If you decide to enable the feature, let us know on theproject talk page.CDekock-WMF (talk)19:29, 12 February 2026 (UTC)[reply]
option 1 >option 2,oppose option 3. i think it would be a shame if the largest wikipedia did not participate in the celebration. i'd also prefer it to be on by default, as people generally don't change default settings, but i'm fine either way.ltbdl (skirt)19:19, 17 January 2026 (UTC)[reply]
Supportoption 1 >option 2,oppose option 3 per ltbdl. This is an excellent feature that our readers will hopefully enjoy. It also fits nicely with one of our goals in recent times, which has been to emphasize the human aspect of Wikipedia.Toadspike[Talk]20:41, 17 January 2026 (UTC)[reply]
Option 2 Per Thilio. Suggest that greater consideration be given to limits on the number of top-of-page distractions we allow. I also wouldn't mind a shorter period.--Wehwalt (talk)21:10, 17 January 2026 (UTC)[reply]
Second choice is 3. I feel the case can be made that we're being very self indulgent in patting ourselves on the back in ways that do not benefit the reader.Wehwalt (talk)15:17, 19 January 2026 (UTC)[reply]
Option 1 Agree with Chaotic Enby that this is contingent on having a readily available (and known--e.g., included in banner announcement of easter eggs) method to disable. — rsjaffe🗣️21:13, 17 January 2026 (UTC)[reply]
Option 1 let's have fun for once, 25 year anniversaries don't happen very often. Yes it's quirky, correct some people won't like it, but this is only temporary. Let's celebrate in style and get noticed for it.CNC (talk)20:09, 18 January 2026 (UTC)[reply]
Option 3 unless we have a lot more information. I wouldn't like to see a confetti-throwing Wikimedia globe appear on the page for some disaster- or genocide-related page with massive viewer numbers. The linked Wikimedia page doesn't inform me sufficiently about what to expect.Fram (talk)10:32, 19 January 2026 (UTC)[reply]
option 1, it's toggleable by the user and doesn't affect the actual contents of the page (thinking back to the grimace mcdonald's wiki incident)Jaidenstar (talk)17:43, 19 January 2026 (UTC)[reply]
option 1. No one will notice it if it's not on by default. And Baby Globe is great. It would be a shame not to participate in the birthday celebrations. --asilvering (talk)04:27, 24 January 2026 (UTC)[reply]
Option 1 – I was hesitating due to the concerns that Fram raised, but now that @CDekock-WMF has shared the table of different page queries and configurations, I feel reassured that a lot of thought has gone into context-aware presentation of the mascot.ClaudineChionh(she/her ·talk ·email ·global)22:45, 19 January 2026 (UTC)[reply]
Option 1 - Like Fram, I had some concerns about showing a celebratory globe on pages for horrific actions, but I am confident in the solution provided by the Foundation for that. So, yeah, after 25 years I think we can celebrate for a bit.LightlySeared (talk)12:21, 20 January 2026 (UTC)[reply]
Option 2 - it's very cute and fun, but I think it's more of a clever Easter egg when it'snot available by default -- Easter eggs are by definition hidden. I think it would likely become more popular and talked about if it's "a cool special feature to add" versus "some thing Wikipedia put on pages." People like having agency. Option 1 is my second choice.✨ΩmegaMantis✨(they/them)❦blather |☞spy on me 17:50, 20 January 2026 (UTC)Option 1 now that they say that it will only be on a limited amount of pages, I think it will be a clever Easter egg then as there is agency to find the pages.✨ΩmegaMantis✨(he/him)❦blather |☞spy on me20:53, 12 February 2026 (UTC)[reply]
Option 1 - per above.Option 2 - I'm unsure how this would affect printable versions and whatnot, so I would prefer if it was disabled by default. (It would make it more of an Easter egg as well, per ObserveOwl.) The Wikidata configuration shared above is useful. Also, it's been 25 years, so why not?Jude Halleytalk/contribs13:18, 21 January 2026 (UTC)[reply]
Option 2 Please, please don't put animated stuff on pages by default; it's distracting and makes it much harder for me to focus on the content that I am trying to read. Thanks. --David10244 (talk)05:48, 22 January 2026 (UTC)[reply]
Option 2. I'd suggest send a notification to users on the website to indicate its now available, or an email, albeit some editors don't link their account to their email.Inpops (talk)17:11, 28 January 2026 (UTC)[reply]
Option 2: Color and especially movement are distracting and annoying, and the described month-long persistence of the annoyance is beyond the pale. — BarrelProof (talk)01:38, 27 January 2026 (UTC)[reply]
Option 1: While I wouldn't mind Option 2, I personally would prefer Option 1, especially since the OG should have it defaulted.F1fan00 (talk)09:44, 28 January 2026 (UTC)[reply]
Option 1 (strong option 1) - We can always use more reasons for the public to feel warm and fuzzy and Wikipedia, and this does exactly that. This is a serious project, but it's also a fun project, and written by volunteers. Letting people have a glimpse of that fun --reminding people that this can be a silly place -- has value. Just look at the resonance ofDepths of Wikipedia, for example. Do it, and deal with issues as they arise. I say this as someone who has been critical of our April Fools antics in the past. Unlike that (or rather, unlike the way thatused to be), if you look at thepage linked at the top, there are already provisions in place to consider context and set limits for e.g. the confetti globe. Deal with any issues as they come on a case-by-case basis (I'm sure people will let us know if something unintended happens). —Rhododendritestalk \\17:13, 28 January 2026 (UTC)[reply]
Option 1 orOption 2. An opt-in process means that very, very few people will end up getting the celebration at all. We can always fine-tune after launching if there are issues, but my preference is to get it up-and-running first.ThadeusOfNazereth(he/him)Talk to Me!13:03, 30 January 2026 (UTC)[reply]
SupportOption 1, oppose Option 3. Easter eggs (in computing, not the literal sense) should be surprises, and having to opt into that kinda kills it.Chlod (say hi!)06:01, 8 February 2026 (UTC)[reply]
Option 1 – It's so cute and I absolutely love it. Strongly oppose options 2 and 3, as very few readers will know to opt-in, and to not enable it at all would be frankly cruel.Pretzel Quetzal (talk)17:42, 8 February 2026 (UTC)[reply]
Option 2 on theapparent specific proposal to have a large animated character locked into the right-hand border of every (?) article on Wikipedia, remaining visible as the user scrolls down through it - and if it's an article about something terrible like genocide or war or a breaking news death, the character will still be there buthave a blank expression. Something that's visible to everybody by default is not an easter egg! If the character was opt-in (or implemented more subtly so that it only became visible if you knew, for example, to click on the article title or to look at the very footer of the page), people would enjoy knowing and sharing that secret. --Belbury (talk) 18:11, 12 February 2026 (UTC) Retracting my view on this, the plan wasrecently updated to limit the cartoon to "2500 [articles] per language Wikipedia" rather than putting it on every article and having a special neutral cartoon for bleak subjects. --Belbury (talk)14:34, 16 February 2026 (UTC)[reply]
Option 1>2>3 — and quickly, too! Time is fast running out. Agree with others that if this was an opt-in feature, not many would even notice it. However, I also acknowledge that it may be a bit bothersome to others.Loytra✨09:49, 17 February 2026 (UTC)[reply]
25 icon/, if we are going to have the easter egg, then having the 25 icon provides some context as to its possible meaning. If we switch back to the old globe, it is less clear that the easter egg is a temporary feature, or that it is relevant to a particular event. Further, switching one 25th anniversary element out while swapping another one in may create similar confusion regarding the easter egg's meaning. Conversely, both expiring at the same time makes it clear Wikipedia is back to 'normal'.CMD (talk)05:43, 13 February 2026 (UTC)[reply]
Closer can consider my !vote neutral on the rest of the year proposal below, my goal is to maintain the context for the easter egg if the easter egg is implemented, and extending the logo to the end of the Wikipedia year would do this.CMD (talk)03:35, 16 February 2026 (UTC)[reply]
Just reread the proposal and realised that the 25th globe is only in use on legacy vector. Explains why I have yet to see it. Ah well :(Loytra✨09:55, 17 February 2026 (UTC)[reply]
Looking atthe documentation, it looks like it will be pretty accessible (pop-up) on mobile, while V22 desktop users will have it in their configuration panel – not exactly hidden, but not the most accessible for new users unfamiliar with the interface.
Regarding distractions, we have several articles with GIFs near the top of the page. Ones you'd expect, likeChronophotography, but also ones you may not, likeSwing bridge andPanenka. Those GIFs can't be stopped by the average reader – at least, I wouldn't know how – which is in stark contrast to the cute puzzle globe, which looks like it can be disabled with one or two well-advertised button presses.Toadspike[Talk]21:09, 18 January 2026 (UTC)[reply]
As a reader, the GIFs do distract me from the text. For me, the value they add by illustrating the concept better than a static image justifies the distraction, but it's silly to say there is no distraction.Toadspike[Talk]15:52, 23 January 2026 (UTC)[reply]
Comment. Some thoughts:
Like Fram, I am also concerned that cute(they are) easter eggs will show on serious articles.
If we want to enable the easter eggs by default, then we need to accept that they will show on serious articles or we need to filter which articles they show on. Aside from the scale needed for it, the second option also might go against the community sentiment that Wikipedia is not censored.
Do we know which extension this is linked to? If so, we could raise a patch/file a bug and/or read the code to figure out if there are safeguards against this.Sohom (talk)11:43, 19 January 2026 (UTC)[reply]
Oh this isExtension:WP25EasterEggs, taking a look at the code it is extremely configurable! We can enable it for a specific set of pages, or enable it globally and not show it for a specific set of page and all of that is configurable through CommunityConfiguration (read through a on-wiki JSON file).Sohom (talk)12:05, 19 January 2026 (UTC)[reply]
Good job finding it! My concern is that, if we enable it globally, we need to check most en.WP pages if they should be excluded.Excluding categories may help, but I remember an argument against actual policy proposals like inappropriate-image blurring that also apply here: categories are imprecise in a lot of ways (the first thing in my search about it isThryduulf's 2024-11-06T11:57:00). If we will do categories regardless of that, you will still need to vet which categories are included or not.LightNightLights (talk •contribs)12:24, 19 January 2026 (UTC)[reply]
Pretty much every pick for which pages will have it disabled or not will be extremely controversial, and more worryingly could be used as precedent for future "hiding" tools, so I don't think that's something we should go through. Going deeper than straightforward things like "have it enabled on the Main Page" and "have it enabled/disabled on X namespace" opens up a massive can of worms.ChaoticEnby (talk ·contribs)12:37, 19 January 2026 (UTC)[reply]
This has nothing to do with NOTCENSORED though. We are not here to deliberately cause offence with unencyclopedic content either. Displaying these easter eggs or not doesn't change the contents of the encyclopedia.Fram (talk)14:01, 19 January 2026 (UTC)[reply]
I doubt "deliberately" is the best way to put it. It doesn't change the contents directly, but does leave us with a list of "acceptable pages" and "controversial pages", which can absolutely be used as a precedent for making some "controversial" material less visible/prominent.ChaoticEnby (talk ·contribs)14:03, 19 January 2026 (UTC)[reply]
Wouldn't like such a list either, which means this can go on the Main Page or perhaps on user pages but should stay out of the articles in general (with what we now know of what kind of easter eggs we may expect). Perhaps my opinion would change with more info, at the moment it feels too much like writing a blanco cheque.Fram (talk)14:22, 19 January 2026 (UTC)[reply]
A reader choosing to look at a potentially offensive article does not change the fact that Wikipedia is 25 years old now and we are celebrating that. These are entirely unrelated.Toadspike[Talk]14:39, 19 January 2026 (UTC)[reply]
Not if you display them on the same page, in ways so far unknown. A reader looking in mid-March to our article "US invasion of Greenland" may well be completely unaware that Wikipedia was 25 years old a few months before and that the rightside image is displayed forthat reason and not to celebrate the invasion.Fram (talk)14:50, 19 January 2026 (UTC)[reply]
In my opinion, this is why we should make it clear (e.g. with a banner) that this easter egg is to celebrate Wikipedia's birthday. Incidentally, this also solves the "make it easy to turn off" problem.ChaoticEnby (talk ·contribs)15:02, 19 January 2026 (UTC)[reply]
Your idea sounds good. Maybe we should have text below the globe mascot images in the lines of "Celebrating English Wikipedia's 25th birthday"? It does not suffer frombanner blindness and will always appear alongside the cute images, but does not solve the turn-off problem.LightNightLights (talk •contribs)15:27, 19 January 2026 (UTC)[reply]
That could work! Either that, or making the banner very obviously birthday-themed so readers don't have to actually read the words to understand the context behind it all. Or both!ChaoticEnby (talk ·contribs)15:34, 19 January 2026 (UTC)[reply]
id say, put below the globe thing, put in the normal size, 'Wiki 25', then below in a smaller font, put '25 Years of the Free Encyclopedia', or something along those linesF1fan00 (talk)10:03, 28 January 2026 (UTC)[reply]
Based on what is already implemented, tThere is going to be a relatively large toggle on the sidebar every page (similar to the dark mode one) that says "birthday mode" but yes, also CE's idea is not a bad idea.Sohom (talk)15:14, 19 January 2026 (UTC)[reply]
Maybe the "Birthday mode" toggles should be shown above the old ones so that people will see a) most likely see the new ones first, and b) most likely see that something was added in the options menu.LightNightLights (talk •contribs)15:33, 19 January 2026 (UTC)[reply]
Hello :) My name's Corli and I'm working on this project and want to share a bit more context on how we've tried to solve thisvery tricky problem of "which articles gets which version of Baby Globe?"
We also concluded that trying to make a "disable" list would be extremely difficult (if not impossible!) to do, especially because what we're building needs to work across all language Wikipedias. So we created aversion of Baby Globe that appears "neutral". They don't do much, they stand around, blink and look cute. This version can then show up on pretty much any page and not imply anything particularly positive or negative.
By comparison, the versions that are overtly celebratory (like the confetti one) can be configured to show up on overtly celebratory things (people also turning 25 this year, all “cakes”). This is done using mostly Wikidata items, you can see afirst version of this here, which we will be updating with all the versions of Baby Globe later this week.
The configuration setup allows Baby Globe to be configured by each opted in language edition to be blocked on specific pages defined in community configuration (eg. define specific pages where no instance of Baby Globe will appear, not even its default neutral state). So you can very easily override and adjust thisdefault setup.
The longer story is that there are 14 different versions arranged along a spectrum of sorts from very neutral to outright celebratory. You can get a sense for them inthe table, which this week we'll update with the actual gifs so you can properly see the vibe :) These can all be individually turned on / off and customised to appear ornot appear on specific articles.CDekock-WMF (talk)16:21, 19 January 2026 (UTC)[reply]
I want to explicitly mention that I think there is a sentiment among editors that Wikipedia is not censoredoutside of NOTCENSORED, so I avoided saying "NOTCENSORED" at my original comment.LightNightLights (talk •contribs)14:19, 19 January 2026 (UTC)[reply]
Comment #2. Some more thoughts:
If we decide to hide it by default (option 2), I think a lot of people will not enable it. This may be bad because it would mean that we did not utilise someone's work to the fullest reasonable extent, but may also be good because we probably should not shove it in our readers' faces.
If it's hidden by default, then we might want to run "opt-in now!" messages, and that might be more annoying than just having it visible.
I don't find the "but what if someone's reading serious content?!" argument to be very compelling. AFAICT Google doesn't suppress theGoogle Doodle if you search for a "serious" subject. I've never seen anyone saying "I was searching for information on how to plan my aunt's funeral, and Google posted a celebratory logo. How dare they!" Have you? And if you haven't, why would you expect readers to accept Google's celebratory logo but not Wikipedia's?WhatamIdoing (talk)02:26, 25 January 2026 (UTC)[reply]
If it's hidden by default, then we might want to run "opt-in now!" messages, and that might be more annoying than just having it visible. that's absolutely right. What if we configure a default display timer of five minutes? For example, the baby globe would appear on readers’ screens for a maximum of five minutes and then automatically disappear... If a reader closes the browser session and later reopens it, the baby globe would be displayed again for five minutes before disappearing. CONFUSED SPIRIT(Thilio).Talk05:22, 25 January 2026 (UTC)[reply]
Today's Google Doodle is about Winter Olympics, a Google logo but the Os are replaced with a puck and a hockey stick, a funny thing. It still appears as that when I searched about "holocaust" and about "Putin invasion". Both are very serious issue and Google is not changing their look for such matter.✠SunDawn ✠Contact me!16:00, 7 February 2026 (UTC)[reply]
Am I understanding theproposed implementation correctly, that as a reader scrolled down through the text-heavy sections of a genocide article, they would have a 125x125pxFile:Neutral Baby Globe.gif remaining constantly visible in the right-hand margin, looking from side to side and blinking? That would be a lot more prominent than Google's modification to their top-of-screen logo.Belbury (talk)18:54, 12 February 2026 (UTC)[reply]
It turns out theyupdated the plan on the 12th to say that they've decided toLimit the amount of QIDs to 2500 per language Wikipedia and remove the “neutral” Baby Globe that would have shown up on all non-configured pages, so genocide articles won't have a cartoon character at all.Belbury (talk)14:41, 16 February 2026 (UTC)[reply]
Question I assume this would not be available on classic vector? If so, that would be a shame, considering I've strongly preferred classic Vector's enumeration of a page's table of contents and am unwilling to temporarily switch to Vector 22 to experience the joy of birthday mode, but I understand.DrewieStewie (talk)21:02, 26 January 2026 (UTC)[reply]
This is not the most pressing inquiry for resolving the technical implementation of this feature, but can someone explain to me why a baby was chosen as the mascot to celebrate the project having reached the milestone of 25 years--it seems peculiar to me, if not outright counter intuitive, given that, if you are going to anthropomorphize such an abstract condition, 25 would normally be an age that one might reasonable associate with coming into full adulthood? What am I missing here? If it's not obvious to me after having been with the project for roughly 2/3's of that period, I can't imagine it's any more intuitive for our average reader. Am I overthinking this--was it just an organic selection of the most obvious cutsy mascot that could be adapted from the movement logo?SnowRise let's rap00:27, 31 January 2026 (UTC)[reply]
It's not a baby it's aplushie, which doesn't denote age or lifespan. Despite it's anthropomorphic appearance, as is common with these toys, plushie's aren't the embodiments of humans so I'm not seeing the issue. If it were agreenland shark, at 25 years of age it would still be considered a juvinelle (and shark plushies are quite popular btw). So plushies cansymbolically live for upto hundreds of years, thus 25 shouldn't be measured anthropocentrically, even if WP is indeed anthropocentric.CNC (talk)09:19, 31 January 2026 (UTC)[reply]
Well, I never regarded it as an "issue" so much as a peculiar choice. But I've since found an interview with the artist of the original graphic which clarifies that the unnamed design came first, and people just started calling it "Baby Globe" organically after the fact. I still think this makes for a curious mascot to celebrate this particular threshold, but certainly a curiosity of a "meh" level of significance.SnowRise let's rap07:50, 1 February 2026 (UTC)[reply]
As we got the 25 globe up earlier, this proposal is out of sync with the timing of the globe running, which is nearing completion. Without prejudging consensus here, I would like to suggest that if the above proposal passes for its 16 February to 16 March timing, that we maintain the 25 globe as well until 16 March (or whatever end time is determined). This provides at least one obvious visual suggestion for why the easter egg is there. PingingChlod who is working on the Phab for the globe logo switchback.CMD (talk)05:46, 8 February 2026 (UTC)[reply]
As this needs clear consensus, I've opened a formal sub-poll above. Given the previous consensus was 3 editors, hopefully this should be a simple clarification.CMD (talk)05:54, 13 February 2026 (UTC)[reply]
Support as proposer: WP:Close is an information page that well-documents current community practice with the level-of-detail one'd expect from a guideline, with the exception of the "Closing procedure" section mostly of uncontroversial technical details, but it's not unheard of for guideline pages to include such sections either (e.g.Wikipedia:Signatures#Dealing with unsigned comments). Despite the widespread practice of consensus being the counted supermajority when arguments are of equal weight, this determination is only documented in essays and this information page (If the discussion shows that some people think one policy is controlling, and some another, [...]). An experienced editor in a discussion I closed a few months ago pointed this out to me and thus argued my close should've said "no consensus" instead as a small number of participants !voted oppose. The increased visibility of this page as a guideline would reduce the amount of editors (including newcomers) who aren't caught up on our closing standards.It is my opinion that the practices documented in this information reflect the current community standard, and the situation I mentioned above marks a need for such practices to be included in guidelines.Aaron Liu (talk) (timestamp omitted deliberately to improve thepermanent discussion link)
To address concerns of Creep/excessive rulemaking: Creep-avoidance's purpose is tokeep Wikipedia policy and guideline pages easy to understand, but currently we have absolutely no guidelines on how consensus is determined from a discussion, saveoverall concurrence.Wikipedia:Consensus#In talk pages is worthy of mention as it does list some qualities to weigh for arguments, but it doesn't mention critical things like how arguments of equal weight are compared numerically and when discussions should be closed.(Other thanWP:ROUGHCONSENSUS, which misleadingly lives onWikipedia:Deletion guidelines for administrators—it is outdated to imply these standards only apply to deletion. It should live on a dedicated page to increase visibility and reduce the overlapping maintenance work needed, and WP:Close is pretty much what it says.)As opposed to WP:Snow and the much more redundant WP:Poll, I think this is something newcomers need to read like the other major guidelines. I don't see these things mentioned anywhere else, and I feel like things so normative should be mentioned in our PaG, accessibly, as Creep intends.Aaron Liu (talk)21:23, 9 February 2026 (UTC)[reply]
Support per Aaron Liu. I've long found this a useful guide and personally never had it questioned asonly an info page, but I can see the issue of it not being an official guideline as an issue, especially given it's the guidelines that closers follow. It might be worth considering some other pages in this area for review and promoting;Wikipedia:Non-admin closure (widely accepted essay, referenced in hatnote atWP:INVOLVED asguidance on involvement for non-administrator actions - also not a guideline but quasi-advertised as such. Likewise we haveWikipedia:Requested moves/Closing instructions, as a subpage of RM no less, which again isnothing more than an essay, even if widely used as guidance. I think it might be time to start making the effort to categorise certain pages more accurately, reflecting their status quo as defacto guidelines.CNC (talk)13:30, 30 January 2026 (UTC)[reply]
You're not wrong, "enforcedBRD" is referenced inWP:STANDARDSET, whereas BRD is only an essay intended as advise. Given it describes anoptional strategy rather than any fixed rules, the categorisation doesn't seem off to me at all. Realistically it's evolved into an infopage as documents the cycle in-depth, rather than pov-led like essays often are.
I'm aware not everythingneeds a tag, but if there aresets of best practices supported by consensus, then promoting to guideline satus is logical for sake of clarity. Five pillars is otherwise a higher-level summary page, so acts more like an infopage than policy or guidelines. There doesn't appear to any independently crafted policies or guidelines, only references to them. Thus, it's categorised correctly as a page that either isn't confirmed to have widespread consensus, or doesn't require it.CNC (talk)16:48, 30 January 2026 (UTC)[reply]
Good suggestion, also the notes on that page that are linkedneed anchors, or ideally resolve the duplicate lists of restrictions. There is one at the base page and the other transcluded to subpages; one with useful links, notes, and a set of other restrictions; and the other without. Hopefully an arb can bring some sanity to that.CNC (talk)20:19, 30 January 2026 (UTC)[reply]
No, I can't. The Enforced BRD sanction in my userspace is historical and part of the point of STANDARDSET is that it eliminated custom sanctions like the ones in my userspace.~Awilley(talk)22:06, 1 February 2026 (UTC)[reply]
(Pedantic note: it didn't eliminate custom sanctions. It made them so only a rough consensus of uninvolved admin at AE could do them.) Best,Barkeep49 (talk)03:08, 2 February 2026 (UTC)[reply]
Great. What's the procedure for getting the committee to stop linking to a page that says it is "one of manyoptional strategies" (emphasis in the original)?WhatamIdoing (talk)06:19, 2 February 2026 (UTC)[reply]
I support better documenting the de facto approach to consensus. I do find this sentence weird:The desired standard is rough consensus, not perfect consensus. I understand it’s the de facto approach, but should there be an effort to revise consensus, rather than having a separate guideline that sorta says, “we didn’t mean that page, we mean this page”?Dw31415 (talk)01:09, 31 January 2026 (UTC)[reply]
AIUI our notion ofWikipedia:Rough consensus is derived from theInternet Engineering Task Force. "Rough consensus and running code" is the goal for their decision-making process. The first half means that it's unnecessary to have unanimity, to have agreement on the details, or to have a formal vote. In the case of decisions made underRFC7282, it literally means that support sounds louder than opposition. They are looking for an absence of significant opposition, rather than strong support. The second half means that the group should defer to the people doing the work instead of someone pontificating about theory.WhatamIdoing (talk)01:51, 31 January 2026 (UTC)[reply]
I'm not sure why we should expect people to know the IETF's protocol.That said, I think WP:C already appropriately summarizes consensus asConsensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy. Detailed, further explanation is what WP:Close provides.Aaron Liu (talk)02:26, 31 January 2026 (UTC)[reply]
I’m not sure about the best solution and don’t want to distract too much from the main question. I just think there’s an odd smell about this (as a guideline) saying we don’t use policy (consensus) we use an essay (rough consensus). If no one else sees a problem with it I’ll defer.Dw31415 (talk)03:17, 31 January 2026 (UTC)[reply]
Oppose (until harmonized with RFCEND): After some reflection, I oppose based on my understanding that it will make it harder for involved editors to close RfC's with an obvious outcome.Comment: As an example, I tried to close an RfC as an involved editor because the outcome was obvious. The nominator (whom I respect tremendously)wrote that the RfC did not need closure citing the page under discussion. I was relying on RFCEND. I'm concerned that elevating this page to guideline will then give it more weight than RFCEND. My concern would be addressed by changing this page fromformal closure is neither necessary nor advisable to RFCEND'sinvolved editors should be able to close most discussions. Thanks for considering!Dw31415 (talk)14:26, 3 February 2026 (UTC)[reply]
Thank you for your kind words. The exact same wording is present atWP:RFCEND:If the matter under discussion is not contentious and the consensus is obvious to the participants, then formal closure is neither necessary nor advisable. In fact,that's where I imported the sentence at WP:Close from. This is in line with RfCEnd'sEditors are expected to be able to evaluate and agree upon the results of most RfCs without outside assistance, uninvolved closers being one kind of outside assistance.I unfortunately couldn't find where RfCEnd saysinvolved editors should be able to close most discussions. If it does, that should be removed as it directly contradictsWP:Involved:editors closing such discussions should not have been involved in the discussion itself or related disputes.Aaron Liu (talk)18:20, 3 February 2026 (UTC)[reply]
Can the person who started the RFC, or another involved editor, write a summary of the discussion?
Yes. In particular, when a proposal is soundly rejected, proponents are encouraged to accept defeat with grace. However, if the outcome could plausibly be disputed, then involved editors (on all sides of a dispute) are encouraged to let someone else write a summary.
The RFC process is looking for a good, shared understanding rather than bureaucratic niceties. If the outcome is clear rejection, then having the OP post something like "Everybody hates my idea. Sorry for wasting your time" is a valid summary, and it is not improved by having an uninvolved editor get involved.WhatamIdoing (talk)18:53, 3 February 2026 (UTC)[reply]
Ah, I misunderstood what "most discussions" meant; sorry Dw3. The sentence you mentioned needs some work, though. It's a 2021 addition that contradicts the bolded sentence I mentioned on what to do when the consensus is obvious, though I do see ways to make it not contradictory. I'll elaborate on WT:RFC and invite you two.Aaron Liu (talk)14:13, 4 February 2026 (UTC)[reply]
Changed my "oppose" to a "comment" with the expectation that elevating this doesn't impact the ability to change it or impact the discussion around involved closure.Dw31415 (talk)16:07, 7 February 2026 (UTC)[reply]
I don't think we should mark this as a guideline right now. Compare it to something likeWP:NAC which is much closer to being a guideline in form and covers a topic the proposal doesn't:who should close discussions. The proposal is also redundant with many of our existing P&Gs, and WhatamIdoing points some out in the discussion section below. Redundancy adds a maintenance burden---there are many discussions where editor time was spent resolving a policy conflict because two pages drifted apart and no one noticed. Redundant P&Gs also harm editor recruitment and retention when newcomers need to navigate14 15 policies, see the sources atCriticism of Wikipedia#Excessive rule-making for more on this. WP:CLOSE is a good informational page, but I don't think it's a good idea to make it a guideline.Marking this as a guideline won't make newcomers better understand our unique governance system or stop wikilawyers from coming up with a tortured reason to challenge a close. Those are non-starters for me. Frankly, if an editor is starting to interpret P&Gs about closing discussions, they are already so deep into "wikilaw" that they should be evaluating essays by their quality and level of community acceptance, not the banner at the top. Essays likeWP:SNOW,WP:NAC, andWP:POLL have incredibly broad consensus and 10x as many links asWP:CLOSE, but they lack a guideline banner because they're not good guidelines. Level of consensus is only part of it.—Wug·a·po·des08:44, 8 February 2026 (UTC)[reply]
Oppose perWP:CREEP. The current text is quite debatable, starting with the first sentence (Consensus is Wikipedia's fundamental model for editorial decision-making.)WP:BOLD is actually more fundamental because nothing gets written until someone boldly decides to make a start. Insofar as the proposed change would make any difference, it would be to make it more difficult to change this debatable text.And formal closing seems quite abnormal and exceptional. The typical talk page discussion consists of someone saying something and no-one responding. And even when there are responses, you rarely get a formal close. Consider thetalk page for the page in question, for example. If you look at that orits archive, you'll find about 30 discussions, including a formal RfC, andnot a single one has a formal close that I can see. It's a farce.Andrew🐉(talk)17:26, 9 February 2026 (UTC)[reply]
BOLD is actually more fundamental
WP:Bold isWP:EditConsensus. The very next next sentence after the one you quoted summarizes Bold:Consensus is typically reached as a natural and inherent product of the wiki-editing process; generally someone makes a change to a page content, and then everyone who reads the page has an opportunity to either leave the page as it is or change it.The sentence you quoted is the first sentence ofWP:Consensus, so I don't think WP:Close would elevate Consensus over Bold here. I definitely could remove it from WP:Close but I unfortunately can't figure out how to do so without making the lede read weird. I'd welcome any suggestions on how to do so!
formal closing seems quite abnormal and exceptional
The page does mention that! Besides the second paragraph saying closes are only advised to happen whendiscourse [is] lengthy and the results hard to determine, half of§ When to close discussions is dedicated to explaining what you said here.I think we agree on what the page should say, just not whether it says them. I believe making sure the page says these and would be seen is our chance to clarify that these are in fact the community norms.Aaron Liu (talk)21:30, 9 February 2026 (UTC)[reply]
No, we don't agree. I've looked through this material and it's trash. Let's look at that first sentence again. It's a copy of the first sentence ofWP:CON which is a different policy. Why does the page start by talking about consensus rather than talking about closing? These are not the same thing.
If you look at thefirst draft of this page, it doesn't say anything about consensus. It is all about closing instead -- terminating a discussion so that no further comments may be made. And this is done mainly to stop disruption and time-wasting.
Another editor then comes along then then rewrites the page. He's the one who is focussed on determining consensus rather than the process of closing. The page is then confused from that point.
The page waffles indecisively about how discussions may be left open for years or not closed at all. It repeatedly says that there are no policies for this. It seems to understand that there are different discussion processes such as RfC but it doesn't catalog these and explain their closure rules.
For example, consider a process page such asWP:ERRORS, which is quite busy and which I attend often. This is quitesui generis in that discussions are resolved rapidly as time is of the essence. They are typically actioned by admins as the main page is protected. After the action is taken, the discussion is typically then blanked. It's not hatted or archived, it's just deleted from the page. Any discussions left open at the end of the day are typically cleareden masse and there is an admin button to do this. There's often not much in the way of consensus or appeal and it doesn't much resemble processes used elsewhere. I don't much like the process but so it goes.
Other forums such as Arbcom, AE, DYK, ITN or the reference desk have their ownold Spanish customs which have evolved over the years. There are lots of discussions at these but they have their own mechanisms and rules for closing them. This page displays no understanding of this and so, as a general guideline, is useless.
Closing has two parts: terminating the discussion (with e.g.{{atop}}) and summarizing it (i.e. determining its consensus). (Other forms of terminating are not closure.) I have not seen the former happen without the latter. I only see "there are no policies" mentioned once, and of course that would be removed if the page becomes a guideline.
The page waffles indecisively about how discussions may be left open for years or not closed at all
That would be a problem. Could you specify where you see that?
it doesn't catalog these and explain their closure rules
I feel like the closure guidelines included on this page are generally applicable. WP:Close's ways of assessing consensus are used on all the pages you've mentioned. I think it would be both unwieldy and unnecessary for a page to document the closing procedures of every process page on Wikipedia; I don't see the problem in having the reader just read the relevant process page.Aaron Liu (talk)12:58, 10 February 2026 (UTC)[reply]
Oppose. If this were to become a guideline about closing, closing would still be described better and in more detail in PAG outside of this page. This alone means that the page should not be promoted to a guideline, and that its nature really is that of an information page. The page's content does not match what would be needed for a comprehensive guideline about closing and lacks unique substantive normative content relative to existing PAG. The actual PAG-grade norms about closing (and highly-specific at that) already exist and they are at:
WP:ROUGHCONSENSUS (guideline) -- basically, this section is pretty much the "closing discussions" guideline; it is applied universally -- outside of the deletion process by analogy. The last paragraph significantly referencesWP:IAR ("shockingly", a local consensus can suspend a guideline)
WP:NOTBURO andWP:IAR (policies) throughWP:SNOW (titanium-clad interpretation of policy) -- the other closest thing to a substantive guideline about closing discussions. A guideline about closing has to explain WP:SNOW in the prose.
Wikipedia:Talk page guidelines#Closing discussions (guideline) -- general informational material about closing discussions already existing in the form of a guideline + one important provision, effectively stating: do not demand an uninvolved close unless the consensus is unclear, the issue is contentious, or the decision has wiki-wide implications, i.e., involved closes are not a priori bad.
WP:INVOLVED (policy) -- "involved status" does not matter with respect to closes where the issue is non-contentious and straightforward (that is the correct interpretation).
Wikipedia:Deletion process#Non-administrators closing discussions (guideline) -- Even though administrators are, in general, responsible for closing discussions, there are times when it is also appropriate for non-admins to close discussions. This is then significantly elaborated upon. This is another "lost fragment" of the existing one and true "closing guideline", also applied universally, of course -- outside of the deletion process by analogy
If we were to assemble these genuine norms about closing disussions, we would get an actual standalone, comprehensive Wikipedia guideline about that. But the page nominated for promotion is not that page.—Alalch E.— Precedingundated comment added17:41, 11 February 2026 (UTC)[reply]
The goal is for this to be that page. I'll go through the sections you mentioned:
RoughConsensus is covered far more clearly at§ How to determine the outcome except for the last paragraph, which I agree we should add to the "Policy" subsection.
I'm not sure what NotBuro says about closes; I only see it discussing the role of rules. I think Snow is adequately summarized in the "When further contributions are unlikely to be helpful" bullet point.
Explained in footnote [5], which is used where how closers should be uninvolved is mentioned. I think this is the right level of prominence.
Ooh, this is really good! I think I can consolidate this and WP:Close's explanation of closure qualifications in the Closure procedure section into a new "Who should close discussions" section. Would you support making this a guideline when that is done, or are there other additions you think are necessary?
Oppose. My view (pretty similar to Wugapodes) is that this page serves its current purpose pretty well but isn't written with the precision we'd expect from a guideline in this area.WP:NHC in particular is something that is really useful in its current "tips and tricks on determining consensus" role but would lead to more wikilawyering rather than less if people started treating it as authoritative and parsing its every word (example). More generally, although I never used to feel this way, I've come to think that leaving things vague in this area (as illustrated by the one sentence atWP:DETCON) has really been a very wise choice, and I'd encourage people not to knock down Chesterton's fence here unless they're sure the benefits outweigh the costs.Extraordinary Writ (talk)02:41, 12 February 2026 (UTC)[reply]
For clarity for onlookers, I think the intended diff wasSpecial:Diff/1077853382. I could amend the sentence referenced to add "or different interpretations of the same policy".Could you elaborate on the benefits of leaving things vague?Aaron Liu (talk)03:22, 12 February 2026 (UTC)[reply]
If you're interested in closing, I'd encourage you to reflect on that question yourself for a bit longer. Then come back and share your own thoughts on what this metaphorical fence is for.—Wug·a·po·des10:19, 12 February 2026 (UTC)[reply]
I have done a dozen closes (and a successful close challenge for someone else's). I do see that there is nice leeway for different closers to weigh arguments differently, but I've never seen that to such an extent that it contradicts WP:Close's guidance. (or did I misinterpret as "it would be bad to have a new guideline on closing" your concerns that were simply on specific sections instead?)Aaron Liu (talk)12:35, 12 February 2026 (UTC)[reply]
Mostly, I don't see why not make clear a series of practices are standard. Your assumption is correct but I don't see why that lessens the argument for clarity, and said editor is someone I usually wouldn't assume obstructionist motivations.Aaron Liu (talk)21:14, 26 January 2026 (UTC)[reply]
Meta comment: AWP:PROPOSAL is supposed to be made on the talk page of the proposed guideline. I don't think we need to take any action right now, but if this discussion gets long (RFCs on Village pump pages frequently need to beWP:SPLIT to keep the overall page size under control), maybe it could be moved there instead of to a subpage.WhatamIdoing (talk)20:25, 26 January 2026 (UTC)[reply]
I agree that there should be a guideline on closing discussions, but it might be worth fine-tuning it a bit and getting everything in one place first. Right now it's not as concise as it probably could be.Thebiguglyalien (talk)🛸22:08, 26 January 2026 (UTC)[reply]
I've finally looked over both; I don't believe there is overlap, other thanIf the matter under discussion is not contentious and the consensus is obvious to the participants, then formal closure is neither necessary nor advisable. which I don't see a problem with.Aaron Liu (talk)03:22, 28 January 2026 (UTC)[reply]
Hi Aaron, I boldlyadded a link to the RfC close template. Feel free to revert if it should get more review. I would like there were more consistency in using the RfC closure template or to have it deprecated.Dw31415 (talk)14:34, 30 January 2026 (UTC)[reply]
This part of RFCEND strikes me as out of touch with current practice but maybe I’m looking at a controversial subset.Editors are expected to be able to evaluate and agree upon the results of most RfCs without outside assistance. I guess that’s not immediately relevant to this discussion. I support the proposal to make it a guideline.Dw31415 (talk)03:33, 28 January 2026 (UTC)[reply]
I looked through a handful of consecutive RFCs from November-ish. About two-thirds got a closing statement. However, almost half of those didn't need a closing statement (e.g.,Andrew Huberman,Advance UK,Scientology) because the responses were so lopsided. That said, sometimes editors want a closing statement for social/behavioral reasons rather than because they don't know what the result is.WhatamIdoing (talk)06:00, 28 January 2026 (UTC)[reply]
I don't think I've ever seen that particular claim before, but I'd expect that to be solved by educating the editor about Wikipedia's processes. If that happens a lot (more than a couple of newbies a year), then I'd like to have a few examples (drop some on my talk page? It's kind of off-topic for this discussion), then we should address that error somewhere. MaybeWikipedia:Tendentious editing#Concerning discussions would be the place for that.WhatamIdoing (talk)16:02, 30 January 2026 (UTC)[reply]
I’d like to propose moving “If the matter under discussion is not contentious” to a L3 section under closing procedure and include the same involved closure language from RfC end. The current bullet is a bit odd (it’s a stand alone bullet and it’s a bit redundant to the following paragraph). Any thoughts on whether I should boldly edit or make a sandbox version?Dw31415 (talk)18:40, 6 February 2026 (UTC)[reply]
No, not usually. It's just awkward to have something change while people are voting. Someone who dislikes the outcome might claim that the change in the middle of the discussion invalidates all the votes they disagree with. So I suggest avoiding changes, even as minor as rearranging.WhatamIdoing (talk)05:15, 7 February 2026 (UTC)[reply]
Replace animated GIFs with SVG animation, AVIF or APNG
As title, since the UK and US governmental websites do not consider any browser whose share of usage does not exceed 2%, and the only browsers (considering only newest versions) that lackAPNG support areInternet Explorer andOpera Mini, which are extremely rarely used worldwide[1], andAVIF has major web browser support[2], and currently even an entry-level notebook can commit real-timeSVG rendering quite quickly, just like in 2007, many PCs can not commit smoothH.264 decoding, yet not long after even an entry-level notebook can do so, andGIF lackstrue color andcolor management support, this proposal won't harm. By the wayWikimedia Foundation can announce that IE and Opera Mini will be unsupported after 3 months, making exploiting newer web technologies (e.g. the newest edition ofECMAScript) possible and reducing the burden of newbies of theMediawiki staff.RekishiEJ (talk)13:42, 4 February 2026 (UTC)[reply]
The capabilities of hardware are generally not the problem. It is all about someone putting in the work to build a runner that converts one thing to another in a safe and sandboxed way, keeps track of the storage of those derived files and maintains it. Of note btw, converting a GIF to a newer format isn't really useful, as the information you need doesn't spontaneously start existing and internet users simply aren't using any of the formats you discuss as widely as they should (chicken and egg problem). Our browser cutoff is .5% generally btw. For those interested, you can look into the PNGHandler and discover how this works. and then look into our thumbor plugins. —TheDJ (talk •contribs)14:15, 4 February 2026 (UTC)[reply]
If it was convenient and easy to make compatible animations and images into SVG format, that would be nice, but I am not aware of a way to do that on a large scale suitable to Commons. Plus, there are many thousands of people that still access Wikipedia through hardware that is less capable than an entry-level notebook (like those who are accessinghttp://www.native-languages.org on a regular basis). --Reconrabbit20:04, 4 February 2026 (UTC)[reply]
@Reconrabbit: if all Aboriginal Americans access Wikipedia through hardware that is capable of committing real-time rendering of many SVG files quite smoothly (no more than 8 seconds), would you argue for the abolition of the PNG-to-SVG renderer in all Wikimedia projects? By the way, the introduction of the converter in Mediawiki is meant to address the lack of SVG support in IE versions before 9[3], and nowadays IE is extremely rarely used worldwide.--RekishiEJ (talk)11:02, 6 February 2026 (UTC) Removed one comma 06:06, 7 February 2026 (UTC)[reply]
Because SVG-to-PNG renderer sometimes worsens the appearance of an SVG file, and turns an SVG animation file into a static file, andFoundation for Individual Rights and Expression's official website directly uses SVG files (not turning them into any other file format), the fact that some use hardware that cannot commit smooth SVG rendering is not a valid argument against abolishing SVG-to-PNG renderer. Instead, the U.S., Canadian, Australian, NZ, Japanese, Taiwanese governments and those of Latin American and African states should endeavour to ensure that every aboriginal that uses hardware uncapable of smooth real-time SVG rendering can use one that is capable of doing so.--RekishiEJ (talk)11:02, 6 February 2026 (UTC)[reply]
Looking athttps://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser NetSurf isn't listed, and PaleMoon is running around 0.01% of traffic, which I believe makes it eligible for non-support in principle. But we wouldn't want to actively disallow a browser 'just because' (e.g., just because it's unpopular, or just because it's old). Non-support is more like a decision not to go out of our way to make sure it continues functioning. Wikipedia must be made to work fully in our readers' most popular browsers, even if that requires extra work from the devs. For a browser chosen by one in 10,000 users, it's great if it keeps working, but if this or that feature doesn't happen to work, then it's not worth dev time to change that. Non-support would ideally degrade gracefully; it is more like benign neglect than "disallowing" or "discouraging".WhatamIdoing (talk)18:02, 9 February 2026 (UTC)[reply]
Opera Mini's usage share is 1‰, meaning according to the UK and US governmental guidelines its support does not have to be considered (once a browser's usage share is no more than 2%, then its support does not need to be considered).--RekishiEJ (talk)03:00, 14 February 2026 (UTC)[reply]
In my experience attempting to implement a massive automated image conversion project is certain to lead to the use of one specific word: "regret". The famous "what can go wrong?" question will have more answers than one can imagine. Unless we are looking for long headaches we should not attempt this.Yesterday, all my dreams... (talk)12:05, 14 February 2026 (UTC)[reply]
Somewhat correct. Overall, i would summarize this proposal as bringing a sledge hammer without even knowing all the different variants of nails that we are suggesting to apply it to. Still it is not wrong to think about things like this. A lot definitely could be better, but it is simply way more complex than most people can imagine. Even most developers have rarely had to deal with the breadth of material that we are talking about here. But any help is more than welcome if you can make targeted and detailed proposals and suggestions on this front. Or better, code contributions. —TheDJ (talk •contribs)12:36, 14 February 2026 (UTC)[reply]
Thank you for saying "somewhat correct". You modesty in assuming that you know more about software than yours truly is commendable, of course. As for "code contributions" I would not do so, for it would be one step on the road to chaos. Piecewise code contributions eventually lead to a large "code Jambalaya" that no one can digest. Good code starts with a good design, before a line of code is written. But of course you would know that. Right? I would not do a partial code contribution here for the same reason that I would not offer a sandwich to a 17 year old and his grandfather to help them climb a high mountain. I would tell them to go and have a nice cup of cofee together instead. But you know that of course. Right?Yesterday, all my dreams... (talk)04:44, 15 February 2026 (UTC)[reply]
The following discussion is closed.Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Make it so unregistred users cannot submit empty submissions
There has been a increasing number of empty submissions submitted by unregistred users. Those are usually declined automatically onWP:AFC/R and,. to a lesser extent,WP:AFC/C.
Why does this need to be a formal policy, amd what effect do you believe the policy would have? Most people doing this wouldn't be aware of any policies to begin with.331dot (talk)13:28, 7 February 2026 (UTC)[reply]
I don't think a policy change will do anything, but a technical solution so that empty requests cannot be submitted might be worth looking into. My guess is that this is something an edit filter might be able to do, but I don't know.Thryduulf (talk)15:39, 7 February 2026 (UTC)[reply]
Neither, the submission template is scripted such that empty submissions are marked declined without the need for so much as one additional edit.~2026-80954-2 (talk)15:44, 9 February 2026 (UTC)[reply]
IMO the correct solution for this is to make empty requests not get posted in the first place (zero edits, not one edit that is automatically pre-declined). The 'Publish changes' button should be grayed out until something is manually typed in the editing window, not just preloaded. (This might be easier to do in the visual editor and its 2017 wikitext editor.)
Something using the NEWTOPICTOOL would be much more user friendly. Presenting new users with curly brackets and commented out text is likely the reason so many requests end up being blank. --LCUActivelyDisinterested«@» °∆t°18:16, 13 February 2026 (UTC)[reply]
Afteran ARCA clarfication established that the ECR for Kurds and Kurdistan is a community issue, I'm bringing this back to VPP. The debate is an argument that while nobody objects to the large scope ofWP:CT/KURD, the community ECR for the topic area isde jure overly broad, since it includes non-controversial topics based on their location alone. With current wording, it includes everything inKurdistan, regardless of whether it is politically controversial. In contrast toa similar 2023 discussion on the Armenia–Azerbaijan ECR, I have no evidence right now that the Kurdistan ECR is enforcedde facto narrowly. In fact, this dispute was started by the G5 deletion of a draft about a valley inIraqi Kurdistan. We're building a concrete proposal to advance an RfC in this thread, initially with the exact wording of the post-2023 community ECR forWP:GS/AA:Politics, ethnic relations, and conflicts involvingKurds andKurdistan, broadly construed. –LaundryPizza03 (dc̄)21:38, 9 February 2026 (UTC)[reply]
I’m of the view that we decouple geography at our own peril, as ethnic conflicts are inevitably about the right for a given group to live on a given territory and evidence of current/past inhabitance is thus central to such disputes.signed,Rosguilltalk21:42, 9 February 2026 (UTC)[reply]
Sometimes I think I'm reading a run-on sentence. Then I realize I missed the period separating two sentences. I took a good look at periods used in Wikipedia articles. I think the period is not very visible. It either needs to be slightly bigger or slightly darker.Ifyoucrydon'tlose (talk)01:00, 10 February 2026 (UTC)[reply]
Sometimes it's kind of annoying from time to time; when I want to log in to the Wikipedia main page I have got the press on english wikipediaZefliu (talk)06:35, 10 February 2026 (UTC)[reply]
An automatic redirecting to the English wiki isn't going to happen, given how the project as a whole is supposed to be for a global audience.
For now if you want to save a click, you can either bookmark the English wiki homepage, rely on autocomplete in your browser; I visit the english wikipedia frequently enough that my browser (Firefox) will automatically fill in the URL "https://en.wikipedia.org/" once I just type in "en".EatingCarBatteries(contribs |talk)07:09, 10 February 2026 (UTC)[reply]
Just go to yourUser Page and click theWikipedia25 years of the free encyclopedia symbol on the upper left corner.
Pursuant to the canvassing at deletion discussions likeRichard Kahn (accountant) which led me to discover Great455, an SPA exclusively editing in the topic of people connected to the Epstein files, would it be wise to designate the Epstein files as aWP:CCTOP, perhaps subject to extended-confirmed restriction?
I think we can expect that canvassing and disruption from rightfully concerned editors who are acting in 'the public good' but with no understanding of Wikipedia standards and procedures will only get worse as disclosures continue.Athanelar (talk)11:06, 10 February 2026 (UTC)[reply]
The global component is quite significant and while some of that will also fall under various regional CT/DS/GS not all of it will. BLP will still catch most of that, but there are some (no longer recently) deceased names involved. Even so, ECPing wide swathes of the project on a speculative basis is using a sledgehammer to crack a nut; we have well-honed procedures that can deal with disruption as it arises.~2025-41540-19 (talk)15:42, 12 February 2026 (UTC)[reply]
Isn't it a bit narrow as a topic for that? Even if the scandal reveals links from several countries, it is likely that it will follow the steps of thePanama Papers: Big news for a time (let's say two or 3 months), kickstarts many legal cases, but then the press moves on to something else, the audience does as well (and that includes Wikipedia editors in general), and the problem simply solves itself.Cambalachero (talk)16:29, 12 February 2026 (UTC)[reply]
This CCTOP would have issues of scope, ascontent related to Jeffrey Epstein, broadly construed orcontent related to the Epstein files, broadly construed would open many high-visibility pages to potential ECP -- would every person listed inProminent individuals mentioned in the Epstein files be preemptively placed under ECP asa necessary evil to prevent disruption? The idea of a more narrow scope likecontent related to the misconduct of Jeffrey Epstein, broadly construed without blanket ECP is more appealing; while it would not give us more tools to handle disruption, it would recognize that this is a specific topic withinWP:CT/AP andWP:CT/BLP that has major, ongoing issues, similar to howWP:GS/RUSUKR exists at the same time asWP:CT/EE.mdm.bla19:50, 12 February 2026 (UTC)[reply]
Is there an appropriate venue for proposing that a topic should be designated as a contentious topic? I've looked at the venues for ArbCom and RfC for this matter, though I've yet to find an appropriate place for such proposals. In this case, I'm indending on proposingEast Asian politics and history, WW1 and beyond as a contentious topic, largely due to it having an extensive history of editing disputes. (to name a few,Japanese war crimes,Japan during World War II,Unit 731).
I know that ArbCom proposals for cases like these require you to name a few users and such, however this issue is somewhat widespread, and would take much longer in compiling involved accounts anyhow. ---n✓h✓8(he/him)14:30, 10 February 2026 (UTC)[reply]
Wouldn't it be simpler to compile a list of non-contentious topics? I'd suspect that it might well prove much shorter, given the propensity of contributors to argue about absolutely anything? More seriously though, I don't think I've seen much in the way of evidence that 'East Asian politics and history' is significantly more contentious than politics and history more generally elsewhere. Pick a continent (ok, not Antarctica) and I could compile a list of articles with 'an extensive history of editing disputes'. And in my opinion, over-extension of the scope of 'contentious topics' designation dilutes its effectiveness.AndyTheGrump (talk)14:45, 10 February 2026 (UTC)[reply]
Typically CT designations are needed when we have either a) a massive flood of new editors trying to engage with the topic in a disruptive fashion (off the top of my head, the activity aroundSambhaji last year is a perfect example) or b) intractable disputes and subpar behavior between multiple experienced editors (e.g.WP:PIA, although that also has some of the (a) dynamic as well) . I'm not aware of either of these dynamics being the case for East Asian politics and history. Occasionally we'll get someone complaining that we're referring to the Chinese Communist Party (or the PRC, or Taiwan) wrong, or we'll see some driveby edit warring like what appears to be linked in the initial post, but I don't think either of these dynamics rises to the level of disruption that would warrant a CT designation.signed,Rosguilltalk15:08, 10 February 2026 (UTC)[reply]
I think just locking the page either as gray or pending is because of persistent vandalism is enough. Although, looking at the page histories of this pages, it does not seems to warrant even just locking it. CTOPing involves large scale disagreement. And CTOPing this is a massive overkill. Most of these are just your ordinary political or just simple vandalism that can be solve by blocking the editor or temporarily locking the page when needed.Warm Regards,Miminity (Talk?) (me contribs)14:29, 14 February 2026 (UTC)[reply]
The change to a two-click logout is really irritating me. Sure it's nice to cancel an accidental click, but that happens very rarely. Having to remember the second click - right across the other side of the page - is far the dominant action; timewasting, unreliable. All too often I come back to find that I am still logged in from last time. Having to log back in after a rare accidental click is not /that/ burdensome. Please can we restore the old-style one-click logout? Or at least make it an optional user setting? — Cheers,Steelpillow (Talk)08:54, 12 February 2026 (UTC)[reply]
Load it where? My device, my browser, my Wikipedia account? I'm not a developer, how do I do that anyway? It's this casual attitude to UX that is the root cause of the problem. — Cheers,Steelpillow (Talk)13:39, 13 February 2026 (UTC)[reply]
You want to copy that to your common.js page,Special:MyPage/common.js will take you to the correct location. As someone who regularly misclicked logout the first script I installed was to stop it happening, as itwas burdensome to have to log back in every time. Scripts like this allow editors to customise their own experience easily without impacting other editors. You don't need to understand the code itself (I certainly don't), just copy and paste. --LCUActivelyDisinterested«@» °∆t°18:31, 13 February 2026 (UTC)[reply]
That takes a lot more effort from more volunteers, why not simply copy paste the script. If this becomes something requested by many editors then maybe the extra work would be worthwhile. I believe you can set a preference for one click script installation, but I'm not sure it's not something I've used. --LCUActivelyDisinterested«@» °∆t°20:34, 13 February 2026 (UTC)[reply]
It took a lot of effort from a lot of volunteers to introduce two-click in the first place. That's no argument. How many requests for that two-click were there? — Cheers,Steelpillow (Talk)08:49, 14 February 2026 (UTC)[reply]
Uuhhh. So Wikipedians like UI features that go against tried and trusted design principles. Sorry to bother you, and thank you very much for the link. — Cheers,Steelpillow (Talk)16:27, 15 February 2026 (UTC)[reply]
More accurately our developers/maintainers don't scale. OTOH the providers of endless utility scripts in user space do appear to scale. I wonder if there is a lesson for our architecture model in there somewhere. (Rhetorical question, no need to reply). — Cheers,Steelpillow (Talk)16:27, 15 February 2026 (UTC)[reply]
Steelpillow, I know you said that there's no need to reply, but I will anyway. I used to be an IT techie in the 1980s and 1990s and the early noughties, but have since become rather a technophobe. Under the picture that is supposed to be a person in the top right corner of your screen go to "Preferences"; then click on "Gadgets"; scroll down to the section labelled "Advanced" and click om the last box next to "Install scripts without having to manually edit JavaScript files (documentation)"; scroll down again and click "Save", Up to now you only have to go through this procedure once for anything that anyone tells you is a script. You can now, if you manage that, go toUser:Sapphaline/oneclicklogout.js and click "Install" by the title. I know that this is a long-winded procedure, but there is, in my experience, no way to persuade a techie to simplify it: they just can't understand how anyone could have trouble with anything so simple. I have given these instructions based on my system, Firefox on Linux Mint. If your system puts anything in a different place then I'll have to start again.Phil Bridger (talk)19:16, 15 February 2026 (UTC)[reply]
I'm using Vector (2022) and don't have the two-click logout problem. Logging out for me is the same as it has always been: clicking on the upper right icon, then clicking 'Log out' (there's no confirmation pop-up or another page asking if I hadtruly intended to log out, which is good).Some1 (talk)19:32, 15 February 2026 (UTC)[reply]
TheInfobox person block is a great place for noting essential data about the subject of a biographical article. As such, it seems to be an excellent place to note link(s) toprimary biographical media about the subject.
I notice that one of the box's current fields,television, is nearly perfect for this purpose but its very name and usage precludes the use of other media types:
Television programmes presented by or closely associated with the subject. For multiple entries, use an inline list.
I propose that thetelevision field in theInfobox person template be deprecated and a new fieldTBD (bio_media perhaps) be created to replace it. The new field should be restricted entirely to link(s) to media (that is, books, films, television shows) about the subject that are:
factual (non-fiction),
biographical in nature, and
widely recognized as authoritative on the subject
As an infobox field is it also important that its contents be brief. To prevent misuse it should:
generally be limited to one link or at most, one link per medium.
not be used forfilmographies; use an article section instead.
not be used fordiscographies; use an article section instead.
not be used fornotable works; use thenotable_works field instead.
not be used at all if the subject is very notable and no suitable single biographical medium suffices.
The field you are proposing seems to be for a different thing entirely than the currenttelevision field; I don't really understand why you are linking the creation of this new field and the deprecation oftelevision in this proposal?Caeciliusinhorto-public (talk)12:45, 13 February 2026 (UTC)[reply]
I'm on board with deprecatingtelevision; I agree that it's strange and restrictive as a concept, and on some quick spot checks I'm not seeing evidence of its being widely used.Alex Trebek does not use the parameter even though he's undoubtedly best known for presenting a television program; nor doesTheodore Roosevelt include it despite his having been the subject ofa biographical miniseries. That said, while I support deprecatingtelevision, I'm not convinced that the new proposed field would be desirable either. In particular, I see three notable drawbacks to the proposal: (1) As it stands, biographical infoboxes typically only include factual data about the subject (birth and death dates, places of residence, names of family members) or information about their activities or achievements (offices held, works the subject created, etc). Introducing a single infobox field that breaks from this pattern seems likely to confuse readers or give them an inaccurate impression of the biography's provenance. (2) The proposed field will likely elevate relatively minor information to a more prominent place than is useful.Lyndon B. Johnson is notable for being a US president, not for being the subject ofThe Years of Lyndon Johnson. (3) Because of the risk of confusion, the proposed field would likely be a common target of well-meaning but erroneous edits by editors unfamiliar with its nuances, creating an increased burden on the maintainers of many biographical articles.ModernDayTrilobite (talk •contribs)15:57, 13 February 2026 (UTC)[reply]
I don't think I understand this proposal at all. Itsounds like the idea is to add an external link in the middle of the infobox, to a video (or something similar), but only if there's only one suitable link. I don't think that I want to see something like| Media Who is Alice? biopic | in an infobox. If there's an important documentary or something, then put it in ==Further reading== or ==External links==. Or even describe it in the body of the article.WhatamIdoing (talk)06:15, 15 February 2026 (UTC)[reply]
ThePrompt injection article sort-of covers this topic, but it does so in a confused way that says that prompt injection is not jailbreaking, that it is a type of jailbreaking, and that some some prompt injection techniques are jailbreaking but som aren't, and then doesn't really distinguish them (I'll highlight this on the talk page shortly).Thryduulf (talk)21:32, 13 February 2026 (UTC)[reply]
Well, in theory at least anyone can write an essay, though with a topic like this I'd not recommend anyone trying unless they are very familiar with both relevant policy, and with long-running debates over the issue. Any volunteers? I'd offer, but I have my doubts that some in the community would accept my position on this.
Given that some have found reasons to object to the phrase, it would probably be better to avoid actually using 'Jew tagging' in the title. And maybe it might be better to try to broaden the scope out a little:Wikipedia:Ethnic and religious tagging? The problem isn't confined to content on Jewish individuals only, though some of the worst examples can be found there.AndyTheGrump (talk)15:47, 16 February 2026 (UTC)[reply]
I was thinking about writing one, but Real Life caught up with me and I haven't had the time to devote to doing a good job with it. I like Andy's suggestion for a title and focus, since it's a broader problem and shouldn't single out a particular religion or ethnicity, any more than it's permitted in articles, but I don't think we should completely expunge the term or minimize the observable fact that it's the most troublesome example. I've noticed a recent uptick in malicious tagging, and a relative decline in what I would term benign Judeophilic descriptors. If I start one I'll link here so others can participate.
I would welcome examples of similar phenomena with other religions or ethnicities to cite - I've seen some tagging of Muslims, for example, in India-related topics.
There's also a parallel issue of nested nationalities, such as English/British, that has caused strife, especially if the subject is perceived as a different ethnicity. I'm not prepared to work that out.Acroterion(talk)15:56, 16 February 2026 (UTC)[reply]
I didn't intend to propose omitting the term 'Jew tagging' entirely, just not using it as a title: sorry if that wasn't clear. And I'd think that any essay on the topic should clearly include a link toEdward Kosner's Wikipedia-focussed article with that title[4] inCommentary, as a useful outsider's perspective. An essay clearly needs to distinguish between relevant and proportional discussion of a subject's ethnicity and/or faith and the context-free, reductionist/stereotyping bald-assertion-sentence 'X is Jewish' tagging that Kosner and so many others object to, and I think that Kosner's piece expresses it better than most of us could.AndyTheGrump (talk)18:09, 16 February 2026 (UTC)[reply]
The Jewish version of this tagging does have it's own specific issue. The tagging is done by either those who feel the Jewish identity is being hidden, and those who want to (((tag))) Jewish people. This is opposite to the issue found in most articles, where people attempt to exclude individuals from a given ethnicity. Of course the solution is always to follow the sources, but that regularly differs from the POV of editors. --LCUActivelyDisinterested«@» °∆t°18:01, 16 February 2026 (UTC)[reply]
Sorry, but if you really think that with the exception of Jewish subjects, 'exclusion' is the only issue, I don't think you've been looking very hard. And no, 'following the sources' isn't necessarily sufficient. It is entirely possible to engage in the most egregious tagging while using an impeccable source. Which is one of the reasons why it can be difficult to deal with.AndyTheGrump (talk)18:13, 16 February 2026 (UTC)[reply]
Often, it isn't the 'what' but the 'how' that matters. As an example, I once got into a dispute with arch Jew-taggerUser:Bus stop (now CBANNED) because he wanted an article to merely say 'X is Jewish' in a biography, rather than actually going into any detail regarding the subject's attitude to his faith and ethnicity, which was in my opinion much more enlightening for the biography. Bus stop seemed to see Wikipedia as a Jew-tagger's database, refused to countenance any content that might suggest that the Jewishness of any individual was anything but objective fact, even if the individual concerned was equivocal (which isn't that rare), and routinely resorted to the most ridiculous arguments in order to justify his obsession. In my opinion, any article that has the sentence 'X is Jewish' in it, without further context, needs looking at as potential tagging. You just don't see that in biographies elsewhere. It is reductionist, if not outright stereotyping, and reduces a human being to a mere label. At best it is bad writing. At worst, it is obnoxious.AndyTheGrump (talk)01:29, 17 February 2026 (UTC)[reply]
This is a more general issue with "tagging" (possibly better described as "labelling"), in that often an effort to get a specific word into prose is the end in itself rather than expanding the context or even writing the same thing in a less provocative style.CMD (talk)05:38, 17 February 2026 (UTC)[reply]
As I said in the previous discussion, you can just write the essay yourself? Essays are cheap. But I would focus mostly on "how to recognize it" and "here are the relevant policies" (eg.MOS:ETHNICITY,WP:DUE), plus maybe some convenience links to previous discussions or external coverage of the problem. I don't think trying to get consensus out of the gate is a productive use of time for an essay - just write it, see what people say, tweak it if there are minor problems or quibbles, and if there are larger disputes orirreconcilable problems, someone else can just write a competing essay. --Aquillion (talk)21:04, 16 February 2026 (UTC)[reply]
I see way more Jews online offended that we are "erasing Jewish history" by removing that people are Jewish, honestly. See, for example,[5][6], or objecting to our sort of compromise phrasing of "raised in a Jewish family" as also antisemitic. We can never win.
You're already not supposed to add it if it is not in a reliable source. I don't know what else we're supposed to do, hide that people are Jewish even if reliable sources say they are? Is that not ridiculously antisemitic? And sure, people often break that rule. But that goes for every guideline we have. Perfect enforcement does not exist here.PARAKANYAA (talk)00:55, 17 February 2026 (UTC)[reply]
Is that not ridiculously antisemitic? I hope you don't mean that the way it reads.
This isn't about hiding anything. If someone's ethnicity or religion is a significant feature of their life, it should be mentioned, as long as it's backed by sources, in conformance with the MoS. What we're discussing here is the frequent tendency to substitute ethnicity for nationality in the lede, of qualifying nationality with ethnicity, or guessing about it with no sources or no relevance to the facts of a subject's life. I'd estimate that 75-80% of such edits are malicious. Frequent targets arepeople who've conducted themselves in a manner that draws criticism or negative attention, whereupon they get tagged as plainly as possible. This rarely happens when someone's Presbyterian.
An essay would be helpful in explaining all this to well-intentioned editors who wish to celebrate someone's ethnicity, and are disappointed or upset that it's not appreciated. It also helps cut off debate with the malicious who are cloaking themselves with the same ostensible motive.
I think systematic efforts to erase Jewish history in the sense where we would hide cited information would be very antisemitic. If that's not what is being suggested, then no.
Kosner's article is him personally objecting to the fact he is labeled as being born to a Jewish family, and speculating that this was added by antisemites. Judaism is not just a religion. Where was it mentioned that we're just talking about the lead? The discussion, or Kosner's article, say nothing of the sort. The case at issue in Kosner's had nothing to do with substituting "ethnicity for nationality in the lede, of qualifying nationality with ethnicity, or guessing about it with no sources or no relevance to the facts of a subject's life".
The issue wrt Kosner was a sentence in the body of the article cited to a scholarly article from the Oxford University Press's Studies in Contemporary Jewry, from a Jewish author, solely about Jews and journalism, which names Kosner as a prominent Jewish journalist, added to the article by a seemingly well-respected editor without nefarious intentions[7]. And the article did not even say "x is Jewish", but that he was born to a Jewish family. If that is problematic Jew tagging then how is, by comparison, discussing anyone's ethnicity or background ever acceptable regardless of sourcing?PARAKANYAA (talk)01:25, 17 February 2026 (UTC)[reply]
Yes, erasing Jewish history would be worse than the problem we're discussing. I mention the lede because 90% of the time this is where it pops up, peoples' attention spans being what they are. Often it's in very short articles that are nothing but lede. Kosner offers a different perspective, the out-of-context or gratuitous insertion of ethnicity.Acroterion(talk)01:34, 17 February 2026 (UTC)[reply]
And by that you mean what? If we're going to be making guidelines we need specificity about what behaviors are and aren't okay. What makes the portrayal of one as Jewish "complex"? In an ideal world every article would be perfect, but none are.PARAKANYAA (talk)02:39, 17 February 2026 (UTC)[reply]
We are discussing an essay, here, not 'guidelines'. As for what makes the portrayal of someone as Jewish "complex", mostly the fact that it is. Because people are complicated, whether they are Jewish or not. Ultimately what we are discussing here is good writing vs bad writing, and the need for biographical content aimed at portraying human beings in all their complexity. Or at minimum, to avoid reductionist labelling. Possibly it is too much toexpect this in Wikipedia, but that's no reason not to aspire to it. It requires editorial judgement, which isn't something you can create rules on. Fortunately, at least some of us (probably most, if they bother to put in the effort) have at least a little of this. That's one of the things that distinguishes us from the chatbots.AndyTheGrump (talk)02:59, 17 February 2026 (UTC)[reply]
While I completely agree that ethnic identification is relatively complex, and no less so or not much less than Jews for the Scots-Irish or Basques or Cajuns or black Americans, especially in the age of 23andme, by the very same token, describing someone as Jewish is not reductionism. That descriptor contains multitudes.Andre🚐03:06, 17 February 2026 (UTC)[reply]
No, of course not. But every once in a while, I do read a biography that doesn't at all mention whether a person is Jewish, or mentions it very minimally, despite probably that it should. I've also occasionally seen people removing it. That Jewish identity might be a large or a small aspect of that person's overall identity or their biographical outline. I'm just saying it's possible that the pendulum may have swung compared to where it was last.Andre🚐03:18, 17 February 2026 (UTC)[reply]
I think I agree with PARAKANYAA. I left my thoughts in detail on the previous thread, so I won't repeat myself too much. But I think PARAKANYAA raises several strong points, that I may or may not have touched on last time this came up. While in the past there may have been issues with people trying to identify Jewishness in an article for poor reasons, there are a lot of people nowadays who are more concerned with the erasure of Jewish identity or history, so it's a bit of a delicate balancing act, which is why I don't think a special guideline is a good idea. I can't stop anyone from writing an essay in their userspace or wherever, but in my view this is probably unhelpful at best. As PARAKANYAA points out, Jewishness is not only a group of religious groups, but an ethnicity (and a cuisine, a literature, an art, a music, etc. several of each, actually) The Kosner diff as noted is not necessarily bad faith and is well-sourced, so it comes down to the subject's personal preference? A related problem is subjects that don't like their bad photos. But the point is well taken that we already have a guideline, and that guidelines are routinely disregarded. So it's hard to see how this would help, except to give admins a clearer excuse to block people, which I don't think is a good idea either in this case. Because it is hard to know if someone is "Jew tagging" out of pride or philosemitism, or bigotry. Good faith would suggest we assume the former, and politely correct people who don't followMOS:ETHNICITY adequately rather than blocking them for a proscribed activity.Andre🚐02:26, 17 February 2026 (UTC)[reply]
I can't see anyone proposing a specific guideline here. In fact I can't really think how one would even write such a thing. Essays advise. They don't mandate, and what we (or at least some of us) are advising is a little more care about reductionist labels, and a little more consideration for the complexities of real people. That, and being prepared to deal with those who resort to reductionist labelling to push their PoVs of one sort or another.AndyTheGrump (talk)03:05, 17 February 2026 (UTC)[reply]
You are right. Nobody is proposing a guideline, so that is a straw man that I am conjuring. However, it is also the case that Doug suggested in the prior thread perhaps this would help admins block more easily, so that is what I am alluding to. It's also the case that advisory essays can sometimes obtain a high level of community consensus. I don't think this one would, and inherently, the writing of thoughts isn't a harmful or discourageable activity, but there are also other things to do that could be more helpful. For example, as I offered last time, there are plenty of redlinked people that it wouldn't be inappropriate to call Jewish prominently.Andre🚐03:08, 17 February 2026 (UTC)[reply]
Well yes, there are no doubt many missing biographies, including those for people who's Jewishness is an entirely appropriate topic. I can't see how that is particularly relevant to the issue here though, which is what a fair number of us perceive as inappropriate tagging-style content in existing articles.AndyTheGrump (talk)03:13, 17 February 2026 (UTC)[reply]
Everyone is free to spend or not their volunteer hours where they see fit and what interests them. I'm just pointing out that you could say as a community Wikipedia sometimes allocates more time to the litigation of teh drama than content creation. I noticed you mentioned tagging by Bus stop, a user that has been CBANned for over 4 years. Do you have any more recent diffs that show inappropriate Jew tagging? Or examples of articles where you think the old tagging has managed to stick around? Because my experience is that any such tagging is generally promptly dealt with, and there are also false positives in that area.Andre🚐03:23, 17 February 2026 (UTC)[reply]
As you say, everyone is free to spend their volunteer hours where they see fit, and I see no particular reason to spend mine looking for diffs to support my position when you have provided none to support yours. We clearly see things differently as far as this issue is concerned, and it seems its not just me who still sees 'tagging' (not just in regard to Jewishness) as a problem. And please drop the 'litigation and dramah' hyperbole, since we have already established that we aren't advocating rules to litigate over.AndyTheGrump (talk)03:37, 17 February 2026 (UTC)[reply]
Rather than diffs, how about a little searching exercise? Enter "is Jewish." (with the double quotes and period) into an article-space search. You have already agreed with me that a paragraph consisting solely of 'X is Jewish' is inappropriate. Here's the first three I found, in a couple of minutes.[8][9][10]. There are also many more with the same phrase just slapped, context-free, into a paragraph on other things. Given that I've got better things to do with my time than go through all 3912 results the search throws up to find them all, I'll leave that to you.AndyTheGrump (talk)04:03, 17 February 2026 (UTC)[reply]
I agree those articles and "paragraphs" aren't good, but they're all very short and borderline non-notable. For Judith Seidman, looks like the user who added that line was indeffed as a sock later but it at least has a reliable source[11] which is a dead link but at least provides some context:[12] Joel Sherman it was added in November by a temp account without a source:[13] So potentially revertable. The third has a directory entry in the big book of Jewish sports legends. Frankly, all three could potentially be merged to a list or AFD'd. Anyway, I am sure that there are many articles where they do say that the person is Jewish, but it's not really a given that all of those the appropriate remedy is to remove the line, rather than to expand the context.Andre🚐04:13, 17 February 2026 (UTC)[reply]
I fail to see why being 'borderline non-notable' has any bearing on the appropriateness or otherwise of tagging. And if anything, an article being short makes it more noticeable. As for removal or expansion, as I illustrated with my User:Bus stop example, I'm quite prepared to support either, depending on what the source material available has to say - and in that specific case was arguing formore content. I may not always do so, but please don't make out that I'm advocating erasure.AndyTheGrump (talk)04:25, 17 February 2026 (UTC)[reply]
OK, well then I think we agree. These, and the other articles like them, are pretty bad articles, and those lines in those bad articles are also bad. They could potentially in some cases be fixed by expansion. If the eventual Jew-tagging essay says that, then I think it will be hard to criticize it from the angle I am currently taking.Andre🚐04:29, 17 February 2026 (UTC)[reply]
In the past, every baseball player whose ancestors were Jewish was described in Wikipedia as a "Jewish-American baseball player", while those whose ancestors were not Jewish were described as an "American baseball player". (Black American players were separately tagged.). This is, of course, offensive. The euphemism "from a Jewish family" can be deployed to tag Jews whose families have not identified as Jewish for generations. It is a particular irony that Wikipedia continues to employ the Nüremberg laws to define who is a Jew.MarkBernstein (talk)04:45, 17 February 2026 (UTC)[reply]
If it isn't, it is presumably those objecting to the earlier gratuitous Jew-tagging (along with other ethno-tagging etc) who deserve thanks for cleaning things up. And it seems there are those of the opinion that there is still work to do: hence the proposal for an essay.AndyTheGrump (talk)05:11, 17 February 2026 (UTC)[reply]
Maybe. I've been around for a while but there are some significant gaps in my contribution history. And I really wasn't tuned into this problem or editing in these areas in some of the older timeframes when it may have been happening. But a lot has changed on Wikipedia since then. I've been editing pretty regularly since returning in 2022. And I've definitely noticed that emphasis on reliable sourcing, BLP policy, due and undue weight, and other stuff like that is significantly greater than say, 2004-7ish. Plus the evolution of the contentious topics regimes that deal with a lot of political things. So that might have something to do with why so-called Jew or ethnicity tagging is less troublesome or dealt with more easily. I think there is also a shorter leash for tendentious and problematic editors. Which is for the good, in my view. That's why I challenged the idea that it is a current problem. I am aware of some concrete situations where a Jewish background was removed or omitted and I thought it should be there. But I'm not talking about celebrity actors or ball players, I'm talking about long-dead historical personages. At any rate, I wonder what MarkBernstein makes of the idea that the fix for it might be to expand, not remove, the mention of Jewish heritage. It is also possible that if a Jew-tagging essay is created, perhaps a counter-essay would be needed. I think Wikipedia, at least in its present-day incarnation, has a skew toward post-national, citizen of the world-type philosophy. That often means that mention of heritage or cultural context can not seem very relevant or important. I think in the last discussion, someone said they didn't believe it was ever relevant to a biography to say. Anyway, I just want people to consider both sides of this and check whether some perceptions of how prevalent this problem is or how it is handled might be outdated.Andre🚐05:34, 17 February 2026 (UTC)[reply]
In the absence of significant prior discussion and workshopping to determine what the scope and processes would be, there is absolutely no chance that a process that was not adopted after a short trial over 20 years ago will be adopted now. Additionally, the discussion below additionally suggests that there is not a great deal of appetite for a process like this, so further discussion may not be the best use of editor's time, although there is not a consensus against doing so if anyone genuinely thinks differently.Thryduulf (talk)19:02, 16 February 2026 (UTC)[reply]
The following discussion is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Quickpolls were a trial of a system for making fast decisions about problematic users. They consisted of polls among Wikipedia regulars on issues that needed to be quickly resolved. It operated from March to June of 2004, although some action continued into July.
PerWP:RFCBEFORE this RfC is grossly premature, given that there has been no prior discussion on the topic (or none for around 20 years), very few people will be familiar with the way things were done back then, and it is self-evident that it isn't remotely compatible with current practice. Anything remotely related would need substantial revision, rather than 'bringing back' unchanged. An absurd proposal.
No. You didn't even link toWikipedia:Quickpolls/Rules, which people need to see what you're proposing. And... none of the use-cases Quickpolls existed for are a problem today. Specifically, they were for:
WP:3RR violations. Nowadays admins can just act quickly, we don't need to run some sort of poll.
A sysop misusing their abilities (quickpolls could, apparently, desysop? But only temporarily) I think that it is obvious from looking at the reception toWP:RECALL that quickpolls are not going to replace it.
A user goes on a rampage. Modern admins are empowered to just block in that case.
A user confesses to deliberate trolling. Again, an admin could just drop aWP:NOTHERE block on them, though this is less pressing than the above so I'm not understanding why it needed to go to quickpolls anyway.
It feels like you're anticipating using them for other things (you talk vaguely ofproblematic users) but if so, that's a totally new proposal and you need to spend moreWP:RFCBEFORE time talking about it... and I doubt it would go anywhere. The hard questions, likeWP:TEND /WP:CPUSH editing, are, well... hard. Usually they involve back-and-forth accusations and it takes time for uninvolved editors without a deep knowledge of the subject and the sources to untangle who's making reasonable arguments and who isn't. Quickpolls aren't going to help with the sorts of things that we actually have trouble with today; the things that theycould resolve, we're mostly pretty good at handling with existing methods (ie. an admin can act swiftly to put out an immediate fire, then later it can get brought to AN/I for review and discussion if there are lingering disagreements or issues.) --Aquillion (talk)17:54, 16 February 2026 (UTC)[reply]
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
