Movatterモバイル変換


[0]ホーム

URL:


Jump to content
WikipediaThe Free Encyclopedia
Search

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
"WP:PROPOSE" redirects here. For proposing article deletion, seeWikipedia:Proposed deletion andWikipedia:Deletion requests.
Discussion page for new proposals
 Policy Technical Proposals Idea lab WMF Miscellaneous 

Theproposals section of thevillage pump is used to offer specific changes for discussion.Before submitting:

Discussions are automatically archived after remaining inactive for 7 days.

Centralized discussion
For a listing of ongoing discussions, see thedashboard.

RfC: Increase the frequency of Today's Featured Lists

[edit]
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.
Option 1 had consensus. Some editors asked for a later review a la Option 4 but as some participants pointed out, if there are problems, a discussion can be started or the schedule reverted at any time. There was the suggestion that each of a three-person team schedule one TFL per week, to be worked out by the volunteers involved. The concern against going to four per week was that might result in lack of topic diversity, and frequency can always be increased later if the backlog keeps growing. There was explicit opposition to showing featured lists for more than one day. --Beland (talk)20:19, 8 December 2025 (UTC)[reply]

Increase the frequency of Today's Featured Lists from 2 per week to 3 or 4 per week, either on a trial basis, with the option to expand further if sustainable, or without a trial at all.Vanderwaalforces (talk)07:02, 2 November 2025 (UTC)[reply]

Background

Right now,Today's Featured List only runs twice a week; that is Mondays and Fridays. The problem is that we've built up a huge (and happy?) backlog because there are currently over 3,400Featured Lists that have never appeared on the Main Page (see category). On top of that and according to ourFeatured list statistics we're adding about 20 new Featured Lists every month, which works out to around 4 to 5 a week, and looking at the current pace of just 2 per week, it would take forever to get through what we already have, and the backlog will only keep growing.

Based onprior discussion at WT:FL, I can say we could comfortably increase the number of TFLs per week without running out of material. Even if we went up to 3 or 4 a week, the rate at which new lists are promoted would keep things stable and sustainable. Featured Lists are one of our high-quality contents and they get this less exposure compared toWP:TFAs orWP:POTDs, so trust me, this isn't about numbers, and neither is it about FL contributors being jealous (we could just be :p). Giving them more space would better showcase the work that goes into them. We could run a 6‑month pilot, then review the backlog impact, scheduling workload, community satisfaction, etc.

Of course, there are practical considerations. Scheduling is currently handled byGiants2008 the FL director, and increasing the frequency would mean more work, which I think could be handled by having one of the FL delegates (PresN andHey man im josh) OR another experienced editor to help with scheduling duties.Vanderwaalforces (talk)07:03, 2 November 2025 (UTC)[reply]

Options
  • Option 1: Three TFLs per week (Mon/Wed/Fri)
  • Option 2: Four TFLs per week (e.g., Mon/Wed/Fri/Sun)
  • Option 3: Every other day, with each TFL staying up for two days (This came up at the WT:FL discussion, although it might cause imbalance if comparing other featured content durations.)
  • Option 4: Three TFLs per week (Mon/Wed/Fri) as a 6‑month pilot and come back to review backlog impact, scheduling workload, community satisfaction, etc.
  • Option 5: Four TFLs per week (e.g., Mon/Wed/Fri/Sun) as a 6‑month pilot and come back to review backlog impact, scheduling workload, community satisfaction, etc.
  • Option 6: Retain status-quo

Discussion (TFLs)

[edit]
  • Generally supportive of an increase, if the increase has the support of Giants2008, PresN, and Hey man im josh. Could there be an elaboration on the potential main page balance? TFL seems to slot below the rest of the page, without the columnar restrictions.CMD (talk)10:01, 2 November 2025 (UTC)[reply]
    @Chipmunkdavis Per the former, yeah, I totally agree, which is why I suggested earlier that one of the FLC delegates could help share the load, alternatively, an experienced FLC editor or someone familiar with how FL scheduling works could assist. Per the latter, nothing changes actually, the slot for TFL remains the same, viewers only get to see more FLs than the status-quo. It might fascinate you that some editors do not know if we have TFLs (just like TFAs) on English Wikipedia either because they have never viewed the Mainpage on a Monday/Friday or something else.Vanderwaalforces (talk)17:06, 2 November 2025 (UTC)[reply]
  • Support Option 2 with the Monday list also showing on Tuesday, the Wednesday list also showing on Thursday and the Friday list also showing on Saturday— Precedingunsigned comment added byEasternsahara (talkcontribs)16:28, 2 November 2025 (UTC)[reply]
  • Option 1, for two main reasons: (1) there is no reason to rush into larger changes (we can always make further changes later), and (2) FL topics tend to be more limited and I think it's better to space out similar lists (e.g., having a "List of accolades received by <insert movie/show/actor>" every other week just to keep filling slots would get repetitive). Stronglyoppose any option that results in a TFL being displayed for 2 days; this would permanently push POTD further down, break the patterns of the main page (no other featured content is up for more than 1 day), and possibly cause technical issues for templates meant to change every day.RunningTiger123 (talk)18:08, 2 November 2025 (UTC)[reply]
  • Option 1 – Seeing the notification for this discussion pop up on my talk page really made me take a step back and ponder how long I've been active in the FL process (and my mortality in general, but let's not go there). I can't believe I'm typing this, but I've been scheduling lists at TFL for 13 years now. That's a long time to be involved in any one process, asthis old graphic makes even more clear. Where did the time go? Anyway, I agree with RunningTiger that immediately pushing for 4+ TFLs per week when we may not have enough topic diversity to probably support that amount would do more harm than good, but I think enough lists are being promoted through the FL process to support an increase to three TFLs weekly. In addition, I agree with RT that we don't need to be running lists over multiple days when none of the other featured processes do.
    While I'm here, I do want to address potential workload issues. My suggestion is that, presuming the delegates have the spare time to take this on, each of us do one blurb per week. With the exception of the odd replaced blurb once in a blue moon, I've been carrying TFL by myself for the vast majority of the time I've been scheduling TFLs (over a decade at this point). If I take a step back and ignore the fact that I'm proud to have had this responsibility for the site for this many years (and that the train has been kept on the tracks fairly well IMO), it really isn't a great idea for the entire process to have been dependent on the efforts of a single editor for that long. I just think it would be a good sign of the strength of the TFL process for a rotation of schedulers to be introduced. Also, in the event of an emergency we would have a much better chance of keeping TFL running smoothly with a rotation. Of course, this part can be more thoroughly hammered out at TFL, but I did want to bring it up in case the wider community has any thoughts.Giants2008 (Talk)01:42, 4 November 2025 (UTC)[reply]
  • Option 1, and I'd be willing to do some TFL scheduling. --PresN15:59, 4 November 2025 (UTC)[reply]
  • Option 1, though I would support any permanent increase to the frequency of TFLs as long as the coords or other volunteers have the capacity for that.Toadspike[Talk]20:13, 4 November 2025 (UTC)[reply]
  • Option 4, let's see if some backlog can be cleared and evaluate the workload.BlueRiband►01:00, 5 November 2025 (UTC)[reply]
  • Option 1, sounds like the best option to me at this stage. –Ianblair23(talk)12:26, 12 November 2025 (UTC)[reply]
  • Option 1, Slow changes are better. Also, this doesn't explicitly need to be a pilot (opt4) since we can always switch back to the status quo ante if unforeseen problems crop up. -MPGuy2824 (talk)14:20, 12 November 2025 (UTC)[reply]
  • Option 1, in agreement with others. I would be open to an increase in frequency after some time, with input from editors involved in TFLs about the impact of the initial change. —Myceteae🍄‍🟫 (talk)20:15, 12 November 2025 (UTC)[reply]

Option 1, but I think that this should be trialled and then returned for further discussion based on how it affects the backlog and the wider response to the change.JacobTheRox(talk | contributions)20:45, 20 November 2025 (UTC)[reply]

Based on your response, you should choose option 4. -MPGuy2824 (talk)04:35, 21 November 2025 (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.

RFC: Disable unregistered editing and require all editors to register

[edit]
THAT'S BAIT
Nothing to see here, folks.asilvering (talk)04:03, 24 November 2025 (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.



Should everyone be required to create an account prior to editing the English Wikipedia?ColdNerd (talk)03:27, 24 November 2025 (UTC)[reply]

  • Option 1: Status quo
  • Option 2: Run a 6-month trial (similar to ACTRIAL) and review results afterwards
  • Option 3: Disable unregistered editing now

ColdNerd (talk)03:27, 24 November 2025 (UTC)[reply]

At the previous discussion, as well as [[1]], there appears to be significant discussion about and support for restricting or terminating unregistered edits. Therefore, I have opened a formal RFC.ColdNerd (talk)03:27, 24 November 2025 (UTC)[reply]

  • Oppose (Option 1). In my short time on Wikipedia, I've done mostly anti-vandalism work. I revert a lot of IPs. However, they usually get reverted quickly, and shout out to the team maintainingedit filters. I also see a lot of gnome-like work by IPs; just someone who noticed a typo, and wanted to fix it. Because I think the consequences of allowing unregistered editing are mitigated pretty well, and that IPs do improve Wikipedia, I want to oppose this proposition.win8x (talk)03:43, 24 November 2025 (UTC)[reply]

Discussion

[edit]

@ColdNerd: Do you have any evidence that things have become worse since the introduction of temporary accounts? I am not seeing an uptick in misbehaviour at this point. Anon's are still doing useful or harmless work, and now there is more targeted ways to feedback to an unlogged-in user. The biggest problem for me so far is that it is not easy to copy the temporary account name in the source editor as it is using special markup.Graeme Bartlett (talk)03:54, 24 November 2025 (UTC)[reply]

It's becoming harder to report vandals properly, and the new rules about disclosing IPs of temporary accounts are a nightmare. Also, I don't like the idea of anyone with 300 edits being able to see IPs. Do you want one ofIcewhiz's sockpuppets to gettemporary account IP viewer? If you really are concerned about evidence, we could run a trial.ColdNerd (talk)03:57, 24 November 2025 (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.
PingColdNerd,Asilvering,Win8x,Graeme Bartlett
I for one regret the speedy closure of this discussion, though I think the proposal was premature. IMO the new Temp Accounts have complicated anti-vandalism efforts on the part of those investigating and reporting suspected vandalism, as well as admins when responding to these reports, especially at AIV. FWIW, I think it would be a good thing if we had a community wide discussion on the impact of the new system, perhaps atWP:VPI, though it appears there is already one in progress atWP:VPW. -Ad Orientem (talk)01:12, 28 November 2025 (UTC)[reply]
Ad Orientem, by all means start whatever conversation you like. You, unlike this LTA, have the standing to do so. --asilvering (talk)02:22, 28 November 2025 (UTC)[reply]
I've left a comment at the discussion on VPW. -Ad Orientem (talk)02:42, 28 November 2025 (UTC)[reply]

RfC: royal family templates

[edit]

Please consider joining thefeedback request service.
An editor hasrequested comments from other editors for this discussion. This page has been added to the following lists:When discussion hasended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Should the templates inCategory:Royal and noble family templates display

  • A. Descriptive titles (like "The Princess Royal" or "The Dowager Princess of Sayn-Wittgenstein-Berleburg" or "The Countess of Carladès"
  • B. Article titles (like "Anne, Princess Royal" or "Princess Benedikte of Denmark" or "Princess Gabriella, Countess of Carladès")

Fram (talk)09:52, 2 December 2025 (UTC)[reply]

(added later): Example of option A[2] vs example of option B[3].Fram (talk)16:05, 2 December 2025 (UTC)[reply]

Discussion (royal family templates)

[edit]

This started with some edits atTemplate:British royal family (but applies to the other templates in the category as well), and was discussed atWikipedia:Village pump (proposals)/Archive 224#Royal family templates.@Katzrockso,Rutebega,Chipmunkdavis,Keivan.f, andGoodDay: all participants in the previous VPPR discussion.Fram (talk)09:56, 2 December 2025 (UTC)[reply]

  • SupportB.Fram (talk)09:56, 2 December 2025 (UTC)[reply]
  • A – The styles used in alternative 'B' are irregular. Either use given and family names, or use titles, but don't create an artificial OR-ish mix-mash. The rules for article titles, which can produce some strange constructions, do not apply to prose or templates. There is no better a reason to reproduce 'Anne, Princess Royal,' in prose any more than we would reproduce some other kind of parenthetical disambiguation, e.g.Georgia (country).Yours, &c.RGloucester10:00, 2 December 2025 (UTC)[reply]
  • (Summoned by bot)A. I agree withRGloucester that that there is no need to combine title and name for the templates in this category it just the title works fine and that there is no obligation to do so under the rules for article titles as they do not apply to templates.GothicGolem29(Talk)13:04, 2 December 2025 (UTC)[reply]
  • A, and I'm somewhat confused by the question. To me this looksextremely obvious. We shouldn't use article titles because that's redundant to the, well, article title. Why on Earth would we repeat ourselves? A is the option that gives our readers new information.—S Marshall T/C14:44, 2 December 2025 (UTC)[reply]
    @S Marshall: You have me completely confused now, perhaps my RfC question isn't clear? Why would we use articles titles in links? Because they are the most recognisable to people? In e.g.Prince Harry, Duke of Sussex, the template has links for The Duke of Edinburgh and for The Duke of Gloucester. Turns out that one isPrince Edward, Duke of Edinburgh and the other isPrince Richard, Duke of Gloucester. Instead of "giving our readers new information", it actually gives "less" information and makes it harder for the non-initiated to know what the link is about.Fram (talk)15:18, 2 December 2025 (UTC)[reply]
    We're clearly talking at cross purposes, yes. Probably not worth spending a lot of words clarifying, considering this is currently not unakin to a landslide.—S Marshall T/C15:37, 2 December 2025 (UTC)[reply]
    Well, I would like to hear your reasoning and what in the RfC question was leading you to that conclusion. It seemed obvious to me that the RfC is talking about the links toother articles on the template, there is no need to have or discuss the link to the article the template is already on. And so I don't see how your !vote has anything to do with the actual question or how it is a valid reason to choose A. Instead of giving new information, option A looses information in many cases.Fram (talk)15:58, 2 December 2025 (UTC)[reply]
    I think that in context you must mean loses, not looses. Now that I re-read, I see that you must mean links in one Royal's infobox to an article about a different Royal, and therefore we were definitely talking at cross purposes.
I've struck my vote because, now that I know what you're talking about, I don't have a strong opinion.—S Marshall T/C16:45, 2 December 2025 (UTC)[reply]
  • A per my comment at the discussion page & RGloucester. Article titles aren't and shouldn't be binding for use in prose/templates. Perhaps there are other issues with the template, but our existing article titles are not the solution.Katzrockso (talk)14:47, 2 December 2025 (UTC)[reply]
  • A I basically have to partially repeat what I said in an earlier post in case some people missed it. The reason the article on someone like Birgitte, Duchess of Gloucester is titled the way it is, is because her actual legal name would be too long and the title alone “The Duchess of Gloucester” would be too ambiguous. Which is why we had to compromise and choose titles such as “Catherine, Princess of Wales”, “Meghan, Duchess of Sussex”, etc. as article titles despite them being styles used bydivorced peeresses. We don't need to perpetuate a wrong format across multiple templates. And as another user already stated, the nuances that apply to naming articles do not dictate how pages should be listed in templates. On top of that, the names and titles among all the articles combined are inconsistent. We haveFrederik X,Queen Mary of Denmark andPrince Joachim of Denmark. The monarch's article title is missing the prefix "King" while the consort's starts with "Queen" and his brother's with "Prince". We just have to take into consideration that not all readers are fluent in English or aware of how regnal numbers work and a single glance at a template where the word "King" is not even associated with the monarch can be misleading. And I'm pretty sure everyone can observe how neat and short the format in Option A is as opposed to Option B which would inevitably add to template length and width.Keivan.fTalk15:23, 2 December 2025 (UTC)[reply]
    You mean the "Meghan, Duchess of Sussex" which is also her official Instagram handle and used by her elsewhere officially[4]? That "wrong format"? Perhaps we chose it as both the common name and the name she uses officially, instead of whatever reason you give here.Fram (talk)15:35, 2 December 2025 (UTC)[reply]
    The "whatever reason" you are referring to is an established convention which if you had clicked on the link that I provided you would have known more about. Meghan's use of her own name is inconsistent as one day she signs her name "The Duchess of Sussex"1, while on other days it's Meghan, The Duchess of Sussex2, or Meghan, Duchess of Sussex. What is consistent is how members of the royal family are listed at royal.uk. And I cannot spot the format [Name], [Title] on theofficial list ortheir social media handles.Keivan.fTalk16:42, 2 December 2025 (UTC)[reply]
A - The status quo suffices.GoodDay (talk)15:11, 2 December 2025 (UTC)[reply]
B or some similar variation that helps readers figure out what they're looking at.WP:Article titles are recognizable, natural, and common, all things that help with navigation and thus help with a navigation template. Readers should not be expected to already know the formal titles of individuals and understand how they relate in this bullet list, with the only context being indentation, the meaning of which the reader must discern on their own. Using article title also helps preventWP:EGG issues, as a title does not go to a page about that title but instead pipes to an individual person.CMD (talk)15:46, 2 December 2025 (UTC)[reply]
B per Fram and the reasons I gave in the previous discussion. This is not about mandating AT guidelines in templates, it's about readability and usability. I strongly disagree that using consensus article titles would be "OR-ish" and while some uniformity might be sacrificed, it seems the status quo is already heterogeneous, with the British template includingPrincess Eugenie andPrince Michael of Kent for example. —Rutebega (talk)19:49, 2 December 2025 (UTC)[reply]
As explained above, 'Anne' and 'Princess Royal' are only combined in the article title as a form ofparenthetical disambiguation (i.e. parenthetical in the sense of what is called 'parenthesis'). The article title cannot be 'Anne' or 'Princess Royal' alone, as both are ambiguous. In prose, she should be referred to as either 'the Princess Royal', or 'Anne', depending on context. There is no other situation where we would reproduce parenthetical disambiguation in prose, and I don't see why we should do so here either. This RfC really has nothing to do with royal or noble titles, which should not be treated as a special case. It is about whether we think it is a good idea to force people to use disambiguated article titles in prose and templates.Yours, &c.RGloucester22:03, 2 December 2025 (UTC)[reply]
If the RfC is about that, shifting the name used to include the recognisable names of the subjects but without unnecessary disambiguation should resolve this. (As it is the current template is already using unnecessary disambiguation, unless "of Sussex" is needed to distinguish Prince Archie from another Prince Archie.)CMD (talk)02:18, 3 December 2025 (UTC)[reply]
In prose, she should be referred to as either 'the Princess Royal', or 'Anne' according to whom? And moreover, what encyclopedic purpose is served by forcing prose to be ambiguous just so it can match someone’s idea of “correct”? What policy or guideline can you cite that would overrideMOS:EGG? —Rutebega (talk)20:31, 3 December 2025 (UTC)[reply]
according to whom? According to a gazillion of sources in which she's referred to as "Princess Anne", "Anne", or the "Princess Royal" in prose. I'm not saying that she's not referred to as "Anne, Princess Royal" at all but that is an uncommon combination within an article's text compared to the others. That being saidMOS:EGG is not a policy. I do understand the urge to be unambiguous but this should not be at the expense of accuracy. Although personally I don't find the current set up ambiguous.Keivan.fTalk03:28, 4 December 2025 (UTC)[reply]
You're right,MOS:EGG is not a policy, it's aWP:GUIDELINE which means it carries the weight ofWP:CONSENSUS. In contrast, English case law and the style conventions of British newspapers hold very little sway here. While we're on the subject, the guidelineMOS:PERSONOROFFICE is quite explicit:"It is necessary for a reference work to distinguish carefully between an office and an incumbent. A newspaper does not usually need to make this distinction". It even uses a highly pertinent example:"The guest list included the Prince of WalesorThe Duke and Duchess of Kent, while common in UK news sources, is ambiguous without a name."Rutebega (talk)23:46, 4 December 2025 (UTC)[reply]
That's actually reasonable but I think it applies generally to article texts, whereby you need to disambiguate who the current Prince of Wales or Duke of Kent is because in most cases articles discussing royalty feature two people carrying the same title but at different times. Whereas in a template we know we will be landing on the personcurrently carrying the title if that makes sense. It's not like that by clicking on The Duke of Kent the reader expects to land on the page about Queen Victoria's father who was also Duke of Kent.Keivan.fTalk15:16, 5 December 2025 (UTC)[reply]
B it makes sense to me to include the person who holds the title, there a handful of titles I can identify without knowing their current holder and their are a ton of people I'd know without knowing their current title, so it makes sense to include both. I do not understand a lot of the dialogue in this RFC though, so maybe I am wrong1brianm7 (talk)04:51, 3 December 2025 (UTC)[reply]
  • Support B in service of readability and avoidingWP:EASTEREGGs. I don't see a reason to keep the current staus quo. Yes it will increase volunteer work because there needs to be a change every time there is a change but that is the case anyway with article titles. It may sound informal but clarity is better than formality imo.WP:SUPRISE applies as well. ~212.70~~2025-31733-18 (talk)17:23, 3 December 2025 (UTC)[reply]
So people are going to be surprised that by clicking on the words "The King" on a template about current members of the British royal family that they will land on the current King of the United Kingdom's page? I see the point in your argument but I think this is a bit of a stretch.Keivan.fTalk03:28, 4 December 2025 (UTC)[reply]
It is a bit surprising. For all of the supposed systematic bias we have, there is no standalone article on the position of UK monarch. We do have these for the currentSwaziland andMalaysia, and the historicalChina andGermany. Relating to the British Monarchy there isEmperor of India, although that is also historical. For the UK, it seems this has been absorbed into the slightly broaderMonarchy of the United Kingdom, which spends much time detailing the role of the monarch (and is whereKing of the United Kingdom redirects to).CMD (talk)03:29, 5 December 2025 (UTC)[reply]
That seems like a bit of a bad argument? It is likely that the reader knows who the King is (unless they were living under a rock since 2021 or so before Elizabeth II's death) but the average reader isn't deep enough in the royal title rabbit hole to know who theDuke of Anjou is unless they are into France or something. ~212.70~~2025-31733-18 (talk)07:21, 5 December 2025 (UTC)[reply]
But people may be surprised to end up atPrincess Caroline of Monaco (a name many people know) when they click "The Princess of Hanover" (a name very few people know). What's the point of having "The Princess of Hanover" in the template instead ofPrincess Caroline of Monaco?Fram (talk)09:40, 5 December 2025 (UTC)[reply]
On that one I agree. Because there was an RM on the page where I advocated for it to be moved to its current title and it was successfully carried out. The change should have applied to the template as well because she is legally a princess of Monaco but Hanover as a sovereign state does not exist anymore.Keivan.fTalk15:09, 5 December 2025 (UTC)[reply]
BReaders should not be expected to already know the formal titles of individuals and understand how they relate in this bullet list, with the only context being indentation. I'm UK, but even I find this format clearer and it mirrors the form used in everyday speech, and to a lesser extent, in the media. I don't find theWP:OR argument persuasive.Pincrete (talk)09:10, 8 December 2025 (UTC)[reply]
B. More informative, more useful. If someone "knows" who the current Prince of XYZ is, more power to them, but the templates should be accessible to all readers. (And this is even assuming that the truly proper form of reference is without such an additional identifying name - it often isn't anyway, rendering this moot and that we absolutely should include the more specific names.)SnowFire (talk)16:32, 8 December 2025 (UTC)[reply]
Neither/Invalid RFC - insufficient consideration for other templates and principled basis.
  1. This seems only a discussion for theTemplate:British royal family, not necessarily any bearing or acceptability for all the templates inCategory:Royal and noble family templates, so the RFC intent to determine all that seems invalid.
  2. Can we get a principled basis stated ? This seems discussing superficial considerations, and I do not see anything in the template itself describing the basis or intent. Rather than a 'consensus-du-jour' on content, can we have a more explicit foundation for what it uses and why in principles or benefits the template is based on stated in the template documentation? I don't much care if theTemplate:British royal family says it tries to useWP:COMMONNAME or article title (not the same thing) -- or have properLetters patent (United Kingdom) andRoyal Style and Titles Act -- or 'to better navigate the related articles', but that such template documentation is absent seems the issue. I can definitely see 'Option B' as easier to understand when used within an article since the article titles would match a portion of the template and each link would be an obvious link to the article named there -- and I can see 'Option A' as more clearly showing theRoyal family by proper titles. CheersMarkbassett (talk)07:21, 15 December 2025 (UTC)[reply]
The opening statement also includes examples of Monaco and Denmark, and later replies are about different countries as well.Fram (talk)11:05, 15 December 2025 (UTC)[reply]

Clarification

[edit]

Whay does 'B' recommend "Charles III", instead of "King Charles III"? Shouldn't 'B' have everyone with either "King, Queen, Prince, Princess" etc?GoodDay (talk)17:46, 8 December 2025 (UTC)[reply]

That's one of the discrepancies of allowing page titles to be used in templates which I pointed out before. And this will be replicated across multiple templates. Can you imagine what will end up happening in some of these templates? We'll have "Naruhito" and "Empress Masako"; literally giving off the impression to a clueless reader that the latter is the monarch when she's not.Keivan.fTalk06:24, 9 December 2025 (UTC)[reply]
There is no objection to adding a clarifier (King, Prince, ...) whatever before an article title if that makes the template more coherent or read smoother. We try to establish a general principle here, not some ironclad rule punishable by death if not followed to the letter. If you want to have an option B+ or C (B, but with the preceding titles added if missing from the article name), feel free to add.Fram (talk)11:08, 15 December 2025 (UTC)[reply]

Is it useful to maintain old IP User talk pages?

[edit]

Disclaimer: I haven't kept up on the new way that IP editors are tracked, so I may be completely off-base. If so, please provide a small trout and a quick hatting of this topic.

Now that we don't have IP editors anymore, is it useful to keep old IP editor talk pages around? Most of them are not harmful, but I recently foundUser talk:144.160.98.31 on a report of Linter errors. Its only edits in the lasttwelve years had been seven edits by bots to perform various cleanup tasks, and when I visited, there were still 18 Linter errors on the page, meaning that someone was going to edit that page in the future to clean it up. I replaced its content with{{blanked IP talk}}. If someone had done that years ago, those seven bot edits would have been unnecessary. It made me wonder if there was any point in maintaining any of the IP editor talk pages, since there are (in my understanding) no more IP editors. Can we just blank them all, or at least blank the ones that have errors so that they don't clog up error reports?

Again, let me know if I am completely off-base here. –Jonesey95 (talk)20:56, 4 December 2025 (UTC)[reply]

@Jonesey95 The argument for blanking old IP talk pages used to be to prevent new users at the same IP from seeing irrelevant messages. Now that that is no longer a concern, I don't see any reason to remove them as they can serve as a valuable historical record of past issues with that IP address (seeWikipedia:Village pump (idea lab)#IP talk page blanking bots, now that we have temporary accounts).--Ahecht (TALK
PAGE
)
21:32, 4 December 2025 (UTC)[reply]
Thanks. I will respond over there. I watch VPT, but not the other village pumps. –Jonesey95 (talk)21:59, 4 December 2025 (UTC)[reply]
Thanks for the link. Apparently a bot periodically blanks stale IP talk pages, and some editors do the same using tools such as AWB. That is done so that if someone new inherits an IP, they don't see stale warnings and other blather on their talk. That clearly is no longer needed and IP talk should be kept as-is. That reduces churn and allows searches and WhatLinksHere to find warnings relating to copy-vios and spam which can be useful when dealing with LTAs. Also clear is that fixing old IP talk for linter errors is not productive and blanking per the OP would be best when linter errors exist. I don't see the point of adding an officious template saying the page is blanked. That was (I think) to give a clue that old messages exist and may be relevant to the current IP activity.Johnuniq (talk)22:02, 4 December 2025 (UTC)[reply]
Helpful response, thank you. I have postedon the idea lab. If people don't like blanking IP talk pages in general, maybe we can carve out an exception for pages with Linter errors and other conditions that might otherwise require human or bot intervention. It would be great to be able to blank every IP talk page that had Linter errors. Please respond over on the idea lab to keep the conversation from forking. Thanks. –Jonesey95 (talk)22:08, 4 December 2025 (UTC)[reply]
@Ahecht andJonesey95: New IP user experiences are not the only argument for blanking. I became interested in the issue because, as a frequent disambiguator, it was easier to see what non-mainspace links needed fixing if large numbers of "What Links Here" results for old IP talk pages were removed from those results.BD2412T15:53, 12 December 2025 (UTC)[reply]
That sounds like a problem that could be solved with a quarry query (or tool that does a database query).--Ahecht (TALK
PAGE
)
00:10, 14 December 2025 (UTC)[reply]
Let's not complicate things for disambiguators (and other bad-link fixers). They're stressed enough with the constant flood of bad links being made into the system.BD2412T01:54, 14 December 2025 (UTC)[reply]

WikiProject:

[edit]

How about using the WikiProject namespace?
eg:Wikipedia:WikiProject Books ->WikiProject:Books
It can reduce it to 11 characters.

Additionally, there have been many similar discussions in the past, but most have been neglected. According to previous discussions, the 'project:' namespace is used to link to Wikipedia from MediaWiki, making it unfeasible. Example:project:wikipediaWhatback11.

The work is done with a bot and the shortcut is done withwpj:. (talk)16:11, 6 December 2025 (UTC)[reply]

If we were going to add a namespace, I would just call it "Project:" space.BD2412T19:15, 6 December 2025 (UTC)[reply]
Project: is actually an alias to Wikipedia:. See, e.g.,Project:VPR goes to this page automatically.KevinL (akaL235·t·c)19:22, 6 December 2025 (UTC)[reply]
That could be changed.BD2412T01:06, 7 December 2025 (UTC)[reply]
I'm not sure it can be, actually. "Project" is the canonical name for the namespace. Just like you can go to any MediaWiki wiki and use "User" or "Template" instead of having to know what the name is in that wiki's language, you can use "Project" no matter what the namespace is named there.Anomie01:35, 7 December 2025 (UTC)[reply]
I am not persuaded because I think we should largely not be creating new namespaces absent a showing that something is really necessary (and I think shortening things a bit is not a sufficiently compelling justification). Best,KevinL (akaL235·t·c)19:24, 6 December 2025 (UTC)[reply]
Wikiprojects areclearly different from regular Wikipedia articles. Several other languages ​​already use this namespace. Typing "Wikipedia:Wikiproject ~" manually is tedious and uncool.Whatback11 (talk)22:14, 6 December 2025 (UTC)[reply]
Also, it can be confusing whenWP:MATH andWP:MATHEMATICS go to separate places, one of which is a help page and the other a project page, or whenWikipedia:Books is a deprecated guideline, and the project on actual books is atWikipedia:WikiProject Books.BD2412T01:09, 7 December 2025 (UTC)[reply]
That is indeed confusing. But perhaps the latter should also redirect to the guideline, and editors should get used to the WPMATH (that is,WP:WPMATH) shortcut. Best,KevinL (akaL235·t·c)23:04, 7 December 2025 (UTC)[reply]
Adding a new namespace won't change what the redirects do: they would still have to be reconciled. In which case, if agreement could be reached, we can do that now.isaacl (talk)03:34, 8 December 2025 (UTC)[reply]
I proposedWPJ:.Whatback11 (talk)19:51, 9 December 2025 (UTC)[reply]
It sounds like a newWP:PSEUDONAMESPACE for WikiProjects would be a lower-overhead way of achieving at least most of what you want.Thryduulf (talk)23:08, 9 December 2025 (UTC)[reply]
As I said, a new namespace won't avoid any confusion on how WP:MATH and WP:MATHEMATICS go to different pages.isaacl (talk)23:27, 9 December 2025 (UTC)[reply]
I like this idea in principle, but the implementation work would be tough. Beyond the multitudinous link updates (which a bot can handle for the most part), there are certainly lots of WikiProject-related database reports and template calls that specify the Wikipedia namespace value that I don't think a bot can be relied on to fix in a lot of those cases.Stefen 𝕋owerHuddleHandiwerk01:39, 7 December 2025 (UTC)[reply]
I'm not sure about this. The Wikipedia space is where the community can discuss more meta-aspects of the project in various discussion boards. Wikiprojects are one of these gathering areas, so they fit within this meta-space. There's no sharp delineation between WikiProjects and other areas of discussion.CMD (talk)04:31, 8 December 2025 (UTC)[reply]
Not all pages in the Wikipedia namespace are meta-discussion spaces. Some contain information or functions of Wikipedia, much like regular articles. WikiProject pages are highly fluid in nature and differ in format and purpose from general discussion spaces. The shortcuts currently used for WikiProjects are not very intuitive, but using “WPJ:” would make them much clearer. Moreover, introducingonly this shortcut by itself does not require any technical modifications.Whatback11 (talk)19:45, 9 December 2025 (UTC)[reply]
No, this shortcut does require modifications to the namespace structure, as it would have to be anamespace alias, like MOS: currently is. While making it apseudonamespace wouldn't require technical modifications, it is a lot more controversial, and even "straightforward" proposed pseudonamespaces like T: don't have consensus for their use.
Additionally, many Wikipedia: pages other than WikiProjects are meta-discussion spaces, likeWikipedia:Administrators' noticeboard,Wikipedia:In the news/Candidates, or even the page you are currently reading! They're not any more similar in function to Wikipedia information pages than WikiProjects are, and it wouldn't make sense to have a separate namespace for each aspect of project management.ChaoticEnby (talk ·contribs)01:06, 10 December 2025 (UTC)[reply]
A new pseudonamespace would not be uncontroversial, but I suspect the proposed WPJ: would be less controversial than T: as it's not ambiguous with e.g. Talk: and there are currentlyno articles starting WPJ:. There are a few articles beginning with WPJ but the only one that is not part of a longer acronym isWPJ a redirect toWorkers Party of Jamaica but that's unlikely to be regarded as particularly relevant.WP:WPJ (a redirect toWikipedia:WikiProject Japan) does exist. WPJ is used in two shortcuts to mean "WikiProject" (WP:WPJGUIDE andWP:WPJM) every other projectspace page starting WPJ (WP:WPJAIL/WP:WPJAILS,WP:WPJAPAN,WP:WPJAX (Jacksonville),WP:WPJOBS,WP:WPJS (Javascript),WP:WPJW (Jewish women) andWP:WPJournals) there is a logical division between the WP and the J so aren't likely to be issues. There are no pages in the article or Wikipedia namespaces starting WPj or Wpj, with or without a colon.
The point of this is to say that while a proposal for a new WPJ: pseudonamespace is far from guaranteed to succeed, it is nonzero. My feeling is that most opposition would be on the basis of a lack of need rather than on ambiguity with encyclopaedia content.Thryduulf (talk)03:42, 10 December 2025 (UTC)[reply]
I oppose creating more namespaces. The current solution is fine. We have far more important things to worry about than typing two extra letters or using "uncool" page titles.Toadspike[Talk]13:34, 8 December 2025 (UTC)[reply]
If I were going to create a new namespace, it would be for XFD pages. There are more than 600,000 such pages in the Wikipedia: namespace. For comparison, there are only a couple thousand WikiProjects (and many of them are inactive).WhatamIdoing (talk)05:17, 10 December 2025 (UTC)[reply]
Wouldn't help with the perception by non-Wikipedians that we are eager to delete stuff :p  novovtalkedits06:34, 10 December 2025 (UTC)[reply]

Removing the GS authorization for United Kingdom systems of measurement

[edit]
GS/UKU REPEALED
We have unanimous consensus to repeal the community-authorized general sanctions on units in the United Kingdom.Toadspike[Talk]11:05, 14 December 2025 (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.


Should theGS authorization for United Kingdom systems of measurement be repealed?HouseBlaster (talk • he/they)21:47, 7 December 2025 (UTC)[reply]

Survey (GS/UKU)

[edit]
  • Support as proposer. Since 2014, we have a GS authorization forsystems of measurement in the context of theUnited Kingdom. To date,zero enforcement actions have been issued and there has beenzero alerts since 2021 (search since2020). It is clearly unnecessary additionalbureaucracy.

    There was an unsuccessful attempt to repeal the designation in2020, which was closed with fears that disruption would resume immediately upon repeal. If it was true then, I highly doubt it is true now: there have been zero alerts in the last four years. Evidently new editors are not causing problems (or else they would be getting alerts); if it is a set number of old guard editors causing problems, a GS authorization is using a sledgehammer to crack a walnut. Standard admin action is sufficient. Best,HouseBlaster (talk • he/they)21:47, 7 December 2025 (UTC)[reply]

  • Support – As the primary author of this sanctions regime, many editors here may be surprised that this was ever a dispute of any significance. In the years prior to this scheme's implementation, editors would edit war over whether metric or imperial units should be displayed first in UK-related articles. This evolved into an elaborate campaign of disruption and Wikilawyering, which was only put to a stop by these GS. The editors that were party to this dispute have long since got the message that this kind of disruption would not be tolerated. While this regime has for many years served as a kind of deterrent, ensuring that the dispute would never flare up again, it is quite clear now that the 'UK units' problem is unlikely to resurface again on Wikipedia. The community has much less tolerance for this kind of behaviour than it did in 2014, and I expect that, even without a GS regime, appropriate action could be taken in the unlikely possibility that it does resurface. Therefore, I support this proposal. I must, however, protest the usage of the term 'repealed'. General sanctions are not legislation; if this proposal is adopted, the community's authorisation will be revoked.Yours, &c.RGloucester22:01, 7 December 2025 (UTC)[reply]
  • Support. I've not seen any significant disruption of this nature on my watchlist, and when I looked at a few of the articles where I would expect this to be an issue (e.g.Metric Martyrs,Metrication in the United Kingdom) I found they and their talk pages were all quiet. And this is despite attempts by the previous government to make it a divisive issue.[5]Thryduulf (talk)22:19, 7 December 2025 (UTC)[reply]
  • Support. Its good to have a proposal to remove rules rather than create more of them, for a change.Phil Bridger (talk)22:33, 7 December 2025 (UTC)P.S. I'm proud to drive a car for which I buy fuel in litres but measure the fuel consumption in miles per gallon.[reply]
  • Support. With no enforcement ever needed and no alerts needed in four years, it's served its purpose and can be retired without any negative consequences. (And thanks for that link,Thryduulf, I didn't even know it was an issue so that was informative.)Schazjmd (talk)22:51, 7 December 2025 (UTC)[reply]
  • Support per HouseBlaster et al.KevinL (akaL235·t·c)23:03, 7 December 2025 (UTC)[reply]
  • Wit below notWIThstanding,support. --Tamzin[cetacean needed](they|xe|🤷)00:43, 8 December 2025 (UTC)[reply]
  • Support. I'm glad this served its deterrent purpose. Job done. --asilvering (talk)02:04, 8 December 2025 (UTC)[reply]
  • Support. The idea that a regime that's never been used once in eleven years is somehow serving some great deterrent effect has never made a lot of sense to me. Maybe I'm wrong, but the spirit ofWP:TRYUNPROT, we at least should find out.Extraordinary Writ (talk)03:13, 8 December 2025 (UTC)[reply]
  • Support: The lack ofany enforcement actions and the drought of recent alerts are clear evidence that this general sanction is not necessary. We should try to make this projectless bureaucratic when possible. As in the previous RFC I participated in here, I'd like tosuggest early closure of this discussion, given the so-far unanimous consensus.Chess enjoyer (talk)05:40, 8 December 2025 (UTC)[reply]
    While I agree this probably doesn't need 7 full days, less than 24 hours in is far too soon to be suggesting an early closure. The authorisation has been in place for 11 years, no harm will come if it's in place for another few days.Thryduulf (talk)11:54, 8 December 2025 (UTC)[reply]
    @Thryduulf, I meant early as in, "less than 30 days", not "right this instant." We both agree that this won't need a whole month.Chess enjoyer (talk)15:44, 8 December 2025 (UTC)[reply]
  • Support, with the suggestion that something likeWP:ENGVAR is written into the MOS, with appropriate WP: short link and the equivalent oftemplate:Uw-engvar created (both may exist, I haven’t checked) so that anyone deciding to go to war over customary units,deep sigh, in future can be asked not to with minimum fuss. •a frantic turtle 🐢23:32, 8 December 2025 (UTC)[reply]
    @A Frantic TurtleMOS:UNITS provides guidance about unit order and conversions, which is partly dependent on strong national ties but not on variety of English.Thryduulf (talk)10:59, 10 December 2025 (UTC)[reply]
  • Support per HouseBlaster et. al., it would be helpful to remove this extra layer of bureaucracy since there hasn't been significant disruption in this area for many years. If disruption resumes, admins can take normal actions to resolve any conflicts that might crop up, and if all else fails, we can have a later community discussion on reinstating this sanctions regimeFathoms Below(talk)01:30, 9 December 2025 (UTC)[reply]
  • Support - while I fully understand the original issue was serious enough to warrant general sanctions, no enforcement requests and (AFAICT) only 6 alerts in the past 11 years strongly suggests that everyone involvedgot the point. General sanctions shouldn't be just left in place as a deterrent because we think theremight be disruption in the future. If the same pattern of disruptive editing which led to the 2014 discussion resumes, that's a clear sign that the editors involved are NOTHERE and they should just be blocked.Ivanvector (Talk/Edits)21:10, 10 December 2025 (UTC)[reply]
  • Support if anyone knows why this was even implemented, it was because the UK currently is in a mix of whether to use metric of imperial. For example, the guidance is that any sign with a distance plate can be shown with a +/-10% leeway. This allows the use of 800 yard signs to be actually at 800m (875 yards) rather than 730m, because a yard is 0.9m (within the 10% leeway) and because UK trunk roads have signposts every 100m for use by traffic management crew. In short, metric is used for TM crew, as well as engineers and designers, but imperial is used for drivers, thought petrol prices are sold in litres. (see:Metrication in the United Kingdom, but a note of warning that this article is 6800 words long) But anyway, there hasn't been any recent activity regarding this, to the point that this should be repealed. If anything gets out of hand, theWP:BRD andWP:DR process is here to help, including anRfC.JuniperChill (talk)13:49, 12 December 2025 (UTC)[reply]

Discussion (GS/UKU)

[edit]
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.

Create List of Disasters Attributed to Climate Change

[edit]

I propose a new article that lists disasters associated with climate change, like floods, fires, or droughts. This could be organized into a table of disasters by month, year. Could also list how or why the specific disaster is considered exacerbated/caused by climate change. I think this would be a helpful directory for people wanting to learn about the connection between climate change and current events.

My proposal is similar to these existing articles:

List of areas depopulated due to climate change

List of landmarks destroyed or damaged by climate change

Weather of 2025

2025 in the environment

A standard should be developed for inclusion on the list. I propose that such a standard include that the disaster have some kind of government designation (like state of emergency) and that it have impacted human life or health. Lastly, that sources indicate the disaster was caused or worsened by human-caused climate change. Therefore, a wildfire caused by arson would probably not be included unless sources say climate change played a significant role.

Here's some recent articles that could be included in the list:

Cyclone Ditwah

2025 European heatwaves

2025 Pakistan floods

I'm a new editor and would need help to initiate this proposal.UserDani (talk)20:44, 11 December 2025 (UTC)[reply]

Do you think one or morecategories might be a better starting point for this? I could see a list article being more demanding, especially for a newer editor. You might be able to build it offCategory:Disasters, assuming there isn't already something there that substantially overlaps with your ideas (nothing jumped out at me, but I didn't look that carefully). Just an idea.DonIago (talk)20:52, 11 December 2025 (UTC)[reply]
That seems like a good idea. TheCategory:Natural disasters might be an even better place to start. That said, thisWikipedia:Categorization says "consider whether a list would be more appropriate than a category (or in addition to a category) for a grouping of pages. As examples, a list of Nobel laureates could include dates; a list formatted as a table can provide options for sorting the entries."
I'm happy to do whatever the community thinks is best.UserDani (talk)19:26, 12 December 2025 (UTC)[reply]
Please read the guidance linked to fromWP:LIST before you start.Joe vom Titan (talk)07:29, 13 December 2025 (UTC)[reply]
Curious whetherSuper Cyclone Amphan would make it to this list or not? It was created by abutterfly effect ofCOVID-19.[1]
The pandemic is widely considered as a natural phenomenon of a virus adapting to Human hosts, but the subsequent lockdown was a descision taken by Humans.Cdr. Erwin Smith (talk)11:14, 14 December 2025 (UTC)[reply]
COVID-19 isn'tClimate change, so I'd think probably not.Anomie15:03, 14 December 2025 (UTC)[reply]
How often do actual scientists attribute a specific weather event to climate change, versus statements like "climate change makes extreme weather events like X more frequent and more severe" without drawing a direct connection? Or would most of this list be based on statements from politicians spinning things for political gain (including scientists acting as politicians for funding or favorship) and the popular press spinning things for readership, with pro-climate-change and anti-climate-change editors fighting incessantly over which of these are "good enough" like they doother political issues?Anomie15:03, 14 December 2025 (UTC)[reply]

References

  1. ^"Did the countrywide lockdown act like a catalyst in turning a cyclone to a super-cyclone Amphan?".

Propose new clause to DRN A Rule 2

[edit]

This is in regards toDRN A rule 2.[6] The rule currently doesn't clearly differentiate between DRN participants and completely unrelated third parties.

The point of the rule;

The rule is intended to prevent gaming the system or "forum shopping" where if a case is already handled by DRN, editors must not seek other avenues. However it doesn't account for matters addressing unrelated vandalism or disruptions bynon-participants outside the scope of the DRN dispute.

Problem

For example, if you are engaged in DRN case over a dispute in an article. But a different editor (that is not part of this dispute) starts repeatedly vandalizing that article. It only makes intuitive sense to report that editor to the vandalism noticeboard, and not to DRN as it's not a DRN matter. But one is unable to do so without also technically breaking DRN rule #2. They be forced to withdraw just to make the report.

Proposed Solution

There should had been an exception or clarification. If the disruption is well outside the DRN case. Like it regards a completely different section, and the other editor is not even a participant of the DRN case, then it should be fine to report that user to noticeboards if they don't respond.

Proposed Clause

Editors participating in DRN may report conduct to other noticeboards if the conduct is entirely unrelated to a DRN dispute, and involves an editor who isnot a participant in the DRN case.

This clarification keeps DRN section focused on its intended dispute, while allowing editors to still address unrelated matters through the appropriate noticeboards.JaredMcKenzie (talk)06:06, 12 December 2025 (UTC)[reply]

Consensus on DoubleSpaceBot

[edit]
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.
ThisAccountMightBeNew has withdrawn the proposal.Anomie15:46, 13 December 2025 (UTC)[reply]

I am working on a bot,DoubleSpaceBot, and it would look at articles, search for " " (double space), and also avoid messing with templates and other wikicode. It will take the " ", then it will edit the article to replace all instances of two spaces in a row that are not inside of wikitext stuff and make them " ", a single space. I was just wondering what the community thinks on this, and if I have consensus or not about the bot. Also, I am not sure if this is the right place for this, if it is not, please tell me where the right place is.ThisAccountMightBeNew (talk)14:01, 12 December 2025 (UTC)[reply]

The first two words that come to mind are "pointless" and "WP:COSMETICBOT". The number of spaces in the wikicode makes absolutely no difference to the rendered output and doesn't impact searches, so there is no obvious benefits to making the change and no benefits or other reason for making the change have been included in the proposal.Thryduulf (talk)14:16, 12 December 2025 (UTC)[reply]
No, I mean not in the wikitext, but it is mostly for the text itself, because there are times that two spaces are accidentally placed instead of one on articles, and it can be annoying to remove, but a bot can do so easily, this is not for the cosmetics, but for the article text itself.ThisAccountMightBeNew (talk)14:23, 12 December 2025 (UTC)[reply]
But what are the benefits to doing that? One, two and three (or more) spaces between words are rendered identically so the is no change to the article.Thryduulf (talk)14:26, 12 December 2025 (UTC)[reply]
oh, they are. How do I archive this then?ThisAccountMightBeNew (talk)14:55, 12 December 2025 (UTC)[reply]
You don't. But you can close it though. Also, this comment is a demonstration of what Thryduulf said. It seems like you can stack infite numbers of space and the software will just condense it?~2025-31733-18 (talk)20:42, 12 December 2025 (UTC)[reply]
In addition to the points made above there are editors who prefer two spaces after a period at the end of a sentence. SeeSentence spacing, if you're curious. There's no good reason to change this in the wiki text when it's been written that way by the primary editor(s) of an article, since it makes no difference to the rendered HTML.Mike Christie (talk -contribs -library)00:30, 13 December 2025 (UTC)[reply]
The default way HTML is interpretted is to collapse multiple spaces. So multiple spaces in a WP article source are sent sent to the browser as such, but the browser only displays one. See the CSS spec forwhite-space-collapse for various ways it can be controlled.DMacks (talk)06:12, 13 December 2025 (UTC)[reply]
Thank you everyone for their replies, the community has spoken, how do I close this proposal?ThisAccountMightBeNew (talk)15:33, 13 December 2025 (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.

Use of NIH iCite bibliometric data in scientist biographies

[edit]
icon
Text generated by alarge language model or similar AI technology has been collapsed in line withthe relevant guideline and should be excluded from assessments ofconsensus.
The following discussion has been closed.Please do not modify it.

Hello everyone,I’d like to propose that Wikipedia recognize NIH’s iCite platform as a reliable source for citation impact metrics in biographies of scientists. At present, we often see commercial rankings such as Clarivate’s Highly Cited Researchers list mentioned in articles, but not NIH bibliometric data—even though iCite is government‑backed, open‑access, and reproducible by any reader.Rationale:• Scientific validity: NIH iCite is widely used by granting agencies, universities, and governments to evaluate research proposals and careers. It reflects the consensus of the scientific community rather than editorial judgment by journalists or commercial firms.• Verifiability: Any reader can reproduce the results by entering PubMed‑linked publications’ portfolios into iCite. This makes it uniquely transparent compared to opaque commercial rankings.Neutrality: Presenting percentile data (e.g., “According to NIH’s iCite platform in July 2025, her publications ranked in the 81st percentile of neuroscience papers funded by NIH since 1980”) is factual, not promotional, and avoids subjective interpretation.• Consistency: Wikipedia already allows citation‑based recognitions (e.g., Clarivate’s Highly Cited Researchers list). NIH iCite provides a more rigorous and transparent alternative.Proposal:• Permit inclusion of NIH iCite percentile data in biographies of scientists, provided the data is presented with clear attribution (e.g., “According to NIH’s iCite platform…”).• Encourage editors to list selected publications with PubMed links, so readers can verify the percentile themselves.• Treat NIH iCite outputs as equivalent to other recognized bibliometric honors but avoid editorial synthesis beyond what iCite directly reports.Benefits:• Improves accuracy and neutrality in representing scientific impact.• Reduces reliance on opaque commercial rankings.• Aligns Wikipedia with evaluation practices already standard in science policy and funding.I welcome feedback from the community on whether this could become an accepted standard for biographies of scientists.Thank you!Walerus (talk)23:44, 12 December 2025 (UTC)[reply]

Did you use an LLM to phrase this argument?Joe vom Titan (talk)07:25, 13 December 2025 (UTC)[reply]
Yes, of course. I wrote: "NIH metrics are used every day by granting institutions to rank the grant proposals, by science institutions to evaluate people, by government to decide about funding science. NIH evaluation is by comparable contemporary citation count, which is an evaluation by the science community. Not by a newspaper science editor, who suddenly arbitrarely finds an item interesting enough to write about. Not by Clarivate listing The Best Papers based on unknown murky criteria. NIH data when presented as "among all PubMed- registered worldwide papers on the related neuroscience topics, since 1980, as it stood in the year of 2025" are quite reproducible for everybody, even for journalists - iCite is an open platform. So, if an article provides a list of 10 selected papers by the individual with PubMed links and says that in July 2025 ICite NIH placed that portfolio in the 75% of all NIH-granted papers or in 81% of all published papers globally in this area of neuroscience in the same period - this does not require any additional interpretation, it seems. This is a unique statement valid forever, infinitesimally changing from year to year because of a flow of citations. It is immediately available for verification - by everybody. NIH Icite works across all disciplines and permits to compare them. The link to the personal iCite Analysis page should be provided in an article. NIH iCite and Web of Science ARE reliable secondary sources, with having an open access.". Then I asked Copilot to improve my wording. Even fiction writers do it now!Walerus (talk)06:50, 14 December 2025 (UTC)[reply]
Using LLMs in discussions is discouraged (Wikipedia:LLMTALK).~2025-31733-18 (talk)08:49, 14 December 2025 (UTC)[reply]
The main thing copilot did was make your text longer. So it takes longer to read. That's the opposite of an improvement.Joe vom Titan (talk)19:43, 14 December 2025 (UTC)[reply]
Thank you. You are right. We the immigrant scientists really need at least light editing from LLM, even if it is discouraged, but not forbidden by Wikipedia. But in this case I permitted more wording, because I started a very controversial suggestion for Wikipedia, I expect a lot of resistance.Walerus (talk)20:17, 14 December 2025 (UTC)[reply]
We would much rather hear from you in your own words than hear your words distorted by a chatbot. Wikipedia, as a global project, is very accepting of people who don't have English as a first language. LLM use we're somewhat chilly on.Cremastra (talk ·contribs)02:11, 15 December 2025 (UTC)[reply]
Thank you! As a scientist and educator, I have written hundreds of articles in English, but I still have problems with the English articles (absent in all my Slavic languages), and so I had to ask my collaborators to edit them, or to improve some nuances of wording. I do not want to ruin a good wiki proposal by linguistic errors. Let us not be afraid of LLM in science, if it is used only to smooth out text. Otherwise, my submission will be rejected every time because of the minor language errors.Walerus (talk)02:41, 15 December 2025 (UTC)[reply]
We don't care about minor errors if the text is still understandable. LLMs can change the meaning of your text entirely to what you don't intend it to be. If your text is comprehensible, then it's OK, no need to completely polish it.~2025-31733-18 (talk)17:27, 15 December 2025 (UTC)[reply]

MergeWikipedia:Vital articles withWikipedia talk:Articles for improvement

[edit]

I've tried to get this going for a while and failed to get any momentum/conversation, so I figured I'd try this venue. I've been involved in both projects a bit for a while, and I see some problems that could be overcome by the synergy of combining them. First conversation was back inJanuary at vital articles, andApril at Articles for Articles for improvement. There were a few people in the discussions, but one comment mentioned we would need broader discussion.

Background

[edit]

Articles for improvement suffers a bit from lack of engagement. Proposals can go months without votes, and there are not as many proposals as I'd expect to see. The filter for what articles are nominated is "3 more support votes than oppose votes" with some suggested criteria. These criteria are:

  • Highly important topics. Anything that has top or high importance to a WikiProject is likely highly important.
  • Interesting to the general public. This can be evidenced by page views. Nominations with less than 200 views per day rarely succeed.
  • Needing of improvement, with expansion opportunity. Stubs; start-class, and short C-class articles are the most ideal for improvement. Give due consideration before nominating higher-quality articles.
  • Not targets of controversy. Keep in mind that controversial articles (articles that are the subject of heated discussion, edit warring, or questioned notability) can be very difficult to improve within a week.

Vital articles suffers from a lack of use. A lot of time and energy has been spent curating a list of 50,000 vital articles (based on the project criteria) and other then the tags on the Wikipedia talk pages, the project is not used for much. There are three mainpurposes listed for the vital articles, and the important one for this discussion is "Give direction to the prioritization of improvements of English Wikipedia articles (e.g. which articles to bring to WP:GA and WP:FA status)." The vital article criteria for what makes something "vital" is listedhere. For an article to get added to level 5, it needs at least 4 support votes, and to get to level 4 after that needs 5 or more supports, and so on. Levels 1, 2, and 3 of vital articles are fairly stable, while levels 4 and 5 are still quite dynamic.

The goals and criteria of the two projects seem aligned. The selection criteria for vital articles is stricter then articles for improvement, and the two sets of criteria are fairly similar. As we can only have one article for improvement per week, there is always going to be a bit of a bottleneck, so we need to be quite selective of which articles are nominated.

Proposal

[edit]

Based on this, I propose we merge the two projects, and use vital articles from levels 2, 3, and 4 that are C class or lower as the primary selection criteria (focusing on levels 2 and 3 first). This would limit the articles for improvement a bit and help ensure we are focusing on articles that have passed a few filters that indicate they are viewed as important to the project but have not had the attention they need. Importantly, it makes use on the time already spent at the vital article project, and reduces the overall amount of voting/places to vote, streamlining the process. This would also make use of the resource we have with the vital articles list, and help satisfy the projects goal of prioritizing the pages that need improvement.

Discussion

[edit]

Please discuss here.GeogSage (⚔Chat?⚔)02:53, 15 December 2025 (UTC)[reply]

Merging semi-active projects if similar is not a bad idea, that said, while I've been active with Vitals, I am not active with Improvement. In general, it seems logical that vital articles (read: important articles) should be priotitizxed for improvement. But I fear the organizational intertia and the desire to have one's own playground will make this proposal moot anyway. Let's hope I am proven wrong.Piotr Konieczny aka Prokonsul Piotrus| reply here03:03, 15 December 2025 (UTC)[reply]
I'm not sure what you are trying to achieve with a discussion at the village pump, if the two projects in question didn't express interest in your proposal. In any case, I feel if there is a group of volunteers interested in improving articles from the Vital article lists, they can set up their own process of highlighting an article to work on, without affecting the current articles for improvement process.isaacl (talk)04:18, 15 December 2025 (UTC)[reply]
I have notified the talk pages at both projects. The issue is mostly one of eyes, I don't think many people check the talk page at AFI much, and the more big picture stuff at the vital articles doesn't have a ton of participation. I figured a venue like this could get more people to discuss and think of possibilities. The vital articles has had several contests with financial rewards for improving some articles, and AFI has a good system to notify people about an article for the week. It seems redundant to introduce another system to promote article to improve, and redundant to have voting happening in both places.GeogSage (⚔Chat?⚔)04:31, 15 December 2025 (UTC)[reply]
If you're just trying to look for possibilities, then I wish you hadn't proposed a merger, because that narrows options to a specific one. Personally I'm not too concerned about having multiple queues of articles to improve. That's the reality on English Wikipedia: editors often have specific areas of interest, and so they'll look for interesting articles within them. I think it's better to just find people willing to collaborate following your proposed process, rather than change another project's process to fit.isaacl (talk)04:44, 15 December 2025 (UTC)[reply]
Think of possibilities about how we could execute a merger between the two pages and implement a more streamlined system is what I mean.GeogSage (⚔Chat?⚔)07:10, 15 December 2025 (UTC)[reply]
As I said previously regarding the vital articles initiative, volunteer editors are generally free to spend time on whatever initiatives they like as long as it doesn't have an undue effect or burden on those not participating. I don't agree with forcing the editors participating in the articles for improvement initiative to replace their process.isaacl (talk)17:17, 15 December 2025 (UTC)[reply]
This wouldn't force editors to participate in the articles for improvement initiative, this would use the vital articles as the source for articles for improvement. Rather then nominating articles separately on AIF, they could be drawn from the existing list.GeogSage (⚔Chat?⚔)18:22, 15 December 2025 (UTC)[reply]
The editors participating in the current articles for improvement process haven't expressed an interest in your proposal. I disagree with changing the articles for improvement process to one that the current participants aren't interested in. It's just not necessary; a vital article for improvement initiative is a fine project on its own.isaacl (talk)18:47, 15 December 2025 (UTC)[reply]
AFI nominations page has averaged13 daily views per day since January of this year, with a pretty sharp drop off in July. Thetalk page averages 2 views per day since January of this year. Just level 5 of the Vital articles project, not including the almost 40 sub- pages, has averaged124 views per day during that same period. The main talk page at level 5 is not particularly active, as that is where level 5 policy and quota is discussed, not article nominations. I don't think there are that many editors who even saw my proposals at AFI. The strongest thing AFI has going for it is push notifications when an article is nominated, the vital articles strongest thing is the amount of discussion around items added to upper levels of the list. Making a parallel system is redundant for notifications, separate lists, and maintaining a separate voting process seems redundant when the two projects seem like their goals are extremely closely aligned.GeogSage (⚔Chat?⚔)19:09, 15 December 2025 (UTC)[reply]

Ban temp users from CTOP articles

[edit]

So, I'm over on GENSEX. Back when it was IPs, it was maybe 1 in 100 times where an IP user on a GENSEX article was there to do anything constructive. Now that it's temp accounts that can come back infinite times after being banned or blocked, it's gotten a lot more aggressive. I would thus like to politely suggest blocking temps from CTOP articles, at the very least making a CTOP designation come with an autoconfirmed protection level.Snokalok (talk)13:37, 15 December 2025 (UTC)[reply]

I could see having autoconfirmed restriction for GENSEX as an option, but making it the default for all CTOPs feels like overkill, not least because that would include all BLPs.lp0 on fire ()14:29, 15 December 2025 (UTC)[reply]
I'd be okay with an autoconfirmed restriction for GENSEXSnokalok (talk)14:43, 15 December 2025 (UTC)[reply]
Remember that "CTOP articles" include every article about – and every part of an article that discusses –any living person. Read broadly, this would be a pretty intense restriction. Note also that proposals to amend an existing GS regime must be notified toWP:AN perthis RfC. Best,KevinL (akaL235·t·c)15:48, 15 December 2025 (UTC)[reply]
@Snokalok: If you're still dealing with that one TA, just ignore them and report to AIV. I left advice on your talk page.
For context: Snokalok has been dealing with trolling from a TA-hopping user described inthis ANI discussion for about two weeks now.SuperPianoMan9167 (talk)19:43, 15 December 2025 (UTC)[reply]
It sounds like we need a broader response from admins.
Snokalok, pre-TA deployment, we could block an IP andcookie-block the web browser, and the person could take their phone or laptop to a coffee shop, or power cycle their DSL modem, clear cookies, and just keep going. Now, the appearance is different, but we can still blockboth the IP andalso cookie-block the web browser – just like we used to, even though it doesn't look the same superficially. The new system is exactly as (in)effective at stopping that kind of user as the old system.
You canSpecial:EmailUser a blocking admin to make sure that they're blocking the IP as well as the temp account, but other than that, it's the same problem we've been dealing with for years. To make the revert harassment less visible, you can go toSpecial:Preferences#mw-prefsection-echo and disable notifications for "Edit revert". Then you can follow up when you choose to, via your watchlist orSpecial:MyContributions.WhatamIdoing (talk)22:38, 15 December 2025 (UTC)[reply]
We wouldn't ban all IP editors from CTOPs, so why would be ban all TAs? This is overkill.EvergreenFir(talk)19:49, 15 December 2025 (UTC)[reply]
No. CTOP articles already have many tighter restrictions than other articles, and more and more articles seem to be covered (although I'm finding it difficult to find out how many). Either we need to tighten the restrictions on CTOPS, or to expand the number of CTOPS, as seems to be happening. Doing both would completely change the nature of Wikipedia.Phil Bridger (talk)21:22, 15 December 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1327735859"
Categories:
Hidden categories:

[8]ページ先頭

©2009-2025 Movatter.jp