Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for 7 days.

[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,400 Featured Lists that have never appeared on the Main Page (see category). On top of that and according to our Featured 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 on prior 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 to WP:TFAs or WP: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 by Giants2008 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 and Hey 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 — Preceding unsigned comment added by Easternsahara (talk • contribs) 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). Strongly oppose 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, as this 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. --PresN 15: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. Blue Riband► 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 maintaining edit 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 of Icewhiz's sockpuppets to get temporary 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.
Ping ColdNerd, 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 at WP:VPI, though it appears there is already one in progress at WP: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: Allowing use of AE for community topicwide restrictions

[edit]
ENACTED
This discussion has only been open for about a week, which is far less time than usual for RfCs, but there is no mandatory minimum duration for a Request for Comment. RfCs can be closed once "consensus" emerges, and there's a shifting definition of "consensus". With RfCs that aim to make content decisions we'd define "consensus" as a clear majority of interested, good faith editors that's broadly aligned with our policies, guidelines, and values, but with RfCs like this one, that aim to change Wikipedia's policies, guidelines, processes, or disciplinary procedures, we'd define "consensus" as clear evidence of broad, community-wide support.
It's already clear that community views this proposal as a logical, helpful, and uncontroversial refinement. The broad, community-wide support clearly exists, and I see no benefit in allowing this to run on. I hereby determine that L235's proposal is enacted and the consequent edits may be made.—S Marshall T/C 12:32, 5 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.

There are currently four general categories of general sanctions (i.e., sets of special rules or restrictions that apply across entire topic areas):

  1. ArbCom-designated contentious topics (WP:CTOPs);
  2. Community-designated contentious topics (WP:CCTOPs), which were recently formalized at this recent RfC;
  3. ArbCom-imposed topicwide restrictions (for example, the topic of South Asian social groups is subject to an extended-confirmed restriction; the topic of genetically modified organisms is subject to 1RR); and
  4. Community-imposed topicwide restrictions (for example, the topic of Kurds and Kurdistan is subject to a community-imposed extended-confirmed restriction; the topic of cryptocurrency is subject to 1RR).

Currently, enforcement requests and appeals arising from categories #1-3 can go to either the arbitration enforcement noticeboard (AE) or the administrators' noticeboard (AN), as appropriate. (Enforcement requests tend to go to AE, whereas appeals can go to either venue at the sanctioned editor's choice, as guaranteed by ArbCom's procedures). By contrast, enforcement requests and appeals arising from category #4 can only go to AN.

The question is: should the community allow enforcement requests and appeals arising from all community-imposed general sanctions (including category #4) to be heard at AE (in addition to AN)? 22:52, 29 November 2025 (UTC)

Background

At a recent RfC, the community decided to adopt a standard procedure to govern community-designated contentious topics (CCTOPs) to harmonize the rules governing CCTOPs with ArbCom-designated contentious topics (CTOPs). The community also decided to "authorize enforcement of community contentious topics at AE" (the arbitration enforcement noticeboard).

At the time of the previous RfC, ArbCom's rules only permitted the community to designate AE to hear enforcement requests and appeals for community contentious topics (category #2) and not other kinds of community-imposed topicwide restrictions (category #4).[a] As a result of this limitation, the community was only able to allow category #2 to be enforced at AE, not category #4.

Following an ARCA request, ArbCom has now changed its rules to allow the community to choose to allow any type of GS enforcement request or appeal to be heard at AE.[b] This change only takes effect if the community actively chooses to "assign[] those requests and appeals to the arbitration enforcement noticeboard". The purpose of this RfC is to determine whether the community wishes to make that choice for category #4.

If this RfC passes, editors will have the ability to submit enforcement requests and appeals for each of the four categories of general sanctions at both AE and AN. — Preceding unsigned comment added by L235 (talk • contribs) 22:52, 29 November 2025 (UTC)[reply]

Notes

  1. ^ Specifically, AE could consider requests or appeals pursuant to community-imposed remedies which match the contentious topics procedure, if those requests or appeals are assigned to the arbitration enforcement noticeboard by the community.
  2. ^ Specifically, AE may now consider enforcement requests and appeals from enforcement actions arising from community-imposed general sanctions (including community-designated contentious topics), if the community has assigned those requests and appeals to the arbitration enforcement noticeboard.

Survey

[edit]
  • Support, with caveat. While I agree with the present consensus that this streamlining/harmonization will probably prove to be a positive in general, I think it should probably be noted for all contributors, so there is no confusion moving forward, that part of the discussion on ARCA concerned the fact that under the RfCs authorizing the conversion of the community discretionary sanctions scheme to the community contentious topics system, there was consensus that WP:ANI will remain an accepted forum to bring any appeal of a block, ban, or other sanction assigned to an user by an admin under the auspices of a community contentious topic mandate. That is to say, if this proposal achieves consensus, and Admin_A gives User_B a pageban from Article_C, because Article_C falls under CCTOP_X, then User_B can still choose to take appeal of their pageban to either WP:AN/I or WP:AE.
    Now, although I missed the discussion, I am glad that this was the result of the afore-mentioned RfC. While I have no problem with giving appellants the option to take their appeals to AE for a more constrained, prescribed, and administrator-driven process, I think it is nothing short of essential to the future operation of this project that community vetting of such administrative actions remains a possibility. The rapid and vast expansion of the ArbCom and community contentious topics framework over the last few years is nothing less than a fundamental shift in the way this project is administered and how sensitive topics are approached. I would be surprised if, depending on how you interpret the scope of particular CTOPS, anything less than 60% of this projects articles weren't in some way arguably under at least one CTOP. A guesstimate to be sure, but no one can deny the reach of this system is now extremely broad, and that changes the distribution of authority between ArbCom, the administrative corps, and the rank and file community considerably.
    It is in my view therefor simply essential that a user wishing to appeal a given admin's idiosyncratic call (on scope of CTOPS and whether particular conduct deserves a particular editing restriction or other sanction) remain able to seek community review of that decision, not just have recourse to a small handful of admins volunteering at AE. Again, if that's the process someone chooses: brilliant, and let them be bound by the results. But raucous as ANI/I can be, those fora were designed for situations like this and still have an important role to play. SnowRise let's rap 04:29, 2 December 2025 (UTC)[reply]
  • Support. AE is a good place to be able to hear these requests and it also standardises the situation across all contentious topics. GothicGolem29 (Talk) 13:09, 2 December 2025 (UTC)[reply]
  • Support - We should get rid of unnecessary procedural complexity and provide a streamlined path for dealing with disruptive editing in difficult areas. Robert McClenon (talk) 18:21, 2 December 2025 (UTC)[reply]

Discussion (Allowing use of AE for community topicwide restrictions)

[edit]

Note allowing appeals to be heard at the arbitration enforcement noticeboard, following its standard procedures, means that a consensus of admins will be able to decide upon an appeal, instead of a community consensus. Effectively, this means the community is empowering admins to decide upon appeals of community-enacted topic restrictions, and that the sanctioned user can choose which authority they want to decide the appeal. There are pros and cons to this delegation of authority; I'm bringing it up just to make it clear to all interested editors. isaacl (talk) 02:09, 30 November 2025 (UTC)[reply]

Sure, but I assume most good admins will listen to community feedback before deciding on the appeal, just like how it is now with AE appeals. So we'll have a panel of admins instead of one closing admin on AN. Children Will Listen (🐄 talk, 🫘 contribs) 02:19, 30 November 2025 (UTC)[reply]
An evaluator of community consensus doesn't consider their own opinion when determining consensus. At the arbitration enforcement noticeboard, admins are expressing their own opinions. They can be influenced by comments from others, including non-admins, but are not bound to them. That aspect of the arbitration enforcement noticeboard with respect to the contentious topic procedure is by design: sanctions can't be rapidly overturned by a landrush of community commenters (some people refer to this as more sticky sanctions). Like I said, both approaches have different advantages and disadvantages. isaacl (talk) 05:31, 30 November 2025 (UTC)[reply]
And both are difficult for people new to the discplinary system to understand. I'm tempted to call AE a bench trial, but then it would give the wrong idea. Darkfrog24 (talk) 18:57, 30 November 2025 (UTC)[reply]
I think delegated authority, such as with arbitration enforcement, is the key complicating factor.(*) Ordinary sanctions are performed on the authority of the same entity enacting the sanction, so they are appealed to that entity first, which I think is straightforward enough. This proposal would allow a user that had an ordinary sanction authorized by the community, and skip the step of appealing it to the community, if they choose.
(*) Arbitration remedies are more complicated as they are performed by admins on the authority of the arbitration committee. Sanctions that are performed by an admin under the discretion given by the contentious topics framework are also done on behalf of another authority. Thus it can be confusing to know who is the authorizing entity to which to appeal. isaacl (talk) 21:08, 30 November 2025 (UTC)[reply]
I think what would help those unfamiliar with the appropriate procedures to follow is to unify the front end of the appeal process, and then transition to whatever specific process is required, with the appropriate set of commenters. But I appreciate that in a volunteer environment, it's hard to get consistent volunteer efforts to do the transition work, and so the community prefers to delegate the workload to the sanctioned editor. isaacl (talk) 21:14, 30 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: royal family templates

[edit]

Should the templates in Category: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 at Template:British royal family (but applies to the other templates in the category as well), and was discussed at Wikipedia:Village pump (proposals)/Archive 224#Royal family templates. @Katzrockso, Rutebega, Chipmunkdavis, Keivan.f, and GoodDay: all participants in the previous VPPR discussion. Fram (talk) 09:56, 2 December 2025 (UTC)[reply]

  • Support B. 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. RGloucester — ☎ 10:00, 2 December 2025 (UTC)[reply]
  • (Summoned by bot) A. I agree with RGloucester — ☎ 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 looks extremely 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/C 14: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 is Prince Edward, Duke of Edinburgh and the other is Prince 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/C 15: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 to other 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/C 16: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 by divorced 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 have Frederik X, Queen Mary of Denmark and Prince 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.fTalk 15: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 Sussex 2, 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 the official list or their social media handles. Keivan.fTalk 16: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 prevent WP: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 including Princess Eugenie and Prince 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 of parenthetical 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. RGloucester — ☎ 22: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 override MOS: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 said MOS: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.fTalk 03:28, 4 December 2025 (UTC)[reply]
You're right, MOS:EGG is not a policy, it's a WP:GUIDELINE which means it carries the weight of WP: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 guideline MOS: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 Wales or The 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 person currently 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.fTalk 15: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 wrong 1brianm7 (talk) 04:51, 3 December 2025 (UTC)[reply]
  • Support B in service of readability and avoiding WP: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.fTalk 03: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 current Swaziland and Malaysia, and the historical China and Germany. Relating to the British Monarchy there is Emperor of India, although that is also historical. For the UK, it seems this has been absorbed into the slightly broader Monarchy of the United Kingdom, which spends much time detailing the role of the monarch (and is where King 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 the Duke 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 at Princess 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 of Princess 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.fTalk 15:09, 5 December 2025 (UTC)[reply]
B 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. 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 the WP: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]

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.fTalk 06:24, 9 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 found User talk:144.160.98.31 on a report of Linter errors. Its only edits in the last twelve 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 (see Wikipedia: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 posted on 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]

The 2026 26-article challenge

[edit]

I hereby challenge all Wikipedians to make twenty-six new articles in the year 2026, that being one article every two weeks, with the added catch that these twenty-six articles must correspond with the twenty-six letters of the alphabet (i.e., an article starting with "A" in the first two weeks, with "B" in the second two weeks, and so on). We can be a bit flexible with the letters, so articles on works with titles starting with "The", for example, will count for the first letter following the "The"; and we will count articles on a subject with a name like "Francis Quinn" or "List of people from Queensland" as counting for "Q".

If there are takers, I will set up a project-space leaderboard where editors can self-report. Articles must be on encyclopedia-worthy subjects, so anything that ends up deleted or merged to another title won't count. We'll come up with badges to award for participation and completion at the end. BD2412 T 04:02, 5 December 2025 (UTC)[reply]

26 articles is possible, the alphabet requirement is trickier. Based on the examples you have, I suppose the rule is something like "If it has that letter capitalised in sentence case"? CMD (talk) 05:38, 5 December 2025 (UTC)[reply]
@Chipmunkdavis: That sounds workable. We are somewhat making the rules up as we go along here, but I like that. BD2412 T 15:20, 5 December 2025 (UTC)[reply]
On further reflection, I think perhaps it would be better to allow either article creation or substantial article improvement to count for a given letter, e.g. substantially expanding a stub or sourcing a long-unsourced article. BD2412 T 19:10, 6 December 2025 (UTC)[reply]
Taken. It'll be tricky to find a genus that starts with "X", but there are definitely some. Cremastra (talk · contribs) 21:10, 6 December 2025 (UTC)[reply]
@Chipmunkdavis and Cremastra: I have created Wikipedia:26 for '26 (tweaks welcome). Let's see what fun we get out of this! BD2412 T 22:34, 6 December 2025 (UTC)[reply]

New template Infobox Slovak place

[edit]

I created the template Template:Infobox Slovak place for Slovak municipalities and supmunicipalities. Change (from Template:Infobox settlement): it's added new command car_plate and auto statistics of count people and area size. More in documentacion and look the example on page Fintice. Dušan Kreheľ (talk) 16:25, 5 December 2025 (UTC)[reply]

Please don't. We have spent years merging duplicate templates to {{infobox settlement}}. – Jonesey95 (talk) 16:51, 5 December 2025 (UTC)[reply]
@Jonesey95: Real? Why exist the templates in Category:Templates calling Infobox settlement? Dušan Kreheľ (talk) 17:59, 5 December 2025 (UTC)[reply]
Those templates are using Module:Template wrapper, not just using infobox settlement with a couple of custom parameters. There is a significant difference in maintenance. – Jonesey95 (talk) 19:17, 5 December 2025 (UTC)[reply]
@Jonesey95: Template:Infobox German place doesn't use Module:Template wrapper. Dušan Kreheľ (talk) 20:08, 5 December 2025 (UTC)[reply]
That one still needs to be converted. Please don't make a new one without using the module. It should be easy enough to copy and paste an existing example from the category. – Jonesey95 (talk) 23:54, 5 December 2025 (UTC)[reply]
Note Jonesey95 to Special:Diff/1325860695: My template is not fork, but only sup-layet for Template:Infobox settlement. Dušan Kreheľ (talk) 22:11, 5 December 2025 (UTC)[reply]
@Jonesey95: If i rewrite Template:Infobox Slovak place over Module:Template wrapper, so then is it would be okey? Dušan Kreheľ (talk) 07:29, 6 December 2025 (UTC)[reply]
@Jonesey95: So, I rewrited code. It use Module:Template wrapper now. It would be okey now. Dušan Kreheľ (talk) 13:16, 6 December 2025 (UTC)[reply]
That is better. – Jonesey95 (talk) 15:51, 6 December 2025 (UTC)[reply]
car_plate should be added to Template:Infobox settlement instead. Car plate letters according to counties are common in many European countries. This is highly relevant trivia – often memorized by a large portion of the population. Joe vom Titan (talk) 16:50, 6 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:wikipedia Whatback11.

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

If we were going to add a namespace, I would just call it "Project:" space. BD2412 T 19:15, 6 December 2025 (UTC)[reply]
Project: is actually an alias to Wikipedia:. See, e.g., Project:VPR goes to this page automatically. KevinL (aka L235 · t · c) 19:22, 6 December 2025 (UTC)[reply]
That could be changed. BD2412 T 01: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. Anomie⚔ 01: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 (aka L235 · t · c) 19:24, 6 December 2025 (UTC)[reply]
Wikiprojects are clearly 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 when WP:MATH and WP:MATHEMATICS go to separate places, one of which is a help page and the other a project page, or when Wikipedia:Books is a deprecated guideline, and the project on actual books is at Wikipedia:WikiProject Books. BD2412 T 01: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 (aka L235 · 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 proposed WPJ:. Whatback11 (talk) 19:51, 9 December 2025 (UTC)[reply]
It sounds like a new WP: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 𝕋ower Huddle • Handiwerk 01: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, introducing only 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 a namespace alias, like MOS: currently is. While making it a pseudonamespace 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, like Wikipedia: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. Chaotic Enby (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 currently no articles starting WPJ:. There are a few articles beginning with WPJ but the only one that is not part of a longer acronym is WPJ a redirect to Workers Party of Jamaica but that's unlikely to be regarded as particularly relevant. WP:WPJ (a redirect to Wikipedia:WikiProject Japan) does exist. WPJ is used in two shortcuts to mean "WikiProject" (WP:WPJGUIDE and WP: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) and WP: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  novov talk edits 06:34, 10 December 2025 (UTC)[reply]

Discussion about WikiProject banner templates

[edit]

For WikiProjects that participate in rating articles, the banners for talk pages usually say something like:

There is a proposal to change the default wording on the banners to say "priority" instead of "importance". This could affect the template for your group. Please join the discussion at Wikipedia talk:WikiProject Council#Proposal to update wording on WikiProject banners. Stefen 𝕋ower Huddle • Handiwerk 19:53, 6 December 2025 (UTC) (on behalf of the WikiProject Council)[reply]

Removing the GS authorization for United Kingdom systems of measurement

[edit]

Should the GS 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 for systems of measurement in the context of the United Kingdom. To date, zero enforcement actions have been issued and there has been zero alerts since 2021 (search since 2020). It is clearly unnecessary additional bureaucracy.

    There was an unsuccessful attempt to repeal the designation in 2020, 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. RGloucester — ☎ 22: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 (aka L235 · 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 of WP:TRYUNPROT, we at least should find out. Extraordinary Writ (talk) 03:13, 8 December 2025 (UTC)[reply]
  • Support: The lack of any enforcement actions and the drought of recent alerts are clear evidence that this general sanction is not necessary. We should try to make this project less bureaucratic when possible. As in the previous RFC I participated in here, I'd like to suggest 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 like WP:ENGVAR is written into the MOS, with appropriate WP: short link and the equivalent of template: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 Turtle MOS: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 regime Fathoms 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 involved got the point. General sanctions shouldn't be just left in place as a deterrent because we think there might 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]

Discussion (GS/UKU)

[edit]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1326782883"