The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
This is a high-visibility page intended for proposals with significant impact. Proposals that affect only a single page or small group of pages should be held at a corresponding talk page.
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
baby globe
to celebrate wikipedia's 25th anniversary, a toggleable "birthday mode" has been created. it consists of easter eggs involving baby 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, by 26 january, administrators can configure the mode through community configuration; and the mode will be public from 16 february to 16 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 on Wikipedia: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
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]
Support option 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's not 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 me17:50, 20 January 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 of Depths 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 that used to be), if you look at the page 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 or Option 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]
Looking at the 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, like Chronophotography, but also ones you may not, like Swing bridge and Panenka. 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 is Extension: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 is Thryduulf'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. Chaotic Enby (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. Chaotic Enby (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 for that 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. Chaotic Enby (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 from banner 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! Chaotic Enby (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 lines F1fan00 (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 this very 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 a version 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 a first 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 this default 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 in the 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 or not 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 censored outside 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 the Google 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]
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 a plushie, 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 a greenland shark, at 25 years of age it would still be considered a juvinelle (and shark plushies are quite popular btw). So plushies can symbolically 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]
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) 17:22, 26 January 2026 (UTC)[reply]
Support per Aaron Liu. I've long found this a useful guide and personally never had it questioned as only 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 at WP:INVOLVED as guidance on involvement for non-administrator actions - also not a guideline but quasi-advertised as such. Likewise we have Wikipedia:Requested moves/Closing instructions, as a subpage of RM no less, which again is nothing 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, "enforced BRD" is referenced in WP:STANDARDSET, whereas BRD is only an essay intended as advise. Given it describes an optional 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 everything needs a tag, but if there are sets 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 linked need 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 many optional 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 of Wikipedia:Rough consensus is derived from the Internet 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 under RFC7282, 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 as Consensus 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 from formal closure is neither necessary nor advisable to RFCEND's involved 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 at WP: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's Editors 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 says involved editors should be able to close most discussions. If it does, that should be removed as it directly contradicts WP: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]
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: A WP: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 be WP: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 than If 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 boldly added 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]
It helps prevent the (factually incorrect) wikilawyering over "well that discussion was never closed so there's not a true consensus". Katzrockso (talk) 13:54, 30 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. Maybe Wikipedia: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]
I'd like to open a wider conversation about the wider practice of including those winter storm names in articles. The storm names are called a "marketing ploy" in that storm article above, and so we should really have something stronger than a silent consensus to back up their inclusion (see background below).
Ideally, coming out of a discussion here we would have either an affirmative consensus of the status quo or a reversal of the TWC guidance. This could also instead act as a WP:RFCBEFORE if a wider discussion is needed.
The on-wiki guidance is at the WikiProject level with WP:TWC. The inclusion of the names within articles does not appear to have been recently tested at any level above a silent consensus and various small discussions on article talk pages. Specifically, TWC says that an "understood consensus" exists that "allow[s] mention of the TWC names within the articles, as long as said names are not part of the article title and that there is a "silent consensus for this method and process".
Meteorological agencies in some parts of the world assign names to winter storms, but in the United States, only hurricanes and tropical storms get official names from the National Weather Service. Since 2012, The Weather Channel has used its own list of names for storms, a move that has been criticized as a marketing ploy. It is calling this one Fern.
I am against using TWC names but they are (unfortunately) widely used in news sources. Since the names are used nationwide and not just locally, support status quo, which makes it clear that the names are unofficial. HurricaneZetaC16:17, 27 January 2026 (UTC)[reply]
Support status quo ante bellum. I see no reason to change how we’ve been handling these with a small mention in the lead. As Zeta said, once you have the names being referenced by media outlets it becomes hard to ignore, and we should not leave it out, as some readers may find it helpful. Zeta made it pretty clear as well, and we should not move the article names to them. MarioProtIV (talk/contribs) 20:18, 27 January 2026 (UTC)[reply]
Support I honestly don’t see what the big deal is. There are many storms with unofficial names like Superstorm Sandy, Snowmageddon, The Beast, etc. Trying to take out one nickname/unofficial name is just a waste of time and honestly sounds stupid to me because it’s just nitpicking for no reason, especially when numerous media outlets use them. ChessEric06:43, 29 January 2026 (UTC)[reply]
Overall I think that this should be treated as a navigation issue and similar to how we treat nicknames for people or organizations. We should include the names if readers might be looking for them (e.g., to make sure that they're reading about the storm that they want to read about). We should consider bolding the name if a redirect points there, under the same rules we would bold a nickname. The approach of explicitly labeling it an "unofficial" name sounds good to me. I think the quotation from The New York Times about a "marketing ploy" is unnecessary, but there's nothing inherently wrong with providing a brief quotation from a paywalled source. WhatamIdoing (talk) 16:11, 30 January 2026 (UTC)[reply]
Support trying to get rid of it because it’s “a marketing ploy” or whatever seems like WP:GREATWRONGS (or at least pretentiousness, as if a for-profit source is too good for Wikipedia), as does mentioning that the NYT considers it as such. As long as it’s not the article title and explicitly stated to be unofficial it’s completely fine. Dronebogus (talk) 01:31, 2 February 2026 (UTC)[reply]
I agree. In particular, when we tell the life-story of a historical figure, we tell it in chronological order, from birth to death. For historical figures it looks plain silly to list their life backwards. As one typical example, we list the ships commanded by Sir William Parker, 1st Baronet, of Shenstone in order from the first he commanded, to his last command. Since all our subjects will eventually become historical figures, and we're in the business of telling history, it makes sense to use chronological order from the get-go. The place where "most recent service" style is relevant is (1) in CV's (for impact, not our role), and (2) in articles about the post, not the post-holder. For a post that's important and ongoing, we need to give prominence to the current post-holder, but usually we do that by labelling them as incumbent in the info-box; the former post-holders are still in chronological order (see Secretary of State for Education for example). Pierre Trudeau's info-box is a really good example of a totally confusing layout because of its most-recent-service style. It's particularly inconsistent when the box is listing multiple posts, with some fully-enclosed in the time-line of another, for example his leader of the opposition, which is entirely enclosed in leader of the liberal party. If the whole thing were chronological, we'd quite intuitively order everything by start-date. Elemimele (talk) 17:15, 27 January 2026 (UTC)[reply]
Also agreed. It's rather confusing to go back in time like that, especially in an example like Trudeau where the first term was so long that it's very surprising to jump from reading 1984 to 1968. Cremastra (talk·contribs) 16:40, 28 January 2026 (UTC)[reply]
Is the proposal that lists may, should or must be as you describe? And are you proposing to order the entire infobox chronologically (irrespective of any order of precedence that might hypothetically be relevant), or just the entries under a single infobox heading (irrespective of where it lies in the infobox)?
Would it not be best to have this put the current or most recent office at the top? That's usually the one people are looking for, after all. WhatamIdoing (talk) 18:53, 30 January 2026 (UTC)[reply]
It depends, though. If the person is currently in office, they're probably looking for the times of the current service. In the Pierre Trudeau example, though, he was last in office some forty years ago: it's more informative to start at the beginning of his first term, as the reader will probably want to know about his tenure overall, not just his most recent stint as PM. Cremastra (talk·contribs) 18:57, 30 January 2026 (UTC)[reply]
Would this be desirable: Within a heading, start with the oldest entry on top. Within an infobox, order the headings with the most recent on top (irrespective of the order of entries inside that heading).TheFeds07:42, 31 January 2026 (UTC)[reply]
Example - For Trump's infobox? I recommend having "January 20, 2017 – January 20, 2021", be above "January 20, 2025 – present". GoodDay (talk) 22:14, 2 February 2026 (UTC)[reply]
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 lack APNG support are Internet Explorer and Opera Mini, which are extremely rarely used worldwide[1], and AVIF has major web browser support[2], and currently even an entry-level notebook can commit real-time SVG rendering quite quickly, just like in 2007, many PCs can not commit smooth H.264 decoding, yet not long after even an entry-level notebook can do so, and GIF lacks true color and color management support, this proposal won't harm. By the way Wikimedia Foundation can announce that IE and Opera Mini will be unsupported after 3 months, making exploiting newer web technologies (e.g. the newest edition of ECMAScript) possible and reducing the burden of newbies of the Mediawiki 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 accessing http://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, and Foundation 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]
Proposed version of location map (click for interactive map)
Right now when you click on a location map, it takes you to the file page for the underlying map. I think this is really unintuitive and problematic for accessibility, as many users will want to enlarge the map. I think that instead, when you click on it, it should open an interactive Kartographer map. I've implemented a new version of Location map that does this, as can be seen to the right.
Do people here think that would be a good change to make, or have alternative ideas for how it might work? For example, another user mocked up a version that enlarges the location map rather than opening a Kartographer map. But personally I like my version because I feel that it combines the best of Location map and Maplink: a clean hand-made map for small scales, and a more detailed interactive map for large scales.
Support both options over the status quo, with a preference towards the interactive Kartographer map. Even though most of the time (but not always), a {{Coord}} template linking to GeoHack can be found nearby, I find the UX from current version of Module:Location map with the little red dot (File:Red pog.svg) confusing and often annoying. —andrybak (talk) 23:21, 4 February 2026 (UTC)[reply]
Support Our current locator maps are poorly sourced in general, are wildly inconsistent, poorly maintained, and many of things they show might be POV pushing. An alternative is preferable. GeogSage (⚔Chat?⚔) 23:39, 4 February 2026 (UTC)[reply]
I like this idea. One question that comes to mind, is how this would handle historical locations where zooming out to reveal a world map with modern borders may not be desirable. signed, Rosguilltalk23:46, 4 February 2026 (UTC)[reply]
On this note, how does this logic map to the equivalent inside {{mapframe}}? I've occasionally wondered if it would be possible to have both a zoom for the thumbnail (which we use a lot) and a zoom for the big modal window there. --Joy (talk) 13:43, 6 February 2026 (UTC)[reply]
For mapframes, the scale always stays the same between the thumbnail and the big window (so the big window shows a larger area). For this sandbox module, I tried to get the big window to show the same area as the thumbnail (so the big window is at a larger scale), but it's imperfect because you can't control the centering in the big window, and there's only a finite number of allowable zoom levels. Justin Kunimune (talk) 00:04, 7 February 2026 (UTC)[reply]
First of all, I love Kartographer, I've myself brought it to thousands of articles. Unfortunatelly, I don't think this is the way to go, at least not until Kartographer gets more layers, such as different terrain options. The red pog not appearing when you click on a location map shouldn't be too hard to fix, if people choose to do so. That's a bug. But clicking on a relief map, and getting something completely different is a WP:SURPRISE, so a NO from me. One day we'll be able to replace Location maps with Kartographer. Let's all support m:Community Wishlist/W323.Ponor (talk) 01:12, 5 February 2026 (UTC)[reply]
Support Red pog disappearing when clicking a location map is suboptimal, and it's unlikely to be an easily fixable problem. This proposal seems like a clear improvement over the status quo. – SD0001 (talk) 06:41, 6 February 2026 (UTC)[reply]
Have you noticed the various discussions about {{MergedMap}} and {{infobox mapframe}}? I think this variant of location maps + big mapframe is interesting, but it seems like we're beating around the bush :) The location map thumbnails aren't actually necessarily good, so maybe we shouldn't focus on trying to polish them, but replace them with mapframe thumbnails by default, and only keep some which aren't just "good enough for 2008" but actually still have documented redeemable qualities. --Joy (talk) 13:37, 6 February 2026 (UTC)[reply]
I'm not sure if Kartographer is the right solution, but opening up a base map is not helpful so I appreciate the experimentation. CMD (talk) 13:52, 6 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 on WP: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]
On Vector 2022...
...and on Minerva Neue
Question: is it possible to control the zoom at which the big Kartographer map opens? —andrybak (talk) 23:57, 4 February 2026 (UTC)
You are invited to join the discussion at Wikipedia talk:Citing sources § Moving forward with Reference Check. Sdkb‑WMF talk 07:02, 5 February 2026 (UTC)