Wikipedia:Village pump (proposals)

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

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

Discussions are automatically archived after remaining inactive for nine days.


RfC: Enabling collapsible templates on the mobile site[edit]

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)Reply[reply]

Background (enabling collapsible templates on the mobile site)[edit]

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)Reply[reply]

Survey (enabling collapsible templates on the mobile site)[edit]

  • Support as proposer. — Alexis Jazz (talk or ping me) 09:44, 3 September 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    Mostly indifferent on Opt-In along with user:Folly Mox below. — xaosflux Talk 15:22, 3 September 2023 (UTC)Reply[reply]
    @Xaosflux, @Izno in supporting below notes that it's only about 10 lines of code. Is your argument that even this is going to create an unacceptable performance impact? (Is there any way to measure that?) Or is there another reason besides performance that having gadgets addressing niche use cases is bad? {{u|Sdkb}} talk 05:12, 28 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • Support as opt-in. Edward-Woodrow :) [talk] 20:31, 3 September 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    Stil unsure. InvadingInvader (userpage, talk) 18:25, 12 September 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    • 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)Reply[reply]
      Great. That works for me.  — SMcCandlish ☏ ¢ 😼  18:44, 6 September 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • Strong support as well, this seems like a really useful feature for us mobile users. I think it's best to be done as a global default.PHShanghai | they/them (talk) 16:12, 23 October 2023 (UTC)Reply[reply]

Discussion (enabling collapsible templates on the mobile site)[edit]

@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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@Matma Rex, what specifically needs updating about MOS:COLLAPSE? IznoPublic (talk) 15:48, 6 September 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Oh, "will need". Missed the auxillary verb. Izno (talk) 00:36, 7 September 2023 (UTC)Reply[reply]
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)Reply[reply]
  • 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)Reply[reply]
    • 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)Reply[reply]

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

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)Reply[reply]

Survey (Find sources: NYT vs AP)[edit]

  • 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)Reply[reply]
    • 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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    Not at all opposed to just adding more sources, for clarity. Folly Mox (talk) 08:22, 9 September 2023 (UTC)Reply[reply]
    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.[1]. 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)Reply[reply]
    I also find Conde Nast publications pretty annoying because Nast, Conde always seems to be the byline.[2] Valereee (talk) 16:28, 15 September 2023 (UTC)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    • 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)Reply[reply]
      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)Reply[reply]
  • 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)Reply[reply]
    this is a distraction. no discussion supported "addition of nyt" https://en.wikipedia.org/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)Reply[reply]
    @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)Reply[reply]
    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)Reply[reply]
    I'll answer at your talk, as this probably is becoming tangential. Valereee (talk) 12:49, 9 September 2023 (UTC)Reply[reply]
    @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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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}Reply[reply]
    • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    That's a much more acceptable (to me) argument. RoySmith (talk) 14:52, 15 September 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    +1! Donald Albury 14:46, 12 September 2023 (UTC)Reply[reply]
    then why nyt? why not the union or wsj? RZuo (talk) 14:31, 14 September 2023 (UTC)Reply[reply]
    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)Reply[reply]
    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/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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    @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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • Support defaulting to a global source focused on factual reporting improves Wikipedia's neutrality. – Teratix ₵ 00:44, 21 September 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • Support: AP is easier to access, more international and less biased. a455bcd9 (Antoine) (talk) 07:47, 26 September 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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. –Davey2010Talk 11:00, 28 September 2023 (UTC)Reply[reply]
    Nothing under discussion requires use of a paywalled site. SPECIFICO talk 19:28, 7 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
  • Oppose False dichotomy, just add both. Curbon7 (talk) 21:40, 12 October 2023 (UTC)Reply[reply]

Discussion (Find sources: NYT vs AP)[edit]

  • 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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    Absolutely right. This is the most important comment that anyone has made here. MichaelMaggs (talk) 14:06, 10 September 2023 (UTC)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
https://www.nytimes.com/2023/10/23/pageoneplus/editors-note-gaza-hospital-coverage.html
so much for "NYT's factual reporting is neutral", "by far the best and most comprehensive US newspaper source", "enviable world-level reputation for fair and accurate reporting"... lmao.--RZuo (talk) 20:27, 23 October 2023 (UTC)Reply[reply]
  1. ^ "GERALDINE'S NEW RECORD; MADE YESTERDAY AT THE NEW RACE TRACK. A MOST SUCCESSFUL OPENING DAY AT THE FINEST RACE TRACK IN THE WORLD". The New York Times. 1889-08-21. ISSN 0362-4331. Retrieved 2023-09-14.
  2. ^ Nast, Condé (2012-02-23). "The Beauty and Tragedy of Hungary's Supple Stringbike". WIRED. Retrieved 2023-05-27.

Enable RC patrolling (aka patrolling for edits)[edit]

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? Ladsgroupoverleg 17:39, 10 October 2023 (UTC)Reply[reply]

  • Support as proposer. Ladsgroupoverleg 17:39, 10 October 2023 (UTC)Reply[reply]
    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)Reply[reply]
    @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)Reply[reply]
    @RudolfRed They are the same code and software but many wikis allow the same for edits (not just new page creations). Ladsgroupoverleg 18:39, 10 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    @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. Ladsgroupoverleg 18:42, 10 October 2023 (UTC)Reply[reply]
    @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)Reply[reply]
    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. Ladsgroupoverleg 18:48, 10 October 2023 (UTC)Reply[reply]
    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)Reply[reply]
    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. Ladsgroupoverleg 18:50, 10 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    The queue gets automatically purged after 30 days, as I said above. Ladsgroupoverleg 18:47, 10 October 2023 (UTC)Reply[reply]
    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. Ladsgroupoverleg 18:55, 10 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
    The support for marking edits patrolled can easily be added to popups. Ladsgroupoverleg 11:05, 11 October 2023 (UTC)Reply[reply]
    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)Reply[reply]
  • (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)Reply[reply]
  • 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)Reply[reply]
    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. Ladsgroupoverleg 11:22, 11 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    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). Ladsgroupoverleg 17:55, 11 October 2023 (UTC)Reply[reply]
.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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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. Ladsgroupoverleg 14:08, 17 October 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Edits 3 and 5 weren't checked in the existing system, either. WhatamIdoing (talk) 01:23, 17 October 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
  • Oppose per EspressoAddict and ActivelyDisinterested. Quis custodiet ipsos custodes? Edward-Woodrow • talk 20:41, 11 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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, ~ LindsayHello 14:58, 18 October 2023 (UTC)Reply[reply]
    @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)Reply[reply]
  • Support as opt-in. It should be a user right you can apply for, or maybe an opt-in that any rollbacker/maybe pending changes reviewer can choose to enable. Many patrollers won't go through the effort. One of (admittedly, a bunch of) the reasons I don't do much recent change patrolling is that most edits have already been checked by the time I see them and there are plenty more that I'd either mark good or leave purposefully for someone else, but there's no difference between the last two categories and sometimes nobody gets to the ones being left purposefully. Maybe a trial run would be better, to see if it seems to be beneficial or not, but given it's opt-in and many editors seem to have issues with it/won't have the right to use it, edits should get double-checked anyways even if they've been approved. However, given the concerns raised, I think the status of an edit being patrolled or not shouldn't be easily visible on Special:RecentChanges/etc. unless you specifically opt into it being shown (assuming any user would be able to see the status, just not change it), so that newer users get the current interface and aren't fed into the pool of people who rely on patrol status, as that seems like the most likely way for it to backfire (everyone starts opted-in and then we over-rely on patrols being accurate). Skarmory (talk • contribs) 21:14, 23 October 2023 (UTC)Reply[reply]

Discussion (Enable RC patrolling (aka patrolling for edits))[edit]

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)Reply[reply]

They are mentioned in the proposal Ladsgroupoverleg 10:22, 12 October 2023 (UTC)Reply[reply]


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? Ladsgroupoverleg 20:05, 15 October 2023 (UTC)Reply[reply]
@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)Reply[reply]
@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. Ladsgroupoverleg 12:11, 16 October 2023 (UTC)Reply[reply]

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)Reply[reply]

@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. Ladsgroupoverleg 14:05, 18 October 2023 (UTC)Reply[reply]

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

The most relevant one would probably be WP:CVU. Alpha3031 (t • c) 22:32, 18 October 2023 (UTC)Reply[reply]
done Ladsgroupoverleg 14:44, 20 October 2023 (UTC)Reply[reply]

RfC about the criteria for existence of emoji redirects[edit]

Shortcut

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)Reply[reply]

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

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)Reply[reply]

Survey (Emoji redirects)[edit]

  • 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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
    Note to closer When I wrote this option 2 was entirely different, it should not be taken as support for the (as of this timestamp) current option 2. CMD (talk) 01:35, 26 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    We've tried to this, with not-so-pretty results. Edward-Woodrow • talk 12:13, 16 October 2023 (UTC)Reply[reply]
    I would strongly push back against that characterization. -- Tavix (talk) 13:26, 16 October 2023 (UTC)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    I disagree. Individual debates are often long and ineffective. Martin Tauchman (talk) 14:13, 16 October 2023 (UTC)Reply[reply]
    ... but aren't they more likely to produce the correct result for individual emoji? —Kusma (talk) 15:57, 16 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
  • Option 6 deals soundly with vacuous, cretinous inanity. Serial 12:24, 16 October 2023 (UTC)Reply[reply]
  • (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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • Option 8 is a good summary of the status quo and consensus at recent RfDs. -- Tavix (talk) 13:26, 16 October 2023 (UTC)Reply[reply]
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)Reply[reply]
I support that too, given that it clears up the ambiguities effectively. Edward-Woodrow • talk 19:57, 20 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    All valid. Gonnym (talk) 18:18, 16 October 2023 (UTC)Reply[reply]
    I find this perspective to be absolutist to a degree that is in total dissonance with the general approach of our policies and guidelines, and further a startling lack of care with respect to the intricacies and differences between single-character symbols and their possible referents. signed, Rosguill talk 19:58, 21 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • Option 8 per Thryduulf. Enix150 (talk) 20:20, 16 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
@Thryduulf:. Apologies for the delay, I've been extremely busy this last week and wasn't able to properly return until addressing the RfC situation that has since formed.
For what it's worth, I said that the new option 2 was more close to the Option 8 as suggested, but not exactly due to the redlink clause. It was more close due to the narrowed range of "only emoji redirects without articles". As for the rest of Option 8's contents, I didn't (and still don't particularly) agree that the "multiple article matches" is important as stated to include within the text of the Option (to otherwise differentiate it from Option 2), because the intent of Options 2&3 was to be the catch-all options for any other article possibilities beyond databases or deletion respectively. Because of this, set index articles and disambiguation pages would fall under this if appropriate, because from my point of view the 4 options presented were wholly encompassing of all possibilities. There were essentially 2 proposed criteria, with 2 fully-encompassing binary solutions to deal with them. While the first binary of "keep (at database) or delete emoji redirects where no other target is appropriate" is present in the form of 1&2 versus 3&4, the second binary would be the one that this interpretation is relevant to: Options 1 and 4 suggested to treat ALL emojis the same regardless, whereas Options 2 and 3 proposed that emojis should be treated differently on a case-by-case basis depending on how the image is depicted. From my point of view, Option 8 has the same intention as that, but keeps going with extra examples that to me seem as if it would still be supported by Option 2's solution. The only difference, however, is the mention of red-linked emojis, which I see to be a different subject matter entirely which falls outside the scope of the 2 x 2 binary options. Set index articles are still articles, so I don't see how that is different from the provided example of 🔥 to the fire article. 🥙 still unambiguously depict a Stuffed flatbread, which happens to be a set index article. To me it seems like yet another valid example.
I'll concede that this intention behind the Option could have been confusing, however, as only the fire was shown to explain what it might look like. Furthermore, I guess it can be said that "maybe this type of RfC question shouldn't have been designated with options to begin with". In removing options entirely, this could allow for more involved possible solutions. To me though, this broad path did not feel correct or needed, as there are a seemingly small number (2) of crossroads that needed solutions (such as whether or not a gray area exists). Open forums can work well in RfCs, but here it would effectively be picking and choosing different emoji to assign with different solutions... that all still match the same overarching precedent that "there IS no precedent and each should be dealt with on a case by case basis, depending on whether a regular article, set index article, or a disambiguation page seems to be most appropriate from the depiction". These all fall under the same umbrella, and can be summed up without needing to declare which styles of articles that can and can't be targeted, effectively declaring criteria to set index, criteria to disambiguate, criteria to red-link and etc.
Because of this, I feel like I once again lean back towards the thought that the 4 options were sufficient enough. The second binary option posed by 1&4 vs 2&3, in my eyes, was essentially asking to choose between "There is no gray area (treat all the same, i.e. 1&4)" or "There is a gray area (case by case, i.e. 2&3)". At the risk of duplicating my words, there is no gray area between the two binary conclusions of "there is gray area" or "there isn't". If there's ANY gray area, the latter option (represented by 2&3) would seem to me to be sufficient to capture that, which is what the proposed Option 8 does. The only difference, because of this, would appear to be the redlink clause, which wasn't a part of the two binaries (and also feels to be a different can of worms because emoji's without articles will never be red, as they will appear the same regardless of whether they are an article or not. The cases of emoji with associated articles is easily countable (exactly 8 as of now) so the referred-to cases of emoji that could receive articles but don't have them already feels like it should be a separate topic for "which redirects should be deleted to encourage article creation")
I do wish in hindsight that I could have painted a better picture with clearer intentions behind the option description, because I did feel when putting this together that the 4 options listed sufficiently covered the two main goals of the RfC. I think that focusing on just the new 4 to begin with would have made things a lot easier to wrap heads around, because shifting the goalpost inward was still a shifting of the goalpost. But even then, it seems to me that from the beginning, Option 8 was still covered within the worlds of combining old Option 2 and old Option 3 (making Option 8 a warranted combo-solution at the time). Post-revision, though, it looked to me as if Option 2 was just it, minus the redlink clause. As for the other alternative suggestion, Option 7 was just in opposition towards using an RfC to come up with a solution, which seems to be a paradox and was only given a number for formality. (It's certainly a valid position to be opposed to using the RfC to prescribe a universal solution, but voting for an Option called "7" through the means of the RfC would still be prescribing a universal solution of "no universal solution"... The text is more closely akin to a "none of the above" pathway. I guess it could be given a number for ease of reference, but it certainly falls squarely outside of the proposed grid of 6 solutions -> 4 revised solutions.)
It seems that this RfC may be restarted, which is fine and definitely understandable. I was talking with the User King of Hearts in the discussion section, which was the very first message in the RfC which is where the 4-option alternate setup was first proposed. The conversation between us developed throughout the evening, and I implemented the suggestion on the same day the RfC started. Because the context behind the change was completely available, I believed that restructuring the votes based on the immediate RfC feedback would be uncontroversial as the context behind the change was all quickly accessible, and I figured that collapsing the original options and partitioning the original votes would make things clear moving forward. I did not expect the older alternatives solutions to carry over past the partition line, but this was on me for not clearly structuring the vote options to begin with. I do think a vote will eventually happen on this topic in some capacity, but using this space to figure out what to cover in the future emoji-redirect RfC seems like what will happen at this juncture, whether it is more of an open forum, a series of yes/no propositions, or what have you. Utopes (talk / cont) 07:54, 28 October 2023 (UTC)Reply[reply]
@Utopes: I've only skimread your comment (tl;dr applies) so apologies if I've missed anything, but the "grid" you keep talking about needing to fit things into seems completely arbitrary? That multiple keep are supporting options not in your first or revised set suggest that the considerations left out are important. As for changing options midway through an RFC, that's rarely not going to result in confusion. Thryduulf (talk) 09:58, 28 October 2023 (UTC)Reply[reply]
No worries, I'm going to be heading to bed soon but it was something I had on my mind after seeing the direction things went in regards to the RfC post-option refinement. This could be my misinterpretation as well, but I feel cumulatively we may be saying the same thing in regards to Option 2 vs 8, possibly. Option 2 as above is written "Retarget to pages where the emoji's depiction is deemed unambiguous". The emoji 🔴, to this effect, unambiguously refers to a red circle. Therefore, my view of Option 2 is that it would suggest this emoji be redirected to Red Circle. Such target happens to be a disambiguation page, but it is a page nonetheless, hence why I viewed Option 8 to be redundant on this factor (and in part was why I was concerned things were getting out of hand with the 2 vs 8 😅). If this interpretation of Option 8 is correct and the same as how you described it here, I feel now could be a worthwhile time to workshop and prepare for a potential RfC redo, as the option switch certainly did not make it easier by any means, although I underestimated its negative effect. Utopes (talk / cont) 10:12, 28 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    It's "person playing handball". The emoji redirects to Handball, so the question is answered correctly. -- Tavix (talk) 20:00, 16 October 2023 (UTC)Reply[reply]
    Its Unicode name is simply "HANDBALL", so the question's answered even more correctly. Certes (talk) 21:29, 16 October 2023 (UTC)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • Support Option 8 seems to be reasonable --Lenticel (talk) 00:14, 17 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • Strong oppose Option 4, neutral on others. Frostly (talk) 22:00, 17 October 2023 (UTC)Reply[reply]
    @Frostly: May I ask why? Edward-Woodrow • talk 22:37, 17 October 2023 (UTC)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
  • #️⃣1️⃣ - info about the emoji, not the concept it represents. 👍 Levivich (talk) 14:04, 18 October 2023 (UTC)Reply[reply]
  • Restart RFC per Stifle.The 🏎 Corvette 🏍 ZR1(The Garage) 17:07, 18 October 2023 (UTC)Reply[reply]
  • Restart per Stifle as they have a good point as well as what Sandizer mentioned Isla 🏳️‍⚧ 19:55, 19 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
  • Option 1 - although I agree with the above editors that this RfC needs to be restarted, as the options have changed since many editors !voted. I prefer option 1 as no emoji is unambiguous; for example, 🔥 can mean fire, but it can also mean spicy, attractive, popular or trending, urgency, excellent performance, and far more. Effectively, emoji's are a pictograph language where context provides meaning; it is rare that there is a single appropriate target for them. BilledMammal (talk) 03:29, 21 October 2023 (UTC)Reply[reply]
    What do you think of emoji redirects to country flag articles like 🇺🇸? They're surely unambiguous, right? ObserveOwl (chit-chat • my doings) 18:59, 25 October 2023 (UTC)Reply[reply]
    Should 🇺🇸 target U.S. or U.S. Flag? I'd expect the former, but the norm seems to be the latter. Edward-Woodrow • talk 19:43, 25 October 2023 (UTC)Reply[reply]
  • Option 3 If we can give a straightforward answer, let's do it. Otherwise, we're just playing charades. --BDD (talk) 18:31, 25 October 2023 (UTC)Reply[reply]
  • Option 8 per Thryduulf.-- Patar knight - chat/contributions 15:43, 27 October 2023 (UTC)Reply[reply]
  • Thryduulf's option 8 makes the most sense here; those options are the most likely to send our readers to the information they're looking for when searching an emoji. I'd also be open to keeping some wiktionary redirects, such as 🥺 (which has been discussed at RfD, leading to that result). Elli (talk | contribs) 17:24, 27 October 2023 (UTC)Reply[reply]

Discussion (Emoji redirects)[edit]

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)Reply[reply]

@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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
fwiw, I don't think I received this ping, not sure anyone else did. signed, Rosguill talk 13:48, 16 October 2023 (UTC)Reply[reply]
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) Reply[reply]
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)Reply[reply]
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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    The higher numbered options were introduced during #Survey (Emoji redirects) and are explained there. Certes (talk) 14:17, 17 October 2023 (UTC)Reply[reply]
    @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)Reply[reply]
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)Reply[reply]
Support closing the RfC and workshopping a second one here. Edward-Woodrow • talk 19:37, 18 October 2023 (UTC)Reply[reply]

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)Reply[reply]

@Tavix, Gonnym, Thryduulf, Enix150, and Utopes: what do you think of that idea? Edward-Woodrow • talk 21:31, 17 October 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Here is an initial attempt Draft:List of emojis (faces). Gonnym (talk) 10:59, 18 October 2023 (UTC)Reply[reply]
@Gonnym, that looks good to me, though it might be worth adding images as well. I'm seeing boxes for a few of them. — Qwerfjkltalk 19:43, 21 October 2023 (UTC)Reply[reply]
I like this, but is there any reason we can't do this out of the previous emoji block articles (just adjust their format)? Skarmory (talk • contribs) 21:17, 23 October 2023 (UTC)Reply[reply]
At this point I think it's probably best to wait until the new version is completed and then propose a merge or redirect. Thryduulf (talk) 21:52, 23 October 2023 (UTC)Reply[reply]
  • 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)Reply[reply]
    @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)Reply[reply]
    I agree this RfC is damaged beyond repair. Jc3s5h (talk) 20:14, 20 October 2023 (UTC)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
Would blanket redirect of all emojis to a table with anchors to the specific emoji and then the descriptions, with interwiki links not be the best use case then? I've begun workshopping a draft in the draftspace: Draft:List of Emojis microbiologyMarcus (petri dish) 15:16, 26 October 2023 (UTC)Reply[reply]
I would probably support Option 2-prime Redirect to list of ... meanings. Compare A, X, 7, !, Æ. Some emoji only have one notable, natural meaning; others might have a "literal" meaning and multiple notable figurative meanings; in the latter case, yes there should be a disambiguation page. And if there's a group of closely-related emoji with similar meanings and history, it might be appropriate for each to be a redirect to an anchor-within-a-table within an article about the group. DavidLeeLambert (talk) 21:07, 26 October 2023 (UTC)Reply[reply]
I really like the way Wiktionary (you know, the project where glyphs-as-glyphs are in-scope) handles these. Compare wikt:🥙, wikt:🤾, wikt:🔴. —Cryptic 22:27, 26 October 2023 (UTC)Reply[reply]
Two of those currently don't have entries, but, yes, I agree I like wiktionary's approach (they're freer because unlike us, they are a dictionary). An option is to retarget them all to wiktionary (which been done with a few already, I think). Edward-Woodrow • talk 12:01, 27 October 2023 (UTC)Reply[reply]
Part of my point is I like the way Wiktionary handles them even when it doesn't have entries - for one-character-long entries in their main namespace, they transclude wikt:Template:character info on wikt:Mediawiki:Noarticletext. —Cryptic 04:14, 28 October 2023 (UTC)Reply[reply]

Hebrew in Latin[edit]

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)Reply[reply]

The general rule on English Wikipedia is to use the name most commonly used in reliable English-language sources, even if that differs from the official transliteration. In the case of Holon/H̱olon, it seems as though the transliteration without the diacritic is common and the usage is in line with our usual policy Caeciliusinhorto (talk) 13:18, 22 October 2023 (UTC)Reply[reply]

Reopen Wikipedia:Books page since the concept of a "Wikipedia Book" still exist[edit]

Whether a Wikipedia Book was created using the Book Tool or not, this page needs to be reopened immediately even if the namespace was removed or if the tool is not working. The more general concept of a Wikipedia Book still exists. ModernDaySlavery (talk) 20:26, 21 October 2023 (UTC)Reply[reply]

The page tell us about a tool and namespace that are no longer functioning or available. Book tool no longer functions and namespace deleted. Moxy- 22:53, 23 October 2023 (UTC)Reply[reply]
Book tool still does function, just the PDF functionality doesn't function. Also I removed references to the namespace. Also if you want I can even add the book tool is no longer supported (even only a feature of it isnt supported) but the concept of a book made of wikipedia article is very important and therefore the page should still continue. ModernDaySlavery (talk) 23:00, 23 October 2023 (UTC)Reply[reply]
As the Book Creator no longer generates copies of Wikipedia books, its primary working feature directs users to order printed Wikipedia books from PediaPress, a third-party company. Editors in discussion valued the user experience of Wikipedia readers over the business prospects of PediaPress. Moxy- 23:37, 23 October 2023 (UTC)Reply[reply]
It does generate Wikipedia books just not in PDF form. See User:Lasertrimman/Books/Hart / OSI. In addition there is also MediaWiki2LaTeX that allows you to download Wikipedia Books. Also like I said the concept of a Wikipedia Book remains, a Wikipedia Book doesn't even need to be created by the Wikipedia Book tool, it just refers to a collection of Wikipedia articles. Creating a new Article for the concept doesn't make sense. ModernDaySlavery (talk) 23:57, 23 October 2023 (UTC)Reply[reply]

Stepanakert/Khankendi[edit]

An unrecognized state in Nagorno-Karabakh no longer exists, the city of Khankendi is completely under the control of Azerbaijan, they even hung a state flag there. But the Armenian moderator cancel edits about renaming the city, leaving the unrecognized and irrelevant name “Stepanakert”. Please make the title "Khankendi" in the article 109.87.192.15 (talk) 09:17, 22 October 2023 (UTC)Reply[reply]

Per Wikipedia:Official names, we do not change the name of an article just to recognize an official name. The naming of the article should be in accordance with the provisions of Wikipedia:Article titles#Deciding on an article title. Discussion about renaming the article should continue on the article's talk page. Donald Albury 12:03, 22 October 2023 (UTC)Reply[reply]

To create an Editor Communication Feedback noticeboard[edit]

See also: Wikipedia:Village pump (proposals)/Archive 116 § Do Away with RFC/U

Communication is crucial in society in general and Wikipedia in particular as an essential part of the editing and consensus process. As such I was thinking it would be a good idea to have an Editor Communication Feedback noticeboard. Therefore, I propose creating it to promote good communication between editors. Currently there is no place to discuss communication between editors, except as a disciplinary issue. I am aware there used to be a Requests for comment/User conduct project but my proposal is diametrically different and addresses the main points of contention of that former venue.

From the discussion to discontinue said RfC/Uc,

The community is of the opinion that it no longer serves a useful purpose, that it has a tendency to prolong disputes without helping their resolution, suffers from a lack of participation, attracts biased input, and that it pales in comparison to other processes. There is no consensus for any specific replacement, nor that finding one is required before deprecating RFC/U. Other components of the dispute resolution process should be used, such as ANI and ArbCom. There are some legitimate concerns regarding those alternatives, specifically that ANI isn't well equipped to handle long term issues while at the same time the bar for ArbCom is quite high, meaning a lack of proper venue for handling certain kind of disputes, but they don't justify maintaining a system recognized as inefficient (in those cases too).

The noticeboard would be for constructive and positive feedback, neither as an instrument to impose sanctions, nor to further disputes, nor to condemn.

  1. The purpose of the noticeboard would be to promote (not enforce) good communication between editors.
  2. The objective of the discussions would be to provide neutral feedback to editors on how to improve communication, what could have been done better in the thread being analyzed, what could have been avoided, what strategies could be used in the future.
  3. The noticeboard should not be used for negative actions against editors such as evidence in disciplinary proceedings.
  4. Some rules,
    1. Provide respectful and constructive feedback, avoiding attacks or condemnation.
    2. Limit participation in the analysis discussions to extended confirmed editors.
    3. Barring from the discussion analysis participation of editors involved in the dispute wouldn't participate in the discussion. Any doubts about the motives or objectives of their communications would have to be figured out by those participating in the discussion because after all if they can't figure it out, that signals there was a communication roadblock.
    4. Barring from the discussion analysis editors who have had disputes or edit warring with the editors whose thread is being analyzed would be restricted from participating in the discussion.
    5. Restricting editors who may act as proxies of editors who have had disputes with the editors whose thread is being analyzed advising them not to participate in the discussion.
    6. Participating editors should avoid taking any given disputing editor side.

Thinker78 (talk) 19:48, 22 October 2023 (UTC) Edited 22:03, 22 October 2023 (UTC)Reply[reply]

Pinging @Cenarium, Robert McClenon, and Jehochman:, main participants of the former RfC about the User Conduct forum. Thinker78 (talk) 19:51, 22 October 2023 (UTC)Reply[reply]
Rules 4.3, 4.4, and 4.5 do not parse.
If rule 4.5 is interpreted as forbidding proxying for another editor, it may do more harm than good, if it allows editor C to claim that editor B is proxying for editor A.
More generally, if rules 4.3, 4.4, and 4.5 all exclude editors, the result may be that there may be as much quarreling over whether editors are excluded as discussion of the original topic. Robert McClenon (talk) 20:50, 22 October 2023 (UTC)Reply[reply]
Rule 4.3 has littler room for misinterpretation or different interpretation. Rule 4.4 could be instead barring in the discussion editors who have had edit summary or talk page interactions with the editors in dispute, so as to reduce the risk of disputes in the interpretation. Rule 4.5 would advise proxy editors from intervening but that would be a honors system because difficult to establish who may want to proxy. Then as long as rules 1 and 6 are respected, there would be less risk of an issue even if they are secretly proxying for the interests of other editors.
Although of course, no system is perfect. Regards, Thinker78 (talk) 22:14, 22 October 2023 (UTC)Reply[reply]
It is true that there seems to be only one interpretation of what 4.3 is trying to say. It still doesn't parse. Robert McClenon (talk) 03:44, 23 October 2023 (UTC)Reply[reply]
A key challenge with the former requests for comments on user conduct process was that there was no incentive for the user in question to read any of it. I'm not clear how your proposal addresses this. With your proposed rule 3, the incentive is also reduced for participation by anyone if it means that either poor behaviour on the proposed noticeboard cannot be discussed in other venues, or if specific poor behaviour discussed on the proposed noticeboard cannot be discussed in other venues. isaacl (talk) 23:39, 22 October 2023 (UTC)Reply[reply]
  1. "there was no incentive for the user in question to read any of it". The WP:Dispute resolution noticeboard also has the same issue. In fact, it states, "You are not required to participate". The proposal is to promote good communication. Certainly not everyone would want to read the analysis but certainly many others may. It would be one more tool for those editors in the dispute resolution process and also those interested in improving or seek feedback in their communication.
  2. "poor behavior on the proposed noticeboard cannot be discussed in other venues". Rule 3 doesn't state this, it is about the threads themselves of the noticeboard not being used in disciplinary proceedings. The behavior of course can be discussed wherever.
Regards, Thinker78 (talk) 00:29, 23 October 2023 (UTC)Reply[reply]
Without addressing how to provide incentives for the user to engage, I do not feel you have addressed a main point of contention with the RfC/U process.
If someone lays out poor behaviour X, Y, and Z in a thread on the proposed noticeboard, then someone later raises these behaviours at the incidents' noticeboard, the subject can claim via rule 3 that since the behaviour was already discussed, no sanctions should be given. This is a disincentive for others to use the noticeboard, which will reduce its effectiveness. isaacl (talk) 04:03, 23 October 2023 (UTC)Reply[reply]
"Poor behaviour" would be addressed by newly minted rule 7: Include about the issue a brief, neutral statement or question. Therefore, poor behavior wouldn't be accepted as a neutral statement or question about the issue.
Should rule 3 be discarded? Regards, Thinker78 (talk) 04:38, 23 October 2023 (UTC)Reply[reply]
Discussing what could have been done better in the thread being analyzed, what could have been avoided will result in discussing undesirable behaviour. isaacl (talk) 18:34, 26 October 2023 (UTC)Reply[reply]
That's one of the objectives, with the aim to improve communication between editors. Regards, Thinker78 (talk) 22:18, 26 October 2023 (UTC)Reply[reply]
Exactly; thus your proposed rule 7 is a non-sequitur to the concern I raised. isaacl (talk) 22:49, 26 October 2023 (UTC)Reply[reply]
No because although the editors in the noticeboard would discuss communication issues that may include undesirable behavior, it doesn't mean that they should state it is undesirable behavior or that editors should refer to the case as undesirable behavior. Check also rules 2 and 4.1. Regards, Thinker78 (talk) 22:57, 26 October 2023 (UTC)Reply[reply]
Yes, I quoted rule 2. Discussing what could have been done better in the thread being analyzed, what could have been avoided is equivalent to discussing behaviour that is undesirable, as it should have been avoided and could be improved. A basic tenet of providing effective feedback is to identify the concern. isaacl (talk) 23:10, 26 October 2023 (UTC)Reply[reply]
Yes but it is not necessary to state that it is undesirable behavior. It should be stated in neutral or positive terms for constructive criticism what could have been done better or how it could be better. After all, behavior that is undesirable for some is desirable for others. Regards, Thinker78 (talk) 02:23, 27 October 2023 (UTC)Reply[reply]
Proposed rule 3 doesn't rely on whether or not something is called undesirable behaviour; it bars use of any of the discussion no matter how it's worded. That's why proposed rule 7 isn't relevant to my concern.
Regarding constructive criticism: saying a behaviour should be avoided is equivalent to saying (in the speaker's view) that it is undesirable. Clearly describing problematic behaviour can still be constructive, with the commenter providing clear reasoning, and ideally based on common agreed-upon principles. isaacl (talk) 04:01, 27 October 2023 (UTC)Reply[reply]
Should rule 3 be discarded? Regards, Thinker78 (talk) 04:34, 27 October 2023 (UTC)Reply[reply]
  • One of the problems with RFC/U was that it was "a process laden with bureaucratic nonsense" (as one commenter put it in the linked RfC). This too seems to have a lot of WP:BURO which will invite wikilawyering and need clerking/policing. I'm also confused what its purpose is meant to be: a friendly space for a chat? or somewhere to bring a specific ongoing "dispute" or "issue" as referred to later in the rules? Bon courage (talk) 05:19, 23 October 2023 (UTC)Reply[reply]
    I have noticed that oftentimes in talk pages there are storms of disputes where communication could be better. I think this noticeboard could help sort out such situations without resorting to ANI or the Committee and help provide feedback to editors seeking to improve their communication skills with fellow editors. Regards, Thinker78 (talk) 18:46, 23 October 2023 (UTC)Reply[reply]
    Also, the idea is to have a forum that is a mix or could mirror somewhat RFC, Third Opinion, and the dispute resolution noticeboard or other noticeboards, but for analysis of cases of communication between editors. Regards, Thinker78 (talk) 18:59, 23 October 2023 (UTC)Reply[reply]
    Sounds fanciful. Anyway to enforce your rules you'd need clerks to do things like making sure 'barred' editors were barred, and so on, and you'd need completely uninvolved editors willing to comment. God only know what sort of people would be attracted to that task! Perhaps you could point at two or three of these 'storms of disputes' where you think this proposal would help? Bon courage (talk) 19:08, 23 October 2023 (UTC)Reply[reply]
    I think any experienced editor who has participated in discussions knows by personal experience about what can happen in discussions and how they can become very stormy. Regards, Thinker78 (talk) 20:10, 23 October 2023 (UTC)Reply[reply]
    But I don't know what you mean by 'stormy' exactly. If editors are telling each other to fuck off, that's one thing; but do you include robust exchanges? Many editors mis-construe robust argumentation about propositions as being personal. What do you mean by stormy? Where is the line crossed? Examples please! Bon courage (talk) 06:33, 24 October 2023 (UTC)Reply[reply]
    Editors would be free to submit threads in which they were involved for review even if there was no dispute but the editor simply wants feedback about hisher communication. Regards, Thinker78 (talk) 21:14, 24 October 2023 (UTC)Reply[reply]
    Above you wrote "this noticeboard could help sort out such situations". What "situations"? Is this a problem that actually exists? Can you point to some (hell, even one) and sketch a "before and after" where this noticeboard does the sorting out you mention? Bon courage (talk) 01:50, 25 October 2023 (UTC)Reply[reply]
    "storms of disputes where communication could be better." Thinker78 (talk) 03:04, 25 October 2023 (UTC)Reply[reply]
    Okay, the question is being evaded. Can somebody close this waste of time? Bon courage (talk) 03:10, 25 October 2023 (UTC)Reply[reply]
    There is your example. Also, it illustrates the point of rule 4.4 "Barring from the discussion editors who have had disputes or edit warring with the editors whose thread is being analyzed". We had a dispute some time ago. Regards, Thinker78 (talk) 04:16, 25 October 2023 (UTC)Reply[reply]
I can't picture how this would work in practice. If parties are snarking at each other, and someone steps in to criticise their communication skills, is that really going to mollify them? I have a feeling it would just open up a new frontier in the dispute, probably moving the discussion even further away from content. Barnards.tar.gz (talk) 20:58, 23 October 2023 (UTC)Reply[reply]
That would ring true about any other noticeboard though. Besides, the Feedback noticeboard would analyze a discussion only if editor (s) involved in the discussion brings the case (although they would not participate in the discussion). Regards, Thinker78 (talk) 22:14, 23 October 2023 (UTC)Reply[reply]
  • I'm not sure what benefit there is to a forum where people who were not involved in a contentious discussion then discuss that discussion; a person with poor communication skills is not going to improve by being scolded on the internet. I think a better solution is to have some sort of peer mediator program, but even that isn't a replacement for touching grass or going to a therapist instead of getting heated and nasty over an edit dispute. voorts (talk/contributions) 00:33, 26 October 2023 (UTC)Reply[reply]
    The noticeboard wouldn't be for "scolding", but to provide impartial analysis using positive feedback. Or at least that's the idea. Although I recognize some people get nasty because of their particular life issues, in other situations editors may be nasty in a discussion but later snap out of it and sincerely want to check what went wrong. Also, there are other situations where editors might simply seek feedback even if there was no particular nastiness. Regards, Thinker78 (talk) 00:49, 26 October 2023 (UTC)Reply[reply]
  • I suspect we have too many user-behavior noticeboards. AN, ANI, and WP:XRV come to mind. It may make sense to move in the direction of consolidating them towards ANI, rather than creating new ones. –Novem Linguae (talk) 01:57, 26 October 2023 (UTC)Reply[reply]

Article renaming[edit]

CLOSED
This discussion is better served locally, at the Talk Page of the article, not here. Forum Shopping is frowned upon. Perhaps, consider an RfC at that page GenQuest "scribble" 03:33, 26 October 2023 (UTC)Reply[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hi, my problem is the article renaming of Dobrujan Tatar, we did make some discussions, but there is no result. Where I think it's better to rename it to "Dobrujan Tatar language". But everytime it's rejected, for the first time it was called "Dobrujan Tatar", we did make a discussion, there was the result "Dobrujan Tatar dialect", for the second discussion was actually not result to find (but there was an Idea, called "Dobrujan Tatar dialects"). And also I think the name "Dobrujan Tatar dialect" was wrong. Zolgoyo (talk) 22:15, 22 October 2023 (UTC)Reply[reply]

@Zolgoyo: Consensus is that that is not the right name for the article. Edward-Woodrow • talk 21:21, 23 October 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Signature wiki markup[edit]

OP is currently indef blocked. If someone else wants to re-propose this go ahead and unarchive. — xaosflux Talk 18:39, 25 October 2023 (UTC)Reply[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Increase the character limit for signatures if it is wiki markup. Wiki markup is far longer than regular text making the current limit rather stifling, especially if you are using many formattings/templates. G'year talk·mail 22:41, 22 October 2023 (UTC)Reply[reply]

Then don't use so many formattings, and do not use (unsubsted) templates, parser functions, images, and so on . See Wikipedia:Signatures#Length for why the current technical limitation is embraced by our signature guideline, so even though you've apparently found a way around it you're not allowed to make use of it. Anomie⚔ 11:42, 23 October 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Elon Musk[edit]

Again, let's not WP:FEED the (off-site) troll, shall we? Edward-Woodrow • talk 20:40, 25 October 2023 (UTC)Reply[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

It usually isn't a good idea to feed the trolls or fan the flames, but should editors draft a formal response to Musk's increasing attacks on Wikipedia? He is, after all, one of the most influential people in the world — ironically according to the "mainstream media" that he hates. Musk has always been critical of Wikipedia (and by extension, the WMF), but recently he has been mounting an all-out attack on the platform formally known as Twitter: [1] [2] [3] [4] [5] [6] [7] [8]. InfiniteNexus (talk) 17:01, 23 October 2023 (UTC)Reply[reply]

I say no. He's the ultimate troll. Jimbo has done a fine job of responding on his own. – Muboshgu (talk) 17:05, 23 October 2023 (UTC)Reply[reply]
Ignore. It’s all hot air. Loads of people gripe about Wikipedia. He can join the queue. Barnards.tar.gz (talk) 19:15, 23 October 2023 (UTC)Reply[reply]
Ignore. Musk is just scared. The Banner talk 00:34, 24 October 2023 (UTC)Reply[reply]
  • I would be somewhat more concerned about the potential of trolls coming here and trying to create exactly the kind of chaos one might predict from that high-profile tweet. Yes, I know we are already dealing with that all the time, but let's apply some extra caution. BD2412 T 00:53, 24 October 2023 (UTC)Reply[reply]
  • I agree with everybody else here that the best solution here is to ignore Musks immature gripings. Hemiauchenia (talk) 01:31, 24 October 2023 (UTC)Reply[reply]
There's around a thousand admins. We can edit the main page. That's a million dollars each. Who's with me?! ScottishFinnishRadish (talk) 01:33, 24 October 2023 (UTC)Reply[reply]
Unfortunately for you, the 12 interface admins, who can modify the MediaWiki files and change the name of the site everywhere, have a better chance of claiming the money. Plus, it's almost 100 million each - who could blame them? BilledMammal (talk) 01:37, 24 October 2023 (UTC)Reply[reply]
Brb, opening a request at WP:BN. ScottishFinnishRadish (talk) 01:39, 24 October 2023 (UTC)Reply[reply]
Keeping it that way a full year is absurd. Would he pro-rate the payment so that we could just do it for a day and get $2.74 million? jp×g 04:34, 24 October 2023 (UTC)Reply[reply]
  • DNFTT. AndyTheGrump (talk) 01:34, 24 October 2023 (UTC)Reply[reply]
  • No, per AndyTheGrump. -- Euryalus (talk) 01:47, 24 October 2023 (UTC)Reply[reply]
  • To be honest, Musk makes some legitimate points. I mean, not the one about rebranding, that was just silly. But this tweet about excessive fundraising makes much the same criticisms as WP:CANCER. This tweet about editorial hierachy and bias is another fair observation. This tweet about source bias might indicate a misunderstanding of our purpose (we're source-summarisers, not truth-finders), but let's be honest, the average reader probably does think of us as truth-finders, and if you think Wikipedians ought to be truth-finders then it's an arguable point. Rather than attack or ignore Musk's points, we should do what we always do: take feedback on board and keep working to improve the encyclopedia. – Teratix ₵ 02:19, 24 October 2023 (UTC)Reply[reply]
    He distorts, bullies, misrepresents, lies, personally attacks. He's doing it for a reason, but it's not to legitimately criticize Wikipedia for ours, or anyone's benefit, only his own. Furthermore, nothing he said is original, he has no new insights. Don't try to legitimize or normalize it. -- GreenC 05:27, 24 October 2023 (UTC)Reply[reply]
    We shouldn't ignore criticisms because we don't like who they come from or because other people have made them before. Please don't insinuate my response was intended to "legitimize or normalize" lies or attacks. – Teratix ₵ 06:49, 24 October 2023 (UTC)Reply[reply]
    Criticism needs to be rooted in facts. Say what you want about Guy and Andreas, at least there is some substance to their grievances. This is just fear mongering, attacking institutions and knowledge. It's classic populism, amplified by right wing media who are whipping up a frenzy because they are sad. —TheDJ (talk • contribs) 11:52, 24 October 2023 (UTC)Reply[reply]
    To be fair, we do some truth-finding by limiting input to sources which, in our subjective opinion, are reliable. That's a useful function and performed as objectively as possible, so I'd see it as a point in Wikipedia's favour rather than valid criticism. Wikipedia isn't perfect but, if recent changes at Twitter are any indication, Musk's involvement might not lead to improvement. Certes (talk) 10:18, 25 October 2023 (UTC)Reply[reply]
    Maybe I'm looking in the wrong place, but I don't see any criticisms in common between the excessive funding tweet and WP:CANCER, except the overarching claim that it doesn't cost as much to run Wikipedia as the money it raises. The only specific point made in the tweet is the false statement that Wikipedia can fit on a phone. And when Musk says Wikipedia is "inherently hierarchical", what is he talking about? Bryan Henderson (giraffedata) (talk) 18:56, 25 October 2023 (UTC)Reply[reply]
  • Surely, in a free country, some guy is entitled to log onto his own website and write a post on it that some other website is stupid, whether or not his post is itself stupid. Of course, I guess we could put together an essay saying his post was stupid. It was kind of stupid. Of course, it was also kind of true. Anyway, we are always willing to publish good writing in the Signpost. Perhaps that'd be better than letting other news outlets valiantly defend our honor by reassuring their readers that everyone on Wikipedia is 100% in favor of all WMF spending. jp×g 04:32, 24 October 2023 (UTC)Reply[reply]
  • Just ignore him. --Malcolmxl5 (talk) 15:02, 24 October 2023 (UTC)Reply[reply]
Never heard of him. Levivich (talk) 02:29, 25 October 2023 (UTC)Reply[reply]
  • Support accepting the $1 Billion offer. Sports stadiums sell (temporary) branding rights, and here we have a $1 Billion offer by Musk to change our name to "Dickipedia". Before you get on your "not for sale" or "haggling about the price" soapbox, just consider how we could spin the marketing here, have a little fun with it, and laugh all the way to the bank. We could stick a cartoon of Dick Tracy on the main page and explain how editors do detective work ("Dick" is a 19th/20thC slang for detective[9]) to find reliable sources to improve articles. After just one year, Musk says we can change the name back. And if in October 2024, Scrooge McDuck wants to buy the one-year naming rights for "Duckipedia", then we should take his money too. Hold Musk to his word—the former management and shareholders of Twitter are glad they did. Cheers! BBQboffin (talk) 05:08, 25 October 2023 (UTC)Reply[reply]
    I think you're on to something here. Let's just have an RFC on this and then split the money between the RFC voters. Levivich (talk) 05:47, 25 October 2023 (UTC)Reply[reply]
    Would we have to deprecate WP:DONTBEADICK? Certes (talk) 10:14, 25 October 2023 (UTC)Reply[reply]
    @Certes, WP:BEADICK is just waiting to be written. — Qwerfjkltalk 16:11, 25 October 2023 (UTC)Reply[reply]
    Stop your dicking around, will you? GenQuest "scribble" 17:40, 25 October 2023 (UTC)Reply[reply]
  • Oppose WMF already has more money than it needs (acquired from people who want to support Wikipedia (not WMF)) and spends too much of it elsewhere and not enough on Wikipedia. Also, as back of the envelope estimate, the main value of Wikipedia is the approx $50 Billion in unpaid volunteer time that has gone into it. You don't get renaming rights on that by giving $1 Billion to somebody else (WMF). North8000 (talk) 12:18, 25 October 2023 (UTC)Reply[reply]
Hear! Hear! GenQuest "scribble" 17:40, 25 October 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Automatically put RfCs that are 30+ days old to WP:CR[edit]

WP:RFCEND says that by default, Legobot will assign a 30-day period to an RfC and then "forget" about it. I have encountered some unclosed RfCs in the archives. Currently, to create a request, a user must manually submit it to CR. Because most discussions are closeable at the 30-day mark, it would make sense to list all of these "old discussions" so that people direct their attention to them. Can someone write a piece of code that would contain the following info:

  • Where the discussion is
  • How old it is (determined by timestamp of when the rfc started)
  • How many comments were submitted during the past 7 days to the discussion
  • Some boilerplate text (eg. This discussion has likely reached maturity. An uninvolved editor is asked to close it if its outcome is already clear). Szmenderowiecki (talk) 17:03, 26 October 2023 (UTC)Reply[reply]
See WP:WHENCLOSE. Not everything needs a formal close, and if everybody has moved on without one then that's usually a sign one wasn't needed. Also, some discussions are very much not mature at the 30 day mark. Together this means that this proposal would fill up WP:CR with discussions that don't need closing (yet) making it harder for prospective closers to find the ones that do. Thryduulf (talk) 19:56, 26 October 2023 (UTC)Reply[reply]

2023 Israel–Hamas war has an RFC[edit]

2023 Israel–Hamas war has an RFC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. BilledMammal (talk) 01:50, 27 October 2023 (UTC)Reply[reply]

Rule that will cover anachronistic informations in the articles[edit]

At the moment there is an RFC with a question whether ”Christopher Columbus was an Italian explorer” or ”Christopher Columbus was an Genoese explorer”. One of the editors noted that this has been discussed for 20 years. Given that there is a possibility that mention of modern nations in the context of historical figures is an anachronism, as far as I know from my editorial experience this is not acceptable in articles given that time context in which a person lived must be used. I think there should be a rule that will solve this question. This same rule should determine the guidelines in which it must be proven that some information is anachronism. While the second part of the rules would determine what is done in such cases. Considering that without this rule we have uneven articles, I think that this rule is inevitable and necessary. The same rule will apply to all cases of anachronism in articles. I think that debating some things for 20 years does not make sense, it is better to adopt a new rule that will make the work of editors easier.

I am asking interested editors are you in favor of adopting a new rule which will concern the problem of anachronism in the articles? If necessary, I will write a new rule myself and put it up for discussion.

Mikola22 (talk) 08:20, 27 October 2023 (UTC)Reply[reply]

I might be sleepy, but I don't understand what exactly is being proposed here. We shouldn't have anachronisms in articles? We have to provide a source when removing anachronisms? We should have anachronisms when they help the general reader understand a topic in a specific historical context that is not well understood by non-specialists? Folly Mox (talk) 11:08, 27 October 2023 (UTC)Reply[reply]
Wikipedians argue indefinitely about a lot of things, it's kind of our thing. I don't think we can come up with a blanket rule on how to deal with anachronisms. For example, the vast majority of articles on archaeological sites describe them as being located in a modern country, which is technically anachronistic, but it wouldn't be very helpful for readers to learn that Nibru was a city in Kengir. It needs to be decided with on a case by case basis, following the lead of reliable sources. – Joe (talk) 12:21, 27 October 2023 (UTC)Reply[reply]
@Folly Mox and Joe Roe: There is no rule on Wikipedia regarding information which are out of time context. Let's say a certain historian from Rome and the Roman Empire is presented as an Italian in the article. And now for 20 years there has been a debate whether he was Italian or Roman. I think that in such case it would be good to have a rule or guideline that we can refer to, so that the article contains information in accordance with the sources and time context. Furthermore, we now have a situation where the time context is respected in some articles and not in others. The situation is anarchic in this regard. If something else needs to be clarified, feel free to ask. @Joe Roe In any case, everything depends on the sources, if 5 RS says that a person from the first century is Roman and 5 RS says that he is Italian, we won't going to debate for 20 years about who he was? If something is an anachronism and this is determined by the opinion of editor majority, then we cannot keep this information in the article. For now, such informations are legitimate because there is no guideline that would regulate this situation. Mikola22 (talk) 12:58, 27 October 2023 (UTC)Reply[reply]
Even if there was agreement on whether any particular item is an anachronism, it would be extremely difficult to write guideline or policy that encompasses all topics in a way that captured the many possible nuances out there. Suggesting that an editor majority overrules reliable sources is even more unlikely to be a solid basis for policy. Nationality is a particularly tricky topic, MOS:NATIONALITY has some existing guidelines. CMD (talk) 13:57, 27 October 2023 (UTC)Reply[reply]
Regarding 'editor majority overrules', I meant in the sense that guideline or policy which concerns anachronism exist. If that guideline or policy defines anachronism as forbidden, it would be sufficient that some RFC establish that some information is anachronism, and such information would gain legitimacy for removing from the article. Mikola22 (talk) 18:13, 27 October 2023 (UTC)Reply[reply]
I think I understand the proposition now, but I'm not sure I would support it. For one thing, it shouldn't take an RFC to determine if something is anachronistic. A reliable source should suffice, although I accept there may be edge cases where published experts disagree. The other thing is that anachronism can be helpful to anchor understanding in a familiar context, as Joe Roe mentions, and as is also common in my topic area, early China, where toponyms are almost universally located with respect to present-day geography, names are written in modern Chinese characters, etc.
Whether a particular instance of anachronism is helpful enough or necessary enough to be present in an article, and whether it needs to be called out as anachronistic and where: these are questions that RfCs can answer, but usually only after normal editing and normal discussion, I feel. Folly Mox (talk) 20:19, 27 October 2023 (UTC)Reply[reply]
I always look at the RFC in which the arguments must be consistent with the sources. And in that sense anachronism would be determined on the basis of sources in which would be written that some information is not in accordance with the time context. I know from Christopher Columbus sources where one RS states that Christopher Columbus is not Italian because Italy did not exist at that time. But in the article he is presented as Italian although there are many sources which talk about him as a Genovese. So this information are not enough by itself to remove anachronistic name Italian from the article. But if there was a rule which determines this question, the Italian fact would be replaced tomorrow. It wouldn't even need RFC in a wider sense. This rule can also regulate question of old toponyms etc in a manner that is acceptable for today's time. Some information can also be excluded, etc. Mikola22 (talk) 03:52, 28 October 2023 (UTC)Reply[reply]
Huh? What source states he was not Italian? Walrasiad (talk) 06:17, 28 October 2023 (UTC)Reply[reply]
Christopher Columbus by Ernle Bradford, first page[10] Mikola22 (talk) 06:23, 28 October 2023 (UTC)Reply[reply]
It doesn't say Columbus was not Italian. It uses some rather careless wording to emphasize that individual loyalties may be parochial. But Italy existed. Indeed, Genoa was a fief of the Kingdom of Italy. Walrasiad (talk) 06:36, 28 October 2023 (UTC)Reply[reply]
He uses wording in the context of anachronism. However, this is not the issue we are dealing with here, so it is not really important. Mikola22 (talk) 07:31, 28 October 2023 (UTC)Reply[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1182285939"