Wikipedia:Village pump (proposals)

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

RfC: Enabling collapsible templates on the mobile site

Should a JavaScript gadget be installed and enabled by default to enable collapsible templates on the mobile site? — Alexis Jazz (talk or ping me) 09:35, 3 September 2023 (UTC)

Background (enabling collapsible templates on the mobile site)

When users of the mobile site encounter content in a collapsed template, they always see the content in an uncollapsed state with no way to collapse it. On some pages this can result in a long list to scroll past. For example, compare the "official status" section in the infobox of the article about the English language on the mobile site with the same article on the desktop site.

This has been a longstanding issue, phab:T111565 has been open since 2015. In response to myself and @Izno, @Matma Rex (who works for the WMF) said the following: As there are people opposed to making this change in MediaWiki core, I would suggest doing it in your wiki's MediaWiki:Common.js or a gadget, as long as your community finds that agreeable.

The reason some oppose making the change in MediaWiki core is the "fat finger problem", some people may have difficulty to tap short links titled "Hide" or "Show". The proposed gadget alleviates this issue by enforcing a minimal link element width of 6em.

The gadget can be tested on betacommons. If any bugs or serious issues with the gadget surface the deployment will be delayed until those issues are resolved. Similar to WP:ENOM, if the gadget is deployed this will be done in waves. — Alexis Jazz (talk or ping me) 09:35, 3 September 2023 (UTC)

Survey (enabling collapsible templates on the mobile site)

• Support as proposer. — Alexis Jazz (talk or ping me) 09:44, 3 September 2023 (UTC)
• Oppose Default for now - the use case is niche for forcing a gadget on to every single reader on every single page load. — xaosflux ^Talk 10:39, 3 September 2023 (UTC)

  Mostly indifferent on Opt-In along with user:Folly Mox below. — xaosflux ^Talk 15:22, 3 September 2023 (UTC)

• Support at least making the gadget available as opt-in. Although honestly this should be done in the mediawiki core without concern for whether or not people will be able to register a tap on the expand / collapse element at default zoom. The "back to citation" carets (and letters for reused citations) to hop from the References section back to the prose are already too small to register a tap reliably, but of course mobile users know to zoom in on anything they're not able to select due to size.
  I feel like up until a few months ago, collapsible templates were always just stuck in their default state, so anything set to autocollapse was just hidden entirely and required hopping into desktop view. Having everything uncollapsed everywhere is better, but still incredibly inconvenient for certain pages. For example this page, WP:VPR, which still currently features WP:LUGSTUBS2 at the top, with an uncollapsed list of over a thousand entries to scroll past before reaching the discussion, or User:XOR'easter/sandbox/ReferenceExpander, with something like 2300 table entries to scroll past before reaching the diffs that have not yet been repaired.
  This doesn't address the larger issue of the mobile interface hiding navigation templates, but it feels like a step directly towards that direction. Folly Mox (talk) 13:35, 3 September 2023 (UTC) Switched to full support 18:14, 4 September 2023 (UTC)
• Support as opt-in. Edward-Woodrow :) _[talk] 20:31, 3 September 2023 (UTC)
• I have no true objections. Overall i think collapsibility is generally a failure of authorship, but that ship has long since sailed. —TheDJ (talk • contribs) 12:25, 4 September 2023 (UTC)
• Support as default - This would bring a much-needed basic function to the mobile interface. Any solution should be enabled by default for logged-out users since they make up the vast majority of our readership and don’t have the ability to opt-in or, for all intents and purposes, ask for changes to be made. –dlthewave ☎ 14:30, 4 September 2023 (UTC)

  But logged-in users don't make up the mast majoriy of our readership, just the majority of the editorship. Kind of a big difference. Only about 6% of our readers have ever edited here.  — SMcCandlish ☏ ¢ 😼  23:20, 5 September 2023 (UTC)

• Support as default for logged-out users. Don't much care what the default is for logged-in users, as long as each user can select their own preferred setting. MichaelMaggs (talk) 14:56, 4 September 2023 (UTC)
• Support as an option, unsure on whether to make it default. People who want collapsible stuff on mobile should be able to get collapsible stuff. I do think further discussion is needed on whether this should be the default for logged out users. I get that it could be useful, but I also have to give due consideration to the idea of the gadget potentially being "forced" on users. Ideally, I'd like for Wikipedia to avoid any situation reminiscent of the Vector 2022 RFC, or the niche but much more controversial recent drama on the Minecraft server 2b2t. InvadingInvader (userpage, talk) 16:58, 4 September 2023 (UTC)

  How would you feel about enabling the feature but not collapsing anything by default? Pages would display as they do now, there would just be a Show/Hide button that readers could use if they wanted to. –dlthewave ☎ 00:01, 5 September 2023 (UTC)

  Stil unsure. InvadingInvader (userpage, talk) 18:25, 12 September 2023 (UTC)

• Support, but prefer collapsed not the default. Collapsibility should work, but content shouldn't be hidden by default. No reason to distinguish between logged-out and logged-in users, if possible, except to allow logged-in users to set a preference that sticks.  — SMcCandlish ☏ ¢ 😼  23:20, 5 September 2023 (UTC)
  • SMcCandlish, just to clarify here: the gadget enables collapsible templates just like the desktop site. (with one exception: "autocollapse" is always collapsed, but this affects pretty much exclusively navboxes which aren't rendered on mobile anyway atm and I suspect many people don't even know how autocollapse actually works autocollapse also functions the same as on desktop now) Whether anything is collapsed by default depends on the classes/template parameters used, just like the desktop site currently. — Alexis Jazz (talk or ping me) 09:10, 6 September 2023 (UTC)

    Great. That works for me.  — SMcCandlish ☏ ¢ 😼  18:44, 6 September 2023 (UTC)

• Support, including for editors logged out. The gadget is only about 10 lines of code and brings the mobile website inline with how the desktop website works. Editors logged in don't use the mobile website, more or less. We're trying to target the ones using the mobile site, which is the set of people who don't have access to an opt in. Subsequently, I don't really understand why the several editors above have said "only opt in". Izno (talk) 00:34, 7 September 2023 (UTC)
• Oppose - Right now, the mobile and desktop experience is very fragmented and inconsistent, but the long term solution is not to bodge together some JavaScript gadget that will be unnecessary and that might break when the two are reunified. There is this long term goal of unifying the mobile and desktop experiences through making Vector 2022 responsive (see phab:T106463) but that seems mostly stalled because some editors really despise responsive skins. And I agree - coming from wikiHow, where a responsive skin was deployed in 2020, responsive designs done wrong can make the experience worse for everyone. But when done right, like in Timeless, it makes the experience so much more consistent. Aasim - Herrscher of Wikis ❄️ 13:58, 7 September 2023 (UTC)
  • Awesome Aasim, just to clarify, the gadget doesn't really implement collapsible templates. After checking if any collapsible elements are present on the page it just loads the MediaWiki module that handles this. If native MediaWiki support arrives some day, it'll be virtually identical. This also means that if support for collapsible elements on Minerva is ever added to MediaWiki core this gadget can simply be disabled as it's expected to be functionally identical anyway. See also the patch that was submitted but sadly not merged.
    Note that plwiki has already deployed something similar, though somewhat less efficient because they load the module unconditionally. — Alexis Jazz (talk or ping me) 15:25, 7 September 2023 (UTC)
• Support, as opt-out. I would prefer to not have collapsed as the default though. Some page elements in mobile can be very unwieldy and often annoying to scroll through. Given that most of our traffic comes from mobile devices, we shouldn't have elements that are hidden in mobile only. I feel adding a small show/hide button on collapsible elements would cause the least amount of disruption. Ca ^{talk to me!} 23:41, 7 September 2023 (UTC)
• Support, as in mobile such templates could not be seen which makes the reading experience worse than desktop. Lightoil (talk) 03:40, 20 September 2023 (UTC)
• Strong support The collapsible templates, among other stuff, make navigation between articles which are thematically connected a much easier task; the lack of their implementation on the mobile site was a major downside of the latter. Handmeanotherbagofthemchips (talk) 17:47, 5 October 2023 (UTC)

Discussion (enabling collapsible templates on the mobile site)

@Xaosflux, there are actually quite some use cases. {{Sidebar with collapsible lists}} for example is disabled on mobile because mobile can't collapse anything. As a result, any content that is shown using that template is inaccessible on mobile. {{Sidebar with collapsible lists}} is transcluded nearly 90.000 times. While this template won't suddenly become visible with this gadget (it uses the nomobile class), editors will be able to decide on a case-by-case basis if such a sidebar should also be visible on mobile which can be viable once collapsible elements are made available. For another example of an even longer list of countries in an infobox, see IPhone 14.
Some numbers on performance impact: the gadget is currently just 911 751 bytes and gets cached in localStorage. Measuring how long the script takes to load on a page without collapsible elements is difficult because a duration of less than 1 millisecond is hard to measure accurately. — Alexis Jazz (talk or ping me) 11:09, 3 September 2023 (UTC)

I'm pretty sure that discussion has already occurred that it was appropriate to not show this content on mobile; if it isn't it should be just fixed. — xaosflux ^Talk 15:20, 3 September 2023 (UTC)

Xaosflux, if at some point collapsible elements become available on mobile, like with this gadget, the editorial decision could be made on a per-article basis. There are other considerations regarding sidebars and navboxes, but there would be options. The status quo for existing usage of {{Sidebar with collapsible lists}} wouldn't change, but for existing usage a parameter could be implemented to suppress the nomobile class or it could switch to a different template. Module talk:Sidebar/Archive 6#How to override "class=nomobile" to display sidebar in mobile view? is an example where this could be done. According to that thread, "nomobile is used because the old class vertical-navbox is already hard-coded to be removed on mobile, but I wanted to change that class name to reflect the name of this module and because it was shorter for the purposes of TemplateStyles, so I added nomobile as a result." It doesn't say why, but the fact nothing can be collapsed on mobile will surely be one of the reasons for this.
nomobile is actually a hack, quote from User talk:Jon (WMF)#nomobile is my current annoyance today: "as the Minerva maintainer I'd love to remove the `nomobile` class in the Minerva skin eventually. Now all that said I wouldn't rely on `nomobile` at all to be honest. It was a short term fix for a long term problem. If you are using TemplateStyles just add a media query and display: none anything that you don't want to show on mobile and avoid the class entirely. There's no need to rely on it. Sure this will increase the HTML payload of mobile, but leave that to us WMF staff - we can always add rules for DOM-heavy elements at a later date."
The overall sentiment seems to be that navboxes should be enabled on mobile. See also phab:T124168. In what exact form is TBD, but one thing seems clear: without the ability to make elements collapsible on mobile, it can't ever happen. As a side note, the proposed gadget has one extra trick up its sleeve: it enables the creation of elements that are collapsible on mobile but don't become collapsible on desktop. This would make it possible to make long lists or tables collapsible on mobile only, potentially saving mobile users from some lengthy scrolling. Update: this mobile-only feature has been commented out for now and may be revisited if the gadget gets enabled as a default gadget. This gadget now more purely aims to replicate the functionality of the desktop site without alterations. — Alexis Jazz (talk or ping me) 01:32, 4 September 2023 (UTC)

The reason these don't display on mobile is partially the display. But a bigger reason is that navboxes do not suit the mobile need, which is predominantly get in and get out with the desired fact. This quality, combined with the basically useless and usually quite large HTML downloaded just to inevitably not need a navbox is why these are "disabled". (Why yes, MobileFrontend does rip them fully out of the HTML.) IznoPublic (talk) 15:45, 6 September 2023 (UTC)

Question - As a Gadget, would this be enabled for logged-out users? –dlthewave ☎ 14:35, 3 September 2023 (UTC)

Dlthewave, the way I phrased the proposal ("installed and enabled by default"), yes. However, if many votes include the condition that it be made opt-in I would consider that a valid outcome as well. If it would be enabled by default it would allow editors to assume the feature is available to mobile users when writing templates and articles which won't be the case if it's opt-in, but c'est la vie. If the proposal passes (without opt-in condition) the gadget will be deployed in waves. At first it'd be enabled for admins only and every week or so another group would be added: WP:extendedconfirmed, wp:autoconfirmed and finally everyone (including logged-out users). — Alexis Jazz (talk or ping me) 01:44, 4 September 2023 (UTC)

Good! I wasn't quite sure how gadgets worked, wanted to make sure it would eventually be available to all users. –dlthewave ☎ 02:44, 4 September 2023 (UTC)

Dlthewave, a gadget is a collection of JavaScript and/or CSS pages, similar to WP:User scripts. Unlike user scripts, they are centrally governed in MediaWiki:Gadgets-definition. Some gadgets, for example mw:Reference Tooltips, have the "default" parameter set in MediaWiki:Gadgets-definition, those are enabled and loaded by default. The wording "enabled by default" in the proposal refers to the default parameter in Gadgets-definition. — Alexis Jazz (talk or ping me) 06:57, 4 September 2023 (UTC)

Thanks for working on this. I left some suggestions for the implementation at Wikipedia talk: MakeMobileCollapsible.

Before enabling the gadget, please consider whether the "mobile-only collapsible" feature is really desirable. Personally I think we should avoid adding any mobile-only and desktop-only features these days, to avoid confusion for people who only use desktop or only mobile and see different things. It might also lead people to use collapsible elements in cases where other approaches would be better (per MOS:COLLAPSE): moving the content to a separate section (which are already collapsible on mobile, and easier to navigate using the TOC on desktop), or to a separate page – and since it would be mobile-only, the desktop power-users might not notice it.

And while we're talking about MOS:COLLAPSE, it will need some updating about the mobile support. Matma Rex talk 12:33, 4 September 2023 (UTC)

Matma Rex, interesting points. I added the "mobile-only collapsible" feature because it was easy and I believe there is a difference between mobile and desktop here: scrolling is more labor-intensive on mobile devices as you have no page up/page down keys and dragging the scrollbar is more difficult without a mouse or touchpad. If it turns out the feature goes unused or causes people to use less optimal approaches it could be removed easily and any existing uses could be updated by a bot in that case.
Header levels above level 2 don't become collapsible on mobile. I guess the only way to find out if it's a good idea is to just see if and how people would use it. If people don't use it or only use it when other approaches would be better, it could be scrapped at a later point. Btw, one way to use that feature is to combine mw-collapsible with mw-collapsed-mobileonly, resulting in a collapsible element on both mobile and desktop but which is only collapsed by default on mobile. I also think mobile-only collapsing could be an alternative for the nomobile class in some cases. — Alexis Jazz (talk or ping me) 13:32, 4 September 2023 (UTC)

Firefox won't even let me drag the scrollbar. It only supports manual scrolling. On the pages I linked to in my not-vote, it might take me forty or sixty seconds to scroll all the way down to what I'm tryna read. Usually I end up all the way at the foot of the page and have to work my way back up, but too aggressive of an upscroll will – alas – trigger a page reload. Anything to help ameliorate this would be quite welcome. Folly Mox (talk) 18:11, 4 September 2023 (UTC)

While we're on this tangent, adding a collapsibility to level three subheadings, defaulted to uncollapsed, would be pretty nice. Some of those get real long, and it would be convenient to collapse them if I'm editing them one after another. Folly Mox (talk) 18:31, 4 September 2023 (UTC)

I agree with Matma Rex here: let's not introduce mobile specific behavior, especially since that's not the primary point of the change we're trying to make here. (And were you going to do it, using the same class namespace as core functionality is a bad idea "mw-".) IznoPublic (talk) 15:51, 6 September 2023 (UTC)

@Matma Rex, what specifically needs updating about MOS:COLLAPSE? IznoPublic (talk) 15:48, 6 September 2023 (UTC)

For example this part: "the mobile version of the site, which has a limited set of features and does not support collapsing". Matma Rex talk 16:50, 6 September 2023 (UTC)

It... Doesn't, still. We just went from "displays nothing" to "displays everything", so I think that statement remains valid. (Perhaps less than obviously the context of that section ignores MF collapsing whole sections.)

As for limited set of features for mobile, yeah, less true, but also not totally relevant to that section, so removing it in toto might be called for. Izno (talk) 00:20, 7 September 2023 (UTC)

Oh, "will need". Missed the auxillary verb. Izno (talk) 00:36, 7 September 2023 (UTC)

Matma Rex, following your and Izno's comments, I commented out the mobile-only collapsing feature for now. If the gadget gets enabled by default I plan to open a discussion on enabling it again. Maybe in some more limited form, like only changing the default collapse state on mobile. For now, the gadget just aims to replicate the collapsing functionality from the desktop site. — Alexis Jazz (talk or ping me) 12:34, 7 September 2023 (UTC)

• Mobile viewers should be able to see the same templates as desktop users. It's somewhat baffling to me that we have different versions of the site for desktop and mobile viewers. The latter cannot, for example, expand a {{cot}} or a {{hat}} (why?). Many navigation templates in articles are just unusable on mobile, meaning that if you want readers to actually be able to see what you're writing, you must include it twice. jp×g 21:32, 19 September 2023 (UTC)
  • JPxG, the answer to your "why?" question is in the background info: The reason some oppose making the change in MediaWiki core is the "fat finger problem", some people may have difficulty to tap short links titled "Hide" or "Show". The proposed gadget alleviates this issue by enforcing a minimal link element width of 6em.
    This is why jquery.makeCollapsible doesn't get loaded on the mobile site. The proposed gadget loads jquery.makeCollapsible on the mobile site. @Awesome Aasim, I should have mentioned it in my reply to you above some time ago, but jquery.makeCollapsible is the module that I was talking about. A WMF developer suggested that individual projects should load this module using MediaWiki:Common.js or a gadget, so this isn't expected to break anything in the future. — Alexis Jazz (talk or ping me) 22:31, 19 September 2023 (UTC)

RfC on Module:Find sources - replace New York Times with Associated Press

Currently, the only media outlet in Module:Find sources/templates/Find sources is the newspaper The New York Times (nytimes.com). Should we replace it with the news agency Associated Press (apnews.com)? Previous discussions here and here. starship.paint (RUN) 04:18, 9 September 2023 (UTC)

Survey (Find sources: NYT vs AP)

• Support as proposer on these three fronts. (1) Accessibility: The New York Times requires a paid subscription to read, the Associated Press does not. We should avoid paywalls for our editors and readers. (2) Content focus: The Associated Press is more internationally focused and operates in 94 countries, while the New York Times is more U.S.-focused and operates in around 30 countries. (3) Less biased: The Associated Press has been rated as less left leaning, and more neutral, than The New York Times by two media bias assessors - Media Bias Fact Check on NYT versus AP, AllSides on NYT versus AP. starship.paint (RUN) 04:20, 9 September 2023 (UTC)
  • I'd also like to add that I did not propose news agency Reuters as it requires registration, while news agency Agence France Presse doesn't seem to actually post news articles on its website? Or maybe it is here but you need a login? starship.paint (RUN) 04:28, 9 September 2023 (UTC)
• Support per nom, with particular emphasis on (1). Directing editors to a source which requires a paid subscription after opening five(?) articles is just not best practice. In addition to making it more difficult for editors to find sources initially, it also has the potential knock-on effect of increasing the number of citations to the NYT in mainspace, citations which are more difficult to verify than those to free sources (this is a dumb concern and I'm dumb for saying it.)
  Associated Press is internationally regarded as – at minimum – a pretty good press agency. It should be more than adequate as a replacement suggestion in this module. The main downside I can think of is that Citoid works impeccably with the NYT, always correctly resolving authorship and publication date, only missing the |url-access=subscription parameter. I don't remember if AP always works so consistently, although it might. Folly Mox (talk) 04:53, 9 September 2023 (UTC) edited 08:20, 9 September 2023 (UTC)

  Oh no, now I remember that Citoid does correctly identify the important parameters from AP sources, but invariably chooses to render the |work= parameter in all caps, as "AP NEWS". Pretty trivial downside all things considered. Folly Mox (talk) 05:04, 9 September 2023 (UTC)

  Not at all opposed to just adding more sources, for clarity. Folly Mox (talk) 08:22, 9 September 2023 (UTC)

  Speaking of ALL CAPS, what's annoying about citiod and the NY Times is that it doesn't handle the historical NY Times style of ALL CAPS headlines.. It's annoying having to manually convert those into title case as required to pass a GA review (I can't actually find anyplace in the MOS which requires that, but reviewers seem to insist on it). RoySmith (talk) 21:24, 14 September 2023 (UTC)

  I also find Conde Nast publications pretty annoying because Nast, Conde always seems to be the byline. Valereee (talk) 16:28, 15 September 2023 (UTC)

  Heh. I took a look at the HTML they generate:

  <head>...<meta name="author" content="Condé Nast">...</head>

  So, yeah, we're just believing what they tell us. RoySmith (talk) 16:47, 15 September 2023 (UTC)

• Support AP, and other options as well. I think that the NYT, nothing against it as a reliable source, should not be considered the most reliable source and promoted the same way as it is. The NYT is nowhere near deprecation like the Daily Mail, but it should be treated as a source with a lean-left American bias. I personally think that the AP and Reuters are best, and for non-Qatari content, Al Jazeera should also be encouraged due to its general lack of bias on non-Qatari topics based on its ownership. Inclusion of the NYT should only be in concurrence with a counter-balancing reliable source, such as the Wall Street Journal. InvadingInvader (userpage, talk) 04:57, 9 September 2023 (UTC)
• I'd be happy to see apnews.com on the list, but why "replace"? Why not just "add"? WP:PAYWALLED sources are okay. I'd be happy to see half a dozen news sources. Maybe we need to add the BBC and The Globe and Mail, too. WhatamIdoing (talk) 05:25, 9 September 2023 (UTC)
  • Using paywalled sources is okay, but what we are doing here is recommending a paywalled source to everyone, which would surely cause inconvenience to non-subscribers as the paywall can prevent them from reading article text. Why make life harder in this way? starship.paint (RUN) 06:55, 9 September 2023 (UTC)

    I don't think that convenience is the right way to measure news. First of all because it's not a primary factor when selecting verifiable sources, but also because convenience seems to be a placeholder for free. The first AP news article I opened was indeed without up-front cost, but has infinite tracker-laden Tablooa spam all over it; that is definitely not convenient from a privacy or bandwidth perspective. In practically all other areas of Wikipedia, sources are measured by the fundamental quality they bring to the encyclopedia, and I don't see why news should be treated differently. Orange Suede Sofa (talk) 07:26, 9 September 2023 (UTC)

• Oppose removal of the NYT -- as has been pointed out elsewhere on this page the NYT's factual reporting is neutral, and removing something because it has a paywall I think is a mistake -- we should recommend the best sources, not the most accessible ones. I'd be fine with adding other reliable sources, including the AP, as WhatamIdoing suggests. Mike Christie (talk - contribs - library) 07:12, 9 September 2023 (UTC)

  this is a distraction. no discussion supported "addition of nyt" https://en.wikipedia.org/enwiki/w/index.php?title=Module%3AFind_sources%2Ftemplates%2FFind_sources&diff=prev&oldid=722553515 . you first need to find support for "addition of nyt", before debating about its "removal". RZuo (talk) 09:35, 9 September 2023 (UTC)

  @RZuo, -- and to be clear, this is not a comment on the proposal, just on this argument, which you've made several times -- it's not actually correct that there had to be some discussion supporting the addition before it was made. The addition was made in (2016? too lazy to check) and apparently created no controversy at the time. The fact it's remained this long, even with occasional discussions about removing it, is the evidence for consensus. You'd be better off dropping this argument and simply arguing merit rather than process. Valereee (talk) 11:41, 9 September 2023 (UTC)

  Wikipedia:Consensus#Through_editing: "An edit has presumed consensus until it is disputed or reverted."

  Wikipedia:Silence_and_consensus#Silence_is_the_weakest_form_of_consensus: "Consensus arising from silence evaporates when an editor changes existing content or objects to it."

  even if there ever were any implicit consensus, it has evaporated no later than 2018. RZuo (talk) 12:46, 9 September 2023 (UTC)

  I'll answer at your talk, as this probably is becoming tangential. Valereee (talk) 12:49, 9 September 2023 (UTC)

  @RZuo, I'm having a hard time interpreting this as meaning anything but that you don't actually want to discuss unless it's in a public forum? Trying really hard to AGF here...why did you delete that instead of responding? Would you prefer I explained it here, where it doesn't really add anything? I was trying to avoid distracting people from the question at hand. Valereee (talk) 18:48, 9 September 2023 (UTC)

  I just wanted to comment, whether or not there is pre-existing consensus for somethings inclusion does not make an editors !vote to include it any less valid. Googleguy007 (talk) 14:44, 26 September 2023 (UTC)

• Oppose removal of NYT, support addition of AP - No special fondness for NYT, but in the areas I edit in, it's more useful than AP. I agree with the editors saying having a greater mix would be better. Red Fiona (talk) 14:14, 9 September 2023 (UTC)
• Support - for the above reasons as articulated by starship.paint. The associated press I think it is fair to say, is a source moreso associated with worldwide NPOV viewpoints than the NYT. On pages like this sources like the AP are preferable as to avoid centering the US perspective. Wikipedia can and should be more than an American website Jack4576 (talk) 11:55, 9 September 2023 (UTC) {this is a copied comment}
  • Note: I copied this over from my talk page because Jack4576 is blocked from Wikipedia-space pages like Wikipedia:Village pump, but Jack4576 has said that he is not topic banned from Wikipedia-space. starship.paint (RUN) 14:48, 9 September 2023 (UTC)
• Support removal of NYT because of the paywall, and therefore support addition of AP in its place. I could propose a scheme where ENWP would establish a floating account with the name of Nicholas Bourbaki to read NYT articles, but that would be too complicated and weird. We need our reliable source to be accessible, because most of us have the disability of not having paid the NYT. Robert McClenon (talk) 16:13, 9 September 2023 (UTC)
• Oppose removal of the NYT for reasons described in the previous discussions and mentioned below. The NYT is an excellent, top tier source that is exactly the kind of thing that should be offered as a suggestion, including for non-American news. I have no opinion on the AP, but the decision should be whether to add the AP, not to replace the NYT with the AP. SnowFire (talk) 04:30, 10 September 2023 (UTC)
• Support As I said previously, a choice is better but no real reason to prefer NYT (or the BBC) over a global news source.Selfstudier (talk) 14:14, 10 September 2023 (UTC)
• Support as proposed, still, for the reasons listed in the nomination and that I gave in the last discussion. We don't need to clog talk pages with multiple listings in "Find sources", and AP is international, not paywalled, and neutral. SandyGeorgia (Talk) 22:15, 10 September 2023 (UTC)
• Oppose as the NYT is a high quality source and has more in-depth coverage in some areas than the AP; though I do agree with the argument that it is too US-centric. I think we shouldn't favour one publication over all others though, so the most ideal option in my mind would be to add multiple sources or remove all sources and make the "WP refs" search (which retrieves results from plenty of newspapers including both NYT and AP) more prominent. ― novov (t c) 07:55, 11 September 2023 (UTC)
• Support Removal of NYT. Oppose adding of AP. I absolutely understand the frustration of New York Times paywalls. However, I don't think switching to another for-profit journalistic source is the solution. We can maybe also link to NPR, PBS, CBC, BBC, (Australia)BC, and other not for profit journalism that is more in line with our goals. Aasim - Herrscher of Wikis ❄️ 17:11, 11 September 2023 (UTC)

  Can you clarify "more in line with our goals"? A news source that is non-profit is not more in line with our goals as an encyclopedia than one with a reputation for high-quality journalism, even though it might align ideologically. Mike Christie (talk - contribs - library) 13:18, 15 September 2023 (UTC)

  I am not doubting that NYT is high quality journalism. But public broadcasters and several news sources are not incentivized by advertising in general. The removal of NY Times is less to do with its quality as it has to do with being able to ensure that Wikipedians are able to quickly access a good source for stuff like WP:V and WP:N. Aasim - Herrscher of Wikis ❄️ 13:25, 15 September 2023 (UTC)

  I'm all for "information should be free", and would certainly support adding entries for other sources, but we would be shooting ourselves in the foot if we started down the road of deprecating sources behind paywalls just because they're behind paywalls. Full disclosure: I'm a paid NYT subscriber. RoySmith (talk) 13:48, 15 September 2023 (UTC)

  I never said that NYT should be deprecated. Only that it should not be included in {{find sources}}. If there is a way to access NYT through programs like WP:TWL then that is what should be linked. Aasim - Herrscher of Wikis ❄️ 14:13, 15 September 2023 (UTC)

  Removing it from {{find sources}} is a step down that road. I agree it would be wonderful if the NYT were available through WP:TWL, but whether it is or not should not be a factor in how we treat it as a source. RoySmith (talk) 14:17, 15 September 2023 (UTC)

  Maybe I misread the question, but I thought this was about {{find sources}} for a minute, not the associated module. I think the only entries that should be listed there are those related to what the module is for - finding sources. Linking to one publisher in the module is not "find sources", it's "find source". In other words, I only think search engines querying a wide variety of databases and curated news reports across the world should be there. Google News and Bing News which in turn pull up articles from NYTimes and AP and other high (and low) quality sources will suffice enough. Aasim - Herrscher of Wikis ❄️ 14:33, 15 September 2023 (UTC)

  That's a much more acceptable (to me) argument. RoySmith (talk) 14:52, 15 September 2023 (UTC)

• Support removal of NYT. Oppose adding AP. I don't like the idea of promoting one or two specific media outlet(s) above others. Perhaps a set of several, but that's not really in scope for this RFC. —siroχo 17:46, 11 September 2023 (UTC)
• Oppose addition of AP. The value of having nytimes.com comes from its archival nature. Searching there returns matches dating back to 1851. On apnews.com, on the other hand, I can't even find an article from earlier than 2021. It's pretty clear which is useful for a wider range of subjects. If regionality is a concern, replace it with Google Newspapers (I'm surprised it's not there). Nardog (talk) 07:37, 12 September 2023 (UTC)
• Oppose removal of the New York Times, which is by far the best and most comprehensive US newspaper source. Most high quality journalistic sources are behind paywalls these days. I subscribe to several paywalled sources and limit my usage of others that restrict my access to X articles a month or whatever. But I will never support any limits on or any discouragement of other editors using paywalled sources. The Associated Press is great for routine coverage of breaking news and the like, but it is a news agency, not a newspaper. AP does not decide which of their content that actual newspapers run. Those decisions are made instead by actual living and breathing newspaper editors. The AP does not cover stories with anywhere near the depth or breadth that the New York Times does. Or the Washington Post, the Wall Street Journal, the Los Angeles Times, the San Francisco Chronicle and many others, or my little hometown paper, The Union, which has been published since 1864. It would be a terrible mistake to start down the path of deprecating sources behind paywalls. That is where the very best journalism can be found these days. The expectation that outstanding journalism can always be consumed for free is pernicious, and will lead to the death of independent journalism if followed to its logical end. Cullen328 (talk) 08:03, 12 September 2023 (UTC)

  +1! Donald Albury 14:46, 12 September 2023 (UTC)

  then why nyt? why not the union or wsj? RZuo (talk) 14:31, 14 September 2023 (UTC)

  Well, this proposal was to replace NYT with AP. Any other outcome will require a new RfC. Donald Albury 17:17, 14 September 2023 (UTC)

  for anyone who still hasnt read the discussion or understood the origin of this rfc: nyt was added without any consensus or discussion https://en.wikipedia.org/enwiki/w/index.php?title=Module%3AFind_sources%2Ftemplates%2FFind_sources&diff=prev&oldid=722553515 , so any user supporting using nyt should first explain why nyt should be chosen over any other sources.

  yet i could readily give 2 reasons why for example wsj is a better us newspaper than nyt. RZuo (talk) 07:24, 15 September 2023 (UTC)

  RZuo, Valereee responded to this argument of yours, above and on your talk page, giving what I would consider good reasons for discounting your point. You've ignored their post above and silently deleted their post from your talk page. If you're going to continue making this argument I think it would be helpful if you explained why you disagree with their response. Mike Christie (talk - contribs - library) 14:04, 15 September 2023 (UTC)

  RZuo, I'm not sure it's fair to assume the edit was made with no discussion simply because no discussion was referenced in the edit summary. The editor who made that edit thinks there had been discussion. The fact no one has dug it out doesn't mean it doesn't exist. As I mentioned at your talk, we should at minimum assume good faith on that. This argument, which you have made over and over again, including after objections, is starting to feel like an intentional unsupported accusation of bad faith. Valereee (talk) 16:12, 15 September 2023 (UTC)

  instead of busy lecturing other users, you two can answer the question at hand instead: why is nyt chosen over all other sources? RZuo (talk) 18:23, 15 September 2023 (UTC)

  I've given my reasons for keeping the NYT in my !vote above; I have no objection to adding other sources. Mike Christie (talk - contribs - library) 19:19, 15 September 2023 (UTC)

  did you know whether you answered why nyt is chosen over all others? no?

  you merely said nyt is neutral.

  many more newspapers are neutral. many more are more neutral than nyt. RZuo (talk) 20:35, 15 September 2023 (UTC)

  I don't know why it was chosen, but I assume it was because some 2016 discussion suggested it. I can't know because I haven't seen the original discussion which, as someone AGFing, I assume happened. It doesn't mean it was the best choice, it doesn't mean consensus hasn't changed since, and I'm completely open on the question.

  @RZuo, I am going to tell you: stop making unsupported accusations of bad faith. The fact this pisses you off does not mean you can accuse another editor of intentionally operating in bad faith without evidence. Valereee (talk) 19:31, 15 September 2023 (UTC)

  @Valereee:

  1. you're making a claim without evidence. that's not what "assumption of good faith" means. you better stop.
  2. you're falsely accusing me of assumption of bad faith. you better stop. i've been asking a simple question, which any supporter of nyt can answer, regardless their awareness of a non-existent discussion you're handwaving to.

  RZuo (talk) 20:29, 15 September 2023 (UTC)

  You've accused another editor of intentionally acting in bad faith. Your first intimation was here. You accused the other editor of editing without discussion or consensus, implying BOLD didn't exist or apply and that because there was no mention of a discussion in the edit summary, there was no discussion, even though the other editor said they thought there was discussion, here and here and here and here. I objected here and here. You ignored/deleted my attempts to discuss.

  I literally have no opinion on this question. Please explain what you mean by "handwaving to", as I am not sure what you're saying. Valereee (talk) 21:49, 15 September 2023 (UTC)

• Oppose removal of the NY Times. It has a comprehensive archive and most stories contain an attributed author. Not opposed to adding additional sources. --Enos733 (talk) 21:06, 14 September 2023 (UTC)
• Oppose Absolutely not. The NYT is, in my view, the single most high-quality respected news publication in the Western world of all time. InfiniteNexus (talk) 00:43, 15 September 2023 (UTC)
• Support defaulting to a global source focused on factual reporting improves Wikipedia's neutrality. – Teratix ₵ 00:44, 21 September 2023 (UTC)
• Oppose removal, but support addition. In general, I would have multiple newspapers listed, rather than just one. Google has been getting shittier and not pulling up everything. AP, WaPo, AFP, Reuters, etc. would all be useful, in addition to the NYT. The NYT is still a very reliable source for information, globally. SWinxy (talk) 04:13, 21 September 2023 (UTC)

  I have a love-hate relationship with Google search. On the one hand, they're the most comprehensive compendium of what's available on the internet; any search for sources which didn't include Google in some way is clearly defective. On the other hand, I hate how much information Google collects about their users, and from a more practical point of view, the results they give are biased by your previous browsing (and other application use) history. I use Duck-Duck-Go as my everyday search engine, but I still do Google searches as needed to ensure complete coverage.

  As for WaPo, I think they're a great news source. I maintain paid subscriptions to both NYT and WaPo. On the other hand, I recognize that those two papers overlap in both their US-centric coverage (obviously they have great international coverage, but overall, US-centric) and in their political biases (i.e. liberal-leaning). I would like to see more news outlets listed, but we should make an effort to cover both the political spectrum and geographic diversity. Surely we can satisfy that without compromising on journalistic excellence. RoySmith (talk) 14:54, 21 September 2023 (UTC)

• Oppose on all points. The Wikipedia Library represents WMF recognition that the highest-quality reliable sources often exist behind paywalls. Google News is linked for those who can only afford free sources, allowing for focus on the NYTimes' comprehensive reporting and archives stretching to 1851 at a cost of $4/month. As for international coverage, counting national bureaus is hardly indicative of the breadth of reporting. For example, neither news organization maintains a permanent office in Vanuatu, but only the NYTimes website offers pre-2021 coverage and has far more long-form reporting on the island nation. Lastly, Media Bias Fact Check and AllSides are not objective determinations of media bias. One can argue that the NYTimes' in-depth coverage necessitates fact-finding that exposes it to further claims of bias. BluePenguin18 🐧 ( 💬 ) 23:49, 23 September 2023 (UTC)
• Support adding AP on the basis that it's less USA-centric: on many articles where it's included, this template is useless because there's nothing useful to be found. Paywall status is relevant but I'm not sure it's dispositive here: AP will probably become paywalled like Reuters at some point, and NYT is very easy to access for free on any privacy-conscious browser or through the Internet Archive. I'm also ok with outright removing the NYT or replacing it with some of the other sources mentioned like The Guardian, for reasons given by others above. Nemo 16:03, 24 September 2023 (UTC)
• Support removing NYT and adding AP. Though they are equivalent in quality and bias, AP is easier to access (no paywall) and more international than NYT. Levivich (talk) 16:36, 24 September 2023 (UTC)
• Support: AP is easier to access, more international and less biased. a455bcd9 (Antoine) (talk) 07:47, 26 September 2023 (UTC)
• Oppose removal Proposer's rationale for removal are unconvincing, including false claim about "left-leaning" factual reporting, as opposed to editorial stance. Other sources can be added to address other of OP's concerns, e.g. Reuters, NPR, BBC, AP... SPECIFICO talk 19:19, 26 September 2023 (UTC)
• Support removal (from Template:Find sources, Template:Find general sources, and similar). This is not a free-floating debate about how good of a source the New York Times is. This is about what gets included in templates plastered indiscriminately across AfCs, AfDs, talk page headers, etc. There should be as little as possible; less is more. What gets included should be of exceptionally broad and global applicability, and (like a point made by Aasim above) should consist only of tools to actually "find sources" and not any particular source or publisher. Adumbrativus (talk) 10:38, 28 September 2023 (UTC)
• Support - Never paid for paywalled stuff and never would when there's free alternatives out there, I do agree with Cullens point 99% of those alternatives won't be as good as NYT but I also don't believe it's useful to anyone linking to paywalled articles when like I say there's free alternatives out there. I would also support BBC over AP but that's just me personally. –Davey2010^Talk 11:00, 28 September 2023 (UTC)

  Nothing under discussion requires use of a paywalled site. SPECIFICO talk 19:28, 7 October 2023 (UTC)

• Support - no point leading readers to a site that the VAST majority cant view. Our goal should be to guide readers to a place that will be accessible for the research the template is intended for.Moxy- 19:22, 12 October 2023 (UTC)
• Oppose. The New York Times has an enviable world-level reputation for fair and accurate reporting. We should always make every effort to use the very best sources available to us, and this is surely one of them. There's no paywall, just a minor (but rather aggravating) pay-obstacle – if you can't read a particular article online, all you need to do is go to the public library and read it there. The walk will probably do you good. Justlettersandnumbers (talk) 19:49, 12 October 2023 (UTC)

  Kind of a privileged, first-world take. Not everyone has a public library at all, or in walking distance, or can walk, and not every public library subscribes to NYT. Levivich (talk) 20:56, 12 October 2023 (UTC)

  That's a reason to provide other sources that are more universally accessible, certainly. I don't see it as a reason to remove a high-quality source that many editors can indeed access. Mike Christie (talk - contribs - library) 21:18, 12 October 2023 (UTC)

• Oppose False dichotomy, just add both. Curbon7 (talk) 21:40, 12 October 2023 (UTC)

Discussion (Find sources: NYT vs AP)

• @SandyGeorgia, Shibbolethink, Sdkb, Mathglot, SilkTork, Mr. Stradivarius, Wikmoz, Hog Farm, SnowFire, ProcrastinatingReader, and Nemo bis: - notified from past discussion. starship.paint (RUN) 04:24, 9 September 2023 (UTC)
• @RZuo, JohnFromPinckney, Zaathras, Schazjmd, Stultiwikia, Masem, Joseph2302, Shakescene, UnironicEditor, Orange Suede Sofa, Dylnuge, Jack4576, GreenC, Fiachra10003, WhatamIdoing, Folly Mox, Valereee, Enterprisey, Mike Christie, InvadingInvader, and Selfstudier: - notified from above discussion. starship.paint (RUN) 04:33, 9 September 2023 (UTC)

• Are these the right metrics? Without expressing a preference for any of the choices, I'm not sure the metrics given above are what we should be prioritizing. First being paywall; we should strive for the most neutral and accurate sources, not the most free-as-in-beer. Unlike media (such as images or sound), for which we prefer freely-licensed content as we host and display that content directly, news sources should be the most accurate available, as it is in many other areas in Wikipedia that are not news-oriented. Next is international coverage— the "countries operated in" statement is not quite accurate. For example, NYT has actively staffed bureaux in many countries but that's more of a logistics matter; they will send reporters to any country in the world as needed and permitted. And I found at least three different figures in different areas of the AP site so I'm not sure what is going on there. Finally, I fear that a lot of this is moot because many news organizations' public-facing search capabilities are often terrible. As a test, I took the first linked term in today's WP:ITN (Tharman Shanmugaratnam) and tried it with both the AP and NYT search. The AP search returned nothing and the NYT search returned a lot of things, yet notably none of them relevant to the ITN item in question. Are we focusing on the right issues here? Orange Suede Sofa (talk) 05:59, 9 September 2023 (UTC)

  https://www.reuters.com/site-search/?query=Tharman+Shanmugaratnam

  https://www.bbc.co.uk/search?q=Tharman+Shanmugaratnam RZuo (talk) 06:23, 9 September 2023 (UTC)

• Some premises are wrong here and strongly suggest that interested editors read the previous discussions. In particular, the claim that the NYT is "left-leaning" is misleading. It is well-known that the NYT's editorial section is mostly left-leaning (although, interestingly enough, they've gotten heat from the left in the past year as well - see this article for example). However, "find sources" is about the news stories as editorials should only be referenced rarely, so the claim that this is addressing some left-wing bias is weak. (The same is true in reverse of the Wall Street Journal.) The larger concern is accuracy - the NYT is handy for having fairly deep coverage of many topics, and from the sources cited on bias as pointed out by Mathglot in the previous discussion:
  • They are considered one of the most reliable sources for news information due to proper sourcing and well-respected journalists/editors.
• If the NYT were a "conservative" outlet in its editorial page but still had lines like that, then they'd still be fine to use. Maybe we can add AP stories but NYT is a good start and not in any way "problematic." SnowFire (talk) 06:09, 9 September 2023 (UTC)

  I'd second the comment about the strict wall that most U.S. newspapers follow in separating hard news (reporters' own personal opinions, or lack of opinion, disregarded so long as they report all sides fairly) from opinion-editorial and both of them from the business side (advertising and circulation).

  A good counter-example is The Wall Street Journal, whose conservative opinion-editorial bent is if anything sharper than the Times' left-liberal one. Nonetheless, liberal and left-wing Americans constantly cite the Journal both for important economic and corporate facts, and for the enterprising original investigations that its reporters (of any persuasion or none) undertake. The American socialist leader Michael Harrington told young socialists fifty years ago that they should read the Journal regularly, and a very bohemian friend of mine pointed out that the business press (cf. The Financial Times) can't let politics or ideology interfere with the hard facts that their readers need to make sound corporate, financial and investment decisions. However both The WSJ and The FT have rigid paywalls that are, if anything, higher than the NYT's. —— Shakescene (talk) 14:22, 9 September 2023 (UTC)

• Actually, who is the target audience here? When was the last time anyone in this discussion ever had Module:Find sources appear in the course of normal editing, then clicked on a link in it to find sources? I feel like most of us probably have our methods already, and will do the same kinds of searches at the same places for similar kinds of information.
  I fielded a question at one of the helpdesks the other day, where a user was trying to get information about some 19th century book. I pointed them at Internet Archive, google scholar, Jstor, and told them to check their school library resources, like they had zero idea where to start since we didn't have an article specifically about this one book. I kinda get the impression that this find sources template has a similar purpose, and I think for this use case, finding easier sources does make a difference, even if for a more experienced user going through a quality assessment process, it absolutely doesn't.
  It may in fact be the case that NYT has more information readily available via search than AP does per Orange Suede Sofa's comment. That's a pretty strong argument against this particular swap. Higher quality sources are always going to be ceteris paribus more important than easy sources. I just don't think for the people this template most benefits, that all other things are equal.
  I'm never going to argue that ease of access or ease of verification are the most important things about a source. My own topic area of concentration, Early China, is woefully outdated and often doesn't reflect modern scholarly consensus, because so much of the sourcing is from centuries-old classics that have been digitised and are freely available multiple places. It sucks. But if someone hit me up with no idea where even to start, I'd probably still point them at things I know they'll have access to at home for free with no special accounts anywhere. It's a better starting point than asking if someone can afford a subscription or a particular book. Folly Mox (talk) 08:15, 9 September 2023 (UTC)
• Comment I am concerned that we not set a precedent that accessibility is more important than reliability in ranking sources. For many topics, the best sources are on paper, or, if available on-line, are behind paywalls. I understand that many editors are at a disadvantage over access to such sources, but I think we still need to recommend the best sources first. Freely-accessible sources are fine, it they reliably support the content they are cited for, but they should not be a permanent substitute for better sources that may be behind paywalls or only available on paper. - Donald Albury 13:46, 10 September 2023 (UTC)

  Absolutely right. This is the most important comment that anyone has made here. MichaelMaggs (talk) 14:06, 10 September 2023 (UTC)

  I agree though there should be a preference for sources not behind paywalls be it subscriptions to news outlets or academic journals. UnironicEditor (talk) 07:27, 12 September 2023 (UTC)

• For most topics, the emphasis in sourcing should be on scholarly sources rather than breaking news. Both NYT and AP are not ideal sources for an encyclopedia simply because they are news sources and may not reflect scholarly consensus on a particular topic. Their only notable advantage is being more up to date, thus being citable for current events. (t · c) buidhe 15:37, 15 September 2023 (UTC)

Request for comment: Unreferenced PROD

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is overwhelming consensus against this proposal. For a perennial proposal to succeed, something must be different about this specific iteration of the proposal, and that is not the case here. Supporters generally argue that unsourced articles are a Bad Thing, and that notion did find a wide degree of support. However, the opposition argued that unsourced articles can be fixed by editing, and thus should not be fixed with deletion. If it can't be fixed by editing (i.e. there are no sources that could be added to the article), opposers argued that this process is redundant to AfD and/or PROD. Some supporters also argued that the status quo amounts to a grandfather clause: new unsourced articles tend to get draftified, but older unsourced articles just sit around. This was squarely refuted by opposers, who noted that the proposal explicitly contains a grandfather clause exempting articles already tagged with {{unreferenced}} from this process. (non-admin closure) HouseBlaster^talk 17:42, 9 October 2023 (UTC)

---

Should the process described in this discussion be adopted in some form; to wit, should unreferenced articles be subject to a PROD-like process where, after a two weeks (or other suitable time), the article is deleted? 19:11, 6 October 2023 (UTC)

• Support as proposer: I see this as an extension of WP:BURDEN, which is part of Wikipedia's policy on verifiability. That policy states: The burden to demonstrate verifiability lies with the editor who adds or restores material, and it is satisfied by providing an inline citation to a reliable source that directly supports [...] the contribution. [...] Any material lacking an inline citation to a reliable source that directly supports [...] the material may be removed and should not be restored without an inline citation to a reliable source. Unsourced articles, as suggested in this essay, is not valuable to a serious encyclopedia.

In earlier times, Wikipedia needed to expand, to cover a variety of topics, so we could beat out competitors such as Britannica and Citizendium. That time has passed. We should now put more emphasis on quality, ensuring that our articles are trustworthy, well-written, neutral, and verifiable.

Obviously, the nominator of an unsourced article under this process should take time to conduct a quick WP:BEFORE; but again, the burden to demonstrate verifiability lies with the article creator. Article reviewers and other editors shouldn't have to break their backs scratching up sources for a now-destroyed theatre in Moscow.

This process would allow editors, using an {{unreferenced prod}} tag or similar, to nominate such unreferenced content (viz., articles) for deletion. These proposals would have the regular notifications to WikiProjects and user talk pages, giving involved editors plenty of time to add at least one reference that supports article content.

This would be a separate template from the existing {{unreferenced}} tag, so articles tagged with that template would not all suddenly be nominated for deletion. However, this would allow us to chip away at the backlog of 119 000 or so unreferenced articles more quickly, as the backlog would no longer grow – new articles would be tagged with the new PROD.

Given the two weeks to add at least one reference to the article, I find it unlikely that many articles would actually be deleted under this process.

WP:TLDR? A gloss of my 340-word comment: I think this proposal is an extension of our policy of WP:BURDEN. Article creators and interested editors are given two weeks – fourteen days! – to provide at least one reference that supports the article content. This would also help reduce the large backlog of unreferenced articles. An important point to note is that a separate template would be created; articles already tagged with {{unreferenced}} would not be all suddenly up for deletion. Edward-Woodrow • talk 19:11, 6 October 2023 (UTC)

• Oppose. Many people who are not well versed in our policies create articles without references. Why should those of us who know better not look for sources before nominating for deletion, as is the situation now? This proposal seems to imply that articles are owned by their creators. They are not. This seems to be another step away from becoming an encyclopedia towards becoming a Google mirror. Phil Bridger (talk) 19:59, 6 October 2023 (UTC)

  @Phil Bridger: Why should those of us who know better not look for sources before nominating for deletion, as is the situation now?. I have said no such thing. In fact, to clarify any confusion, I have said the opposite: Obviously, the nominator of an unsourced article under this process should take time to conduct a quick WP:BEFORE... Edward-Woodrow • talk 20:21, 6 October 2023 (UTC)

  So what change are you proposing from the current situation? As it is a nominator can look for sources and if none are found can nominate for deletion via AfD or PROD. Phil Bridger (talk) 20:45, 6 October 2023 (UTC)

  Oppose as per your take Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 02:48, 7 October 2023 (UTC)

• Question: what's the difference between the process proposed here and the existing process of simply making a proposed deletion under WP:DEL-REASON 7 (Articles for which thorough attempts to find reliable sources to verify them have failed)? Is this proposal just meant to reaffirm that the above is a valid reason for proposing deletion? Shells-shells (talk) 21:04, 6 October 2023 (UTC)

  No, it will make it easier to delete articles for which the nominator cannot be bothered to make any attempt to find reliable sources to verify them. That would be the outcome of applying WP:BURDEN to article deletion (to which that policy has never previously applied). James500 (talk) 22:19, 6 October 2023 (UTC)

  That is the point of the proposal, yes. To expedite and facilitate removal of unsourced content, which is worthless and of no value to the project. Edward-Woodrow • talk 22:48, 6 October 2023 (UTC)

  No, unverifiable content is worthless. Unsourced content that is verifiable is not necessarily worthless, and might be very valuable. In my experience, most of the unsourced articles I have examined were very easy to find sources for, and those sources generally verified their content. James500 (talk) 01:02, 7 October 2023 (UTC)

  That's been my experience too, particularly since the Wikipedia Library. Espresso Addict (talk) 03:59, 7 October 2023 (UTC)

• Oppose, I think. If the process is what I think it is (the precise RfC proposal is very poorly explained here), it won't do anything about the backlog, just delete a few random untagged unreferenced articles whose creators have disappeared. Some people are going to want to extend the process to the entire unreferenced backlog, which would be a major disaster. —Kusma (talk) 21:22, 6 October 2023 (UTC)

@Shells-shells, Immanuelle, Phil Bridger, Kusma, James500, Espresso Addict, Pppery, Thryduulf, Red-tailed hawk, BilledMammal, Oknazevad, and David Eppstein: If you're interested here's an example:

• I recently came across Chaimite, Mozambique, an unreferenced article. Initial searches turned up databases and Wikipedia mirrors/forks/scrapers, or passing mentions that only proved its existence. The was created in 2010, by the way.
• If it was recently created, I would draftify it... but it's 13 years old.
• Under this proposal, I would tag it with {{unreferenced PROD}}, notify a WikiProject or two, and move on.
• Given the phrasing of DEL-REASON 7, though, I will continue my attempts to verify the information, probably eventually taking it to AfD or regular PROD.

Edward-Woodrow • talk 17:02, 7 October 2023 (UTC)

Or I will spend effort the page creator should have spent getting the article sourced. Edward-Woodrow • talk 17:05, 7 October 2023 (UTC)

No, it is not effort that only the page creator should have spent. As I have said before the page creator does not own the article, and this is a collaborative project, so anyone with an interest in the subject, including you, should spend the effort. Phil Bridger (talk) 18:07, 7 October 2023 (UTC)

I think this is a fine example of our current system working properly. Someone created the article as a translation from a pt article that had a source, but failed to include it. Another editor came across it later and sourced it. Encyclopedia built. Espresso Addict (talk) 22:14, 7 October 2023 (UTC)

This seems helpful. Worth at the very least a redirect to the parent Chibuto District. Deleting articles like this would make our systemic bias worse. —Kusma (talk) 17:10, 7 October 2023 (UTC)

None of that explains why standard prod, AfD, merging or redirecting are insufficient. Especially for places in parts of the world less well covered by the English-speaking internet, "initial searches" are wholly insufficient to declare an article unsalvageable. Thryduulf (talk) 17:29, 7 October 2023 (UTC)

Exactly. This would make systemic bias a lot worse on wikipedia Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 17:58, 7 October 2023 (UTC)

@Edward-Woodrow: This proposal was explicitly stated not to apply retroactively. Under this proposal, you could not tag a 13-year-old unreferenced article as you propose to tag it. This is a bad example. The proposal has not even gained consensus and already we see severe WP:CREEP in it. —David Eppstein (talk) 18:15, 7 October 2023 (UTC)

No, it would not apply to articles already tagged with {{unreferenced}}, something that article was not. Edward-Woodrow • talk 18:30, 7 October 2023 (UTC)

That's not a helpful distinction to make. We can apply this to old articles, but only if nobody has bothered to tag them for cleanup? Why? Another reason to oppose this proposal. —David Eppstein (talk) 17:17, 9 October 2023 (UTC)

• Explanation for @Kusma, Phil Bridger, and Shells-shells: I apologize that I did not sufficiently explain the proposal in my RfC statement or my !vote. The proposal is different from PROD in the following ways:
• The tag may not be removed if the problem is not fixed (like BLP PROD)
• The tag allows a longer period for adding sources.
• PROD is for uncontroversial deletion; this is for unsourced articles. Not necessarily different, but not necessarily the same.
• Re DEL-REASON 7: The attempts need not be thorough, just a quick WP:BEFORE to make sure that the problem can't be fixed super-easily.

I swear there was another difference, but my mind is blanked out at the moment. Edward-Woodrow • talk 21:53, 6 October 2023 (UTC)

• Oppose. This proposal is not compatible with WP:ATD, criteria 6 and 7 of WP:DEL-REASON, WP:NPOSSIBLE or WP:BEFORE. Unreferenced tags are very often erroneously placed on articles that are referenced. Many erroneous tags still remain on those articles. There are editors (including an entire wikiproject) trying to clear the backlog of unreferenced articles by adding sources, and an artificial two week deadline would seriously disrupt their efforts. If an editor is trying to systematically work through the unreferenced tags on, to pick a random example, articles about the chronology of Ireland (which has many obviously notable articles to which tags were inappropriately added instead of sources), it is not helpful to waste his time by forcing him to look at yet another prodlist every day. If a nominator actually cannot find sources, there is no good reason for using a "sticky" prod instead of an ordinary prod. James500 (talk) 22:16, 6 October 2023 (UTC)

  @James500: I think there is a misunderstanding. The proposal would not apply to articles already tagged with {{unreferenced}}. Unreferenced tags are very often erroneously placed on articles that are referenced. Many erroneous tags still remain on those articles. There are editors (including an entire wikiproject) trying to clear the backlog of unreferenced articles by adding sources, and an artificial two week deadline would seriously disrupt their efforts is not a problem. Edward-Woodrow • talk 22:46, 6 October 2023 (UTC)

• Support The current situation, through no fault of anyone else, amounts grandfather clause (old unreferenced articles survive, new ones usually get deleted), which is exactly what should not be happening. * Pppery * _{it has begun...} 22:51, 6 October 2023 (UTC)

  As written, the proposal has a grandfather clause for articles already tagged as unreferenced. —Kusma (talk) 13:33, 7 October 2023 (UTC)

  That's not what Edward-Woodrow said on the VPI thread. My understanding is that someone has to redundantly add the {{unreferenced PROD}} tag, but otherwise they are subject to the same process. * Pppery * _{it has begun...} 17:04, 7 October 2023 (UTC)

• Oppose Tagging or AfD (with deletion sorting) allows a reasonable chance for other editors to find sources to build a collaborative encyclopedia. Long experience with AfD suggests that many nominators either don't do references searches or do them very ineptly, and prods would receive even less scrutiny -- in my experience hardly anyone is organised enough to diligently comb through the messy list of prods. Espresso Addict (talk) 00:14, 7 October 2023 (UTC)
• Strong oppose per most people above. It is already too easy to nominate articles for deletion without even attempting to see if the problems are (a) real, (b) fixable, and/or (c) better resolvable by something other than deletion (e.g. merging or redirecting), we should be strengthening the protections against this not weakening them. Thryduulf (talk) 00:27, 7 October 2023 (UTC)
• Comment. Many NPPs will draftify unsourced articles if they are new enough (falling within the 90 day draftify rule). So there is kind of a process to handle these problematic articles already. –Novem Linguae (talk) 01:30, 7 October 2023 (UTC)
• Support. Unreferenced articles are incompatible with our core policies, including WP:V and WP:OR. This helps address that issue. BilledMammal (talk) 01:37, 7 October 2023 (UTC)

  No, unverifiable articles are incompatible with V and NOR, not unreferenced ones. This proposal does not help to add sources to verifiable but unreferenced articles. James500 (talk) 01:50, 7 October 2023 (UTC)

• Oppose. If the article is wholly unreferenced, and you think that no reliable citations for it exist, then you can already PROD/AfD the article. If the article is wholly unreferenced, and you can find citations, then stubbify the article and use them. The point of Wikipedia is to build an encyclopedia; rather than deleting wholesale, it may be better to have a one-to-two paragraph-long entry on a thing that's well-sourced (like the old paper encyclopedias used to have). And, if we can't find anything to substantiate an article, then WP:DEL-REASON#7 is more than sufficient. There's no need for a special carveout here. — Red-tailed hawk _(nest) 04:17, 7 October 2023 (UTC)
• Oppose. Typically new unsourced articles get draftified, and the proposal explicitly covers only new articles, so this process is unnecessary WP:NOTBURO and WP:CREEP. —David Eppstein (talk) 07:14, 7 October 2023 (UTC)
• Oppose. Fails to keep in line with the spirit of WP:BEFORE, and confuses the difference between article condition and notability, which is a property of the subject entirely separate from the state of the article. oknazevad (talk) 15:40, 7 October 2023 (UTC)

  and confuses the difference between article condition and notability Can you elaborate? I haven't mentioned notability anywhere in my proposal. Edward-Woodrow • talk 16:40, 7 October 2023 (UTC)

  The only true reason to delete an article is if the subject is non-notable or unverifiable. The present state of an article is not a valid deletion rationale. This basically would allow for PRODing articles based solely on their current state of referencing. That is not a proper reason to delete. oknazevad (talk) 21:56, 7 October 2023 (UTC)

  WP:5P5. Edward-Woodrow • talk 22:30, 7 October 2023 (UTC)

  I don't see how what I said disagrees with the five pillars in any fashion. Can you explain what you mean? oknazevad (talk) 03:09, 9 October 2023 (UTC)

• Support as per the discussion for new articles only. This is a situation where realistically only established editors can create articles like this, new or IP editors continuing to try and publish unreferenced articles aren't given such leniency. This theredore only brings established editors inline with what is community practice elsewhere. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:28, 7 October 2023 (UTC)

By "established editors", you mean those with autopatrolled? If an autopatrolled editor is creating articles entirely without sources, then the autopatrolled right should be removed. Espresso Addict (talk) 22:04, 7 October 2023 (UTC)

• Oppose, per several others above. BeanieFan11 (talk) 18:17, 7 October 2023 (UTC)
• Oppose. Creating unreferenced articles is undesirable and far from ideal IMO, and merely adding a citation is not at all difficult even for a new editor, who should read Help:References. However, I am unconvinced with this proposal. If I am understanding correctly, the grandfather clause is only for articles with an existing unreferenced tags and this applys to all other articles. Firstly, for new pages, the existing new page patrol system is sufficient already in sorting out problematic pages that are non-notable, unverifiable, or meet other deletion reasons. Instead, this proposal will increase the number of hasty proposed deletions mostly by non-NPRs who are more inexperienced with deletion criteria and especially NEXIST and BEFORE to little benefit. Another concern is that the rise of hasty/inappropriate PRODs will be accompanied by mass deprods that theoretically address the concern by adding a source, but then the source would be a poor one (i.e., obvious SPS and the like). There is some more benefit for older pages created years ago and are not subject to NPP, but I think that AfD is sufficient, and that inappropriate and hasty "unreferenced prods" and mass deprods that only adds a clearly unsuitable reference for older pages is still a concern. Overall, this proposal will escalate the contentiousness for little benefit. As such, due to these concerns I therefore oppose this proposal. VickKiang (talk) 20:55, 7 October 2023 (UTC) Updated on 20:55, 7 October 2023 (UTC)
• Oppose unless the process limited to certain subjects that can either cause real-world harm (e.g. medical treatments), or are severe "spam magnets" (e.g. currently available commercial products). We should not delete a page like weak operator topology because no one qualified to read and understand the potential sources has gotten around to fixing the page yet. That's tearing down a house only because it isn't finished. This site is, and will always be, a work in progress. Suffusion of Yellow (talk) 23:25, 7 October 2023 (UTC)
• Oppose This seems aimed at a nebulous idea of a problem rather than a well-understood actual problem. XOR'easter (talk) 00:20, 8 October 2023 (UTC)
• I don't really see the point TBH, there aren't that many deletion nominations due to being totally unsourced that I see the need for a lighter process. Alpha3031 (t • c) 03:09, 8 October 2023 (UTC)
• Oppose. Like some other opposers above, and mindful of WP:CREEP, I don't think there is sufficient need for introducing this new process, subtly different from existing ones yet also similar and overlapping in purpose. I hesitate to add to our assortment of deletion or quasi-deletion procedural mechanisms, which is already confusing to not-too-experienced editors. Adumbrativus (talk) 09:19, 8 October 2023 (UTC)
• Oppose - Proposal does not respect WP:DEMOLISH or WP:NODEADLINES. We don't delete unreferecend articles at AfD so doing so via prod is inappropriate. ~Kvng (talk) 19:17, 8 October 2023 (UTC)

  @Kvng: WP:DEMOLISH and WP:NODEADLINES are essays, not policies or even guidelines. I could have equally cherrypicked essays supporting by point of view: Support as nominator: respects and supports WP:REALPROBLEM, WP:DEADLINENOW, and WP:CHEWINGGUM Edward-Woodrow • talk 20:11, 8 October 2023 (UTC)

  And regarding your second point... I direct you to WP:5P5. Edward-Woodrow • talk 20:11, 8 October 2023 (UTC)

  User:Edward-Woodrow, I think we can all agree that a lack of sources is not a good thing, but why are current procedures insufficient? Some of us do some actual work by looking for sources when we don't have to spend time on these endless discussions mostly started by people who want someone else than themselves to do the work. Phil Bridger (talk) 20:34, 8 October 2023 (UTC)

  Some of us do some actual work by looking for sources when we don't have to spend time on these endless discussions mostly started by people who want someone else than themselves to do the work. Comment on content, not contributors. Edward-Woodrow • talk 21:18, 8 October 2023 (UTC)

• Oppose This proposal has clearly had a lot of thought and effort go into it, but I am not sure it is the right solution. As mentioned above, new unreferenced articles are almost always either draftified or tagged with WP:BLPPROD or {{Expand language}} (latter two if applicable), so I don't think new unreferenced articles are really a big issue. Older unreferenced articles should not be dealt with this way, either; in most cases, it would merely be a shortcut to deletion by supplanting the need to go through the proper processes (and thus WP:BEFORE checks). Curbon7 (talk) 21:27, 8 October 2023 (UTC)

  There are also old articles that haven't been tagged yet. Edward-Woodrow • talk 21:28, 8 October 2023 (UTC)

  My understanding of the proposal was that this would only be used for articles created as of the date this is implemented and not to existing unreferenced articles, no matter if those were tagged or untagged. Is that an incorrect reading? Curbon7 (talk) 22:23, 8 October 2023 (UTC)

  That is in fact an incorrect reading; and given that many people have read it this way, clarification is probably needed.

  By "does not apply retroactively", I mean that {{unreferenced}} would not be replaced with the PROD template; i.e., the contents of the backlog (the articles tagged with the {{unreferenced}} template) would not suddenly all be up for PROD. Edward-Woodrow • talk 22:28, 8 October 2023 (UTC)

  Thank you. In accordance, I have further clarified my position. Curbon7 (talk) 00:01, 9 October 2023 (UTC)

  Thanks. Edward-Woodrow • talk 00:17, 9 October 2023 (UTC)

• Motion to close this is approaching a point of WP:SNOW opposition; and in fact there is no clear proposal made here as the VPI discussion did not come close to finding consensus for any specific change. This discussion should be speedily closed. Walt Yoder (talk) 22:36, 8 October 2023 (UTC)
• Support in principle. A page w/o a single cited source is not an encyclopedic article. It is a 21st century specie of graffiti and should be dealt with accordingly. Completely unreferenced articles are incompatible with WP:V and WP:CITE. Their existence undermines the credibility of the project and should not be allowed. With the stipulation that deletion should only occur after a reasonable time in which sources can be added, something along this line is long overdue. -Ad Orientem (talk) 03:18, 9 October 2023 (UTC)

  Unreferenced articles are fully compatible with WP:V, it is unverifiable articles that are not. The two are not the same thing. Thryduulf (talk) 08:43, 9 October 2023 (UTC)

• Strong support (I see someone has written "strong oppose" above so maybe my "strong support" cancels that out otherwise I would just have written "support") I don't know whether Google or other search engines have manually favored all Wikipedia articles as well as particular ones but if they have then the existence of so many unsourced articles would be an argument for them removing that. To get rid of the backlog of unsourced articles under existing rules is likely to take at least a decade I suspect. If people want unsourced info they can just ask ChatGPT or similar nowadays, so there is no reason for us to keep our unsourced articles. Anyway the "prod" process allows an admin to get a "soft deleted" article back into draft if necessary I understand. Chidgk1 (talk) 06:30, 9 October 2023 (UTC)
• Procedural comment Can someone please add this to WP:CENT? I would do it myself, but cannot figure out a good wording for it. Curbon7 (talk) 07:53, 9 October 2023 (UTC)

  @Curbon7:  Done, I did my best with the wording but it is hard to phrase, I agree. Feel free to tweak it, of course. Edward-Woodrow • talk 13:25, 9 October 2023 (UTC)

  Not sure if it's needed to put an RFC that is snowing on T:CENT. But I guess it couldn't hurt. –Novem Linguae (talk) 13:38, 9 October 2023 (UTC)

• Oppose, due to significant overlap with normal PROD and AfD (despite the clarifications above), which are already frequently used to accomplish the same things as this proposal's stated goal. Excess overlap hints at a poorly-designed proposal. DFlhb (talk) 11:47, 9 October 2023 (UTC)
• Oppose. Unreferenced articles that went through WP:NPP would be draftified or PRODed 15-30 minutes after the article is created. As far as I know, NP patrollers are fairly zealous to act on unreferenced articles. Second, PROD in most cases are silent deletion process. New editors would just panic and didn't know what to do, while experienced editors who can help didn't know that somewhere in Wikipedia an article that they can rescue is being deleted. ✠ SunDawn ✠ (contact) 13:48, 9 October 2023 (UTC)
• Oppose seeks to overrule far-better thought out processes in WP:CREEP. Completely unnecessary. ~~ AirshipJungleman29 (talk) 14:23, 9 October 2023 (UTC)
• Oppose. I believe that our current processes are already sufficient for addressing this issue. The comments above by Red-tailed hawk and VickKiang lucidly describe my thinking on the matter. ModernDayTrilobite (talk • contribs) 15:42, 9 October 2023 (UTC)

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.

Temporary moratorium on new proposals regarding deletion, notability and related matters

At Wikipedia:Village pump (policy)#Discussion (Non-primary sourcing in NGEO) multiple editors have expressed that they feel there are currently too many concurrent noticeboard discussions regarding notability, deletion and related matters (and two others thanked me when I initially suggested a moratorium). Since then the discussion above has been opened, so it seems a formal proposal is needed:

Proposal: Until such time as all the discussions listed below are closed, withdrawn or archived without formal closure and any appeals and disputes regarding such closures have concluded, no new RFC or similarly large proposal or discussion of policy may be opened that relates to the following topics, all broadly interpreted.

1. Notability,
2. The inclusion/exclusion of types of content on a large number of pages
3. Draftification, and/or
4. Deletion

If a proposal or policy discussion meeting these criteria is opened between this proposal passing and the moratorium expiring any uninvolved administrator may close it without prejudice to the same question being asked after the moratorium expires. Reverting such a closure requires an active consensus of uninvolved editors. In borderline cases it is recommended to get agreement from a few other editors before speedily closing. The discussions concerned are:

• Wikipedia:Village pump (policy)#Admins and being paid to advise on editing
• Wikipedia:Village pump (policy)#Relationship between Notability guidelines and WP:NOR
• Wikipedia:Village pump (policy)#Requirement for non-primary sourcing in NGEO Withdrawn
• Wikipedia:Village pump (policy)#RfC on the "Airlines and destinations" tables in airport articles
• Wikipedia:Village pump (proposals)#Changes to GEOLAND Withdrawn
• Wikipedia:Village pump (proposals)#Request for comment: Unreferenced PROD Closed

Any relevant discussions/proposals omitted from the list (e.g. any begun after the proposal was made) should be added to the list (unless the proposal is rejected). Discussions that are closed, withdrawn or archived should be struck (not removed).

This is explicitly not intended to prevent or limit the asking of genuine questions, the functioning of specialist noticeboards/discussion venues (e.g. WT:CSD, WP:RSN, WikiProject talk pages, etc) as long as such discussions are not used to avoid needed wider community consensus. Thryduulf (talk) 01:10, 7 October 2023 (UTC)

Survey (temporary moratorium on new proposals)

• (Support) As proposer. The large number of discussions is exhausting editors resources and hindering their ability to productively improve the encyclopaedia. Thryduulf (talk) 01:11, 7 October 2023 (UTC)
• (Support) * Pppery * _{it has begun...} 01:16, 7 October 2023 (UTC)
• (Support) Per Thryduulf: it is genuinely getting hard to do any real work here (including deletion) for having to repetitively check forum after forum for discussions on matters related to deletion or notability. The repeated RfCs are quite literally exhausting and are encouraging uncivil discourse. Espresso Addict (talk) 01:23, 7 October 2023 (UTC)
• (Support) The sheer number of proposals, the speed with which they are being proposed, and the sheer number of comments in those discussions, is making it impossible for other editors to get anything useful done elsewhere on the project. This has been going on for some time, and there have been a number of other proposals that were closed recently, in additions to the ones listed above. If you look at the ideas lab, and the talk pages of a number of the notability guidelines, there are a large and increasing number of discussions planning for further RfCs in the immediate future. There appears to be a real possibility of the village pump being flooded with an even larger number of RfCs. James500 (talk) 01:47, 7 October 2023 (UTC)
• Support per nom and James500. Dave (talk) 03:48, 7 October 2023 (UTC)
• (Support) Yes, I've stopped reading this page but saw this proposal on my watchlist. Johnuniq (talk) 03:59, 7 October 2023 (UTC)
• Oppose. If someone wants to propose a small but substantial tweak or clarification to a policy, I see no reason why they should be prohibiteed from doing so. Moreover, the language discussion of policy may be opened that relates to the following topics... deletion is overbroad; certainly we are able to have discussions of policy as it relates to deletion—when they are in the contexts of specific XfD nominations. The proposal also bizarrely includes a prohibition on discussing the various deletion/notability policies until a completely unrelated discussion (i.e. Wikipedia:Village pump (policy)#Admins and being paid to advise on editing) is closed, which is nowhere near narrowly tailored towards the problem that some are experiencing with discussion burnout. Moreover, the Reverting such a closure requires an active consensus of uninvolved editors line will inevitable lead to a closure review at AN for times when this is invoked, which will further the amount of time spent discussing these sorts of things while also simultaneously directing editor energy towards procedural matters rather than substantial ones. As written, the proposal is overbroad in its scope, and it may well create more work than if the proposal were to never have been made. — Red-tailed hawk _(nest) 04:05, 7 October 2023 (UTC)
• Support - it's counterproductive to pile the blasted things up as has been done recently. Ingratis (talk) 05:16, 7 October 2023 (UTC)
• Oppose, per RTH. Notability might be a hot topic right now, but it is still a topic that we are being productive on with many of the recently closed discussions have substantial results - and while I understand that many editors may disagree with those results, disagreeing with results in not a reason to shut down a topic. BilledMammal (talk) 07:26, 7 October 2023 (UTC)

  This is not shutting anything down, it's just pressing pause on any future discussions until the current ones have concluded so that all the discussions can be productive without disrupting the encyclopaedia. Thryduulf (talk) 11:18, 7 October 2023 (UTC)

• Support. This is starting to get the feel of certain editors attempting to get their way not by achieving actual consensus, but by exhausting so many of the contributors who have other better things to do in their wiki-editing that only the notability-crackdown enthusiasts are left. —David Eppstein (talk) 07:27, 7 October 2023 (UTC)
• Oppose, this is far too broad. All the referenced RfCs appear to be unrelated and all opened by different editors. I don't think any of those editors should open up new large RfCs, but I'm not sure we should moratorium new ones from other editors. On these sorts of RfCs, I think it is useful to keep them open for a bit longer than normal so that there is more time for editors to add to them, at least until discussion dies down naturally, and pressure to close might pre-empt that. CMD (talk) 09:23, 7 October 2023 (UTC)
• I fully understand the underlying sentiment, but I'm not convinced this is the right way to deal with the issue. We do seem to have a lot of RfCs with possibly wide-ranging consequences recently (not always advertised at all the places that would be affected by the proposal in violation of WP:LEOPARD). Some kind of rate limit and/or rejection of more under-prepared RfCs might be a good idea; this proposal is an emergency brake that doesn't really fix anything going forward. —Kusma (talk) 09:55, 7 October 2023 (UTC)

  This is intended to allow some time and space for long-term solutions to be identified and developed. Thryduulf (talk) 11:17, 7 October 2023 (UTC)

  On balance, I support. Discussions that are postponed by this will have more time to draft better RfCs in userspace or at the idea lab. —Kusma (talk) 13:30, 7 October 2023 (UTC)

• Support, excellent idea. I think we're passed the point where these attempts to tighten notability standards have become disruptive. The volume, the bludgeoning, the attempts to make major changes based on local consensus – these are not the signs of a good faith attempt to build consensus. I hope this can cool things down, otherwise the next step has to be arbitration. – Joe (talk) 09:58, 7 October 2023 (UTC)
• Support I have little to no skin in the game, and even I think some should keep NODEADLINE higher in their minds. ~~ AirshipJungleman29 (talk) 10:09, 7 October 2023 (UTC)
• Oppose The numerous discussions are a sign that this complex area needs work, not that we should prohibit working on it. It might need better organization / coordination, but broadly nuking it like this is not a good idea. North8000 (talk) 10:22, 7 October 2023 (UTC)

  This does not "nuke" anything, it simply requires that current discussions are concluded before starting any new ones - i.e. that better organisation/coordination you agree is needed. Thryduulf (talk) 11:15, 7 October 2023 (UTC)

  i.e. that better organisation/coordination you agree is needed That's not what this proposal is asking for; even proposals that are well organized and coordinated would be prevented. If that was all this proposal was asking for I would support it - although there are other pages I would support it on first, such as WP:RSN which has far too many RSP-related RFC's. BilledMammal (talk) 11:25, 7 October 2023 (UTC)

  No discussions will be prevented. They will just need to wait until the current discussions have concluded first. Thryduulf (talk) 11:28, 7 October 2023 (UTC)

  One of the proposals on this list was work-shopped over repeated revisions for a period of months before being brought here. Particularly, the proposal should be neutrally-worded (which this one is not) and well-thought out so as not to have unexpected side-effects (which this one is not).

  What I'm hoping the proposer is getting a feel for here is, it's actually very difficult to bring a proposal here and I doubt any of the people doing so are doing so lightly. FOARP (talk) 22:40, 7 October 2023 (UTC)

• Oppose More activity and discussion >> Less activity and discussion. Selfstudier (talk) 11:27, 7 October 2023 (UTC)
• Oppose The large, dare I say say overwhelming, number of unsourced or poorly sourced stubs needs to be addressed, and the search for an approach that will receive a broad support should not be limited. - Donald Albury 12:20, 7 October 2023 (UTC) (Edited 12:25, 7 October 2023 (UTC))
• Strongly oppose: far too broad. Also per Selfstudier. My first thought on seeing this was: why the hell would we want to stymie discussion on important topics? Edward-Woodrow • talk 12:33, 7 October 2023 (UTC)

  We don't want to stymie discussion, we want to facilitate productive discussion alongside productive contribution to the encyclopaedia without burnout. If there are too many concurrent discussions this is not possible. Thryduulf (talk) 13:19, 7 October 2023 (UTC)

• Support It seems to me we need a bit of cooling off of the broad topic area, a lot of these discussions seem to have the same sides bludgeoning each other with increasing allegations of ABF on both sides. And I include the "paid advising" RFC in that.
  I note this type of behavior isn't specific to this topic area, a month or two back we had the same thing happen with proposals related to MOS:GENDERID where people jumped on the bandwagon of proposing things and forked off several new RFCs as old ones got too heated. In fact, it seems some of the same people were deeply involved in those as are in this one too... Anomie⚔ 12:36, 7 October 2023 (UTC)
• Oppose - the problem isn't too many RFCs, it's a few editors bludgeoning the crap out of them. Deal with the bludgeoning editors instead of having a moratorium on RFCs. Levivich (talk) 14:47, 7 October 2023 (UTC)
• Oppose. Badly thought out, and more or less certain to result in more round-in-circles arguing if anyone was so misguided as to try to enforce it in any but the most trivial cases. AndyTheGrump (talk) 14:59, 7 October 2023 (UTC)
• Oppose I can understand the sentiment, but this would have far to many consequences. Also why is Wikipedia:Village pump (policy)#Admins and being paid to advise on editing, it has nothing to do with "deletion, notability and related matters". I agree with others here that less replying to replies, of replies, of replies, etc.. would make a big improvement. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:24, 7 October 2023 (UTC)
• Support something to halt the notability-RFC-after-notability-RFC-after-notability-RFC pattern - this is getting dizzying for me how many different notability proposals by the same group of editors are active. BeanieFan11 (talk) 18:17, 7 October 2023 (UTC)

  I have to wonder... I am one of those editors? Edward-Woodrow • talk 18:31, 7 October 2023 (UTC)

  I don't know anymore...if you are one, I've lost track because of the sheer quantity of proposals. BeanieFan11 (talk) 18:33, 7 October 2023 (UTC)

  Five is the quantity of notability proposals listed in this proposal. These five proposals were made by five different editors: Newimpartial, BilledMammal, Sunnya343, FOARP, and Edward-Woodrow. I'm not sure how they constitute the same group of editors, as I'm unaware of them ever doing anything as a group, like repeatedly voting the same way in other RfCs or AfDs or anything. Five is not too many RFCs for me to keep track of, although if one writes a dozen or more comments per RfC, then I could see how doing that in five RFCs would be overwhelming. For everyone. Levivich (talk) 18:57, 7 October 2023 (UTC)

  The "same group of editors" also implies there's some kind of deletionist conspiracy going on. Edward-Woodrow • talk 19:07, 7 October 2023 (UTC)

• Opposed - Having multiple large RFCs (on unrelated topics) hitting the Pump at the same time is nothing new, and is hardly disruptive. And it shouldn’t be a time sink. Just formulate your thoughts, state your opinion on the question as clearly as you can and move on to your regular editing. Don’t respond to other editor’s comments unless they directly ask you to clarify something you said. I know it is tempting to refute every opinion that disagrees with your own. Don’t do it. Don’t bludgeon the discussion. Blueboar (talk) 18:57, 7 October 2023 (UTC)
• Oppose any attempt to shut down discussion on these topics. Also, what Levivich said. Certain editors (including the odd admin) need to take a step back and stop bludgeoning these RfCs every time someone disagree with them. _wjemather^{please leave a message...} 19:24, 7 October 2023 (UTC)

  Once again this is not an attempt to "shut down" any discussion on anything, just to spread the discussions out in time. Thryduulf (talk) 19:34, 7 October 2023 (UTC)

  The framing of the proposal (including the title) and several of the comments and contributions, both here and in the discussions listed, tell a different story. And you continue to bludgeon. _wjemather^{please leave a message...} 06:32, 8 October 2023 (UTC)

  If you wish to read something other than what I have written, and characterise the proposal based on what I haven't written, then that is your prerogative but please do not expect me to agree with you. Thryduulf (talk) 10:04, 8 October 2023 (UTC)

• Oppose and Bad RFC - This is a non-neutrally-framed RFC question that simply assumes the proposals to be bad faith, and in some way connects a group of people who basically aren't connected. Particularly where they say "This is explicitly not intended to prevent or limit the asking of genuine questions" - does the proposer think the RFCs weren't genuine questions? The proposal would also block discussions that recently passed (but which the proposer opposed...) such as the LUGSTUBS draftification proposals. BM already agreed to withdraw their proposal on notability, so why is this proposal necessary? This is "temporary" moratorium that could last an indefinitely long amount of time given it being tied to the closure (after any review or other process) of five mostly unconnected discussions. Moreover the area banned for discussion includes a topic (mass creation of articles) that ARBCOM literally mandated discussion of (albeit that was withdrawn after no conclusion was reached, though obviously we should still try to reach some kind of conclusion).
  If you are exhausted in discussing certain issues then don't discuss them. If you want to do other things, then go and do them. It is the very essence of WP:BLUD/WP:BATTLEGROUND to think you have to rebut every single point in a discussion and cannot do anything else because you have to "win" for your "side".
  Finally, can I point out the extreme irony of attempting to shut down "exhausting" discussions by . . . making a proposal to shut them down then responding to people opposing with repetitive comments like "Once again this is not an attempt to "shut down" any discussion on anything"? FOARP (talk) 22:24, 7 October 2023 (UTC)

  Not an RfC. Edward-Woodrow • talk 22:29, 7 October 2023 (UTC)

  I didn't know we could just jump over the neutrality requirement by simply not using the template? FOARP (talk) 22:34, 7 October 2023 (UTC)

  This isn't an RFC, assumes nothing about the merits or otherwise of anybody or any discussion, assumes no good or bad faith about anything, does not connect the discussions in anything other than subject matter and makes no connections between those starting proposals (it doesn't even mention the discussion initiators at all so I'm puzzled where you've got this idea from?). No discussions are or will be "prohibited" or "blocked", no topic area is "banned" (as I've explicitly said multiple times now). Also, the moratorium idea was endorsed by multiple people with differing views on the merits of the different proposals, so this is not one side trying to "win" anything - the only suggestion of a battleground is from you. TLDR, almost none of what you've written relates to what has actually been proposed here, almost everything that does relate is incorrect. Thryduulf (talk) 23:06, 7 October 2023 (UTC)

  Literally the whole first paragraph is about why your proposal is a great idea - not a neutral question even in the slightest. ”as I’ve explicitly said multiple times now” - maybe learn something from this? FOARP (talk) 05:21, 8 October 2023 (UTC)

  Whether it is neutral or not, exactly none of it assumes anything about the nature of the discussions, the merits of the discussions, or the initiators of the discussions. Try reading what I wrote rather than what you want me to have written. Thryduulf (talk) 10:00, 8 October 2023 (UTC)

• Support It seems like a good idea to pace ourselves and obtain one consensus at a time, so that later discussions can refer to earlier ones. XOR'easter (talk) 00:17, 8 October 2023 (UTC)
• Oppose. The listed discussions are only loosely related at best, and the proposed moratorium is unwarranted and absurdly broad. Adumbrativus (talk) 09:42, 8 October 2023 (UTC)
• Oppose: Far too broad of a proposal and purports that other proposals are a burden upon others in some unclear way. Nom appears to be a long-winded case of WP:IDONTLIKEIT as it pertains to gaining the support of the wider community for various issues. User:Let'srun 12:50, 8 October 2023 (UTC)
• Oppose This feels like a proposal in search of a problem, and a non-neutral framing of the situation. No one forces any editors to engage with any or all proposals, and they're not actually related to the same things. If there's an issue with vexatious RfCs or conduct therein, that can be dealt with at an editor level. Der Wohltemperierte Fuchs ^talk 17:58, 8 October 2023 (UTC)
• Support - Many of the articles are being removed/drafted without proper research being done to see if they are or aren't notable. There's been many articles that were proven to be notable that were marked anyway to be drafted, yet nothing changes and nobody seems to care. I think it's wrong to ask people to look through a thousand articles at a time to check for notability. This is just turning into an endurance contest and that should not be what this is about. The best part about all of this is that it is becoming the exact same thing that mass article creations were about - getting things done fast and in large quantities, then worrying about the details later.KatoKungLee (talk) 21:18, 8 October 2023 (UTC)
• oppose I don't think this make sense from a procedural perspective. In the first place, I don't see how anyone who wasn't here for this should feel in the last bit bound by it. Second, since the effect is basically to shut out those who have a problem with the status quo, it isn't really a moratorium for the proposers. Third, the only reason I can see for a moratorium is to discuss a larger scale proposal, which isn't out there yet. Mangoe (talk) 04:43, 9 October 2023 (UTC)
• Oppose per Levivich, FOARP, and David Fuchs. XAM2175 ^(T) 23:14, 13 October 2023 (UTC)
• Oppose: A good faith idea that is impractical to implement. This is certainly a non-neutrally-framed RFC question. Per user CMD's comments we can simply leave an entry open as long as there are recent comments. -- Otr500 (talk) 19:06, 14 October 2023 (UTC)

Discussion of temporary moratorium on new proposals

• Comment. Not sure the discussion on paying administrators to consult is on topic? Espresso Addict (talk) 01:26, 7 October 2023 (UTC)

  @Thryduulf, should Wikipedia talk:WikiProject Boxing#RfC on readding upcoming fights in professional boxing record tables be in your list? WhatamIdoing (talk) 04:31, 7 October 2023 (UTC)

  I wasn't aware of that discussion, but it could qualify. At present it doesn't seem to be utilising a lot of editor time, so I'll leave it off for now but it can be added if that changes. Thryduulf (talk) 11:25, 7 October 2023 (UTC)

  I agree, the admin discussion seems unrelated to the problem of too many open fronts in the deletionist-inclusionist war and should be removed from the proposal. —Kusma (talk) 06:43, 7 October 2023 (UTC)

  I included that discussion as it is a large discussion featuring a lot of the same editors with similar consequences for editor time. The point of this proposal is not a "deletionist-inclusionist war" (or any other "war") but too many large discussions open concurrently. This proposal would not stop a new discussion on that subject but I don't think that is likely. Thryduulf (talk) 11:23, 7 October 2023 (UTC)

  If that's the case you may have wanted to title the section something other than Temporary moratorium on new proposals regarding deletion, notability and related matters. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:30, 7 October 2023 (UTC)

  The title does accurately reflect the scope of the actual proposal being made. That doesn't mean it's perfect but I'm not sure I can come up with something that is both concise and not misleading - you might be able to (concise summaries are not my strong suit) but I'd prefer if comments could be restricted to matters related to the proposal as written rather than matters related to what a different proposal with this title might have said. Thryduulf (talk) 18:22, 7 October 2023 (UTC)

  How is "Admins and being paid to advise on editing" related to deletion and notability? BilledMammal (talk) 05:31, 8 October 2023 (UTC)

  In fact, I'm not even sure how "RfC on the "Airlines and destinations" tables in airport articles" is related to deletion and notability; if you could explain that as well I would appreciate it. BilledMammal (talk) 05:32, 8 October 2023 (UTC)

  It is a discussion with potential destructive consequences for many articles. —Kusma (talk) 07:38, 8 October 2023 (UTC)

  Which one? Regardless, that might be your opinion, but it doesn't explain how it is related to deletion or notability? @Thryduulf:, can you explain why you believe those two discussions are related to deletion or notability? BilledMammal (talk) 09:11, 8 October 2023 (UTC)

  For the airlines discussion see point 2. For the admin discussion see previous answers. Thryduulf (talk) 09:57, 8 October 2023 (UTC)4

  Point 2 doesn't seem to be related to "notability and deletion"? Even on the basis of that, I have to agree with AD that your title is inaccurate and does not accurately reflect the scope of the actual proposal being made.

  For admin discussions, are you referring to I included that discussion as it is a large discussion featuring a lot of the same editors with similar consequences for editor time.? That doesn't explain how it is related to "notability and deletion"? BilledMammal (talk) 10:08, 8 October 2023 (UTC)

  The title is "deletion, notability and related matters". If you read the whole of the answer you quote and replies you will see I have already answered your question regarding admin discussions. Thryduulf (talk) 10:11, 8 October 2023 (UTC)

  The title is "deletion, notability and related matters". Yes. How is The inclusion/exclusion of types of content on a large number of pages related to deletion and notability?

  The rest doesn't answer my question; it's a discussion unrelated to "notability and deletion", and shouldn't be in the scope of this proposal. I agree with the above editors that you either need to reword the proposal, or remove that discussion. BilledMammal (talk) 10:42, 8 October 2023 (UTC)

• This isn't how consensus works. We don't put gag orders on topics. The frequency of these discussions (and I expect more in the near future) indicates that there's a series of interrelated, long-standing problems that editors are finally attempting to fix. Even if this was something at all enforceable, I see little to gain by saying "fix them more slowly". Thebiguglyalien (talk) 18:34, 7 October 2023 (UTC)
• BM’s RFC (which I think has been productive) has been withdrawn, as had been agreed before this present discussion even opened. The GEOLAND discussion I previously opened only had a relatively short period of time left before it was due to be archived anyway, and discussion there had come to a natural conclusion, but I’ve withdrawn it all the same. If these discussions truly were as taxing as made out here, closure of them could have been requested through the ordinary channels: I ask the proposer here to be consistent with their own statements about how tiring and distracting they find these discussions, and withdraw this one, which I do not believe is likely to pass. FOARP (talk) 11:27, 8 October 2023 (UTC)

Indeed, with the closure of the prod discussion, I think we're now down to a reasonable number of discussions, so closing this one too would seem sensible. Espresso Addict (talk) 23:01, 9 October 2023 (UTC)

• Comment I agree with the above that having such a vast blanket mortarium on new proposals is misguided but I would like to express my concern/general worries about not just the haste and successiveness of these proposals but also the reach. A lot of the articles I've made/contributed to would be significantly affected by some of the proposed changes (particularly those in the deletionism/inclusionism field) but I only figured out about these proposals from random chance (one of the editors involved in these discussions happened to send me an unrelated message to me and took a while to respond so I got worried and noticed their contributions on the proposals). While in an ideal world going through proposals quickly and efficiently would be great, there has to be much more done in the way of notifying affected users, especially those who would be significantly impacted by each proposal or are an active, major contributor to a wikiproject that would be affected. That said, given the number of open discussions on the page has dropped sufficiently low, this proposal isn't really necessary (e.g. a mortarium isn't necessary) but it would be beneficial to take a patient/slow approach with future high-impact proposals (maybe extended the time a discussion could be kept open/active depending on the context?). Also, while I guess it would depend on the articles in question, it would also be good to have discussions about mass-deletions of fewer, more narrowly defined articles (I'm thinking specifically of the LUGStubs proposals which were overly expansive and poorly executed, imo). In any case, these are just my experiences, thoughts, and opinions but hopefully they have some bearing on this and future proposal discussions. Cheers, Dan the Animator 01:59, 10 October 2023 (UTC)

  This requirement cuts both ways though - we've seen in the past stub articles created at a rate of hundreds a days by an individual editor based on a single, primary source, with the explicit idea that other editors would expand the resulting stubs, but without anyone ever really being consulted on the idea. When it turned out that the sources they were using had been epicly mis-understood/were inaccurate and that there was no actual secondary sourcing on which those stubs could be expanded, it was already way too late for any intervention from the community to stop Wikipedia being spammed with tens of thousands of useless and inaccurate stubs. When confronted with this, the editor simply responded with bizarre accusations and quit the project. That was more than two years ago and we're still trying to clean up the resulting mess.

  No-one should simply build up a fait accompli of unimprovable stubs so numerous that none of the processes we have in place can handle them, without any discussion with anyone about it. We even had an ARBCOM ruling on this: "Editors who are collectively or individually making large numbers of similar edits, and are apprised that those edits are controversial or disputed, are expected to attempt to resolve the dispute through discussion. It is inappropriate to use repetition or volume in order to present opponents with a fait accompli or to exhaust their ability to contest the change. This applies to many editors making a few edits each, as well as a few editors making many edits." FOARP (talk) 07:44, 10 October 2023 (UTC)

• I fundamentally believe editor time is a precious resource we should try to be thoughtful about expending. But I don't understand, on a practical level, how this moratorium does anything productive. In order to do something productive in the end I feel like we'd have to set some priorities so that the questions that lots of editors care about aren't forced to wait in some queue for things relatively few people care about to be finished. And I just have trouble imagning that working. And frankly I think we could do better with being more decentralized in general. "Back in the olden days" these kinds of discussions were happening all the time, and no one saw it as a problem. Partly this is because of the editor base we had at the time (which wasn't necessarily larger but which was distributed and focused in different ways), but also, crucially, people didn't feel like decisions were as fixed so if you didn't have time at the moment it wasn't like you lost your chance to weigh in on the topic forever. Doing something about that feels equally as manageable as some kind of nebulous moritorium. Barkeep49 (talk) 22:14, 11 October 2023 (UTC)

Enable RC patrolling (aka patrolling for edits)

This is something that has been bothering me for years now. Many other wikis have patrolling for edits in recentchanges and watchlist and it drastically improves efficiency of vandalism patrollers. Edits done by autopatrolled users automatically gets marked as patrolled, reverted and rolled back edits also automatically get marked as patrolled too (as there is no need to be reviewed again) but also when someone reviews an edit and it doesn't need to be reverted, they can mark the edit as patrolled which avoids double, triple or more reviews by others.

You can enable the filter to only look at unpatrolled edits (or combine that filter with other filters, such as ores damaging ones). The software for it already exists and this feature is enabled in Wikidata, Commons, French Wikipedia, Italian Wikipedia, Dutch Wikipedia, Chinese Wikipedia, Portuguese Wikipedia and Vietnamese Wikipedia (Wikis with above >1M articles) and many more wikis.

One concern was that it might start a massive backlog of edits needed to be reviewed (like pending changes) but the patrolled status gets purged after 90 days so no large backlog will be made (and it's better than status quo where there is no status stored). It was enabled in here in January 2005 but some people didn't like the "!" it adds next to unpatrolled edits. That was almost nineteen years ago when we didn't have ores or highlighting or filtering in RC/Watchlist. We can change that exclamation mark if people want it to or completely hide it (I can make the software changes necessary if there is consensus for anything different). That's not really an issue now.

What do you think? Ladsgroup^overleg 17:39, 10 October 2023 (UTC)

• Support as proposer. Ladsgroup^overleg 17:39, 10 October 2023 (UTC)

  Heh. Disclosure: We had talked about this in person and I was invited to this discussion via e-mail. To my understanding, the one huge difference to Pending Changes is that all edits are immediately visible to the public. There is no queue of edits that need to be reviewed before they're displayed to readers. However, the patrol permission required to mark edits as patrolled seems to be the same one we grant at WP:PERM/NPR (cf. Special:ListGroupRights#patroller). We can either start granting that flag liberally (not going to happen) or practically forget about the idea then... ~ ToBeFree (talk) 18:25, 10 October 2023 (UTC)

  @Ladsgroup: From your link: Patrolled edits is a feature which allows specific users to mark new pages and items in Special:RecentChanges as "patrolled" We have WP:RCP and WP:NPP which seems the same, or very similar. RudolfRed (talk) 18:28, 10 October 2023 (UTC)

  @RudolfRed They are the same code and software but many wikis allow the same for edits (not just new page creations). Ladsgroup^overleg 18:39, 10 October 2023 (UTC)

• Question: First, is this compatible with mw:Extension:PageTriage that we already have? Second, I think at the least it uses the same groups/etc - which means we'd likely end up greatly expanding those that bypass parts of new page review. — xaosflux ^Talk 18:30, 10 October 2023 (UTC)

  @Xaosflux Why would it interfere with PageTriage? This is about edits not page creations.

  They use the same rights as the NPP which can become a problem as @ToBeFree mentioned but the fix is not that hard in the software, we can split the right and define a new group. That part is fixable. Ladsgroup^overleg 18:42, 10 October 2023 (UTC)

  @Ladsgroup I don't recall the details, but something about how the very enwiki customized pagetriage hooks the patrol system already? — xaosflux ^Talk 18:44, 10 October 2023 (UTC)

  It uses patrolling for new pages but it can't interfere with the edit patrolling in any way, the only complication is that the rights are the same which can be fixed easily. Ladsgroup^overleg 18:48, 10 October 2023 (UTC)

  The entire MediaWiki extension would be changed to make it compatible with enwiki's new page patrolling? ~ ToBeFree (talk) 18:48, 10 October 2023 (UTC)

  nah, the code for it is not too hard to change and if we want to deploy NPP to more wikis that might have edit patrolling, we have to change it anyway. Ladsgroup^overleg 18:50, 10 October 2023 (UTC)

• Seems like trouble - every non-user revision would be un-patrolled, which I expect would instantly flood queue in to a backlog that will never get cleared. — xaosflux ^Talk 18:46, 10 October 2023 (UTC)

  The queue gets automatically purged after 30 days, as I said above. Ladsgroup^overleg 18:47, 10 October 2023 (UTC)

  And the point of it is not to clear any queues either. You will just have a a new filter to avoid re-reviewing edits and wasting your time. Ladsgroup^overleg 18:55, 10 October 2023 (UTC)

• Oppose. If the right is new-page patroller, a critical feed which is nearly always backlogged, we don't want to divide the attention of the small group of people who are trusted to work in this area into something significantly less pressing. Espresso Addict (talk) 21:53, 10 October 2023 (UTC)

  Actually the more I think about this, the less I like it. Frank vandalism is usually easy to spot and revert, so wastes little time. The really problematic edits are PoV pushing of one form or another, and it would be trivial for a PoV pusher/paid editor to get the permission and then reduce scrutiny on problematic edits. Espresso Addict (talk) 00:19, 11 October 2023 (UTC)

• Comment I review most edits on my watchlist by hovering over (diff) (or "(3 changes)", etc.) with Popups. This is quick and easy. I'd be much less productive, and less likely to bother, if I had to click (diff) against every edit, wait for the page to load, click "mark as patrolled" and find my place in the watchlist again. Certes (talk) 22:11, 10 October 2023 (UTC)

  The support for marking edits patrolled can easily be added to popups. Ladsgroup^overleg 11:05, 11 October 2023 (UTC)

  Or... you could just not mark things as patrolled, @Certes.

  I don't think that everyone is understanding this proposal. Think of the question this way:

  • We could have a system that allows admins and other editors we trust to optionally signal to other editors – the ones who are voluntarily choosing to use this feature – to signal to the other editors in the opted-in group that one editor personally thinks a given edit no longer needs extra eyes on it (e.g., because it was reverted already, or because the patroller knows that it's good).
  • If you choose to use this optional system, then you can filter Special:RecentChanges to show you only those edits that other editors either haven't checked or are uncertain about. You would not need to see (and re-check) edits that other editors have already marked as acceptable. You would know which ones have no been checked, instead of assuming that the entire list of recent changes needs your personal attention.
  • Nobody will be required to use this system. In fact, it would probably be good to have a mix of editors: some being more efficient (so that everything gets checked, instead of some edits being checked many times and others being overlooked), some looking at their watchlists, and others looking at everything they can (to double-check).
  • Note that not re-re-re-re-checking known-good edits is what anti-vandal tools like Wikipedia:Huggle do automatically, so this is not a new idea.

  I think the question really is: Do you want to ban other editors from voluntarily and easily sharing information about which edits they've already checked, keeping firmly in mind that if you personally don't want to use their system, then it doesn't need to affect you at all? WhatamIdoing (talk) 01:07, 16 October 2023 (UTC)

• (edit conflict) If this happens, we definitely need separate "new page autopatrolled" vs. "recent change autopatrolled", as well as "new page patroller" vs. "recent change patroller" user-rights. I'm not convinced this is a good idea anyway, but I'm not an active RC patroller so I'll leave the merits to others.
  Although creating that split means that global rollbackers would lose new-page autopatrolled, instead of me having to manually unpatrol every article they create. * Pppery * _{it has begun...} 22:13, 10 October 2023 (UTC)
• Comment. This reminds me of a conversation a few months ago at Help talk:Citation Style 1/Archive 89#Proposal: 'Verified' parameter, and is a subgenre of the mark something as "no action needed" problem. Personally I feel like the proposal here would create an immense amount of paperwork and possibly false sense of security, but I do think a general optional tickbox for "looks good to me" could be beneficial. Generally, we want to double check each other's work but not octuple check it. It's a grey area for sure.
  Folly Mox (talk) 22:29, 10 October 2023 (UTC)

  While I understand your point, I want to mention that this has been working for over a decade in many large/medium wikis including mine without a a lot of paperwork and has been quite useful. A wiki can turn it into a paperwork nightmare or something lean if they chose to. Ladsgroup^overleg 11:22, 11 October 2023 (UTC)

• I'm generally supportive. If it can be made to work technically, i.e. there's no unresolvable conflicts with other extensions, and we can get a sensible set of permissions, I think this would help prevent a lot of duplicated effort. -- zzuuzz ^(talk) 22:42, 10 October 2023 (UTC)
• Support individual changes for rollbackers and administrators. Old vandalistic and other disruptive edits often go unnoticed for years. Oppose new pages inside of mainspace for anyone who is not a new page reviewer or autoreviewer, as those require a solid understanding of the deletion policy beyond the criteria for speedy deletion. Awesome Aasim 17:16, 11 October 2023 (UTC)

  giving the right to rollbackers is a good idea to avoid creating yet another group of users and extra paperwork. There is a major overlap between rollbackers and patrollers too (if not the exact same). Ladsgroup^overleg 17:55, 11 October 2023 (UTC)

.Oppose If you believe something might be wrong you should check it yourself, not rely on other editors. Either this user right is limit to a small group, making it ineffective, or a larger group, opening it up to all kinds of abuse. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:36, 11 October 2023 (UTC)

I think you're wrong. You can choose to ignore this system and still check every change (do *you* check every change now?). You'll give the patrol right to your trusted users, with the possibility of having the right removed if they're no longer trusted; patrol actions are logged, and you can easily tell who marked each change as patrolled. Can you say that *every* change has been seen by someone (trusted) now? I'm pretty sure a user with, say, 2000 clean edits is a good patroller candidate, someone I'd trust. But I'd still sometimes take a look, even if the change was marked as patrolled. Nothing to lose here, trust me! Ponor (talk) 03:25, 15 October 2023 (UTC)

@ActivelyDisinterested, you say If you believe something might be wrong you should check it yourself, not rely on other editors, but there's nothing in this proposal that would prevent you from doing exactly that. So why the opposition? WhatamIdoing (talk) 01:09, 16 October 2023 (UTC)

I didn't say "I should check", maybe I should have said "should be checked". This system and many other recent discussion on similar things would mean that editors are relying on other editors for verification. That shouldn't happen, it's fundamentally wrong.

This has nothing to do with currently checking all edits, the question is trusting current edits. I don't blindly trust current edits, no editor should, but this would directly implement a system of doing exactly that. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:11, 16 October 2023 (UTC)

Our current system works like this:

• Alice looks at Special:RecentChanges and looks at the diffs for edits 1, 2, 3, 4, and 5. She wasn't sure about edit 2, but she didn't think it was bad enough to revert. Maybe someone else will look at it.
• Bob looks at Special:RecentChanges and looks at the diffs for edits 1 and 4.
• Chris looks at Special:RecentChanges and looks at the diffs for edits 1, 2, and 4.
• David looks at Special:RecentChanges and looks at the diffs for edits 1 and 4.

Result: Nobody looks the diff for edit 6 or 7. Four people have checked edits 1 and 4. Two people have checked edit 2. One person has checked edits 3 and 5. If you wrote it out in order, editors looked at diffs 1111223445XX.

Imagine that we instead said:

• Alice looks at Special:RecentChanges and looks at the diffs for edits 1, 2, 3, 4, and 5. She marks edits 1, 3, 4 and 5 as okay, but isn't sure about edit 2.
• Bob looks at Special:RecentChanges and looks at the diffs for edits 1 and 4, just like he always did.
• Chris looks at Special:RecentChanges, turns on the filter so they can see what others haven't already accepted, and looks at the diffs for edits 2, 6, and 7. Chris marks edit 7 as okay, but isn't sure about edits 2 or 6.
• David looks at Special:RecentChanges, turns on the filter so he can see what others haven't already accepted, and looks at the diffs for edit 2 and 6. David – who wouldn't have looked at either of these diffs under the previous system – is able to resolve the question about edit 2 but leaves edit 6 in the queue for another editor.

In this scenario:

1. Any editor can still look at whatever they want, like Bob did.
2. Any editor can voluntarily focus on the un-patrolled edits, like Chris and David did.
3. The result is that more people look at the uncertain diffs, and somewhat fewer editors look at the obviously good edits. If you wrote it out in order, editors looked at diffs 1122234456667.

What I'm not hearing from you is any reason to believe that requiring all editors to randomly checking RecentChanges is a better system (as measured, e.g., in the percentage of diffs that get looked at by an experienced editor) than having the old system plus allowing some editors (i.e., those who want to) to check specifically the ones that other editors haven't indicated is okay. Adding this system takes nothing away from you. Why do you want to take away the opportunity to use a different system from the editors who want to use it? WhatamIdoing (talk) 17:42, 16 October 2023 (UTC)

I was going to say almost the same. We like to think that every change gets 'seen' by someone, but in reality I'm observing a lot of propaganda, wp:refspam, false statements, original research (...) being added and never reverted. This system will raise some red flags for those edits, especially as they get closer to the 30 day limit. Ponor (talk) 18:28, 16 October 2023 (UTC)

Nothing you added changes my point. It isn't, and has never been, about what editors can check and again it has absolutely nothing to do with what I can check.

As you have just said the purpose is for editors to not have to check obviously good edits. But that is just a backwards way of saying editors won't check edits based on the reliablity of other editors, and is directly in opposition to how things should be done.

Nothing you have said, nor anything anyone else has said in support of the proposal, changes that this change would have a large negative effect on the project. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:29, 16 October 2023 (UTC)

Or as an exaple.

1) Editor A marks a edit as approved

2) Editor B sees that editor A has marked as approved and doesn't check it.

3). FAIL -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:31, 16 October 2023 (UTC)

That could only happen if everyone is using it (I rate this as being exceedingly unlikely), and it could only make things worse if we additionally assume that Editor B does nothing (e.g., reviewing other edits and therefore finding other problems; I rate this as unlikely).

But again: Why should you get to effectively ban other editors from using this tool? Nobody's going to force you to use it, but why shouldn't other editors be permitted to do so, if they wanted to? WhatamIdoing (talk) 18:47, 16 October 2023 (UTC)

Other editors shouldn't use it because using it would have a negative impact on the project, for the reasons I have outlined (a few times). This is again, for the second time, nothing to do with my using it or not. Please stop trying to twist my words in that way.

The situation in my last comments happens every time an editor doesn't check an edit because another editor they trust "approved" it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:10, 16 October 2023 (UTC)

The situation in your last comment happens only if no editors check an edit because another editor they trust "approved" it. It does not happen when some editors move on to other, unscreened edits.

This is already being done by anti-vandalism tools such Huggle, and the situation you hypothesize is already not happening. Why do you think that having one more tool doing this will create your situation, when your situation has not materialized through the tools that are already doing this? WhatamIdoing (talk) 21:03, 16 October 2023 (UTC)

Some or most makes absolutely no difference, as I have already stated about whether the right is given to a large group or a small one. Also the suggest 2000+ edits for an editor in good standing is not a small group, it would just be the new watermark to reach for POV pushers.

This is not done by current tools, or at least to my knowledge, at the moment edits are highlighted as potentially bad by an algorithm. This would mark edits as "good" in the opinion of an editor, the inverse of the current situation.

I've shown using your own example that there is a problem. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:36, 16 October 2023 (UTC)

This is done by existing tools. Some of them, including Wikipedia:Huggle, set up a feed with the idea that it's better to check all edits once than to check some of them multiple times and some of them never.

This green button is used in Huggle to mark an edit as a "Good Edit".

If the edit is cleared by one Huggle user, then it's not shown to other Huggle users. See mw:Manual:Huggle/Quick start#Controls, especially the green icon associated with the words "Clicking on the green pencil with the checkmark will flag the edit as a good edit."

You don't have the user right necessary to use Huggle, so I'm sure you've never personally seen it, but it's still happening whether you've seen it or not. WhatamIdoing (talk) 01:38, 17 October 2023 (UTC)

I don't care for such things, due to the many issues such things cause. If this is already happening it's not something we should encourage, as per my previous statements. Making a bad situation worse, doesn't make it better. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:32, 17 October 2023 (UTC)

So:

• it's been happening for years, and
• you believe it causes many issues, but
• you can't point to a single example of any issue it's ever caused.

Okay. WhatamIdoing (talk) 17:52, 18 October 2023 (UTC)

Or as an example. (1) Editor A marks a edit as approved (2) Editor B sees that editor A has marked as approved and doesn't check it. (3). FAIL

The issue with this reasoning is that patrol actions are logged, and you can easily tell who marked each change as patrolled, quoting Ponor. In other words, there's accountability. Make a few mistakes, fine (page watchers probably couldn't have caught it either), you'll get some feedback and learn. Make consistent mistakes and your RC patrol right is revoked. DFlhb (talk) 23:24, 16 October 2023 (UTC)

So great we now have to have watchers for the watchers. How about instead don't have such a system, and all editors are watchers of all edits. I made a similar point in my original statement. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:34, 17 October 2023 (UTC)

You don't need to watch the watchers. No one in other wikis do that, there are many ways to surface incorrect patrol including highlights, people who don't use the edit patrolling, etc. Ladsgroup^overleg 14:08, 17 October 2023 (UTC)

That other wikis don't do something I feel they should do is the epitome of OTHERSTUFFEXISTS. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:28, 17 October 2023 (UTC)

In you list of checks, 1122234456667. The problems is that 3 and 5 could be the edits with issues, but because everyone takes Alive as a reliable source they are not checked again. This change creates an environment where editors are trained to think in ways that the opposite of how they should think about the situation. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:41, 16 October 2023 (UTC)

Sorry, I should have specified from the beginning, from my viewpoint as the omniscient narrator that edits 2 and 6 were the suspicious edits. WhatamIdoing (talk) 18:49, 16 October 2023 (UTC)

So yes, your suppositions are correct if you control all the variables. But life is not like that. In a real world situation were you are not the "omniscient narrator" edits 3 and 5 could be the edits with problems, and your system would mean they are not checked when they should be. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:05, 16 October 2023 (UTC)

Edits 3 and 5 weren't checked in the existing system, either. WhatamIdoing (talk) 01:23, 17 October 2023 (UTC)

Maybe, maybe not. But this system ensures they are not, because it's a system that trains editors to not check such edits. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:35, 17 October 2023 (UTC)

At most, it would "train" the ~9,000 of admins and editors who have rollbacker rights to divide the workload rationally. The rest of us – more than 100,000 editors each month – wouldn't be able to use it. WhatamIdoing (talk) 14:53, 17 October 2023 (UTC)

It would train them to do something I have repeatedly said I feel is a negative the project. That you don't have the same opinion is obvious, that you don't seem able to take onboard that I disargree is verging of IDLT territory. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:27, 17 October 2023 (UTC)

I have no idea why my opposition in particular has gained so many replies, but I've had enough of it. I won't be replying to any further comments. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:30, 17 October 2023 (UTC)

• Oppose per EspressoAddict and ActivelyDisinterested. Quis custodiet ipsos custodes? Edward-Woodrow • talk 20:41, 11 October 2023 (UTC)
• Support. I'm not sure how other wikis use it, but I don't see a disadvantage to keeping track of which pages have been checked at least once, whether this is applied to all pages, a specific subset or as needed. If people want to, they can continue to check the feed of all edits, it's not like turning this on would disable to normal recent changes feed. Patrols don't have to always be good, as long as they're correct more than 50% of the time, that's potentially useful information. I don't see the merit of not collecting information for fear of people using it badly in this specific case. Maybe it would be better if instead of defaulting to everything needing to be checked, everything gets automatically patrolled but RCPers can unpatrol things they find suspicous, I know there's a "suspicous edit" button in Huggle that I don't use very much (when I actually do RCP, which isn't much these days), but I'd say the best way to see how well it'll work is to enable it as a trial. If nothing else, having a log of patrol actions would help collect data on RCP work (or some subset of it), even if the data isn't directly used on-wiki at all. Alpha3031 (t • c) 14:56, 14 October 2023 (UTC)
• Support. I don't understand how you work here without this bookkeeping system, but I do see how and why some false statements I discovered over the years found their way into enwiki and stayed for a long time: I myself sometimes think someone else will take care of the things, but do they? By enabling this extension, you have nothing to lose. I've patrolled thousands of edits on another wiki, even made it easier to patrol from recent changes, page history, and user contributions pages by using two scripts for "inline" patrolling (much easier than that floating window, Certes!) from this proposal (check animated pics to see how patrolling works). As for who should patrol: all advanced rights users, any additional "trusted" users... as I said, this is just another bookkeeping system, let those who want to use it - use it. Nothing will change for those who don't. Ponor (talk) 02:59, 15 October 2023 (UTC)
• Support because it's an optional system that can be used by those that want to use it and ignored by those who don't want to be bothered with it. Ladsgroup, I suggest talking to the maintainers of the Wikipedia:Cleaning up vandalism/Tools. There's no reason to require two clicks. People like Remagoxer (on the RedWarn/UltraViolet team) would probably like to know about this, assuming it gets implemented. WhatamIdoing (talk) 17:51, 16 October 2023 (UTC)
• Support. This seems great; it enables optional 'coordination' when scrutinizing the watchlist. Even though it's not perfect, I think it's valuable to reframe: fighting against bad edits is best done through defense in depth. ORES, page watchers, people who check recentchanges, this new RCpatrol, anything that helps, by any amount, is good to have in the toolbox. Fully optional, too - DFlhb (talk) 00:02, 17 October 2023 (UTC)
• Support as a great idea – easy way to improve our accuracy. As it stands an immense amount of unsourced and incorrect additions get through the system, and by spreading out who checks what more evenly the percentage of bad edits getting through will dramatically lessen. Even requiring two editors to check every good edit would IMO improve efficiency. J947 † ^edits 03:43, 17 October 2023 (UTC)
• Oppose as not a great idea ~ per ActivelyDisinterested and EspressoAddict. Obvious vandalism is easy to spot and is then reverted; less obvious stuff benefits from as many eyes as we give it. I fail to see the benefit. Happy days, ~ Lindsay^Hello 14:58, 18 October 2023 (UTC)

  @LindsayH, but what makes you think it won't get enough eyes? The only thing that's added is a little red exclamation mark in recent changes *for users with patrol rights*, which only they can remove, and they still get to see all edits on their watch list. There's no change whatsoever for nonpatrollers. Ponor (talk) 07:09, 19 October 2023 (UTC)

Discussion (Enable RC patrolling (aka patrolling for edits))

Could someone comment on the other large wikis that the proposer is referencing? Do they have a large editor base that is similar to en-wiki? The smaller wikis of my acquaintance tend to have sufficiently few highly active editors that triaging patrolling by the "have I heard of this editor" method is a rational strategy.

Also, could an admin active in permissions comment on how much scrutiny is given to rollbackers? My guess is not enough to grant this kind of right, but I don't work in this area. Espresso Addict (talk) 00:45, 12 October 2023 (UTC)

They are mentioned in the proposal Ladsgroup^overleg 10:22, 12 October 2023 (UTC)

Two notes:

• The patrol logs can be used to improve ML models of vandalism highlights and revertbots. I already used the patrol logs to build the revert bot in my home wiki. I can see this could be used to improve general AI models.
• I feel there is a bit of misunderstanding on how this works, possibly a trial period to show its pros and cons and then we can decide? Ladsgroup^overleg 20:05, 15 October 2023 (UTC)

@Ladsgroup, have you talked to your colleagues in Tech, just to make sure that the servers won't fall over if this is enabled here? WhatamIdoing (talk) 00:54, 16 October 2023 (UTC)

@WhatamIdoing yeah, specially since this is enabled in wikidata (which has a massive flood of edits) which caused issues in 2017 and I overhauled how the data is stored around that time and now it's quite healthy. Ladsgroup^overleg 12:11, 16 October 2023 (UTC)

What is the proposed workflow for a bad edit? If User:Vandal serves up spam and User:Helpful reverts the addition, is the first edit marked as patrolled because it's been assessed, or left unmarked because it wasn't approved, or marked in some other way as bad but dealt with? What if the first edit isn't marked "reverted"? (Perhaps the second edit also fixes a typo, or it keeps part of the first edit because it mixed useful information with a spammy citation.) Certes (talk) 11:14, 18 October 2023 (UTC)

@Certes If it's a rollback, it automatically gets marked as patrolled by the software itself. I think that is also the case by manual revert but not 100% sure. But conceptually a reverted edit is a patrolled one since there is no further action is needed. Ladsgroup^overleg 14:05, 18 October 2023 (UTC)

Should this be mentioned in CENT or if there is a wikiproject for patrolling (I couldn't find one), notify its members? Ladsgroup^overleg 14:22, 18 October 2023 (UTC)

The most relevant one would probably be WP:CVU. Alpha3031 (t • c) 22:32, 18 October 2023 (UTC)

done Ladsgroup^overleg 14:44, 20 October 2023 (UTC)

RfC about the criteria for existence of emoji redirects

What should be done with emoji redirects, particularly with emoji redirects that are found to represent vague concepts that are not well reflected on Wikipedia? Utopes _{(talk / cont)} 02:52, 16 October 2023 (UTC)

Initial options

Option 1: All emoji redirects should target lists of symbols by default, such as emoji which appear on Supplemental Symbols and Pictographs or Symbols and Pictographs Extended-A. Option 2: Emoji redirects should only target pages where the emoji is directly mentioned or referred to, such as Face with Tears of Joy emoji. All other emoji should instead exist as redirects to relevant lists of symbols. Option 3: Emoji redirects should only target pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire. All other emoji should instead exist as redirects to relevant lists of symbols. Option 4: Emoji redirects should only target pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire. All other emoji with ambiguous designs should be deleted, and not target lists of symbols. Option 5: Emoji redirects should only target pages where the emoji is directly mentioned or referred to, such as Face with Tears of Joy emoji. All other emoji redirects should be deleted. Option 6: Delete all emoji redirects.

Update: The options have been recontextualized. If an article mentions or refers to an emoji, such as Face with Tears of Joy emoji, it is currently practiced to have the emoji in question (😂 in this instance) exist as a redirect to such page. This is the status quo for these situations, which is not being disputed. This RfC was intended to address the gray area where there isn't a perfect match for a target, so I've narrowed the options as follows:

For emoji redirects that don't have an associated article in existence, should we:

• Option 1: Retarget all other emoji redirects to lists of symbols by default, such as emoji which appear on Supplemental Symbols and Pictographs or Symbols and Pictographs Extended-A.
• Option 2: Retarget to pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire, and retarget ambiguous emoji to relevant lists of symbols.
• Option 3: Retarget to pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire, and delete all other emoji redirects with ambiguous meanings.
• Option 4: Delete all other emoji redirects without associated articles.

Background

Over the last several months, there have been several Redirects for Discussion entries at increasing frequency about the justification for the existence of emoji redirects. At this point, there are often several different discussions happening on a weekly basis, which often boil down to the same general viewpoints about how to deal with redirect emojis as a whole. Some past discussions that have recently closed in September and early October include the following: RfD on 🤪, RfD on 🙀, RfD on 🤭, RfD on 👩%E2%80%8D💻, RfD on 💨, RfD on 🫸, among many discussions which were also ongoing during this period, as well as many others which have cropped up and still have not been closed. The only precedence which has been recorded is in an RfD subset page which documents the common outcomes of discussions, and under the section for WP:REMOJI. During recent discussions, however, this documentation has been challenged and dated, particularly relating to emoji that can be depicted and interpreted differently on multiple platforms and different people, and whether or not a redirect is necessary for these emoji in the first place. Comments on this matter would be appreciated to help determine whether or not all emoji should inherently be considered as "likely search terms" and automatically exist as redirects, or whether there should be criteria for inclusion for emoji redirects to exist in the first place. Utopes _{(talk / cont)} 02:52, 16 October 2023 (UTC)

Survey (Emoji redirects)

• I sympathize most with Option 2, and I would further suggest that most or almost all such 'single-glyph redirects' should be treated in basically this way, as I see this system as being the most helpful to the reader (though I am happy to be persuaded otherwise! :D). For example, suppose I were to encounter the symbol ❦, unfamiliar to me, in a digital document; to learn about it, my most obvious course of action would be to copy and paste that single character into the search bar. If I were to do so right now, I would be redirected to fleuron (typography), which explains what this glyph is and how it's used. This behavior makes sense to me. Moreover, if an article specifically about some glyph does not exist (as is the case for ⌀), then it makes sense to me that a search for that glyph should redirect to whatever location deals most specifically with it as a glyph (in this case, diameter#Symbol). At the moment, this seems like helpful redirect behavior, and I don't see why emojis in particular should be treated much differently. Tl;dr: I think redirects from emojis should generally point the reader to a location that discusses the emoji as an emoji. Shells-shells (talk) 03:44, 16 October 2023 (UTC)

  I am not sure about my terminology, so feel free to substitute grapheme or character or some other term in the place of glyph as you like. Shells-shells (talk) 04:06, 16 October 2023 (UTC)

• Option 2, was writing more but Shells-shells covered it very elegantly. Glyphs should redirect to the location where readers can learn more about that glyph. If the best is a list of glyphs, redirect there. Don't redirect to a particular interpretation of meaning, emojis take on different meanings in conversation far removed from the official intention. CMD (talk) 03:51, 16 October 2023 (UTC)
• Option 7, do not try to prescribe this centrally, but let RFD do its thing on individual redirects based on individual consensus. Do not mass-create, do not mass-delete. —Kusma (talk) 09:24, 16 October 2023 (UTC)

  We've tried to this, with not-so-pretty results. Edward-Woodrow • talk 12:13, 16 October 2023 (UTC)

  I would strongly push back against that characterization. -- Tavix ^(talk) 13:26, 16 October 2023 (UTC)

  I agree with Tavix. The recent discussions of emoji redirects have pretty much all ended in a clear consensus and the discussions have been perfectly civil affairs. Thryduulf (talk) 14:49, 16 October 2023 (UTC)

  In addition, keep all emoji redirects that are potentially affected by this discussion but haven't been tagged for deletion, per WP:LEOPARD. Option 8 is also better than the options presented above. —Kusma (talk) 13:32, 16 October 2023 (UTC)

  I disagree. Individual debates are often long and ineffective. Martin Tauchman (talk) 14:13, 16 October 2023 (UTC)

  ... but aren't they more likely to produce the correct result for individual emoji? —Kusma (talk) 15:57, 16 October 2023 (UTC)

• Option 3 (the numbers changed?): the "definitions" of emojis, frequently touted by Keep !voters at RfD, may be subject to change, and, furthermore, the interpretation of what an emoji means is wholly subjective and may vary from person to person. Worse, display varies across operating systems and devices, adding another layer of complexity. In this way, I believe ambiguous emoji redirects should be deleted, as their interpretations may vary, and no target is good. Retargeting to the emoji block is not very helpful to the reader, as all it tells them is "wow, it's an emoji", while targetting to the "definition" is only one of many interpretations. Straightforward emoji redirects, like the fire example mentioned, should probably be kept, as they indirectly inform the reader of the meaning of the emoji.
  Take 🤪. Is that silliness? Zanyness? Insanity? Drunkenness? Or just someone having a really good time? Who knows? The consensus of that discussion was retarget to Supplemental Symbols and Pictographs, which is better than the alternatives, I guess, but not really helpful to the reader, as explained above. Edward-Woodrow • talk 12:21, 16 October 2023 (UTC)

Option 2 is my second choice. I strongly oppose Option 8. We should not have to create entire DAB pages for emojis. We're not emojipedia. And, as a side comment, there is a tendency at RfD that the "definition" of the emoji as listed in unicode is the end-all of potential interpretations. Edward-Woodrow • talk 19:45, 16 October 2023 (UTC)

And also, I maintain that emojis are unlikely search terms, that we're not emojipedia, and that we should have to provide results for people pasting emojis into the search bar for who-knows-what reason. But consensus seems unlikely to swing that way. Edward-Woodrow • talk 19:48, 16 October 2023 (UTC)

• I personally would find Supplemental Symbols and Pictographs useful, as it tells me the unicode number for 🤪. There are other websites I suppose, but I don't think a redirect to information about the emoji is a bad thing for en.wiki. CMD (talk) 12:26, 16 October 2023 (UTC)

  Note the official Unicode character names cannot change, to the point where errors are left uncorrected. See Unicode Technical Note #27, Known Anomalies in Unicode Character Names for examples. isaacl (talk) 16:04, 16 October 2023 (UTC)

• Option 6 deals soundly with vacuous, cretinous inanity. Serial 12:24, 16 October 2023 (UTC)
• (edit conflict) Option 8. Emojis with articles should target those articles, other emoji with meanings that clearly correspond to one article should target that article. Emojis with meanings that correspond to multiple articles should target a list, disambiguation page, set index or other place where readers can follow links to the article(s) relevant to their search. Other emojis should redirect to relevant lists of symbols. Emoji should be redlinks only when we want to encourage the creation of an article about that emoji and/or its meaning. Thryduulf (talk) 12:31, 16 October 2023 (UTC)

  So we should create emoji disambiguation pages? Because what existing DAB page covers the potential meanings of 🤪? Edward-Woodrow • talk 19:42, 16 October 2023 (UTC)

  I see no reason not to if that is the best option, that's why Stuffed flatbread was created, but 🔴 targetting the pre-existing Red Circle disambiguation page is going to be the more common example. Thryduulf (talk) 20:15, 16 October 2023 (UTC)

• Option 8 sounds good to me. Option 7 was tempting but RfDs don't attract enough attention to provide consistent treatment. Certes (talk) 12:46, 16 October 2023 (UTC)
• Option 8 is a good summary of the status quo and consensus at recent RfDs. -- Tavix ^(talk) 13:26, 16 October 2023 (UTC)

I'm now in favor of finalizing a list of emoji and retargeting them all there. Draft:List of emojis (faces) looks excellent! -- Tavix ^(talk) 19:51, 20 October 2023 (UTC)

I support that too, given that it clears up the ambiguities effectively. Edward-Woodrow • talk 19:57, 20 October 2023 (UTC)

• Option 8 seems like a good solution here. And in general I'm against deletion of any emojis just as I would be against deletion of letter glyphs being deleted. --Gonnym (talk) 13:43, 16 October 2023 (UTC)

  Gonnym, could you elaborate on your reasoning? It's not self-evident why someone would oppose the deletion of redirects from letters on principle, so it's not clear what to infer from that analogy to the case of emoji. _signed, Rosguill ^talk 13:50, 16 October 2023 (UTC)

  Are you serious? If the letter A did not have an article, are you seriously saying you think that Wikipedia would be better off without a redirect from the letter to a more general place where that article is dealt with? Other examples would be Ƞ redirecting to a descriptive title such as N with long right leg or א leading to the English language title. Do you believe these should be deleted and users should just have to find the best targets for themselves? These are the same for emojis and in fact, the numerous past RfD have shown that some of the nominations have been the result of the nominator not understanding them, so deleting them would result in even less clarity. Gonnym (talk) 14:05, 16 October 2023 (UTC)

  What about letters with accents, which could be resolved as either the letter or as the accent? Or letters for which, for one reason or another, we don't have a suitable target yet? Or letters that are also the names of actual things/places (such as Å, which could refer to 12 different towns in Scandinavia, or Angstroms, or just the letter). Or uncommon digraphs such as fl (which currently points to a less-than-helpful disambiguation page), including letters such as ƣ that have ambiguous codepoints (that symbol currently is used for both Turkic gha and as a Medieval Latin digraph for oi, but those are two letters with distinct histories that should not and in the future may not have the same codepoint). Or letters that are themselves notable enough to meet WP:REDYES criteria? What about logographic characters used in Chinese or Japanese? _signed, Rosguill ^talk 14:27, 16 October 2023 (UTC)

  All valid. Gonnym (talk) 18:18, 16 October 2023 (UTC)

• Option 2 makes the most sense. Emoji's frequently have contested meanings - so we should not guess where a redirect should go. --Enos733 (talk) 15:09, 16 October 2023 (UTC)
• Option 8 per Thryduulf. Enix150 (talk) 20:20, 16 October 2023 (UTC)
• We should be treating these the same way we do foreign-language redirects. Lorry is an English-language word for the same concept as "truck", and so redirects there. (It could have been the other way around.) "Lastkraftwagen", "camion", and "貨物自動車" are how that concept is spelled in German, French, and Japanese; they don't redirect to truck because trucks don't have anything in particular to do with Germany, France, or Japan. They don't have anything to do with iconography, either, so ⛟, 🚚, and 🚛 are just as inappropriate. It's a different matter entirely for an article like smiley, which is specifically about little pictures of happy faces, just as it is for Deutschland, département, and 東京都. —Cryptic 20:47, 16 October 2023 (UTC)

---

I've added a partition here, as the options' wording has been adjusted. For the suggested Options 7 and 8 proposed above, Option 8 now more closely aligns with the current Option 2 (minus the redlink clause), whereas Option 7 would be the rejection / opposition of all other options, and to deal with redirects on a case by case basis. Utopes _{(talk / cont)} 16:50, 16 October 2023 (UTC)

The new option 2 does not closely match option 8 as it is missing the important clause about emoji with multiple article matches (e.g. 🔴 → Red Circle (a disambiguation page), 🥙 → Stuffed flatbread (a set index)) as well as the redlink clause. Thryduulf (talk) 18:07, 16 October 2023 (UTC)

• This is one of those RFCs that I wish had been formatted as a Request for Actual Comments instead of a simplistic Request for Numbered Votes. Here's what I want: If I paste an emoji into the search bar, I want it to take me to some place that tells me what that thing is. It doesn't actually matter if it's perfect. As a general rule, I'm just trying to figure out what that tiny little thing is. I can read without my glasses on, but I can't tell you what 🤾 is even with them on. Please redirect those to some sensible page. If you send them to a list, then please make it really easy to figure out which list item it's being redirected to. WhatamIdoing (talk) 19:54, 16 October 2023 (UTC)

  For 🤾, I'm guessing a discus thrower, a frisbee player, a dancer, or a track athlete. Edward-Woodrow • talk 19:56, 16 October 2023 (UTC)

  It's "person playing handball". The emoji redirects to Handball, so the question is answered correctly. -- Tavix ^(talk) 20:00, 16 October 2023 (UTC)

  Its Unicode name is simply "HANDBALL", so the question's answered even more correctly. Certes (talk) 21:29, 16 October 2023 (UTC)

  Without my glasses on, it looks kind of like sparkles. Confetti, maybe? With them on, maybe it's a dancer. WhatamIdoing (talk) 05:46, 17 October 2023 (UTC)

  This is exactly the reason why I see redirects from emojis as a Good Thing and it's the principle behind my option 8 of retargetting to the most specific place we have. Thryduulf (talk) 21:05, 16 October 2023 (UTC)

• I'm in favor of Option 2 for the reasons described more elegantly than I could above (thanks to Shells-shells and others). But what I want to add to the discussion is that we should be more perscriptivist than descriptivist because the nature of emoji's creation is technical, rather than their use, which can be covered in an article if necessary, like the one described above where the emoji now gets an article such as Face with Tears of Joy emoji. That's where editors should be allowed to use secondary sources to delve into the descriptivist side of things using secondary sources. That's the nuanced that's missed when we allow 👩‍💻 to redirect to Women in computing but 👨‍💻 gets Information technology, maybe? That's not what was written when the standard was created. Yes, ❦ leads to Fleuron (typography) because that's what it is. If there isn't a 1:1 match for the description of the character as set by the standard (🔥 to Fire, and 🛑 to Stop sign), or an article about the technical thing it describes such as (⏯️ play/pause button to Media control symbols and 💨 dashing away to The Lexicon of Comicana § Briffits) then it should be redirected to the technical list so people can see the perscribed definition of a technical glyph. 🙀 should not be cat because the nuance can't be captured in a redirect--it's a weary cat, 👩‍💻 isn't women in computing, it's a women technologist, and 🫸 isn't a hand (not that I'd be able to tell, it doesn't load on this browser) it's a rightwards pushing hand--because I can't see it, that's required nuance that I'd miss if I were redirected to hand.
  In summary, I think much like the importance of keeping the redirect for simple and uncontroversial emojis is required for an encyclopedia, losing the nuance of a technical glyph via non-specific redirect hurts the purpose of an encyclopedia. For that reason, we need to make sure there's diligence and clear directives not to allow broad redirects, and to save the nuance. And that's accomplished by redirecting to the list with technical descriptions. microbiologyMarcus ^{(petri dish)} 21:05, 16 October 2023 (UTC)

• Other I suggest creating a new article titled List of emojis (similar to the List of emoticons article), and suggest all those emojis redirect to that 'List of emojis' article instead. Some1 (talk) 23:02, 16 October 2023 (UTC)
• Comment (completely confused by the change in available options). I agree with above commenters that someone pasting such a character into Wikipedia search is most likely to be looking for an idea of what it is generally considered to represent, and redirection to that particular symbol if we have an article, or to a list of symbols including it if we do not, is most likely to be useful. I'm not sure why we have a list of emoticons but not a list of emojis that states the usual associated meanings? I also don't think redirecting, say, 🔥 to Fire should necessarily be the norm, even where a 1:1 correspondence can be agreed; after all we often deliberately don't redirect foreign language terms. (And in that particular case, I've seen it used as "you're on fire" or "go you!" or "hot!" kinds of metaphorical meanings, rather than the literal one.) Espresso Addict (talk) 00:04, 17 October 2023 (UTC)
• Support Option 8 seems to be reasonable --Lenticel ^(talk) 00:14, 17 October 2023 (UTC)
• I agree with WhatamIdoing, if I search for an emoji I just want the article that is most helpful. Emojis with articles should redirect to those articles, emojis without articles should redirect to a new list articles explaining the emojis with appropriate links as needed. I don't think emojis should be redirected to articles about the subject they represent. 🤾(Person Playing Handball, as mentioned above) redirects to Handball, but that article makes no mention of the emoji so it's hardly helpful for someone looking for details about the emoji itself. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:17, 17 October 2023 (UTC)
• Option 1 - specifically this is a vote against redirecting 🥕 to Carrot or 🔥 to Fire. The title for an emoji should have information about the emoji, not the concept it represents. Ideally, there will be a link to the concept (or several related concepts) on the target page.
  Deleting these outright is asking for a long series of well-intentioned re-creations; some redirect should be maintained for these titles. Walt Yoder (talk) 21:39, 17 October 2023 (UTC)
• Strong oppose Option 4, neutral on others. Frostly (talk) 22:00, 17 October 2023 (UTC)

  @Frostly: May I ask why? Edward-Woodrow • talk 22:37, 17 October 2023 (UTC)

  Emojis greatly aid in navigation, especially for younger generations. Including them as redirects is one more step towards modernizing the site. Frostly (talk) 23:17, 17 October 2023 (UTC)

• Option 1 Any other outcome feels nonsensical. Why would we redirect 🔥 to fire?? If I'm googling an emoji, I want to see it in its emoji context, i.e. the list of emojis. I know what a fire is. What I don't know is the background behind the fire emoji. CaptainEek ^{Edits Ho Cap'n!}⚓ 00:50, 18 October 2023 (UTC)
• Start again. There are references to options 7 and 8 which don't ever seem to have been defined. You can't move the goalposts halfway through. Stifle (talk) 11:47, 18 October 2023 (UTC)

  Option 8 was proposed by Thryduulf. "Emojis with articles should target those articles, other emoji with meanings that clearly correspond to one article should target that article. Emojis with meanings that correspond to multiple articles should target a list, disambiguation page, set index or other place where readers can follow links to the article(s) relevant to their search. Other emojis should redirect to relevant lists of symbols. Emoji should be redlinks only when we want to encourage the creation of an article about that emoji and/or its meaning." Enix150 (talk) 03:21, 21 October 2023 (UTC)

• Redo RFC, per Stifle. The new option numbers overlap with the old option numbers reusing the same numbers for different options. The survey is thus essentially incomprehensible. Sandizer (talk) 12:27, 18 October 2023 (UTC)

  IMO, we should just cancel the RfC and let editors work on the List of emojis article (non-redirect), along with its subpages (Draft:List of emojis (faces), etc.) Some1 (talk) 12:35, 18 October 2023 (UTC)

• #️⃣1️⃣ - info about the emoji, not the concept it represents. 👍 Levivich (talk) 14:04, 18 October 2023 (UTC)
• Restart RFC per Stifle.The 🏎 Corvette 🏍 ZR1^{(The Garage)} 17:07, 18 October 2023 (UTC)
• Restart per Stifle as they have a good point as well as what Sandizer mentioned Isla 🏳️‍⚧ 19:55, 19 October 2023 (UTC)
• Do we really need an RfC for this? The point of RfD is to discuss where a redirect should point to. If there is no agreement as to what the title means, it usually results in deletion or disambiguation. Status quo is fine. Awesome Aasim 13:07, 20 October 2023 (UTC)

  Because there is no firm policy on emoji redirects, which makes discussion difficult; it descends into a matter of opinions. A policy, or at least a guideline, addressing what to do with these things, would make discussion much easier (I've noticed that on old log days, emoji discussions are almost always the last to be closed). Edward-Woodrow • talk 19:33, 20 October 2023 (UTC)

  Yes, we do. It helps significantly to establish the pros and cons of emoji redirects before discussing them, as currently there's a lot of talking past one another going on in these RfDs. J947 † ^edits 23:29, 20 October 2023 (UTC)

Discussion (Emoji redirects)

Notifying @Edward-Woodrow:, @Lenticel:, @Gonnym:, @Thryduulf:, @Tavix:, @Enix150:, @Illusion Flame:, @MicrobiologyMarcus:, @Yoblyblob:, @TartarTorte:, @Hey man im josh:, @Qwerfjkl:, @Ivanvector:, @Polyamorph:, @Rosguill:, @A smart kitten:, @Pppery:, @ClydeFranklin:, @BDD:, whom have weighed in on one of the currently ongoing emoji redirect discussions. Utopes _{(talk / cont)} 03:15, 16 October 2023 (UTC)

@Utopes: I'm not sure the options are set up optimally. It should be completely uncontroversial that emojis with articles should target those articles, such as Face with Tears of Joy emoji, no matter which option we choose for the rest. Then we have four options for emojis without articles: a) redirect all to Unicode block (same as your 1 & 2); b) redirect to unambiguous subjects, else default to Unicode block (same as your 3); c) redirect to unambiguous subjects, else delete (same as your 4); d) delete all. -- King of ♥ ♦ ♣ ♠ 03:21, 16 October 2023 (UTC)

@King of Hearts: I think you're probably right in the sense that a delete-all option would be a beneficial "nuclear option", so I will go ahead and add that. With that out of the way, in that case, would your suggestion be to remove Option 1 or 2 and shift everything else up? My reasoning for including a difference between #1 and #2 was to have an option that was close to nuclear while allowing some valid exceptions, i.e. "emoji redirects are only valid to articles about emoji". I think this differs from Option 1, which I felt would be the standard nuclear option that is directly opposite of mass-deletion, using the stance that "emojis shouldn't ever be redirects to topic articles, and should only ever target lists of symbols (because emoji are symbols)".

If you think its too uncontroversial, I'll strike it out, but wanted to make sure I was understanding your thought process first. Utopes _{(talk / cont)} 04:19, 16 October 2023 (UTC)

@Utopes: I think there are way too many options now, which just makes it more confusing. And the problem is that outside of Options 2 and 5, it is unclear what is being proposed for emoji redirects to direct targets. Instead there are two orthogonal questions: 1) If there is an article on an emoji (as the subject of the article), should the emoji redirect to that article? (Note that this question does not ask what to do if the answer is no. I assumed the answer here is obviously yes, but maybe it's not so obvious and it doesn't hurt to ask.) 2) For all emoji redirects that have not been explicitly allowed under the previous question, what should be the criteria for inclusion? (Here we have my four previously proposed options.) -- King of ♥ ♦ ♣ ♠ 08:31, 16 October 2023 (UTC)

I see what you mean. I think the current option setup made a bit more sense in my head than in practice. I viewed there to be three different "priorities" that emoji redirects could have. They could be treated as "symbols" and symbols only, they could be treated as the image they depict, or they could not be dealt with at all (and deleted). In other words, a "Yes", a "Yes, AND", and a "No". In general, I feel like 6 options is likely the "maximum" number to be able to wrap around (especially if its fundamentally a 3x2), although it also depends on the options themselves. Option 1 and 6 might have been too extreme of choices by ignoring obvious alternatives to mass-deletion/redirection, and unnecessarily add complexity because of it, so I'll take your advice and re-contextualize the solutions. Utopes _{(talk / cont)} 16:28, 16 October 2023 (UTC)

• Could lists in addition to Miscellaneous Symbols and Pictographs be provided for reference? That list doesn't seem to have any of the emojis that were subject to rfds listed. CMD (talk) 03:39, 16 October 2023 (UTC)

•  Done Utopes _{(talk / cont)} 04:26, 16 October 2023 (UTC)

fwiw, I don't think I received this ping, not sure anyone else did. _signed, Rosguill ^talk 13:48, 16 October 2023 (UTC)

No, pings only work when they are signed in the same edit. The ping edit was not signed. -- Tavix ^(talk) 14:38, 16 October 2023 (UTC)

Huh, I didn't realize that the ping's functionality depended on a signature; I put the ping-list together after setting things up to alert people that it's live. At this rate, I'm not sure whether it would be worth it to re-send the pings though. Utopes _{(talk / cont)} 15:46, 16 October 2023 (UTC)

At this point it can't hurt. Notifying @Edward-Woodrow:, @Lenticel:, @Gonnym:, @Thryduulf:, @Tavix:, @Enix150:, @Illusion Flame:, @MicrobiologyMarcus:, @Yoblyblob:, @TartarTorte:, @Hey man im josh:, @Qwerfjkl:, @Ivanvector:, @Polyamorph:, @Rosguill:, @A smart kitten:, @Pppery:, @ClydeFranklin:, @BDD:. Edward-Woodrow • talk 19:57, 16 October 2023 (UTC)

• Comment I don't particularly see much encyclopaedic value of using emojis to navigate wikipedia. The best scenario in my mind would be to redirect either to an article on that specific emoji or to a general article on emojis. We should not be using emojis to redirect to articles that don't relate to emojis. Polyamorph (talk) 20:39, 16 October 2023 (UTC)
• What are people referring to numbered choices that are not on the list, such as "Option 8"? –LaundryPizza03 (dc̄) 13:31, 17 October 2023 (UTC)

  The higher numbered options were introduced during #Survey (Emoji redirects) and are explained there. Certes (talk) 14:17, 17 October 2023 (UTC)

  @LaundryPizza03 the RFC question originally had 6 options. Kusma and I preferred options that were not on that list, and so detailed them as options 7 and 8 respectively. The RFC question was then rewritten with 4 options replacing the original 6, but options 7 and 8 are still not covered. For easier reference I've copied those options below:

  • Option 7: do not try to prescribe this centrally, but let RFD do its thing on individual redirects based on individual consensus. Do not mass-create, do not mass-delete.'
  • Option 8: Emojis with articles should target those articles, other emoji with meanings that clearly correspond to one article should target that article. Emojis with meanings that correspond to multiple articles should target a list, disambiguation page, set index or other place where readers can follow links to the article(s) relevant to their search. Other emojis should redirect to relevant lists of symbols. Emoji should be redlinks only when we want to encourage the creation of an article about that emoji and/or its meaning.

  Thryduulf (talk) 14:26, 17 October 2023 (UTC)

Comment I think this has completely spiraled as a result of the numbers changing and I'm not sure what information we can glean from the current state of the RfC. microbiologyMarcus ^{(petri dish)} 13:45, 18 October 2023 (UTC)

Support closing the RfC and workshopping a second one here. Edward-Woodrow • talk 19:37, 18 October 2023 (UTC)

Some1 I like the idea of a list of emojis, as a middle ground between targeting the literal meaning and targeting the block. That would also give us room to note different meanings (at least those that reliable sources discuss). Here's my vague idea for what an entry would look like:

😨 Fearful Face (U+1F628) used to x or sometimes y.

Edward-Woodrow • talk 21:30, 17 October 2023 (UTC)

@Tavix, Gonnym, Thryduulf, Enix150, and Utopes: what do you think of that idea? Edward-Woodrow • talk 21:31, 17 October 2023 (UTC)

There are 3,664 emojis as of the latest update so if such a list would be created, it would probably be needed to split into a few pages, but in general I'm not opposed to anything that can make the target more clear. Gonnym (talk) 08:37, 18 October 2023 (UTC)

I agree with Gonnym. It should have a link to the relevant Wikipedia article, so perhaps something like:

😨 Fearful Face (U+1F628) see Fear.

The link should be to the article(s)/dab/etc that most closely matches the definition, unless we have reliable sourcing that it is used for some other/additional meaning (otherwise it's WP:OR). Thryduulf (talk) 09:57, 18 October 2023 (UTC)

Here is an initial attempt Draft:List of emojis (faces). Gonnym (talk) 10:59, 18 October 2023 (UTC)

• Comment This is listed on CENT, so I have come here from there. What the heck is going on with the options? Who hatted a bunch of them and completely re-numbered the rest halfway through an RfC? It is now basically impossible to tell what anyone was talking about in the above comments. Can this be undone? jp×g 05:20, 18 October 2023 (UTC)

  @JPxG the who was Utopes. As for whether this can be undone, I think that would just move the problem to the comments left between the renumbering and the unrenumbering. Especially now we have a third option not listed in the options it's probably better to cancel the RFC bit of this but treat it as pre-discussion for a better prepared RFC. Thryduulf (talk) 10:00, 18 October 2023 (UTC)

  I agree this RfC is damaged beyond repair. Jc3s5h (talk) 20:14, 20 October 2023 (UTC)

  Well, it's de-RfC'd now, so maybe we can discuss the issues raised, instead of my, isn't this RfC bad?' Edward-Woodrow • talk 20:19, 20 October 2023 (UTC)

• Per the above comments, I've removed the RfC tag. The discussion can stand or continue as a pre-RfC discussion, where participants workshop the best possible options for further discussion. The mid-RfC changes to the options have made it untenable. Firefangledfeathers (talk / contribs) 20:03, 20 October 2023 (UTC)

Notice of proposal to blacklist an image

I started a proposal on Talk:2023_Israel–Hamas_war#Question_2:_Should_the_video_be_blacklisted_from_the_English_Wikipedia? about blacklisting a particular piece of media. You might want to read that discussion for context before commenting. Awesome Aasim 15:06, 16 October 2023 (UTC)

PS you can add an RfC tag before this proposal. Awesome Aasim 15:09, 16 October 2023 (UTC)

The blacklisting has already been discussed at the correct place (MediaWiki talk:Bad image list) and rejected. —Kusma (talk) 15:19, 16 October 2023 (UTC)

Uhhh.... I am pretty sure the edit protected template must be used after obtaining consensus. Since there was no consensus established and it turned out to be a contentious matter I withdrew my request. Awesome Aasim 16:47, 16 October 2023 (UTC)

Consensus determines whether or not an image is used in an article. The Bad image list is mostly an anti-vandalism tool, where the inclusion is on basis of need. You do not need to show consensus, but necessity. —Kusma (talk) 18:49, 16 October 2023 (UTC)

Discussion at Wikipedia talk:WikiProject Articles for creation § Where should we place the scam warning?

 You are invited to join the discussion at Wikipedia talk:WikiProject Articles for creation § Where should we place the scam warning?. Ca ^{talk to me!} 14:04, 18 October 2023 (UTC)

Hebrew in Latin

Hello, I’ve noticed that many Hebrew words are transcribed wrongly. For example, on of the cities in Israel is transcribed <Holon> instead of <H̱olon>, so are many other places in Israel. I suggest changing all names according to this very list: https://hebrew-academy.org.il/2022/06/27/%d7%a8%d7%a9%d7%99%d7%9e%d7%aa-%d7%94%d7%99%d7%99%d7%a9%d7%95%d7%91%d7%99%d7%9d-%d7%91%d7%99%d7%a9%d7%a8%d7%90%d7%9c/

This isn’t only for English, but for any language that uses the Latin alphabet – French, German and even Turkish. מושא עקיף (talk) 03:19, 21 October 2023 (UTC)