Jump to content

Wikipedia:Village pump (proposals)/Archive 209

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Reduce WP:ADVOCACY in Module:Find sources/templates/Find sources

Module:Find sources/templates/Find sources currently contains WP:ADVOCACY for Google/Alphabet Inc, one of the world's most powerful and monopolistic, highly criticised corporations that pays 10s of billions of dollars to try to maintain a monopoly with its criticised search engine. This advocacy is contrary to our mission. Moreover, this advocacy violates the spirit of the Universal Code of Conduct in the sense that it encourages Wikipedians to disclose their personal data, and in some cases puts us at risk of harm. What editorial changes should we make in the module to reduce the level of advocacy, without favouring one particular attempted monopoly and without harming Wikipedians' privacy rights, while helping readers find reliable, independent sources using notable search engines? Boud (talk) 16:44, 10 November 2023 (UTC)

  • Proposed discussion structure: Please add Support or Oppose and arguments for or against the following specific proposals in the sections below, or add additional proposals, so that someone uninvolved can summarise the consensus after a reasonable period of debate.
  1. tech step 1: Add missing engines to the list of available search engines at Module:Find_sources/links, for engines that catalogue high numbers of pages, according to Comparison of web search engines, or are notable scholarly search engines:
    1. Add Qwant
    2. Add Mojeek
    3. Add Semantic Scholar
  2. tech step 2: Add some metasearch engines that respect privacy to the list of available search engines at Module:Find_sources/links
    1. Add Startpage.com
    2. Add one or 3-4 Searx instances such as https://searx.thegpm.org
  3. policy step 1: modify Module:Find sources/templates/Find sources that defines the list of search engines at Template:Find general sources
    1. Replace Find sources: by Use a [[List of search engines|search engine]] ([[Comparison of web search engines|comparison]]) to find sources: (which renders as: Use a search engine (comparison) to find sources:)
    2. remove the general link to Google and replace it by Startpage, Qwant and/or Mojeek and/or [add a proposal]
    3. keep Google Books unless someone can propose a similar equivalent
    4. replace Google News by a link to the Startpage or Searx.thegpm.org news link (needs tech solution for direct URL) and/or [add a proposal]
    5. replace Google Scholar by Internet Archive Scholar and/or Semantic Scholar and/or [add a proposal]
    6. (Other modifications)
  4. (Other)

Boud (talk) 16:45, 10 November 2023 (UTC)

tech step 1: Add missing engines

Add missing engines that catalogue high numbers of pages, according to Comparison of web search engines, or are notable scholarly search engines. The following should be added to the list of available search engines at Module:Find_sources/links (support/oppose NAME(s) or NUMBER(s) + evidence + reasons):

Boud (talk) 16:45, 10 November 2023 (UTC)

  • Support Mojeek + Semantic Scholar (proposer) - Both are Wikipedia-notable, reasonably well-established over several years, and no known privacy concerns are listed in their Wikipdia articles. Qwant is more controversial, and despite claiming to protect privacy, there are RSed concerns about privacy. On the other hand, this point is only about adding these search engines to the list available for templates to use, so maybe it should be added anyway. I may update on Qwant after seeing other evidence for/against. Boud (talk) 16:53, 10 November 2023 (UTC)

tech step 2: Add some metasearch engines that respect privacy

The following should be added to the list of available search engines at Module:Find_sources/links (support/oppose NAME(s) or NUMBER(s) + evidence + reasons):

Boud (talk) 16:45, 10 November 2023 (UTC)

  • Support Startpage + a Searx instance. (proposer) Per the sources in Startpage.com, Startpage has been around for many years, it claims to protect privacy, and there don't appear to be any sources contesting the privacy claims. Startpage does do contextual advertising, so it's not ad-free, but it does not do targeted advertising, so that makes it a lot closer to the spirit of UCOC than Google. Searx: the Searx software package is mature, stable software (available in Debian in the old-old-stable, old-stable, stable and unstable distributions). The practical tech question is whether (i) to list one or a few specific Searx instances (such as https://searx.thegpm.org), or (ii) a list of instances, or (iii) whether Wikimedia community techies should install our own Searx instance. I would tend to go for (i) or (ii), at least in the short term, since (iii) would require waiting for the techie work/server resources to be done. Boud (talk) 17:04, 10 November 2023 (UTC)

policy step: Modifications to Module:Find sources/templates/Find sources

Modify Module:Find sources/templates/Find sources that defines the list of search engines that is used in Template:Find general sources in the following ways (support/oppose + evidence + reasons). Boud (talk) 16:45, 10 November 2023 (UTC)

3.1: Replace 'Find sources'

Replace Find sources: by Use a [[List of search engines|search engine]] ([[Comparison of web search engines|comparison]]) to find sources: (which renders as: Use a search engine (comparison) to find sources:) Boud (talk) 16:45, 10 November 2023 (UTC)

Remove the general link to Google and replace it by Startpage, Qwant and/or Mojeek and/or [add a search engine]. Boud (talk) 16:45, 10 November 2023 (UTC)

  • Support removal of Google, with no replacement (proposer). Along with point 3.1, which would link to our NPOV, non-advocating list of search engines, removing Google, with no replacement, would satisfy our desire to help the reader find sources while also avoiding advocacy. Boud (talk) 17:10, 10 November 2023 (UTC)

3.3: Keep Google Books or propose alternative

Keep Google Books unless someone can propose a similar equivalent. Boud (talk) 16:45, 10 November 2023 (UTC)

3.4: Replace Google News

Replace Google News by a link to the Startpage or Searx.thegpm.org news link and/or [add a news search engine]. Startpage and Searx may need extra tech work since they don't display direct URLs to their news sections. Boud (talk) 16:45, 10 November 2023 (UTC)

  • Support Startpage and/or Searx (proposer) The influence of any single organisation in the selection of news stories is a particularly sensitive question in terms of biasing Wikipedia content. Startpage and Searx are both meta-search engines, so they will still be affected by Google's selection biases, but they each have their own mixes of sources. Since they protect users' privacy, either (or both) would be better than Google for news. Boud (talk) 17:14, 10 November 2023 (UTC)

3.5: Replace Google Scholar

Replace Google Scholar by Internet Archive Scholar and/or Semantic Scholar and/or [add a scholarly search engine]. Boud (talk) 16:45, 10 November 2023 (UTC)

  • Comment (proposer) I personally use the Science tab in a Searx instance, but I've proposed several links to Searx above, and having too many links to a Searx instance would be as risky in terms of biasing our source selection as having too many links to Google. Boud (talk) 17:45, 10 November 2023 (UTC)

3.6: Other modifications

Other changes to the current content of Module:Find sources/templates/Find sources and its template form at Template:Find general sources could be proposed. However, for NYT vs AP, please go to the orthogonal RfC at Wikipedia:Village pump (proposals)#RfC on Module:Find sources - replace New York Times with Associated Press. Boud (talk) 16:45, 10 November 2023 (UTC)

As an open-ended component of this RfC, feel free to add other (preferably concrete) proposals or 'see also' links.

  • This is an invalid RfC. From Wikipedia:Requests for comment: Keep the RfC statement (and heading) neutrally worded and short. The opening statement isn't even remotely neutral, and the remainder of the proposal is hopelessly complex. I suggest that it be closed, and instead a simple, brief and neutral RfC be started in its place. AndyTheGrump (talk) 18:58, 10 November 2023 (UTC)
    Not bad for an RFCbefore though. Could ditch the tag for now and reopen later. Selfstudier (talk) 19:05, 10 November 2023 (UTC)
    What is non-neutral in the RfC statement? The Wikipedia mission is clear: we are opposed to advocacy. This is not an RfC about whether advocating for a monopoly is advocacy or not. Advertising and advocacy are almost universally considered to be in opposition to Wikipedia's mission. We don't have to have an RfC about whether the sky is blue. The remainder of the proposal gives concrete subquestions on which to work, in order to avoid abstract blabla. There is a minimum of structure in order to have a chance of emergence of consensus on the current text. Wikipedia modules and templates cannot avoid a minimum of structure. That is not hopeless complexity, it is structure. The choices are dictated by the current content of the module. Without structure, we wouldn't have Wikipedia. Boud (talk) 19:32, 10 November 2023 (UTC)
    Sure, but look at Wikipedia:Village pump (proposals)#Discussion (Find sources: NYT vs AP) above, dead simple but still going. Selfstudier (talk) 19:39, 10 November 2023 (UTC)
    Boud, I'm not going to argue with you - if you aren't going to close this malformed dogs-breakfast of an RfC yourself, I will find an admin to do it instead. AndyTheGrump (talk) 19:42, 10 November 2023 (UTC)
    This doesn't look anything like an RFC. And it's actually advocacy of an anti-GOGGLE position. (Although the ADVOCACY essay likely isn't relevant outside of mainspace.) Just remove the RFC tag, although too complex even for a discussion. O3000, Ret. (talk) 19:59, 10 November 2023 (UTC)

I have removed the RfC tags -- please read through WP:RFC thoroughly (especially its sections WP:RFCBEFORE and WP:RFCBRIEF) before attempting anything like this again. --JBL (talk) 20:02, 10 November 2023 (UTC)

Shit, you've beaten me to it.
I removed "RfC" from title so that nobody thinks there is an RfC.
Boud, I second the advice directly above, but I also think you can discuss this but not as an RfC but more as a preparation to it. Szmenderowiecki (talk) 20:08, 10 November 2023 (UTC)

@AndyTheGrump, JayBeeEll, Objective3000, Selfstudier, Szmenderowiecki, and Hobit: The best way that those of you who have suggested that the RfC could be worded in a different way while still being concrete, actionable would be to edit the draft or discuss changes to be made to it. Thanks in advance. :) Boud (talk) 22:34, 11 November 2023 (UTC)

I think we can discuss it here once we started it and, once we are ready, we can start an RfC in a subsection. It would be better for you because a lot more people will visit this page than your draft. But I will post in your draft anyway because I'm not sure everyone agrees.
And btw, good you've listened. Szmenderowiecki (talk) 22:45, 11 November 2023 (UTC)
(ec)On the contrary. Given that the draft entirely failed to even approximate to a proper RfC proposal, the best way would be to start discussion again from scratch, working on the premise that there seems to be something of a consensus at Wikipedia talk:Articles for deletion that the present wording needs revision, and that this is best accomplished without engaging in soapboxing about monopolies etc. It seems likely that we can get a general agreement that we should avoid implying that Google is the only option amongst search engines, and that we need to make clear that other options are available in most cases. Given the complexities involved when considering the appropriateness of specific engines in specific circumstances, attempting to find wording for RfC at this stage would seem premature. Start a discussion on the general subject, in a thread that doesn't scream 'advocacy' in the title but instead presents the topic neutrally, and see what people have to say. Few have commented so far, and I suspect that more would do so if they weren't being told in advance how to think... AndyTheGrump (talk) 23:10, 11 November 2023 (UTC)
A good place to start would be noting that WP:ADVOCACY defines its subject as "promot[ing] a person's or organization's beliefs or agendas at the expense of Wikipedia's goals and core content policies, including verifiability and neutral point of view". I do not see how the recommendation of Google in modules or at AfD is harming Wikipedia's verifiability or NPOV. Could you explain, Boud? ~~ AirshipJungleman29 (talk) 00:48, 12 November 2023 (UTC)
Don't mean to interrupt a response from Boud. Just thought I would mention that ADVOCACY is an essay, not a PAG. Also, I'm not certain that it applies out of mainspace -- which should perhaps be cleared up in the essay. In any case, good question. O3000, Ret. (talk) 01:12, 12 November 2023 (UTC)
I personally feel that there is absolutely no reason it should apply out of article/article talk spaces, but perhaps Boud feels differently. ~~ AirshipJungleman29 (talk) 01:19, 12 November 2023 (UTC)
Google/Alphabet is an organisation that has beliefs and agendas. Its legal aim is to maximise revenue from advertisements. Our verifiability and NPOV depends on where we choose our sources. By promoting Google over other search engines, we are promoting POVs selected by Google as opposed to POVs that other search engines select. The fact that Google/Alphabet paid 10s of billions of dollars to Apple and Samsung in order to convince them to make it difficult for smartphone users to use a search engine other than Google only makes sense if Apple and Samsung consider other search engines to be at least equally good at providing sources that would make their customers happy. Neither Google/Alphabet nor Apple nor Samsung are academic institutions that run transparently, with collegial decision-making university-style or public git repository style about how their algorithms run or how their preferred search engines run, so they are inconsistent with the usual criteria for the search for knowledge. Criticism of Google goes into quite a fair amount of detail of why Google does not neutrally select its sources. Given Google's current power, we are unlikely to completely avoid advocating for Google. But we can reduce our advocacy for either Google or whichever search engines Apple and Samsung presumably would prefer if they weren't paid 10s of billions of dollars. (Even Mozilla is also is paid by Google/Alphabet to make Google its default search engine.)
As for article space vs non-article space, {{Find general sources}} is used on about 868,000 pages; while these are not directly in article space, they affect the content of articles by advising people about where to seek sources. Boud (talk) 01:34, 12 November 2023 (UTC)
Kinda hate to disillusion you, but Wikipedia:Nobody reads the directions, so sometimes an editor will toss out a few WP:UPPERCASE claims without knowing what they're linking to. WhatamIdoing (talk) 03:10, 12 November 2023 (UTC)
It's true that the essay WP:ADVOCACY suggests that it's mainly about WP:MAINSPACE advocacy, without saying specifically that it's restricted to article content alone. I've edited the draft to clarify that the advocacy is non-mainspace advocacy. It would be hypocritical to advocate for a particular organisation, especially in a way that biases our selection of sources - which affects our core values of verifiability and NPOV - while claiming that we should not advocate for particular organisations in our articles. Google has an agenda that affects our content. Currently we advocate for Google. Boud (talk) 12:44, 12 November 2023 (UTC)
Here's a prediction. You carry on with your 'advocacy' soapboxing. People look at your arguments, recognise them as the great-wrong-righting grandstanding they are, and decide not to get involved in pointless diversions when a simple discussion over wording and links without all the waffle would solve things quicker. Nothing gets decided. The issue remains... AndyTheGrump (talk) 13:28, 12 November 2023 (UTC)
When some people are trying to say that the sky is not blue, it's important not to let a reader of the conversation think that there is consensus that the sky is not blue, but is instead the colour of higher frequency optical light that is inevitably scattered down during the daytime on a cloudless day. But I agree that we need to cut through the distractions. Boud (talk) 18:22, 12 November 2023 (UTC)
Starting at AfD and continuing here, you have made the following statements:
  • (using Google) puts us at risk of harm
  • one of the world's most powerful and monopolistic, highly criticised corporations that pays 10s of billions of dollars to try to maintain a monopoly with its criticised search engine.
  • it encourages Wikipedians to disclose their personal data
  • would-be totalitarian (though fortunately only authoritarian) organisation
  • Trying to impose that as a unique choice - a totalitarian choice - on the world
  • Text presents a totalitarian point of view - "Thou shalt worship no other search engine than Google!".
  • Google's would-be totalitarian nature
  • "Authoritarian" and "would-be totalitarian" are accurate adjectives in this case.
You have used the words totalitarian and authoritarian seven times each. It sounds like it is you who have an agenda – an anti-Google agenda. Look, if it makes sense to add to the Find Sources template, why not? But, it should be based upon our evaluations of their usefulness, not on some personal dislikes about the source's corporate activities (which I also despise). As I said at AfD when this began, throwing contentious political terms in likely makes editors' eyes glaze over. Which is to say that I totally agree with what AndyTheGrump said above. O3000, Ret. (talk) 14:19, 12 November 2023 (UTC)
We cannot know the usefulness of Google sources, because the agenda is done by secret algorithms and secret committee and board meetings at Google. Meta-reviews, which in some sense are what we do for articles, depend on the quality of the selection of sources. Cochrane meta-reviews are obliged to detail exactly how the sources were selected. In Wikipedia, we do not (and cannot) require editors to say how they searched for sources, but we can reduce our advocacy for particular organisations that have opaque ways of selecting sources, or at least diversify our advocacy. Repeating arguments that appear to have been missed or misunderstood is me being patient, not "having an agenda". As stated on the talk page of the draft, I quite deliberately did the best to avoid my own biases by including search engines that are objectively useful and independent of Google, but that I personally do not find useful. I also strongly recommend that you look at the Wikipedia article political science: the adjectives that I have used are not my invention ("would-be" is not a standard term, but the equivalent type of nuance is common), and they are used in numerous peer-reviewed publications. They are objective terms that can be supported or refuted by evidence. The links to Wikipedia pages are to NPOV-ed articles that have survived the usual Wikipedia public peer-review procedures; the titles and section titles are not mine. Boud (talk) 18:22, 12 November 2023 (UTC)
On the contrary: We can know the usefulness of Google Search, because editors can tell us whether they find it useful. Useful is not a synonym for transparent. WhatamIdoing (talk) 17:40, 13 November 2023 (UTC)
What Wikipedians perceive individually as useful overlaps with, but is not the same as, what is useful for Wikipedia. The search engines we use have search engine bias and some of them have customised results and filter bubbles. Knowing these biases and filter bubbles is difficult; in this sense, knowing the usefulness of Google searches is not impossible, but is a difficult field of research. Boud (talk) 01:59, 15 November 2023 (UTC)
(after edit conflict) We are not talking about the content of the encyclopedia, but a tool that may help editors to find sources. I personally find Google Books and Scholar very good for this purpose, with News less good and a general web search (anyone's general web search) hardly at all. It should stick to what is actually used by most people. In the English-speaking world Google seems to be the most used search engine, whether one likes it or not, just as Windows is the most used operating system. There is no advocacy involved in saying this. Phil Bridger (talk) 14:29, 12 November 2023 (UTC)
Your personal perception of usefulness does not change the fact that Google has an agenda and that we advocate for Google; and it does not make Google's selection unbiased. (As for operating systems, as far as I know, Google uses Debian GNU/Linux, Facebook uses Fedora GNU/Linux, and most servers use one or another GNU/Linux distribution; smartphones mostly use Android with a Linux kernel or Darwin/XNU (which is UNIX certified); and Wikipedia runs on Debian. MS only dominates the PC market.) Saying that Google is popular is not advocacy: I agree. Saying on nearly a million pages that people should primarily use Google is advocacy. Boud (talk) 18:22, 12 November 2023 (UTC)
In going for brevity I omitted the all-important qualification that Windows is the most used operating system on home PCs in the English-speaking world. I apologise. The rest of my post stands as written. Phil Bridger (talk) 18:36, 12 November 2023 (UTC)

New proposal for the initial statement:

In the Find sources module and in the {{Find general sources}} template, should we balance the non-mainspace advocacy recommendations for any particular search engine(s) or meta-search engine(s), with the aim of diversifying the selection biases in finding sources and for encouraging Wikipedians to protect their privacy? If yes, then what changes should be made?

Boud (talk) 18:40, 12 November 2023 (UTC)

Done. There is no advocacy in the Find Sources template. O3000, Ret. (talk) 19:01, 12 November 2023 (UTC)
Considering that most of the people in this discussion have disagreed with the salient points of that, how about Should we consider that the use of Google in the Find sources module and in the {{Find general sources}} template violates WP:NOTADVOCACY or WP:NPOV? I mean, that's if you want to form a consensus. ~~ AirshipJungleman29 (talk) 19:02, 12 November 2023 (UTC)
I don't see the point - that version would be unlikely to lead to concrete, actionable changes and the conclusion would be more or less foregone. WP:ADVOCACY tends to focus on the mainspace content rather than the common-sense meaning of how we actually select the sources used for mainspace content, so debating that would get into WP:WIKILAWYERING about how to interpret the essay. As for Google selection violating NPOV, we don't have good data about the details of its selection, so we can only make the reasonsable expectation that the selection biases NPOV, which is not quite as strong as violating it. In any case, it would be unclear what the result of a hypothetical "yes" consensus would be: I fail to see any chance of a consensus to completely remove Google from the module + template.
Regarding consensus, the consensus to be sought is among the people in the future who may participate, not just those most active right now. Several people have already said that they are interested in diversifying the current list.
How about if we replace non-mainspace advocacy by recommendations, since people are uncomfortable stating that advocacy is advocacy? Boud (talk) 19:28, 12 November 2023 (UTC) (I made this v2.) Boud (talk) 19:31, 12 November 2023 (UTC)
Do try and click on links, instead of assuming you know where each one goes (see WhatamIdoing's relevant comment above). I would also suggest being less condescending, as that may put off "the people in the future who may participate", along with, well, myself. Best wishes with your proposal, ~~ AirshipJungleman29 (talk) 20:01, 12 November 2023 (UTC)
I don't like the wording that runs "with the aim of diversifying the selection biases in finding sources and for encouraging Wikipedians to protect their privacy". In particular, this meant to prioritize these over everything else, but it does not say what any of those other things are. It's rather like saying "You support motherhood, apple pie, and the flag, right"? and then finding out that the guy's emptied your bank account, burned your house to the ground, and stolen your dog, because, hey, you said you support motherhood, apple pie, and the flag, but not money, housing, and pets.
I think in this case, the request is: Could we please link to search engines with transparent algorithms and decent privacy practices instead of search engines that are more likely to find relevant results?
I say this as a person who primarily uses the privacy-oriented DuckDuckGo, and who also fairly often gets inadequate or incorrect search results from it, and switches to Google to find the thing that I need. DuckDuckGo is usually sufficient, but not always. WhatamIdoing (talk) 17:57, 13 November 2023 (UTC)
DuckDuckGo as a default with Google as a backup is what I used to do, not so long ago. Now I generally use Startpage + Searx (roughly equally) with DuckDuckGo as a rare alternative. In any case, my own preferences are not the issue here. Back to the question of the RfC statement/question.
I don't understand why diversifying ... encouraging would be interpreted as instead of. "Diversify" says nothing about what sort of compromise to choose: it does not exclude any search engine completely; "encourage" does not necessarily mean excluding any particular privacy-violating search engine either. To continue with your analogy, once someone says "Yes" to "motherhood, apple pie, and the flag", that same someone gets to answer the If yes, then what changes should be made?" question, to give his/her proposal of how to balance motherhood, apple pie, the flag, money, housing and pets. Boud (talk) 20:04, 13 November 2023 (UTC)
Because, realistically speaking, if people were to express support for "diversifying the selection biases in finding sources and for encouraging Wikipedians to protect their privacy", I expect you to turn up the next day insisting that we have an RFC-backed mandate to remove links to Google, because in your opinion retaining a link to Google would not be consistent with support for "encouraging Wikipedians to protect their privacy". WhatamIdoing (talk) 00:29, 17 November 2023 (UTC)
I see your point, but I guess we disagree on interpreting encouraging ... to .... For me, this is not as strong as insisting that .... Anyway, the encouraging ... to ... wording is no longer in the draft. Boud (talk) 19:07, 21 November 2023 (UTC)

Any objections to the current draft RfC at User:Boud/sandbox/draft RfC Reduce advocacy in Find sources Module? Boud (talk) 20:55, 15 November 2023 (UTC)

I think the question is still non-neutral. How about: "In the Find sources module and in the Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL template, should we diversify our recommendations for specific search engine(s) or meta-search engine(s)?" Firefangledfeathers (talk / contribs) 21:00, 15 November 2023 (UTC)
My opinion is to simply go with:
Hey there, here are three options of the template:
Option 1. Leave as is
Option 2. A position we can hash out here for now in broad strokes, and which we haven't yet
Option 3. Boud's original proposal
We should cut on the demagoguery that RfCs like these will inevitably attract, so one RfC only, limited options, in the worst case we may add some articles one by one.
For me, singling out NYT is ridiculous, but AP only isn't the way to go. We could instead link to our articles called Newspaper_of_record#Selected_existing_examples and News_agency#List_of_major_news_agencies, with a link to WP:RSP and advice on WP:RX just in case. Szmenderowiecki (talk) 21:48, 15 November 2023 (UTC)
@Firefangledfeathers: I've updated the first question to match your version but kept in the second question, and haven't changed the Additional comments below first statement and timestamp. I kept the second question to make clear that anyone answering "yes" is expected to give concrete suggestions of changes. The additional comments are also aimed to help focus the "yes" answers on making concrete suggestions, with arguments/evidence. Boud (talk) 22:29, 15 November 2023 (UTC) (separate responses) Boud (talk) 22:41, 15 November 2023 (UTC)
@Szmenderowiecki: There is currently no Option 3, because the requirements of neutrality required me to not make a specific overall proposed change. I don't see much point having an RfC that has Option 3 Boud's one-against-all option in opposition to Option 2 a community rough consensus option :). If you can facilitate a discussion to develop an Option 2, then Option 3 as Other alternatives would seem better to me, although it would be clearly harder to summarise by the closer if Option 3 was the option best supported by arguments. Boud (talk) 22:41, 15 November 2023 (UTC) (clarify Boud (talk) 12:34, 16 November 2023 (UTC))
WP:RFCNEUTRAL does not require you to hide your goal or to make only vague proposals. WhatamIdoing (talk) 00:31, 17 November 2023 (UTC)

I don't see any work done on Szmenderowiecki's alternative with a specific "Option 2", but we already had changes to the RfC draft by Firefangledfeathers, which were implemented on the draft, and we've had further simplifications by whatamIdoing, giving the current draft RfC of

{{rfc|policy|tech}} The {{Find general sources}} template produces this list of search options: "Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL". Should we change the items in the list? If yes, then what changes should be made? ~~~~

with Additional comments below first statement and timestamp.

We seem to have rough (not full) consensus. Any objections to proposing this as an RfC here on WP:VP/PR? Boud (talk) 21:09, 21 November 2023 (UTC)

As I said, I hate open-ended questions, but it's a much better RfC question than you asked originally, so if others think it's OK to start such a question, it's fine. It's that my understanding of VPR/VPP is that you have something concrete to propose and then you vote on change/no change. If your proposal is just "let's do something but I don't know exactly what", then it belongs to the idea lab.
Regardless of all of the above, it's a good question and it's great you have broached this topic. I will definitely have something to say, as I hope will many others. I definitely am not holding you from starting this RfC, but you have been warned.
Also, wait a sec and I will post what I see to be the template I think I would definitely use. Szmenderowiecki (talk) 22:05, 21 November 2023 (UTC)
Find your source
The Wikipedia Library offers wide access to scholarly articles and academic books for eligible users.Explain who is eligible
Consider also using:
Fellow Wikipedians can help you find what you were searching for if you still cannot.
Without the comments, it looks like this:
Find your source
The Wikipedia Library offers wide access to scholarly articles and academic books for eligible users.
Consider also using:
Fellow Wikipedians can help you find what you were searching for if you still cannot. Szmenderowiecki (talk) 23:08, 21 November 2023 (UTC)
Thanks for letting this proceed and for the warning. A flaw in your specific proposal is that the template is currently used as a very compact, single-line (depending on browser width) guide to sources; I think that people would prefer any replacement to also be very compact. Boud (talk) 12:48, 25 November 2023 (UTC)

I have came up with new consistency in some articles of chemical compounds. Gain consensus from most other readers and helpful volunteers staying.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
There's enough WP:SNOW in here to build a very large snowman, so I'm closing this as snow oppose to avoid wasting any more editor time. (non-admin closure) Edward-Woodrow (talk) 22:50, 29 November 2023 (UTC)

Hi, I have brought up two clean-up changes to fit the consistency of whole non-organic compounds articles including: Hydrogen fluoride, Hydrogen chloride, Hydrogen bromide and Hydrogen iodide. I'm keen to keep the lead sentence of each context mentioned to follow the form: [Chemical compound name] is an inorganic chemical compound; it has the formula [Chemical symbol], linking formula and bolden the symbol. I've made two significant changes to Hydrogen iodide and both were restored to last revision before me. Yes, I've referenced WP:CHEMNAME MOS policy and I have known and declared that the formula should be styled in template in accordance. Any thoughts from you? 2001:EE0:4BC2:C190:74A5:B633:51B2:265D (talk) 03:14, 29 November 2023 (UTC)

What response did you get when you asked at WT:CHEMISTRY or WT:CHEMICALS, the projects that have lots of experts in the subject and editors interested in its articles? You will need to clarify how this proposal is different than how articles generally are currently, and why the bolding of the formula. DMacks (talk) 04:19, 29 November 2023 (UTC)
Looks like there is some discussion at Talk:Hydrogen iodide#Consistent grammar wording where 2001:EE0:4BC2:C190:74A5:B633:51B2:265D was told to bring the question/suggestion here. Jo-Jo Eumerus (talk) 09:46, 29 November 2023 (UTC)
So, give me more perspectives. I want to clarify something you are encouraged to say. 2001:EE0:4BC3:23D0:74A5:B633:51B2:265D (talk) 10:44, 29 November 2023 (UTC)
So I want to make sure: what kind of formula would you like to use? In inorganic chemistry or for simple organic chemistry compounds that's often pretty straightforward and no one really writes otherwise (CuSO4·5H2O, CH3CHO), but I would like to see how you apply this to chlorhexidine, amanitin, heme or methylene blue, or probably a simpler case, choline.
Besides, all formulas are already in the infobox, and, for more complicated cases, it's the molecular structure that matters, molecular formulas often tell little in terms of isomers and functional groups.
If your idea is to make simple formulas only according to the template, where's the cutoff? I dread the prosect of some chemistry fans editwarring over the cases when (not to) use the template, or over the preferred types of formula.
I may consider supporting it if you give clear rules about using this formula. Szmenderowiecki (talk) 12:12, 29 November 2023 (UTC)
The proposal states this is for "non-organic", so of your examples only CuSO4·5H2O would be in-scope. DMacks (talk) 12:59, 29 November 2023 (UTC)
Oh, didn't notice it, thanks for turning my attention to this word. Szmenderowiecki (talk) 13:23, 29 November 2023 (UTC)
In my view, bolding the formula symbol to prevent the readers from losing attention and might quickly get confusion about the chemical formula of the chemical compound we are directing the user to. 2001:EE0:4BC3:23D0:B58E:E5C:90B0:54BE (talk) 13:54, 29 November 2023 (UTC)
Oppose this proposal. It is not consistent with the Wikipedia:Manual of Style/Chemistry/Chemicals#Introductory paragraph essay written as a supplement to MOS guidelines and with support of the WTCHEM folks because it forces lumping of all non-organics together as a monolithic single class rather than the "or more specifically" option. That essay seems to give better flexibility than this proposal when a chemical can be more specifically classified without getting too technical. So it seems to force being overly superficial (not well in keeping with MOS:LEADSENTENCE). More importantly, "non-organic" is not even a univeral or well-defined term (per numerous cited refs and discussions on associated articles). Experts have agreed to disagree, and all agree that there are numerous edge cases, so Szmenderowiecki's concern about "where's the cutoff" is actually a verifiable one via WP:RS. I will alert WT:CHEMS for you, so this discussion does not appear as an attempted end-run around them. DMacks (talk) 13:17, 29 November 2023 (UTC)
Strong oppose as a policy, we don't strive for uniformity among articles as each article in a category will have different things that should be highlighted in the lead. Carbon and Silicon belong to the same group, but the information of each is drastically different and, as such, the opening paragraphs reflect that. Important details respective to each compound would be lost if we chose to adopt a uniform opening structure, and that directly contradicts basic policy set out in MOS:LEAD. microbiologyMarcus (petri dish•growths) 13:37, 29 November 2023 (UTC)
(EC) Upon further consideration, I understand that you want to change the manual of style in this respect. In fact, if the point is that you want to show the chemical formula, it's already in the infobox and there is in general no need to repeat it. Other than that, I fully agree with DMacks, flexibility is often a needed thing when making a proper lead. I don't think I can ever recall some rigid template for any category of articles I edited, and I see no compelling reason to introduce it here. Szmenderowiecki (talk) 13:50, 29 November 2023 (UTC)
I would care to receive your comments more before I jump in the arguments. 2001:EE0:4BC3:23D0:B58E:E5C:90B0:54BE (talk) 13:52, 29 November 2023 (UTC)
@Szmenderowiecki: hang on, I'm not proposing any MOS changes. I want differences between articles (not to get artsy, but I think it's beautiful). My response to the IP opener in the article talk page linked above was in regard to one article they proposed changes to, not to a broad swath of articles—my suggestion there was a compromise from the revision they had made, wanting the chemical formula in the lead. Once I realized they had proposed mass changes, I informed them that they would need to seek wider consensus as it didn't pertain to one article. microbiologyMarcus (petri dish•growths) 14:08, 29 November 2023 (UTC)
My response was to the IP rather than to you. It's that your indent is a little confusing (as it was obviously an answer to IP's proposal). FTFY. Szmenderowiecki (talk) 14:16, 29 November 2023 (UTC)
Understood, mea culpa. Thank you kindly! microbiologyMarcus (petri dish•growths) 14:38, 29 November 2023 (UTC)
Oppose. The Chemicals subproject of the Chemistry project is doing fine without a "big plan" from someone with negligible experience in chem topics and article creation. Chemistry is NOT as simple as HX (X = halide) and black/white demarkation between various compounds types. So the idea is doubtless well intentioned, but I recommend doing a few thousand edits in the area and then reporting back.--Smokefoot (talk) 14:08, 29 November 2023 (UTC)
Strong oppose. This IP editor from Vietnam seems to be same one whose earlier proposal about consistency in element articles did lead to a useful consensus (see this closed discussion). However, all the actual work of implementing that consensus was done by others (myself and User:Praseodymium-141 mainly). I am opposed to arbitrary attempts to create further cross-article consistency for topics where the effort of doing so, including the effort of gaining consensus, is much more than the benefit to readers. This specific proposal is particularly poor, as the molecular formula of simple inorganic compounds is not always needed in the lede sentence. Mike Turnbull (talk) 17:18, 29 November 2023 (UTC)
Agree with your statement—it's starting to snow in here and I know there's an essay somewhere about volunteer time being valuable that applies here (that I wish I had the shortcut link too offhand but am not going to search for it now). microbiologyMarcus (petri dish•growths) 17:21, 29 November 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Wikidata connected sections

I think we should have wikidata connected sections. For such situations the section header will have a language dropdown indicator. This could go to articles or other sections in foreign language wikipedias and potentially solve the bonnie and clyde problem. Depending on how it's implemented it could help with translation between wikipedias too by letting people track which subtopics are covered in articles in which languages, someone could use an expand-language template and specify a section from that language's page.


I imagine such wikidata linked sections as being kind of like anchors, with links being more persistent. Renaming the sections could automatically update section link redirects.


Ideally we would somehow change links on wikipedia to more properly respect links to wikidata connected sections. interlanguagelinks could be corrected by User:Cewbot to section links, and we could have some kind of process for spinning off a section into its own article or merging an article into a section of another one. Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 20:33, 12 November 2023 (UTC)

I want to bring this to next year's proposals too https://meta.wikimedia.org/wiki/Community_Wishlist_Survey/How_to_create_a_good_proposal Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 23:22, 12 November 2023 (UTC)
  • Not gonna happen. How to integrate WD into WP has been discussed many times before, and (except in very limited ways) the idea has been continually rejected (I would say it is becoming a perennial proposal). The primary problem is that Wikidata continues to have issues with reliability. It’s a great resource for locating potential sources, but we still need vet those sources manually. Blueboar (talk) 23:52, 12 November 2023 (UTC)
    @Blueboar The main reason I want such an implementation is just so that foreign language wikipedias can be connected more than they currently are. I think that is different than some other proposals. Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 01:44, 13 November 2023 (UTC)
Courtesy links: d:Wikidata:Sitelinks to redirects (the "Bonnie and Clyde" problem); meta:Community Wishlist Survey 2019/Wikidata/Solution to the ‟Bonnie and Clyde” problem. Folly Mox (talk) 03:50, 13 November 2023 (UTC)
@Folly Mox thank you. My proposal is more specific (miht be too specific though idk) but do you agree with the other person that this proposal is dead in the water from the beginning? Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 18:20, 13 November 2023 (UTC)
I don't agree that the proposal is necessarily a non-starter. It seems like it's just increasing the kind of connectedness Wikidata already has with the rest of the ecosystem, and doesn't have a direct impact on content, so the reliability concerns come into play to a lesser degree than many other Wikidata integration proposals.
I do think that this thread as formulated should probably have gone to the Idea Lab first, but I understand this was the venue recommended to you.
As to the merits of the proposal, I don't understand Wikidata well enough to assess whether or not this is likely to be able to solve the "Bpnnie and Clyde" problem as you suggest— I linked those pages above because I had never heard of the problem and didn't know what it meant.
The chief difficulty I see in implementation, at first glance, is how article sections are so much more mutable than article topics. Any major reorg, and some minor reorgs, have the potential to result in broken anchors. It might also be difficult to assign with any degree of certainty that topic of a section. I'm sure multiple topics (or Wikidata items; as I said, I'm unfamiliar with the system) could be assigned, but for anything other than navigation between different language projects – like extraction of structured data – I could see it being fraught, due to loose associations compounding to produce misleading results. I'm no expert though, so I could be wrong about any and all of this. Folly Mox (talk) 18:56, 13 November 2023 (UTC)
@Folly Mox my idea is that at least at first it would solely be for linking articles together cross-language. I think this is less prone to failure than general article sections Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 02:50, 15 November 2023 (UTC)
Ok, well that sounds pretty safe, at least. What advantages does your proposal have over an interwiki link to another language project with more information on the topic? Folly Mox (talk) 03:32, 15 November 2023 (UTC)
@Folly Mox sorry for the late response. The big advantage I see with it is that different wikis have different standards for what warrants a page, or have particular contributors that are interested in certain things. Notable examples I've seen include that Gerrman Wikipedia is a lot better at historical timekeeping topics, Russian wikipedia seems to have a lot more on anthropology of religion, and military strategy. So when an interested reader sees a small section on one article they might find it worth looking at the full article on the thing in another language.
My main area of contribution on Wikipedia is Shinto and I particularly notice Japanese wikipedia has about 3-4 times the articles, but English articles are held to a much higher standard of notability. In this article Kamiyonanayo for example we could have a section dedicated to each of this group of gods that links to the article in Japanese. We could do the same for this article Sect Shinto with each section being linked to an article in Japanese.
At least in the past I've attempted to push for articles to match the structure of Japanese wikipedia, even in areas where them being in one article makes more sense. I imagine wikidata linked structures would allow for more flexibility in the use of wikidata links like this. Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 08:59, 22 November 2023 (UTC)
Nothing will be cited to wikidata, this will all serve the purpose of making interlanguage stuff easier Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 23:43, 29 November 2023 (UTC)

Enable RC patrolling (aka patrolling for edits)

There is no consensus to enable RC patrolling on en.wiki. There is simply not enough engagement here to find any consensus on a project-wide change that involves creating or modifying user rights and further RFCs to determine access to the permissions. Those who supported enabling patrolling argued that the system would be optional and provide an additional layer to our recent changes patrolling. Those opposed were concerned with the gamability of such a queue and that it would discourage having multiple eyes on recent edits. This is mostly moot though, because as I said above, there was not enough engagement to see any consensus, even if there was a solid majority for one position. That this RFC has been here through well over 10,000 pageviews and attracted so little response also demonstrates that the reception for this proposal is pretty tepid. ScottishFinnishRadish (talk) 22:29, 18 November 2023 (UTC)

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.


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)

  • Support as proposer. Ladsgroupoverleg 17:39, 10 October 2023 (UTC)
    Heh. Disclosure: We had talked about this in person and I was invited to this discussion via e-mail. To my understanding, the one huge difference to Pending Changes is that all edits are immediately visible to the public. There is no queue of edits that need to be reviewed before they're displayed to readers. However, the patrol permission required to mark edits as patrolled seems to be the same one we grant at WP:PERM/NPR (cf. Special:ListGroupRights#patroller). We can either start granting that flag liberally (not going to happen) or practically forget about the idea then... ~ ToBeFree (talk) 18:25, 10 October 2023 (UTC)
    @Ladsgroup: From your link: Patrolled edits is a feature which allows specific users to mark new pages and items in Special:RecentChanges as "patrolled" We have WP:RCP and WP:NPP which seems the same, or very similar. RudolfRed (talk) 18:28, 10 October 2023 (UTC)
    @RudolfRed They are the same code and software but many wikis allow the same for edits (not just new page creations). Ladsgroupoverleg 18:39, 10 October 2023 (UTC)
  • Question: First, is this compatible with mw:Extension:PageTriage that we already have? Second, I think at the least it uses the same groups/etc - which means we'd likely end up greatly expanding those that bypass parts of new page review. — xaosflux Talk 18:30, 10 October 2023 (UTC)
    @Xaosflux Why would it interfere with PageTriage? This is about edits not page creations.
    They use the same rights as the NPP which can become a problem as @ToBeFree mentioned but the fix is not that hard in the software, we can split the right and define a new group. That part is fixable. Ladsgroupoverleg 18:42, 10 October 2023 (UTC)
    @Ladsgroup I don't recall the details, but something about how the very enwiki customized pagetriage hooks the patrol system already? — xaosflux Talk 18:44, 10 October 2023 (UTC)
    It uses patrolling for new pages but it can't interfere with the edit patrolling in any way, the only complication is that the rights are the same which can be fixed easily. Ladsgroupoverleg 18:48, 10 October 2023 (UTC)
    The entire MediaWiki extension would be changed to make it compatible with enwiki's new page patrolling? ~ ToBeFree (talk) 18:48, 10 October 2023 (UTC)
    nah, the code for it is not too hard to change and if we want to deploy NPP to more wikis that might have edit patrolling, we have to change it anyway. Ladsgroupoverleg 18:50, 10 October 2023 (UTC)
  • Seems like trouble - every non-user revision would be un-patrolled, which I expect would instantly flood queue in to a backlog that will never get cleared. — xaosflux Talk 18:46, 10 October 2023 (UTC)
    The queue gets automatically purged after 30 days, as I said above. Ladsgroupoverleg 18:47, 10 October 2023 (UTC)
    And the point of it is not to clear any queues either. You will just have a a new filter to avoid re-reviewing edits and wasting your time. Ladsgroupoverleg 18:55, 10 October 2023 (UTC)
  • Oppose. If the right is new-page patroller, a critical feed which is nearly always backlogged, we don't want to divide the attention of the small group of people who are trusted to work in this area into something significantly less pressing. Espresso Addict (talk) 21:53, 10 October 2023 (UTC)
    Actually the more I think about this, the less I like it. Frank vandalism is usually easy to spot and revert, so wastes little time. The really problematic edits are PoV pushing of one form or another, and it would be trivial for a PoV pusher/paid editor to get the permission and then reduce scrutiny on problematic edits. Espresso Addict (talk) 00:19, 11 October 2023 (UTC)
  • Comment I review most edits on my watchlist by hovering over (diff) (or "(3 changes)", etc.) with Popups. This is quick and easy. I'd be much less productive, and less likely to bother, if I had to click (diff) against every edit, wait for the page to load, click "mark as patrolled" and find my place in the watchlist again. Certes (talk) 22:11, 10 October 2023 (UTC)
    The support for marking edits patrolled can easily be added to popups. Ladsgroupoverleg 11:05, 11 October 2023 (UTC)
    Or... you could just not mark things as patrolled, @Certes.
    I don't think that everyone is understanding this proposal. Think of the question this way:
    • We could have a system that allows admins and other editors we trust to optionally signal to other editors – the ones who are voluntarily choosing to use this feature – to signal to the other editors in the opted-in group that one editor personally thinks a given edit no longer needs extra eyes on it (e.g., because it was reverted already, or because the patroller knows that it's good).
    • If you choose to use this optional system, then you can filter Special:RecentChanges to show you only those edits that other editors either haven't checked or are uncertain about. You would not need to see (and re-check) edits that other editors have already marked as acceptable. You would know which ones have no been checked, instead of assuming that the entire list of recent changes needs your personal attention.
    • Nobody will be required to use this system. In fact, it would probably be good to have a mix of editors: some being more efficient (so that everything gets checked, instead of some edits being checked many times and others being overlooked), some looking at their watchlists, and others looking at everything they can (to double-check).
    • Note that not re-re-re-re-checking known-good edits is what anti-vandal tools like Wikipedia:Huggle do automatically, so this is not a new idea.
    I think the question really is: Do you want to ban other editors from voluntarily and easily sharing information about which edits they've already checked, keeping firmly in mind that if you personally don't want to use their system, then it doesn't need to affect you at all? WhatamIdoing (talk) 01:07, 16 October 2023 (UTC)
  • (edit conflict) If this happens, we definitely need separate "new page autopatrolled" vs. "recent change autopatrolled", as well as "new page patroller" vs. "recent change patroller" user-rights. I'm not convinced this is a good idea anyway, but I'm not an active RC patroller so I'll leave the merits to others.
    Although creating that split means that global rollbackers would lose new-page autopatrolled, instead of me having to manually unpatrol every article they create. * Pppery * it has begun... 22:13, 10 October 2023 (UTC)
  • Comment. This reminds me of a conversation a few months ago at Help talk:Citation Style 1/Archive 89#Proposal: 'Verified' parameter, and is a subgenre of the mark something as "no action needed" problem. Personally I feel like the proposal here would create an immense amount of paperwork and possibly false sense of security, but I do think a general optional tickbox for "looks good to me" could be beneficial. Generally, we want to double check each other's work but not octuple check it. It's a grey area for sure.
    Folly Mox (talk) 22:29, 10 October 2023 (UTC)
    While I understand your point, I want to mention that this has been working for over a decade in many large/medium wikis including mine without a a lot of paperwork and has been quite useful. A wiki can turn it into a paperwork nightmare or something lean if they chose to. Ladsgroupoverleg 11:22, 11 October 2023 (UTC)
  • I'm generally supportive. If it can be made to work technically, i.e. there's no unresolvable conflicts with other extensions, and we can get a sensible set of permissions, I think this would help prevent a lot of duplicated effort. -- zzuuzz (talk) 22:42, 10 October 2023 (UTC)
  • Support individual changes for rollbackers and administrators. Old vandalistic and other disruptive edits often go unnoticed for years. Oppose new pages inside of mainspace for anyone who is not a new page reviewer or autoreviewer, as those require a solid understanding of the deletion policy beyond the criteria for speedy deletion. Awesome Aasim 17:16, 11 October 2023 (UTC)
    giving the right to rollbackers is a good idea to avoid creating yet another group of users and extra paperwork. There is a major overlap between rollbackers and patrollers too (if not the exact same). Ladsgroupoverleg 17:55, 11 October 2023 (UTC)
.Oppose If you believe something might be wrong you should check it yourself, not rely on other editors. Either this user right is limit to a small group, making it ineffective, or a larger group, opening it up to all kinds of abuse. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:36, 11 October 2023 (UTC)
I think you're wrong. You can choose to ignore this system and still check every change (do *you* check every change now?). You'll give the patrol right to your trusted users, with the possibility of having the right removed if they're no longer trusted; patrol actions are logged, and you can easily tell who marked each change as patrolled. Can you say that *every* change has been seen by someone (trusted) now? I'm pretty sure a user with, say, 2000 clean edits is a good patroller candidate, someone I'd trust. But I'd still sometimes take a look, even if the change was marked as patrolled. Nothing to lose here, trust me! Ponor (talk) 03:25, 15 October 2023 (UTC)
@ActivelyDisinterested, you say If you believe something might be wrong you should check it yourself, not rely on other editors, but there's nothing in this proposal that would prevent you from doing exactly that. So why the opposition? WhatamIdoing (talk) 01:09, 16 October 2023 (UTC)
I didn't say "I should check", maybe I should have said "should be checked". This system and many other recent discussion on similar things would mean that editors are relying on other editors for verification. That shouldn't happen, it's fundamentally wrong.
This has nothing to do with currently checking all edits, the question is trusting current edits. I don't blindly trust current edits, no editor should, but this would directly implement a system of doing exactly that. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:11, 16 October 2023 (UTC)
Our current system works like this:
  • Alice looks at Special:RecentChanges and looks at the diffs for edits 1, 2, 3, 4, and 5. She wasn't sure about edit 2, but she didn't think it was bad enough to revert. Maybe someone else will look at it.
  • Bob looks at Special:RecentChanges and looks at the diffs for edits 1 and 4.
  • Chris looks at Special:RecentChanges and looks at the diffs for edits 1, 2, and 4.
  • David looks at Special:RecentChanges and looks at the diffs for edits 1 and 4.
Result: Nobody looks the diff for edit 6 or 7. Four people have checked edits 1 and 4. Two people have checked edit 2. One person has checked edits 3 and 5. If you wrote it out in order, editors looked at diffs 1111223445XX.
Imagine that we instead said:
  • Alice looks at Special:RecentChanges and looks at the diffs for edits 1, 2, 3, 4, and 5. She marks edits 1, 3, 4 and 5 as okay, but isn't sure about edit 2.
  • Bob looks at Special:RecentChanges and looks at the diffs for edits 1 and 4, just like he always did.
  • Chris looks at Special:RecentChanges, turns on the filter so they can see what others haven't already accepted, and looks at the diffs for edits 2, 6, and 7. Chris marks edit 7 as okay, but isn't sure about edits 2 or 6.
  • David looks at Special:RecentChanges, turns on the filter so he can see what others haven't already accepted, and looks at the diffs for edit 2 and 6. David – who wouldn't have looked at either of these diffs under the previous system – is able to resolve the question about edit 2 but leaves edit 6 in the queue for another editor.
In this scenario:
  1. Any editor can still look at whatever they want, like Bob did.
  2. Any editor can voluntarily focus on the un-patrolled edits, like Chris and David did.
  3. The result is that more people look at the uncertain diffs, and somewhat fewer editors look at the obviously good edits. If you wrote it out in order, editors looked at diffs 1122234456667.
What I'm not hearing from you is any reason to believe that requiring all editors to randomly checking RecentChanges is a better system (as measured, e.g., in the percentage of diffs that get looked at by an experienced editor) than having the old system plus allowing some editors (i.e., those who want to) to check specifically the ones that other editors haven't indicated is okay. Adding this system takes nothing away from you. Why do you want to take away the opportunity to use a different system from the editors who want to use it? WhatamIdoing (talk) 17:42, 16 October 2023 (UTC)
I was going to say almost the same. We like to think that every change gets 'seen' by someone, but in reality I'm observing a lot of propaganda, wp:refspam, false statements, original research (...) being added and never reverted. This system will raise some red flags for those edits, especially as they get closer to the 30 day limit. Ponor (talk) 18:28, 16 October 2023 (UTC)
Nothing you added changes my point. It isn't, and has never been, about what editors can check and again it has absolutely nothing to do with what I can check.
As you have just said the purpose is for editors to not have to check obviously good edits. But that is just a backwards way of saying editors won't check edits based on the reliablity of other editors, and is directly in opposition to how things should be done.
Nothing you have said, nor anything anyone else has said in support of the proposal, changes that this change would have a large negative effect on the project. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:29, 16 October 2023 (UTC)
Or as an exaple.
1) Editor A marks a edit as approved
2) Editor B sees that editor A has marked as approved and doesn't check it.
3). FAIL -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:31, 16 October 2023 (UTC)
That could only happen if everyone is using it (I rate this as being exceedingly unlikely), and it could only make things worse if we additionally assume that Editor B does nothing (e.g., reviewing other edits and therefore finding other problems; I rate this as unlikely).
But again: Why should you get to effectively ban other editors from using this tool? Nobody's going to force you to use it, but why shouldn't other editors be permitted to do so, if they wanted to? WhatamIdoing (talk) 18:47, 16 October 2023 (UTC)
Other editors shouldn't use it because using it would have a negative impact on the project, for the reasons I have outlined (a few times). This is again, for the second time, nothing to do with my using it or not. Please stop trying to twist my words in that way.
The situation in my last comments happens every time an editor doesn't check an edit because another editor they trust "approved" it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:10, 16 October 2023 (UTC)
The situation in your last comment happens only if no editors check an edit because another editor they trust "approved" it. It does not happen when some editors move on to other, unscreened edits.
This is already being done by anti-vandalism tools such Huggle, and the situation you hypothesize is already not happening. Why do you think that having one more tool doing this will create your situation, when your situation has not materialized through the tools that are already doing this? WhatamIdoing (talk) 21:03, 16 October 2023 (UTC)
Some or most makes absolutely no difference, as I have already stated about whether the right is given to a large group or a small one. Also the suggest 2000+ edits for an editor in good standing is not a small group, it would just be the new watermark to reach for POV pushers.
This is not done by current tools, or at least to my knowledge, at the moment edits are highlighted as potentially bad by an algorithm. This would mark edits as "good" in the opinion of an editor, the inverse of the current situation.
I've shown using your own example that there is a problem. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:36, 16 October 2023 (UTC)
This is done by existing tools. Some of them, including Wikipedia:Huggle, set up a feed with the idea that it's better to check all edits once than to check some of them multiple times and some of them never.
This green button is used in Huggle to mark an edit as a "Good Edit".
If the edit is cleared by one Huggle user, then it's not shown to other Huggle users. See mw:Manual:Huggle/Quick start#Controls, especially the green icon associated with the words "Clicking on the green pencil with the checkmark will flag the edit as a good edit."
You don't have the user right necessary to use Huggle, so I'm sure you've never personally seen it, but it's still happening whether you've seen it or not. WhatamIdoing (talk) 01:38, 17 October 2023 (UTC)
I don't care for such things, due to the many issues such things cause. If this is already happening it's not something we should encourage, as per my previous statements. Making a bad situation worse, doesn't make it better. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:32, 17 October 2023 (UTC)
So:
  • it's been happening for years, and
  • you believe it causes many issues, but
  • you can't point to a single example of any issue it's ever caused.
Okay. WhatamIdoing (talk) 17:52, 18 October 2023 (UTC)
Or as an example. (1) Editor A marks a edit as approved (2) Editor B sees that editor A has marked as approved and doesn't check it. (3). FAIL
The issue with this reasoning is that patrol actions are logged, and you can easily tell who marked each change as patrolled, quoting Ponor. In other words, there's accountability. Make a few mistakes, fine (page watchers probably couldn't have caught it either), you'll get some feedback and learn. Make consistent mistakes and your RC patrol right is revoked. DFlhb (talk) 23:24, 16 October 2023 (UTC)
So great we now have to have watchers for the watchers. How about instead don't have such a system, and all editors are watchers of all edits. I made a similar point in my original statement. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:34, 17 October 2023 (UTC)
You don't need to watch the watchers. No one in other wikis do that, there are many ways to surface incorrect patrol including highlights, people who don't use the edit patrolling, etc. Ladsgroupoverleg 14:08, 17 October 2023 (UTC)
That other wikis don't do something I feel they should do is the epitome of OTHERSTUFFEXISTS. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:28, 17 October 2023 (UTC)
In you list of checks, 1122234456667. The problems is that 3 and 5 could be the edits with issues, but because everyone takes Alive as a reliable source they are not checked again. This change creates an environment where editors are trained to think in ways that the opposite of how they should think about the situation. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:41, 16 October 2023 (UTC)
Sorry, I should have specified from the beginning, from my viewpoint as the omniscient narrator that edits 2 and 6 were the suspicious edits. WhatamIdoing (talk) 18:49, 16 October 2023 (UTC)
So yes, your suppositions are correct if you control all the variables. But life is not like that. In a real world situation were you are not the "omniscient narrator" edits 3 and 5 could be the edits with problems, and your system would mean they are not checked when they should be. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:05, 16 October 2023 (UTC)
Edits 3 and 5 weren't checked in the existing system, either. WhatamIdoing (talk) 01:23, 17 October 2023 (UTC)
Maybe, maybe not. But this system ensures they are not, because it's a system that trains editors to not check such edits. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:35, 17 October 2023 (UTC)
At most, it would "train" the ~9,000 of admins and editors who have rollbacker rights to divide the workload rationally. The rest of us – more than 100,000 editors each month – wouldn't be able to use it. WhatamIdoing (talk) 14:53, 17 October 2023 (UTC)
It would train them to do something I have repeatedly said I feel is a negative the project. That you don't have the same opinion is obvious, that you don't seem able to take onboard that I disargree is verging of IDLT territory. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:27, 17 October 2023 (UTC)
I have no idea why my opposition in particular has gained so many replies, but I've had enough of it. I won't be replying to any further comments. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 18:30, 17 October 2023 (UTC)
  • Oppose per EspressoAddict and ActivelyDisinterested. Quis custodiet ipsos custodes? Edward-Woodrow • talk 20:41, 11 October 2023 (UTC)
  • Support. I'm not sure how other wikis use it, but I don't see a disadvantage to keeping track of which pages have been checked at least once, whether this is applied to all pages, a specific subset or as needed. If people want to, they can continue to check the feed of all edits, it's not like turning this on would disable to normal recent changes feed. Patrols don't have to always be good, as long as they're correct more than 50% of the time, that's potentially useful information. I don't see the merit of not collecting information for fear of people using it badly in this specific case. Maybe it would be better if instead of defaulting to everything needing to be checked, everything gets automatically patrolled but RCPers can unpatrol things they find suspicous, I know there's a "suspicous edit" button in Huggle that I don't use very much (when I actually do RCP, which isn't much these days), but I'd say the best way to see how well it'll work is to enable it as a trial. If nothing else, having a log of patrol actions would help collect data on RCP work (or some subset of it), even if the data isn't directly used on-wiki at all. Alpha3031 (t • c) 14:56, 14 October 2023 (UTC)
  • Support. I don't understand how you work here without this bookkeeping system, but I do see how and why some false statements I discovered over the years found their way into enwiki and stayed for a long time: I myself sometimes think someone else will take care of the things, but do they? By enabling this extension, you have nothing to lose. I've patrolled thousands of edits on another wiki, even made it easier to patrol from recent changes, page history, and user contributions pages by using two scripts for "inline" patrolling (much easier than that floating window, Certes!) from this proposal (check animated pics to see how patrolling works). As for who should patrol: all advanced rights users, any additional "trusted" users... as I said, this is just another bookkeeping system, let those who want to use it - use it. Nothing will change for those who don't. Ponor (talk) 02:59, 15 October 2023 (UTC)
  • Support because it's an optional system that can be used by those that want to use it and ignored by those who don't want to be bothered with it. Ladsgroup, I suggest talking to the maintainers of the Wikipedia:Cleaning up vandalism/Tools. There's no reason to require two clicks. People like Remagoxer (on the RedWarn/UltraViolet team) would probably like to know about this, assuming it gets implemented. WhatamIdoing (talk) 17:51, 16 October 2023 (UTC)
  • Support. This seems great; it enables optional 'coordination' when scrutinizing the watchlist. Even though it's not perfect, I think it's valuable to reframe: fighting against bad edits is best done through defense in depth. ORES, page watchers, people who check recentchanges, this new RCpatrol, anything that helps, by any amount, is good to have in the toolbox. Fully optional, too - DFlhb (talk) 00:02, 17 October 2023 (UTC)
  • Support as a great idea – easy way to improve our accuracy. As it stands an immense amount of unsourced and incorrect additions get through the system, and by spreading out who checks what more evenly the percentage of bad edits getting through will dramatically lessen. Even requiring two editors to check every good edit would IMO improve efficiency. J947 † edits 03:43, 17 October 2023 (UTC)
  • Oppose as not a great idea ~ per ActivelyDisinterested and EspressoAddict. Obvious vandalism is easy to spot and is then reverted; less obvious stuff benefits from as many eyes as we give it. I fail to see the benefit. Happy days, ~ LindsayHello 14:58, 18 October 2023 (UTC)
    @LindsayH, but what makes you think it won't get enough eyes? The only thing that's added is a little red exclamation mark in recent changes *for users with patrol rights*, which only they can remove, and they still get to see all edits on their watch list. There's no change whatsoever for nonpatrollers. Ponor (talk) 07:09, 19 October 2023 (UTC)
  • 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)

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

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

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

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


Two notes:

  • The patrol logs can be used to improve ML models of vandalism highlights and revertbots. I already used the patrol logs to build the revert bot in my home wiki. I can see this could be used to improve general AI models.
  • I feel there is a bit of misunderstanding on how this works, possibly a trial period to show its pros and cons and then we can decide? Ladsgroupoverleg 20:05, 15 October 2023 (UTC)
@Ladsgroup, have you talked to your colleagues in Tech, just to make sure that the servers won't fall over if this is enabled here? WhatamIdoing (talk) 00:54, 16 October 2023 (UTC)
@WhatamIdoing yeah, specially since this is enabled in wikidata (which has a massive flood of edits) which caused issues in 2017 and I overhauled how the data is stored around that time and now it's quite healthy. Ladsgroupoverleg 12:11, 16 October 2023 (UTC)

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

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

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

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


the bot tried to archive this, I rather make sure it gets closed first. Ladsgroupoverleg 11:25, 2 November 2023 (UTC)

Another note to avoid the bot archiving it Ladsgroupoverleg 11:28, 13 November 2023 (UTC)
You could use {{do not archive until}}. WhatamIdoing (talk) 17:13, 13 November 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Post-close (RC patrolling RFC)

The lack of participation and consensus is really too bad. This seems like a proposal best tested on a trial basis, so the claims of supporters and opponents can be experienced instead of conjectured. Would this be worth proposing again, explicitly as a trial? DFlhb (talk) 00:41, 30 November 2023 (UTC)

I don't think many people will join in if there is only discussion, because experience shows that these patrol proposals will come to nothing anyway.
The technical implementation of the patrol system is also not particularly convincing. It would be wrong to claim that everyone on e.g. Commons would be happy with the existing patrol feature enabled. Killarnee (talk) 19:42, 2 December 2023 (UTC)
I think this RfC could've gone better if the technical details were clarified (e.g. how this will affect new page patrol) and if it was advertised on CENT. Galobtter (talk) 20:16, 2 December 2023 (UTC)

Date format for year articles

I checked the year articles for 2021 onwards and they look a tad different from the previous revisions. Recently, the date formatting was changed from MDY (November 16, 2023) to DMY (16 November 2023). According to the edit summary, it stated that "MDY had just been chosen without consensus and for a global article like this [year article], and DMY is more global". Example is given here. So what do you guys think? Should we shift to DMY dates for the year articles? Or keep it at MDY? RMXY (talk • contribs) 11:46, 16 November 2023 (UTC)

  • I'm a little confused (FYI, you haven't added an RfC tag {{rfc}}, and I'm not sure this merits an RfC so I'm not adding one yet), but I assume you're referring (broadly) to MOS:DATE. I am 99% sure that both MDY and DMY are acceptable, and I'd like to keep it that way. There's no need to specify which format we should use for particular group of articles. I mean, DMY is clearly better, but... Edward-Woodrow (talk) 12:51, 16 November 2023 (UTC)
Both are acceptable, mass changes should not be done, editors should be able to come to a consensus on which to use for the page on its talk page. -- LCU ActivelyDisinterested «@» °∆t° 17:53, 16 November 2023 (UTC)

Change all articles about generic years to the DMY format At the Wikipedia talk:WikiProject Years, we've been discussing converting all generic articles about calendar years to the DMY format ("1 October 1998" as opposed to "October 1, 1998"). This is not a proposal for a guideline/policy change, but is a proposal to set a standard for a very narrow set of articles, namely articles about generic calendar years, i.e. 1987. I will personally convert all articles from 1899 to 2029. I would like to create consensus for this standard, is necessary by a RfC here. Reason: There was never created consensus about the use of MDY. It was just chosen. DMY is, to put it shortly, a much more global date system used in the majority of English-speaking contries. I therefore find that DMY is considerably more suitable for use on articles about generic years.--Marginataen (talk) 20:43, 16 November 2023 (UTC) When writing about international subjects, the DMY format is the standard format. I find it baffling that year articles use the MDY format. This is properly because many editors are north american but this is not a proper reason. I've looked in the archives and this is not something that's ever been properly discussed. I would like to suggest chanding articles about dates, years, decades and centuries to the DMY format. This should not apply for some articles about years in specific countries, e.g., 2023 in the United States. DMY = 29 October 2023. MDY = October 29, 2023.--Marginataen (talk) 17:03, 29 October 2023 (UTC)

@Thebiguglyalien @Deb @Alsoriano97 @Carter00000 @Wjfox2005 @PaulRKil @JohnAdams1800 @4me689 @Donner60 @DementiaGaming @Austria Football 02 @XTheBedrockX @Yeoutie

I'll just elaborate a bit. I've look through the archives. There were a few mentions e.g. "Date formatting in decade article" but those never went anywhere. There has been no discussision first before MDY was just implemented. The precedence for using DMY for anything that isn't specifically North American is extremely strong. DMY is used by most English-speaking countries and most of the world. From a lingustic point of view, MDY is simply illigionally as it goes 2-1-3 instead of 1-2-3 (from smallest to biggest). No consensus about using MDY was ever established. Marginataen (talk) 15:56, 31 October 2023 (UTC) Date format by country. Map showing which countries primarily use which endian date format. Colors for base formats CMY, mixing using CMYK color model.

  DMY – Day/Month/Year – Little-endian
  MDY – Month/Day/Year – Middle-endian
  YMD – Year/Month/Day – Big-endian (used internationally as ISO 8601)
  DMY + MDY
  DMY + YMD
  MDY + YMD
  DMY + MDY + YMD

--Marginataen (talk) 20:51, 16 November 2023 (UTC)

  • Comment - I don’t care one way or the other, but I will just mention the 2000 pound gorilla in all this: The MDY format is standard in the US, and an overwhelming number of our readers are from that country. While Americans are aware that other places use DMY , they do find it a bit jarring when they see it (the exception being 4th of July). Perhaps more importantly, an overwhelming number of our editors are from the US. No matter what rules/conventions we may adopt, these editors will continue to use MDY when adding new events. It is what comes naturally to them. We will thus have to perform continuous maintenance on the articles to conform them to whatever set standard we may choose.
So… I would just apply ENGVAR… allow whoever starts the article to set the variant, and don’t change it. Yes, that means some articles will use MDY while others use DMY. I don’t have a problem with that.
Or… we could adopt YMD, and upset everyone equally (😉). Blueboar (talk) 21:16, 16 November 2023 (UTC)
While Americans are aware that other places use DMY , they do find it a bit jarring when they see it applies equally in reverse to people who use DMY dates (maybe also those who natively use YMD dates experience the same for both other systems, but I'd have to research that). This is therefore not an argument in favour of MDY that holds any weight. Thryduulf (talk) 21:31, 16 November 2023 (UTC)
an overwhelming number of our editors are from the US. No matter what rules/conventions we may adopt, these editors will continue to use MDY when adding new events. It is what comes naturally to them This is the exact same the other side around. I constantly see articles with a tag to use MDY using DMY during the text. This is not an argument. Marginataen (talk) 21:44, 16 November 2023 (UTC)
@Blueboar, according to https://stats.wikimedia.org, less than half of our page views come from the US. The breakdown is 42% from the US, 11% from Great Britain, 11% from India, 5% from Canada, 3% from Australia, 1% from Ireland.
But I agree with you that this seems to be an end-run around the usual rule that whoever does the work for that individual page gets to set the standard for that initial page. WhatamIdoing (talk) 00:20, 17 November 2023 (UTC)
The concept that DMY is better than MDY has been rejected in many discussions, many of which can be found in the archives of Wikipedia talk:Manual of Style or Wikipedia talk:Manual of Style/Dates and numbers. Since that argument has no merit, if the format is to be harmonized among year articles, I believe we should use the format that is in the majority among those articles. I had Excel choose 25 random numbers between 1 and 2022. All 25 turned out to use the MDY format. All but one had a {{Use mdy}} template with a date in 2011, so perhaps something systematic was done in that year. Jc3s5h (talk) 21:24, 16 November 2023 (UTC)
Of course they are all MDY. That's what I'm trying to change. The fact that MDY was chosen does not mean it should be used for eternity. I'm not saying that MDY is a priori worse than DMY. I'm simply of the belief that DMY is more suitable for the use in articles about generic years that should have a global and not just American appeal. Look at the map. Marginataen (talk) 21:37, 16 November 2023 (UTC)
I reject the map because I don't think customary formats for information can be compared between languages. The way dates are formatted in Chinese or Hungarian is not relevant for an English encyclopedia. Jc3s5h (talk) 17:41, 17 November 2023 (UTC)
  • This sounds like an attempt to overturn WP:ENGVAR. There's nothing special about year articles vs. any other article on Wikipedia, and no reason to have a special standard there. The "map" being cited would be a reason for any article to have a specific date format, an idea specifically rejected by early Wikipedia very wisely. It doesn't matter if one year uses MDY and another year article uses DMY and another year article uses YMD. Just use whatever format is already established. Consistency isn't important nor expected, just as articles already differ in the variety of English used. SnowFire (talk) 22:30, 16 November 2023 (UTC)
    What WP:ENGVAR actually says is When an English variety's consistent usage has been established in an article, maintain it in the absence of consensus to the contrary. (my emphasis). This discussion is an attempt to form such a consensus. Regardless of whether the discussion arrives at consensus for (or against) the proposal, the discussion is proper and not an attempt to overturn the guideline. Thryduulf (talk) 23:08, 16 November 2023 (UTC)
    Yes, but I'm sure you understand what was meant here. The whole point of ENGVAR and RETAIN is to avoid having to do the same poll all across the site 9999x times. It protects both sides, as you can't have Americans all start whining and holding a vote to move the other way to MDY, either. When there's a consensus, it's always about something local like MOS:DATETIES - e.g. 2023 in the United Kingdom should clearly be in DMY format. Unfortunately, Marginataen phrased the contested edit as that DMY should be used because it's "more global," which is classic ENGVAR-warring stuff. That's basically saying "let's standardize on DMY except for articles on specifically American topics", because a lot more than just years are global topics. Which, well, fine, but that's challenging the truce of ENGVAR like I said in my initial comment. If there's a specific consensus to be had, it needs to be on something unique to years, which I can't find any at DATETIES. (But honestly, based on Marginataen's comments, it really just sounds like an argument to use DMY everywhere.) SnowFire (talk) 23:48, 16 November 2023 (UTC)
    What MOS:DATEVAR, which specifies "consensus on the article's talk page", IMO doesn't need is a "Ha ha, we had a big RFC once six years ago and we voted to not let you use that date style in this group of articles. That's consensus!"
    I could argue that all sorts of subjects are "global" in nature (hmm, a global pandemic?) and therefore should use "my" date style, but that's exactly the kind of thing that DATEVAR says is a bad idea. WhatamIdoing (talk) 00:23, 17 November 2023 (UTC)
    @SnowFire: this discussion, which explicitly excludes articles with ties to a specific country, is happening here to have one centralised discussion rather than one per article. You can oppose change if you wish, but do so on the merits of retaining MDY, the disbenefits of DMY and/or the disbenefits of changing, but having the discussion is appropriate, in the proper place and (given that someone acting in good faith feels the change is desirable) required by the guideline. That would be different if there was a recent consensus on the topic, but the evidence suggests that if there has been previous discussion it took place at least 12 years ago in a location that is sufficiently non-obvious that it has not been found. Thryduulf (talk) 00:55, 17 November 2023 (UTC)
    Okay, I guess you didn't understand what I meant after all. Let me be more blunt. This is an invalid RFC. See WhatamIdoing's comment. The whole point of RETAIN is precisely to avoid polls of "what's your favorite English variety" which lead to anger, bad feeling, and wasted time. When it's talking about consensus, it's talking about "consensus on whether special factors apply or not", e.g. whether national ties are strong enough to override the usual RETAIN rule. It's not an invitation to start a poll on which date format is better, or to make people have to ridiculously defend "the merits of MDY" (it's arbitrary! there are no benefits either way!). It would be a valid RFC, albeit one I opposed, to suggest just overturning DATETIES and replacing it with "We use DMY on Wikipedia". That'd be fine. But there's nothing here so far that is really about years, and is instead really about sneakily overturning RETAIN on date style. Better to just make it explicitly about that. SnowFire (talk) 02:06, 17 November 2023 (UTC)
    Fully concur with SnowFire on this point. --Coolcaesar (talk) 07:25, 20 November 2023 (UTC)
As expressed on other talk pages, I am wholly in favour of the switch to DMY on all main year articles as per Marginataen, and will support any such RFC on the matter. TheScrubby (talk) 23:46, 16 November 2023 (UTC)
According to MOS:VAR: "If you believe an alternative style would be more appropriate for a particular article, discuss this at the article's talk page or – if it raises an issue of more general application or with the MoS itself – at Wikipedia talk:Manual of Style". This is not a request for a particular article but a call for consistent use of DMY across all year articles. Within this very specific and narrow group of articles, I do find it legitimate and despirable to wish for a common format/standard. Before starting a RfC, a better move might therefore be (as recommended in the quote) to suggest a change to the Manual of Style? This might be as simple a change as adding what I've put in bold: "If you believe an alternative style would be more appropriate for a particular article or group of articles, discuss...". Marginataen (talk) 16:28, 17 November 2023 (UTC)
Just to be clear here... if your concern is consistency... would you be okay with standardizing on MDY or YMD in the name of consistency? To be clear, I'm not advocating this. I don't think consistency is important at all, personally. But just a thought - would going the "wrong" way in the name of consistency be acceptable? SnowFire (talk) 16:53, 17 November 2023 (UTC)
My wish is the DMY format to be used consistently across all year articles. Marginataen (talk) 17:06, 17 November 2023 (UTC)

Pre-RfC: Date format for year articles

I get that an RfC is the likely next step here. Can we consider what the options should be, and what would be a good brief, neutral question? Are there options beside:

  1. All year articles should use DMY
  2. All year articles should use MDY
  3. All year articles should use YMD (added per WhatamIdoing)
  4. Neither style should be established, and normal MOS:DATEVAR rules should apply?

Can the question be as simple as "What date style should be used for year articles (e.g. 2023, 1491)? Firefangledfeathers (talk / contribs) 21:06, 16 November 2023 (UTC) adding YMD and numbering options 13:29, 17 November 2023 (UTC) striking YMD 15:00, 18 November 2023 (UTC)

I would just like to empertize that this is only about generic year articles, not an article like 2023 in the United States :) Marginataen (talk) 21:40, 16 November 2023 (UTC)
Ok. We could be clear about that with "What date style should be used for generic year articles (e.g. 2023, 1491)? This RfC would not apply to more specific year articles like 2023 in the United States." Look good? Firefangledfeathers (talk / contribs) 21:42, 16 November 2023 (UTC)
For me, yes. Marginataen (talk) 21:51, 16 November 2023 (UTC)
FFF, I think those are the three main options, though technically YMD (YYYY-MM-DD) is possible. WhatamIdoing (talk) 00:26, 17 November 2023 (UTC)
Thanks WAID. I added it. I think it's unlikely to be the winner, but I don't think a four option RfC is too complex. If the RfC runs, I'm likely to add in a comment pointing out that YMD in a year article would make it seem very MDY-ish, since the year rarely needs to be mentioned. Firefangledfeathers (talk / contribs) 13:29, 17 November 2023 (UTC)
I support the third option--stick to the normal MOS:DATEVAR rules. For prior years (2022 and before) I'm fine with switching to the DMY format, but for 2023 leave it in MDY format until the year is finished to permit a transition period, and for future years use the DMY format. This is a grandfather clause so to speak, where prior articles on generic years don't have to use DMY format, but are encouraged to, and future articles (2024 and beyond) will begin with DMY format.
The 2023 article can continue to use MDY format until the end of the year, and then switch to DMY format--it's easier to change it all at once in January 2024. JohnAdams1800 (talk) 02:37, 17 November 2023 (UTC)
Thanks JA1800. We're workshopping the RfC question and options right now, so you may need to paste your !vote elsewhere later on. A few clarifying points:
  • since I added another option, the one you're referring to is now the fourth option, sorry about that
  • the process you outline would not exactly be Option 4, since we would be determining the date style "from above" and not via article-level consensus
  • the article 2023 is actually using DMY dates right now per some recent rough consensus at its talk page.
Firefangledfeathers (talk / contribs) 13:29, 17 November 2023 (UTC)
  • I think the RfC question and options are in decent shape. I am not likely to start it while the interesting and important discussion above is ongoing, about whether or not this RfC is even valid. Firefangledfeathers (talk / contribs) 13:29, 17 November 2023 (UTC)
  • Per above comments, I don't think this is valid RFC - at least probably not. It would break longstanding precedent to avoid unproductive ENGVAR polling. If the concern is consistency, I guess, but that also sets a scary precedent- imagine some other group of linked topics (other than years) where an American editor is happily editing and maintaining Article A1 in American style, and a British editor is happily maintaining and editing Article A2. A third editor comes along and tells them that these two articles, as part of a linked topic like years, actually need to have consistent date formatting. Great, now one editor is going to be unhappy at best, and maybe driven off from working on their article at worst after being told they can't format dates how they're used to. A pointless loss when readers really do not care at all about this and everyone can understand the "other" format just fine.
    • Also, who exactly has proposed standardizing on MDY? I don't think anyone has.
    • If the RFC went forward anyway, my suggestion would be phrasing the question to be strictly related to the importance of consistency rather than which date format is the best. The RFC should be "Is date consistency important in year articles? Option 1: Status quo, no, different articles have different ENGVAR styles and that's fine. Option 2: Date style should be consistent across year articles." Then if option 2 wins, somebody flips a coin while streaming video of it, and we go with whatever the coinflip says. Really. Avoids unproductive "which format is better" arguments, that way, because the truth is it's arbitrary and if consistency is really important, then we'll get it either way. SnowFire (talk) 16:53, 17 November 2023 (UTC)
      I agree with SnowFire in saying that the underlying (primary) question is whether we maintain the current Status Quo regarding date format consistency or not. The current Status Quo is that we need consistency within an article, but not between different articles, and so we apply WP:ENVAR and WP:RETAIN … retaining whichever format was used first in a given article. It may be that consensus has changed on that question (I don’t mind asking)… but that is the core question. Blueboar (talk) 17:39, 17 November 2023 (UTC)
      I agree with User:SnowFire and User:Blueboar should be the status quo. Its the same as language, the use of English for the relevant article (i.e. American English for American article, British English for British). Davidstewartharvey (talk) 16:41, 18 November 2023 (UTC)
  • Dates in the YYYY-MM-DD must not be used for Julian calendar dates, or any date before 1583, for the reasons explained in the "Manual of Style/Dates and numbers". Such usage should be regarded as falsehoods and the editors adding them should be dealt with accordingly. Jc3s5h (talk) 17:51, 17 November 2023 (UTC)
    @Firefangledfeathers, this means that YMD shouldn't be in the list after all. WhatamIdoing (talk) 03:37, 18 November 2023 (UTC)
    Struck! Firefangledfeathers (talk / contribs) 15:00, 18 November 2023 (UTC)
In terms of context, it might be appropriate to say that most articles happen to be using MDY at the moment, and some editors would like to change them to DMY.
I assume that notifications will be posted for the relevant MOS pages (WT:MOS and WT:MOSDATE should be enough?). WhatamIdoing (talk) 03:40, 18 November 2023 (UTC)
Yeah, let's make a notification there Marginataen (talk) 20:49, 18 November 2023 (UTC)
I've made a request at Wikipedia talk:Manual of Style#Style for group of articles Marginataen (talk) 17:02, 19 November 2023 (UTC)
A detailed comment I made at WT:MOS about all this is also pertinent here [1].  — SMcCandlish ☏ ¢ 😼  21:20, 19 November 2023 (UTC)
  • Question: The proposal says it is limited to “by year” articles… but what about “by month” sub-articles (examples: April 1966 or October 1975)? After a quick glance, it seems these are currently consistently formatted with “Month Day”. Is it envisioned that we would have to reformat all of these sub-articles as well? Blueboar (talk) 12:54, 20 November 2023 (UTC)
    I would expect that to be a separate discussion. If the outcome of this discussion is that each article should be discussed individually and/or opposing any change at all then it seems unlikely that discussing month articles as a set will be worth anybody's time. Conversely if there is a strong consensus in favour of changing year articles to DMY then it will likely only require a short and simple discussion to determine if that also holds for month articles. Thryduulf (talk) 13:21, 20 November 2023 (UTC)
  • We used to have an option to choose date formats, which had some problems. Unfortunately instead of fixing these problems (by comparing to the options available at the Chinese Wikipedia, a fix seems feasible), the option was removed. In any case, I can't think of a reason to go against the wisdom of WP:DATEVAR in cases like this where the article topic does not have any clear WP:TIES. It is possible to work with both formats, and nothing breaks if different articles use a different format; this is a feature of Wikipedia's approach to national varieties of English, not a bug. —Kusma (talk) 14:07, 20 November 2023 (UTC)
    I think you may be referring to wikilinking dates to enable autoformatting of dates. This discussion is a good introduction to the topic. In my opinion, a major problem for that solution, and one of the reasons it was removed, is that it only worked if you were signed into an account and had chosen your default format in your preferences, and a date in an article had been wikilinked in a particular format. So, it did not help any reader/editor who was not signed into an account, or, if they were signed into an account. had not designated their preferred format in their preferences (namely, almost everyone using Wikipedia), and even then it didn't work if the date had not been correctly wikilinked in an article. The only way to make something like work for the general Wikipedia user would be to somehow pop up a window when the user first connected to Wikipedia, and ask them to chose which format they wanted dates to appear in. Even after making such a choice, it is likely that they would see some unformatted or incorrectly formatted dates that would not display in their chosen format. I think most of us will agree that whole process would be undesirable. Donald Albury 16:24, 20 November 2023 (UTC)
    Given how easy it is to switch (without logging in) between different varieties of Chinese (that sometimes use different words) on the Chinese Wikipedia, I believe that all of these problems can be solved. —Kusma (talk) 18:26, 20 November 2023 (UTC)
    That's not actually easy. It's almost a case of Any sufficiently advanced technology is indistinguishable from magic. WhatamIdoing (talk) 21:50, 21 November 2023 (UTC)
    I'm not expecting magic, I am thinking of something like suitable markup in the wikitext that makes it possible to display one of a finite set of options, just like on the Chinese Wikipedia. —Kusma (talk) 21:59, 21 November 2023 (UTC)
  • This pre-RfC discussion has gone stale, with no clear consensus on whether or not an RfC is appropriate for a question like this. Since participants of the RfC will be able to express within it that they view the whole exercise as pointless, or harmful, I think the best option here is to proceed. I'm giving it another 24h or so in case there's any final feedback, and unless there's something major I plan to start the RfC with the above options. Firefangledfeathers (talk / contribs) 17:48, 28 November 2023 (UTC)
    Hello Firefangledfeathers. After reading SMcCandlish's comment where he writes "A detailed comment I made at WT:MOS about all this is also pertinent here [5]", I think there should be absolutely no doubt that the discussion and RfC themselves are valid. I anyone please say read SMsCandlish's comment and tell why you still disagree (disagreeing with the proposal itself is a different issue).
    With the validity of the discussion and the ligitimacy of the village pump as venue for it, I was thinking reposting the proposal in a week or two as this current discussion has become messy and not largely not about the proposal itself. Marginataen (talk) 17:27, 29 November 2023 (UTC)
    I'm fine with waiting a week or two. Firefangledfeathers (talk / contribs) 01:37, 3 December 2023 (UTC)

Wikipedia yearly official releases (for example, as a Kiwix ZIM file)

Hello. I propose to publish Wikipedia yearly official releases, at least on the languages with greatest number of articles (I say yearly, but it could also be every 6 months, or every 2, 3 or even 5 years). In fact, there are currently periodic offline releases of Wikipedia in many (perhaps all?) languages: the current ones are all available here, while many of them are archived at Internet Archive, here (those who are not archived, are lost forever). But this is not known to most people, and they have no official status. I think it would be great if some of them were labelled as, for example "wikipedia_en_full_official_2023.zim", and linked from Wikipedia as the 2023 Wikipedia release. They could also be stored in Wikimedia Foundation servers (if money and resources allow for it, I don't know enough about it), and perhaps even deployed to also be viewed online, as it's possible with Nostalgia Wikipedia. But, as a minimal proposal, I suggest to give official edition status to a Wikipedia ZIM file in each language, yearly, and upload it to Internet Archive as such, while making it known through a link on Wikipedia website. When we want to take a look about the world (and worldview) in 1911, we take a look at Encyclopædia Britannica Eleventh Edition. Wikipedia is the equivalent of 21st century, but it is continually changing. In the future, when having a general look on the world of a year from 21st century, it would be very difficult to dive into thousands of article edits (including vandalisms and edit wars), and this for every article you want to look. Wikipedia isn't a primary nor a secondary source, but, as a tertiary source, as an encyclopedia (as the biggest encyclopedia in history, in fact), it allows a general look at the world that is not possible with any single primary or secondary source. It's almost done: those ZIM files are at kiwix.org and Internet Archive, all that is left is to give them official status. MGeog2022 (talk) 14:54, 3 December 2023 (UTC)

Proposal for change to copy of "has been changed" emails

Currently, the message sent to anyone who subscribes to edits on a page reads as below, emphasis mine:


There will be no other notifications in case of further activity unless

you visit this page while logged in. You could also reset the

notification flags for all your watched pages on your watchlist.


I propose it be changed to : You can also reset the

notification flags for all your watched pages on your watchlist.


Thoughts?


Dreameditsbrooklyn (talk) 01:08, 28 November 2023 (UTC)

Who can change this? Dreameditsbrooklyn (talk) 01:08, 29 November 2023 (UTC)
The text is in MediaWiki:Enotif body. Changing it should be done in the MediaWiki code, not locally at the English Wikipedia. You can ask at Wikipedia:Village pump (technical) for help filing the technical request on phab:
@Trizek (WMF), I suspect that one of the teams you deal with would normally triage such requests. WhatamIdoing (talk) 04:52, 30 November 2023 (UTC)
@WhatamIdoing Probably not one of mine, as it seems to be Mediawiki's code. Documenting it on Phabricator will be followed by a triage to the right team. Trizek_(WMF) (talk) 14:12, 30 November 2023 (UTC)
What is the point of this change? QuicoleJR (talk) 14:25, 6 December 2023 (UTC)

Change in format of film entries

> I would like to offer a change in format in the film entries on the site. > > I think that the Cast should be included prior to the Plot. That way > readers could see the cast of characters first (without having to page > down and then back up), which may help the plot section read easier. 155.190.20.5 (talk) 16:36, 5 December 2023 (UTC)

The current style-guide is Wikipedia:Manual of Style/Film, which notes "There is no defined order of the sections". It has been discussed occasionally at that page's talkpage and Wikipedia talk:WikiProject Film. Please make sure to check those previous discussions so you can see some previous counter-arguments. If this proposal here winds up getting any traction whatsoever, please make sure to alert both of those groups, so it does not look like trying to circumvent them. DMacks (talk) 16:54, 5 December 2023 (UTC)
A proposal to change WP:MOSFILM should be made at WT:MOSFILM, not a village pump. InfiniteNexus (talk) 01:30, 8 December 2023 (UTC)

Topicon for vital articles

There is a proposal to add a "topicon" (small icon in top right of window) to vital articles. Please comment at Wikipedia talk:Vital articles § Proposal for a VA "top icon" — Martin (MSGJ · talk) 19:23, 8 December 2023 (UTC)

"War on Fox" phrase

There is a RfC on the appropriate use of the phrase "War on Fox" in the Media Matters for America lead section. Comments welcome at Talk:Media_Matters_for_America#RfC:_Drop_Fox_campaign. -- GreenC 21:14, 8 December 2023 (UTC)

Scoring for Wikipedia type Articles Generated by LLM

Our research team of students are building a LLM-based system which can generate a full-length Wikipedia page for a given topic without the need for supplemental information (e.g., human written outlines, curated references, etc.). Besides automatic evaluation, we would like to have frequent wikipedia editors collaborate with scoring the articles and providing feedback. Due to GDPR rules we will be limiting participation to those in the USA. Our goal is only for educational research, and we are not intending to try to publish these LLM generated articles on Wikipedia. Our LLM will ideally generate Wikipedia style articles with citations, and different sub-points. We will be scoring the essay based on 1. Well Written, 2. Verifiable with no original research, 3. Broad in its coverage, and 4. Qualitative comments (The first three metrics for a Good Article + Qualitative comments). We would take a subset of our articles produced and score them by actual Wikipedia editors as a way to verify our scoring is within reason.

Please fill out this form if interested and we will send you a consent form in compliance with IRB standards. Link[2]

Below is our ethical statement.

In this work, we study the automatic Wikipedia generation problem as a way to push the frontier of automatic expository writing and automatic knowledge curation. All the studies and the evaluation in this work are designed to prevent the dissemination of misinformation by not publishing generated content online and implementing strict accuracy checks. We avoid any disruption to Wikipedia or related communities, as our system does not interact with live pages. Also, although we try to generate grounded articles, we believe there is no privacy issue related to this work as we only use information publicly available on the Internet.

The primary risk of our work is that the Wikipedia articles written by our system are grounded on information on the Internet which may contain some biased or discriminative contents. Currently, our system relies on the search engine to retrieve high-quality information but does not include any post-processing module. We believe improving the retrieval module to have good coverage of different viewpoints and adding a content sifting module to the current system will be a critical next step to achieve better neutrality and balance in the generated articles. In our experiment, we manually go through all the topics in the test set to ensure the topics themselves are not biased or discriminative.

Another limitation we see from an ethical point of view is that we only consider writing English Wikipedia articles in this work. Extending the current system to a multilingual setup is a meaningful direction for future work as there are more interesting topics that do not have their Wikipedia pages in non-English languages. Terribilis11 (talk) 01:19, 10 November 2023 (UTC)

Who is we? What will you be doing with participants’ personal data that would not be allowed by GDPR? Barnards.tar.gz (talk) 08:02, 10 November 2023 (UTC)
Based off of the google link above, "we" appears to be some team at Stanford. Some Stanford people have done work on LLMs and Wikipedia before (see: Wikichat). Should OP not respond, it may be worth reaching out to the WikiChat folks to figure out what the team is behind this/what the IRB approval looks like for this. — Red-tailed hawk (nest) 03:52, 12 November 2023 (UTC)
To be frank we aren't doing anything with participants' personal data. However, we just aren't familiar with the standards of GDPR and are choosing to avoid the issue as a whole. If there are many Wikipedia collaborates interested in participating in the EU we can evaluate the GDPR more closely to determine if we are in compliance. Terribilis11 (talk) 00:37, 14 November 2023 (UTC)
@Barnards.tar.gz @Red-tailed hawk Given feedback I have received, the large percentage of European editors, I believe we will be confirming compliance with GDPR shortly. Terribilis11 (talk) 00:48, 14 November 2023 (UTC)
Hello we are students at Stanford working on a research project. Terribilis11 (talk) 00:37, 14 November 2023 (UTC)
Oppose
If there is no current English Wikipedia policy that prevents such exploitation of this project, there should be. There is no consensus for use of LLM on this project for any purpose that changes content here. Your statement is a very poor introduction to Wikipedia. I oppose any such endeavor. — Neonorange (talk to Phil) (he, they) 18:09, 10 November 2023 (UTC) —
@Neonorange, could you expand on your objection a bit? The proposal states that none of the generated pseudo-articles will be published and "does not interact with live pages". Schazjmd (talk) 18:20, 10 November 2023 (UTC)
I oppose any use of LLM that might make it easier for any LLM generated material to appear in this project. This is a consensus project where all content is generated by volunteers. And where all error and vandalism are remedied by volunteers. I consider your project as injurious to Wikipedia and exploitative of our volunteers. Ethical and empathetic AI is still twenty years off. — Neonorange (talk to Phil) (he, they) 18:31, 10 November 2023 (UTC) —
They are free to create this large language model because there is a CC-BY-SA 4.0 license for content here. You may think of it however you like but they are allowed to do that.
Whether we use it depends on how well they do it. For now ChatGPT sucks to write Wikipedia, particularly if you are less experienced, but this may change later. Training LLMs on Wikipedia only is bound to fail because we've got so much crap here that sieving through it would probably take about as much time as fixing it.
I wonder what is the GDPR data they are talking of? Are you only going to deploy this tool for non-EU editors? Szmenderowiecki (talk) 20:25, 10 November 2023 (UTC)
@Neonorange, what's your overall view? "Nobody should do research on LLMs, because that 'might make it easier for any LLM generated material to appear in this project'"?
If you're concerned about them posting it, they already said we are not intending to try to publish these LLM generated articles on Wikipedia. I'm assuming you missed that, because otherwise your comments sound like you telling other people what they're allowed to do on their own computers and with their own time. WhatamIdoing (talk) 03:24, 12 November 2023 (UTC)
To reiterate we will not be posting this articles on wikipedia or any other website as a news soruce. Rather we are simply pursuing a model that produces models of similar quality to Wikipedia. We will be using our own scoring mechanism, but feel that to best determine the accuracy of our scoring we would like ot compare it with scoring by actual wikipedia editors. Terribilis11 (talk) 00:35, 14 November 2023 (UTC)
All of the LLMs are already trained on our content [3]. The main issues here are covered by SnowFire below: review of this AI output is unlikely to demonstrate that it doesn't hallucinate because that requires WP:FAC-level examination by subject-matter experts, and WP needs its volunteers to remain focused on doing this at FAC and WP:GAN, not helping some off-site AI project.  — SMcCandlish ☏ ¢ 😼  19:29, 20 November 2023 (UTC)
Hi @SMcCandlish We have found the feedback here to be very useful. As such we are going to be creating a UI that will have the article with in place citations. In addition clicking on a citation should bring up the website pointing to the exact location in article our model pulled from for the generation. We believe this will make it both efficient and more practical to determine what is hallucinated and what is supported.
Of course I hear your opinion on what volunteers should focus on, but we are of course going to honor their autonomy in this matter. Terribilis11 (talk) 08:30, 21 November 2023 (UTC)
You should probably read WP:LLM before going any further. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:48, 10 November 2023 (UTC)
Thank you for the suggestion. Terribilis11 (talk) 00:49, 14 November 2023 (UTC)
To clarify, that page is an WP:ESSAY and does not reflect community consensus - in fact, a proposal to elevate it to policy status was explicitly rejected by the community just recently. That said, it is probably prudent to stick with your plan of not posting these LLM-generated articles on Wikipedia (at least not in the mainspace, i.e. as actual articles). Regards, HaeB (talk) 03:14, 14 November 2023 (UTC)
  • The fundamental problem here is that it is usually easier and quicker (and certainly more enjoyable) to write an article from scratch than to carefully review one created by anyone whose competence is questioned, such as an AI. Espresso Addict (talk) 00:45, 11 November 2023 (UTC)
    Yup. @Terribilis11, it can take hours to review a single article under the Wikipedia:Good article criteria. For some articles, it can take 30 minutes just to read it – and that's without doing things like figuring out whether the sources exist, are reliable, and WP:Directly support the content they've been associated with. You should probably be budgeting for one or two hours per article. WhatamIdoing (talk) 03:48, 12 November 2023 (UTC)
    Okay, this is valuable feedback! I will take this back to the team. Terribilis11 (talk) 00:42, 14 November 2023 (UTC)
    This is my main concern, too. I'm happy to review an article written from the three best sources, but if one of the metrics is 'broad in its coverage' does that mean the project will attempt to exhaust the sources and could end up with twenty or eighty or more, some of which may include multiple pages in books? Valereee (talk) 14:05, 12 November 2023 (UTC)
    Thank you very much for this input! This is great feedback. We will take this into account. In general most citations will be web-based. Regardless, I will take this input back to our team. Terribilis11 (talk) 00:41, 14 November 2023 (UTC)
@Terribilis11: As a general practice, it is recommended to start a documentation page for your research project at meta:Research:Projects. No need to get super detailed or fill out every field in the "add your project" form - you can probably mostly reuse the text from your message(s) above. That page can then also serve as a reference point later, instead of the post and discussion here which will get archived soon. Good luck with the project, and once you publish something about it (even if in preprint form), feel free to ping me and my @wikiresearch collaborators, we would be happy to help publicize it. (E.g. here is our coverage of the "WikiChat" effort mentioned above, which made it to the front page of Hacker News.) Regards, HaeB (talk) 03:24, 14 November 2023 (UTC)
  • Comment. score them by actual Wikipedia editors - I would caution accepting just any volunteers. You can get some baseline feedback on 1, 3, and 4, but 2 ("Verifiable with no original research") requires either subject matter experts or somebody with the time who's willing to dive into all the citations and verify them. The worst outcome - and by far the scariest one for LLMs - is output that looks right but is in fact wrong, and "casual" volunteers giving a 5-minute skim will miss these cases. And I can assure you that editor time for that sort of a deep-dive is quite limited - it's hard enough getting people to do a citation-by-citation level verification at places like WP:FAC, and there at least the work will have "meant" something. IMO, any volunteer willing to do such deep, untrusting, total verification for a machine-generated article should probably spend that kind of valuable time over at WP:GAN instead. Basically, if you really want to verify #2, I suspect that actually paying vetted researchers for their time may be a better option. This is especially true if it turns out that your LLM really is an improvement - saying a LLM doesn't hallucinate falsehoods is cheap, but verifying it is very hard. SnowFire (talk) 23:12, 17 November 2023 (UTC)
    @SnowFire Thanks for the feedback. You make some great points on the dangers of LLMs. We are part of Stanford's Open Virtual Assistant Lab [4] which is focused primarily on the grounding of LLMs. i.e. eliminating hallucination. We feel for the scale of our current project, Wikipedia editors are the best option available, although you are right that finding topic specific experts would be ideal, this would unfortunately be an intractable challenge for a model that should be functional in a wide variety of topics. If you have more thoughts, it could be helpful to checkout our research page, we recently created due to suggestions in this thread. [5] Terribilis11 (talk) 09:36, 21 November 2023 (UTC)
    @Terribilis11: Thanks for the reply. To be clear, and I hope this doesn't come across as nitpicky, but my post wasn't about "the dangers of LLMs", which I'm sure we're both familiar with. Rather, it was a post about how difficult and expensive it is to detect hallucinations, especially subtle ones. Imagine a disease that sometimes results in obvious symptoms, but sometimes is subtle and hard to detect without a trained doctor who knows what to look for, or a nurse with a lot of time on their hands. Now imagine a paper is released saying that a special new treatment reduces the disease 50%, but with evidence being random volunteers who looked over patients for an unknown amount of time. This won't be convincing, except that it perhaps reduced the overt cases of the disease by 50%. It's even more dangerous if you use the feedback to help guide the model adjustments - you might be being mislead by adjustments that just make hallucinations more subtle.
    If there isn't budget to hire Real Experts to check, I would humbly suggest to have your model generate text on topics that people on the project itself know very well, and that way you can perhaps self-verify in the "middle" of your experiment, and save the budget for a few independent verifications at the end. SnowFire (talk) 20:54, 21 November 2023 (UTC)
    You're absolutely right the problem of hallucination is quite difficult. I imagine that's why there are already dedicated companies for the same issue when checking politician's statements. We are taking a very structured approach and are giving it our full attention. Thank you for the suggestion. Terribilis11 (talk) 03:46, 24 November 2023 (UTC)
    Wikipedia editors often suck at this too, frankly. It requires multiple passes to get it right, and is then messed up again as content is added and shifted around by the same editors who don't check content against existing citations.
    And based on the poor success rate of my spot checks, I echo previous posts about the difficulty of detecting hallucinations will be that, if an AI is trained primarily on WP, then unverifiable content in one's results will comparable likely (or much much more) from accurate an interpretation of WP than from hallucinations. SamuelRiv (talk) 22:03, 9 December 2023 (UTC)
  • What SnowFire said. All of it.  — SMcCandlish ☏ ¢ 😼  19:29, 20 November 2023 (UTC)
    My bad-science alarm has gone off. This project needs to decide whether the intent is to create a LLM that writes accurately and reliably in the style of Wikipedia, or whether it's to create a LLM that writes articles that will pass AfC. These are totally different aims. Wikipedia defines itself as an unreliable source because we do not believe our editors get it right all the time. Therefore if you want to design a LLM that is accurate you cannot use Wikipedian volunteers, as they are, by definition, no more accurate than Wikipedia itself. If you want to create a LLM that passes AfC then using Wikipedians is a more reasonable choice, but you need to make sure your volunteers are an accurate match to those at AfC. Vast numbers of articles written by Wikipedia volunteers are rejected at AfC, so you might not want those volunteers to be assessing the products of your model! Do you have a strategy to select volunteers to match AfC? On accuracy, you should also be thinking that Wikipedia's accuracy (or not) stems not only from a careful review by an AfC person, but from the fact that articles are typically read by huge numbers of people, including subject experts, from across the globe. There is no guarantee that a panel of even 50 selected volunteer Wikipedians will give the same accuracy as this panel of an unknown number of casual readers, many with prior, in-depth knowledge. I'm not saying that LLM's can't write accurate articles, or write AfC-passing articles, but I'm saying there are lots of reasons why a model trained by Wikipedian volunteers might end up doing neither. Elemimele (talk) 17:32, 28 November 2023 (UTC)
    It sounds like they are trying to build an LLM that could pass GA. WhatamIdoing (talk) 05:46, 3 December 2023 (UTC)
    @Elemimele We want to design a LLM that is as accurate as Wikipedia, because as you pointed out accuracy is a very complicated metric. It is also not with out disagreement on what is and isn't accurate, we need merely look at American politics which frequently argue over "fact". As such, our research hopes to make clear the limitations of our results. They are verified by our own metrics as well as Wikipedians. Our model isn't being trained by Wikipedian volunteers, rather the results of our model's scoring will be compared to the Wikipedian volunteers scoring. This will give a frame of reference to the results of our model. We aren't going to be making unwarranted claims of complete accuracy as that would certainly be bad-science. Our results will be in terms of our own coring and the Wikipedians, to hopefully give an idea of what level of verifiability and hallucination our model is demonstrating. Obviously if we were able to tap into the hundreds of experts that edit Wikipedia articles to give us hope of high accuracy, we would love to do that. This is unfortunately not feasible in this case. Terribilis11 (talk) 23:07, 3 December 2023 (UTC)
I'm all for this. Sign me up. If we can get an LLM to provide accurate and reliably sourced draft content that can serve as the basis for accurate articles (which, I believe, we will eventually be able to do), that's a good thing for the dissemination of knowledge. BD2412 T 04:07, 10 December 2023 (UTC)
I'm in the UK so I'm not sure if your GDPR qualms would apply. Anyway, I have an idea which might eliminate the need for volunteer effort. You're want to test your model's scoring of article quality, right? So why don't you use your model to score the quality of existing Wikipedia articles? You can then compare your model's quality rating with the ratings of article quality which are usually found on each article's talk page. As these already exist, no additional volunteer effort would be required.
Having caluculated ratings for lots of Wikipedia articles you might then record these ratings and comparisons somwehere as they may be useful to us in highlighting significant differences and discrepancies.
Andrew🐉(talk) 16:26, 10 December 2023 (UTC)

Make Infobox data searchable

Pages that use Infobox Templates should be searchable. For example, one should be able to see all books written by a given author without needing to create a "list of books written by [author]" page. Or "Software using MIT license." Currently much work is duplicated in "List of [attribute]" pages which frequently fall out of date and which creates the question of which attributes should be compiled into lists and which entries are notable enough to be in those list. I am not proposing to remove list pages but there should also be a way to search data in Infobox templates on demand. Or, at the very least, to ensure that the List is up to date.

Background

There was a related issue regarding unifying the Wikipedia Infoboxes with Wikidata, which can be searched via SPARQL. This was discussed most recently (to my knowledge) in 2018:

There is a consensus that data drawn for Wikidata might be acceptable for use in Wikipedia if Wikipedians can be assured that the data is accurate, and preferably meets Wikipedia rules of reliability. For the other issues raised within this RfC, there was no clear consensus.

It is unclear what became of this vague decision. I have tried to find information about which templates are using Wikidata. There is alist of templates using Wikidata but this same list says that thousands of pages are still using "locally defined parameters" rather than Wikidata parameters. It seems that pages that use local template parameters do not necessarily exist in Wikidata and therefore cannot be returned by Wikidata SPARQL, although I have yet to verify this.

In any event, that discussion was about having Wikipedia Infoboxes be updated by Wikidata. I am interested in having Wikidata be updated by Wikipedia Infoboxes. Being that the main concern in 2018 was that Wikidata is more prone to vandalism, by the same token, there should be no issue updating Wikidata using Wikipedia Infobox data where it exists.

There is also DBpedia which can return data from Infoboxes but it is only updated every three months and it's live endpoint has seemingly been down for almost a year.

Proposal

What I would like to see in this proposal is a way to search Infobox data. I would also like to see documentation regarding the relation between Wikidata and Wikipedia Infoboxes in light of the previous discussions. Specifically, I would like for it to be made clear whether Infobox data automatically updates the corresponding Wikidata entries. 65.242.132.98 (talk) 01:01, 11 December 2023 (UTC)

  • Strongly oppose anything that would mandate using Wikidata-derived infoboxes in Wikipedia articles. There is enough contention about infoboxes where all the fields are filled locally. If someone wants to get a data dump out of Wikidata that's absolutely fine, but it's nothing to do with Wikipedia. Espresso Addict (talk) 01:27, 11 December 2023 (UTC)
    Yes, I think that was basically the consensus from the 2018 RfC, despite it's vagueness. I am not proposing that. 172.58.229.191 (talk) 01:43, 11 December 2023 (UTC)
The relationship right now is mostly that Wikidata scrapes infoboxes among other sources for information, so I think usually some automated or semi-automated editing will pick up infobox updates to Wikidata, so you should generally be able to use Wikidata to do the queries you want. This seems like more of a discussion for Wikidata than here if you want them to update data from our infoboxes more. Galobtter (talk) 01:33, 11 December 2023 (UTC)
Thanks, I will take a look. The Wikidata/Wikipedia split is part of what makes this a difficult problem. I have added a post there65.242.132.98 (talk) 01:45, 11 December 2023 (UTC)
You can use the Harvest Templates tool to export Wikipedia template data to Wikidata pretty easily. — Qwerfjkltalk 07:19, 11 December 2023 (UTC)

WP:ECR

Hi, while WP:ECR has recently been amended to specifically restrict interactions of non-ECP users on protected talk pages, pages such as WP:GS/RUSUKR have not been amended to reflect this change. Is there a process for these pages to be updated? Cinderella157 (talk) 05:43, 3 December 2023 (UTC)

WP:RFPP works. I personally wouldn't do this systematically, because I think ECR is way too broad, but that isn't the policy. Mach61 (talk) 05:59, 3 December 2023 (UTC)
I see you're talking about the information pages. In that case, just copy the current ECR text in yourself. Mach61 (talk) 06:00, 3 December 2023 (UTC)
...no, please don't. The information page documents a community consensus that was not changed by ArbCom. ~ ToBeFree (talk) 12:35, 3 December 2023 (UTC)
Hi Cinderella157, you are on the right page!

Requests for amendments, clarification, or revocation (if sanctions are no longer required) should also be discussed at VPR, following a notice at AN.[Reference: September 2023 RfC.]
— Wikipedia:General sanctions § Community sanctions

You have also already created a notice at Wikipedia:Administrators' noticeboard § Wikipedia:Village pump (proposals)#WP:ECR. Perfect. I think the only thing missing now is an actual proposal rather than a question about process. 🙂 ~ ToBeFree (talk) 12:46, 3 December 2023 (UTC)
ToBeFree, WP:ECR has been amended. The text of WP:ECR is part of WP:GS/RUSUKR (and other general sanctions). It would seem to me that as a matter of course, when WP:ECR is amended, then where ever it is currently invoked and cited should be amended too (much like a substituted template). This was an enquiry, because I see (surprisingly) that this is not the case. However, one could also consider it a proposal. Cinderella157 (talk) 13:09, 3 December 2023 (UTC)
The text at WP:GS/RUSUKR is taken from the RfC that led to it, and that exact wording is what the community agreed upon. The Arbitration Committee can't modify this decision by itself. ~ ToBeFree (talk) 15:13, 3 December 2023 (UTC)
This conversation needs to happen no matter which way we land. Our GS pages frequently reference and link WP:ECR, so we should either update to match the new ECR text or de-link ArbCom's version of the restriction. I had already done the latter for two EC restricted topic areas, WP:GS/KURD and WP:GS/AA.
I can repeat this in an RfC later if we get to one, but I'd rather the community did not adopt ArbCom's version of ECR. Even in the Arab-Israel topic area, which is obviously super contentious right now, the severe restriction on IP talk page participation seems like too much to me. For the community GS topics, none of which are (to my knowledge) quite so hot right now, I think we'd be burning down a lot of good houses for fear of a few spiders getting in. Firefangledfeathers (talk / contribs) 20:11, 3 December 2023 (UTC)
The community came to a consensus to use the definition of ECR that was available at the time of the discussion. Subsequent changes to ECR by ArbCom can't be retroactively re-written into the community sanctions without a consensus in favor of that (or unless ArbCom assumes the community sanctions, which they have not in this case). Along those lines, I'd support substituting the old text into the existing community sanctions (or creating a forked page that has the old text) until/unless there is such a time that the community wants to impose the extremely broad restriction that is the new ECR restriction. — Red-tailed hawk (nest) 15:14, 5 December 2023 (UTC)
I think that all the community GS areas have the full text of the ECR they adopted written out. I've de-linked WP:ARBECR from as many places as I'm aware of it existing. These were bold moves on my part, and I'd definitely self-revert on request, but we had to work our way out of the contradiction somehow and this was the more conservative option. Firefangledfeathers (talk / contribs) 03:14, 12 December 2023 (UTC)

RfC for LLM policy

See Wikipedia talk:Large language model policy. jp×g🗯️ 22:23, 13 December 2023 (UTC)

Dark Mode Toggle Option

While in a late night deep dive, having an option to switch between a white background w/ black text to a black background with white text would help with eye strain. This also opens up the accessibility door for other types of visual contrast aids. 2600:1702:4CAC:2310:6D0C:8D45:E269:A27E (talk) 05:29, 17 December 2023 (UTC)

If you create an account and log-in, I'm pretty sure they're beta testing one now. Also, there are some scripts and gadgets that will enable a night mode, but again you need to be logged in. I will say it's a frequent request/suggestion. ~ ONUnicorn(Talk|Contribs)problem solving 05:47, 17 December 2023 (UTC)
You may like to consider a method which works not just on Wikipedia but on other sites too. I use the Dark Reader add-on for Firefox; several alternatives are also available. Certes (talk) 10:47, 17 December 2023 (UTC)
See mw:Reading/Web/Accessibility for reading for the dark mode being developed by WMF right now. It's months away at earliest and likely going to be available only on Vector 2022. Nardog (talk) 21:03, 17 December 2023 (UTC)

Article edit frequency charts

I just thought it would be nice if articles had a bar chart with edits vs time. This would allow one to assess the article's activity/stability/maturity. eg, if citing one, it's probably best to avoid a time when the article is receiving a particularly high amount of edits, which would suggest unfinished or contested content. uKER (talk) 02:29, 20 December 2023 (UTC)

User:UKER, there is such a thing, available from the link "Revision history statistics" from the External tools section at the bottom of Special:PageInfo. See example (you'll have to scroll down a ways, and it may not be as granular as you're seeking.) Folly Mox (talk) 04:18, 20 December 2023 (UTC)
The same statistics, including graphs, are available as "Page statistics" in the External tools section at the top of the revision history page. Thryduulf (talk) 09:45, 20 December 2023 (UTC)
Yeah, I was thinking something like the link that Folly Mox posted, but much more accessible and simple. Just one value of edits per week/month (switchable?), in a horizontal bar chart. Regular users do not know about External Tools and I think the info would be valuable. --uKER (talk) 16:28, 21 December 2023 (UTC)

Infobox of composers

I just noticed that in the infobox of composers it's not possible to write whom the composer was influenced by and whom they influenced. Is this not a serious lack? Is there a way to add this option that I'm not aware of? The Death of the Author (talk) 12:29, 20 December 2023 (UTC)

User:The Death of the Author parameters like |influenced= and |influened_by= have been gradually deprecated across most if not all of the infobox templates that used to include them, because they attracted unsourced trivia.
If you have a reliable source indicating that an article subject influenced or was influenced by another figure who has a Wikipedia article, you can put the information in the article prose somewhere. If it doesn't seem like there's an appropriate spot to put it, it might not be important enough to include in the article, but you can always bring it up on the article Talk: page to solicit the input of other interested editors. Folly Mox (talk) 13:00, 20 December 2023 (UTC)
I'm not super familiar with the actual history here and my search terms have been pretty inaccurate. The primary discussion to deprecate the parameters from {{infobox person}} was a decade ago at Template talk:Infobox person/Archive 19 § RfC: Should the "influences" & "influenced" parameters be removed? A more recent discussion (2023) is at Template talk:Infobox philosopher § Influences/influenced. Folly Mox (talk) 13:24, 20 December 2023 (UTC)
Thanks for the explanation:)! The Death of the Author (talk) 17:52, 20 December 2023 (UTC)

Add Political Affiliation

Closing, no need for more pile-on. (non-admin closure) Curbon7 (talk) 00:19, 26 December 2023 (UTC)

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.


Add "Political Affiliation" to Wikipedia live person pages TEXASFOUR (talk) 10:31, 25 December 2023 (UTC)

Nah… in most cases, a person’s political affiliation is not relevant (or even known). Blueboar (talk) 12:53, 25 December 2023 (UTC)
Not for the infobox - even where a person's political position is significant, it will often change during their life and/or not easily map onto a single political party or movement. This sort of thing is far too nuanced to be presented in the simplified summary of the infobox. It would also be a magnet for unsourced changes and edit warring.Nigel Ish (talk) 13:04, 25 December 2023 (UTC)
Why? 🎄Cremastra 🎄 (talk) 22:31, 25 December 2023 (UTC)
Nope. For most people it's irrelevant; and where it is relevant - e.g. elected officeholders - they will be using a different infobox which does permit the political party to be shown. For example, Joe Biden has {{Infobox officeholder}} with |party=[[Democratic Party (United States)|Democratic]] (since 1969) and |otherparty=[[Independent politician|Independent]] (before 1969). For Joe Swash - who cares? --Redrose64 🦌 (talk) 23:37, 25 December 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Saberov Ruslan Yuryevich

User:KubanaTatar/sandbox Please view and approve the restoration KubanaTatar (talk) 01:39, 27 December 2023 (UTC)

No. Wikipedia:Articles for deletion/Saberov Ruslan Yuryevich. nAndyTheGrump (talk) 01:54, 27 December 2023 (UTC)

Please see and participate in this new discussion. Ed [talk] [OMT] 04:27, 28 December 2023 (UTC)

RfC about the criteria for existence of emoji redirects (2nd)

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?

Note that the discussion only pertains to emojis that do not have their own pages (as in 😂 which links to Face with Tears of Joy emoji), in which case the redirect consensus is clear in that it should direct to the article. microbiologyMarcus (petri dish•growths) 17:43, 16 November 2023 (UTC)

Please see Wikipedia:Requests for comment/Emoji redirects. I've split this off to its own page because it has more than 100 comments and the page overall is too large for some editors (e.g., on mobile devices or with slower internet connections) to participate easily. Please see over there. WhatamIdoing (talk) 02:40, 30 November 2023 (UTC)
Noting I've closed this. -- Tamzin[cetacean needed] (they|xe|she) 07:23, 28 December 2023 (UTC)

Proposal for general change at WP:AFDHOWTO

About a week ago I got into a discussion at Wikipedia talk:Articles for deletion regarding IP editors such as myself making AfD nominations. Long story short, several ppl there falsely claimed I could've completed the nomination myself despite being an IP user, and they got onto my case for going to the talk page and requesting logged in users complete the nomination process, even tho WP:AFDHOWTO says to do exactly that.

This culminated in one of these users suggesting that the quoted text be changed to encourage ppl to create an account. ("Less work for us / teach people to fish... etc.") Should this change be made, or should the text be left as-is? 100.7.34.111 (talk) 18:51, 26 December 2023 (UTC)

I see no reason for this to be part of AFDHOWTO. There doesn't seem to be any reason to restrict AFD creation from unregistered users. If you think the AFD nomination will improve the encyclopedia, see WP:IAR, and just make the nomination, regardless of whether some bureaucratic nonsense on the AFD page says not to. EggRoll97 (talk) 04:51, 27 December 2023 (UTC)
@EggRoll97: You're missing the point, which is that IPs and other non-confirmed users cannot create pages in Wikipedia: namespace, an action that is central to WP:AFDHOWTO step II, even if they wanted to. It's not rules, or bureaucracy: it's a software limitation. --Redrose64 🦌 (talk) 08:33, 27 December 2023 (UTC)
Pedantically, the bar on non-(A)C accounts is a rule, but the fact that we can't make an exception for AfD is a software limitation. (We could lift the MW-level restriction and then filter more selectively by edit filter, but that would add a lot of headaches for a limited benefit.) Anyways, this particular limitation at AfD is why I created an account 11 years ago, so maybe it does some good (or bad, depending on one's opinion of me). -- Tamzin[cetacean needed] (they|xe|she) 08:52, 27 December 2023 (UTC)
Alternatively, we could go the exact opposite route and create something like the redirect wizard for AfD, which would automatically create pages via bot. Mach61 (talk) 13:52, 28 December 2023 (UTC)
There used to be bots that did this. My own was the first; I stopped because I got sick of people screaming at me for "letting bots automatically afd pages", even though I did curate the list. The most recent I'm aware of was User:DumbBOT, though judging from the User:DumbBOT/IncompleteAfD list linked from its userpage, it hasn't done so for more than a decade. —Cryptic 00:11, 29 December 2023 (UTC)

Set index articles

Happy new year everyone! Please see Wikipedia talk:Content assessment#Request for comment. I am trying to get consensus on what an SIA is and whether they are a useful classification of article on Wikipedia. Please comment there. — Martin (MSGJ · talk) 17:58, 1 January 2024 (UTC)

I’d like to find consensus to change the wording of {{R avoided double redirect}} as follows:

−
This is a redirect from an alternative title for (redirect page name), another redirect to the same title.
+
This is a redirect from an alternative title or related topic of (redirect page name), another redirect to the same article.

This stems from a discussion at User talk:Aaron Liu/Archive 1#The Mind Electric with @Richhoncho concerning the redirect The Mind Electric, which is a good example to illustrate why we should do this. That redirect, a song name, was originally a redirect to its album’s article, which was replaced with a redirect to the artist. As the song is not an alternative title for the album, the current wording does not make it clear whether this is allowed.

Why should such redirects be tagged with A2R? Well, A2R was created for the purposes of “grouping” article redirects and automatically fixing 2Rs when their supposed target becomes an article.An A2R to a related topic satisfies both of the above, and letting it remain does no harm. However, removing it does, as the redirect will no longer automatically update if the related topic is created as an article. Aaron Liu (talk) 15:38, 5 January 2024 (UTC)

Makes sense to me. Any case where A really should redirect to B but it can't because B itself is a redirect seems valid for {{R avoided double redirect}}. Anomie⚔ 00:11, 6 January 2024 (UTC)
So let's simplify the question. Artist, Album, Song. If album is removed does the song cease to be an artist song. That is what the OP is arguing, which is plain nonsense. Richhoncho (talk) 00:48, 6 January 2024 (UTC)
How? I don't even know what you mean by "cease to be an artist song". We all agree (or at least consensus does) that when the album article for a song appears, the song should then redirect to the album instead. So why not add the tag which would help automatically do that in that event? Aaron Liu (talk) 00:55, 6 January 2024 (UTC)
Your failure to understand the purpose of A2R is self-evident. Your inability to understand the difference between song and album is also self-evident. Your inability to bring this discussion to appropriate place beggars belief. It is time to stop wasting everybody's time over one redirect because you got it wrong, goodnight. Richhoncho (talk) 01:17, 6 January 2024 (UTC)
I really don't understand what you're trying to do now. You operate under the unfounded assumption that A2R can only be used for alternative titles of the same thing, tell me to get "substantial support" for what I think about A2R, thank me for creating this thread at VPR, accuse me of more things in lieu of argument and then chastise me for creating this thread at VPR. Aaron Liu (talk) 01:33, 6 January 2024 (UTC)
Wikipedians can be so confidently wrong, hey. J947 ‡ edits 03:21, 6 January 2024 (UTC)
Makes sense. But from my experience I do think the whole {{R avoided double redirect}} template text could do with a rework for clarity: all we want to express is "this redirect is dependent on this other redirect, and the dependent redirect's target should sync with the other redirect", correct? J947 ‡ edits 03:21, 6 January 2024 (UTC)
Seems like it, but at the same time I can't think of any other cases than alternative names and related topics. Aaron Liu (talk) 03:28, 6 January 2024 (UTC)
Looks good to me. — Frostly (talk) 10:24, 6 January 2024 (UTC)
OK. That's enough misinformation. Let's pare this discussion back to the basics and the redirect it relates to, read what has been said and see if we can all understand it.
The redirect has 2 tags, the first is R from song which reads, This is a redirect from a song title to a more general, relevant article such as an album, film or artist where the song is mentioned. This entry is not in contention, but does confirm that the redirect can be to a more general article. The OP then wants to add A2R stating that The Mind Electric is an an alternative name for the album Hawaii: Part II, because it does not have it its own article.
This gives us 3, and probably more, inconsistencies.
  1. It assumes that songs articles cannot exist without supporting album articles (some song articles exist without album or artist).
  2. That song articles should not be pointed to the artist without a specific note of the instance.
  3. And, returning to the original point, in which universe is The Mind Electric (a song) an alternative name for Hawaii:Part II (an album it has appeared on)?
Finally, is Village Pump the correct place for this discussion? --Richhoncho (talk) 15:02, 6 January 2024 (UTC)
I think you may need to step back and reexamine your assumptions here. #1 and #2 you are overgeneralizing. Just because this one song is marked as being intended as a redirect to the album (but then redirects to the artist because there is no album article either) doesn't mean that every song "cannot exist without supporting album articles" or that no song ever could skip an album redirect. But chances are the exceptions prove the rule. Your assertion #3 is outdated, as the template now says "or related topic", and the album a song appears on certainly is a related topic in most cases. Anomie⚔ 15:33, 6 January 2024 (UTC)
My point entirely. I was paraphrasing the OP's opinion. Richhoncho (talk) 17:02, 6 January 2024 (UTC)
Your points argue against tagging the redirect as A2R, while everybody else here including me and Anomie think that it's fine to tag the redirect as A2R. I don't see how you were just paraphrasing my opinion. Aaron Liu (talk) 17:21, 6 January 2024 (UTC)
Note that this is now  Done, though the last word remains "title" instead of "article" as this tag is also used on non-articles. Aaron Liu (talk) 17:22, 6 January 2024 (UTC)

Flag icons for sports men and women should show the country they represent in sport if it is a page related to international events, if not (eg. pages relating to club sport and club teams) the flag icon should show their actual nationality/nationalities

Examples: John Aldridge is an english footballer who chose to play for the Republic of Ireland in international football. Meanwhile John Barnes played football for England but is also a dual-national Jamaican. Firestar47 (talk) 22:56, 5 January 2024 (UTC)

  • Support This goes beyond flag icons. Multi-national athletes are becoming more common, and should be listed against the country they are actually representing at a particular event, even though this may mean different nations for the same athlete on different pages. It will also stop arguments over what nationality someone is (which often they don't even know themselves). Hawkeye7 (discuss) 23:07, 5 January 2024 (UTC)
  • Oppose. MOS:SPORTFLAG does a good job capturing the appropriate use of flag icons attached to a person's name. Flag icons should not be used to represent an individual's country of citizenship, country of birth, nationality, ethnicity, or any other combining parameter. Then they become debatable, changeable, and potentially confusing. Also flag templates are wasteful of memory, and flags are annoying and give undue prominence to nation states in a world where such divisions already causes enough problems without importing them to unrelated matters. Folly Mox (talk) 14:41, 7 January 2024 (UTC)

Third RfC on Vector 2022

Æo (talk) 20:56, 9 January 2024 (UTC)

Improve archiving of pages with level two discussions sitting under level-one headers used as ToC dividers

 Courtesy link: User talk:Σ/Archive/2024/February § Archiving in the context of a page that uses level-one headings as dividers
 Related info: User_talk:Scsbot § Hasty_archiving

Please see this discussion for a proposal to enable archiving of discussions at pages like WP:Help desk that have level-one headings to group discussions by date in the Table of Contents. Afaict, Help desk archiving currently happens N days after the *first* message of the day was posted, regardless of how recent the last message was. Mathglot (talk) 00:25, 10 January 2024 (UTC)

RfC: disallowing new signatures obsolete tags

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is clear consensus in favor of the proposal. Any remaining technical questions can be worked out during implementation. (non-admin closure) {{u|Sdkb}} talk 20:40, 24 December 2023 (UTC)

Should MediaWiki's built-in signature validation disallow new signatures with obsolete-tag lint errors to be set in a user's preferences? HouseBlastertalk 01:10, 3 December 2023 (UTC)

Background/details (disallowing new signatures obsolete tags)

In 2020, as part of the DiscussionTools project, signature validation was added to MediaWiki. Since its implementation, users have been unable to save an invalid signature in Special:Preferences (invalid signatures saved beforehand are still allowed). Currently, the validator disallows every WP:LINT error except for obsolete-tags. (The most commonly used obsolete tag is <font>...</font>, but <tt>...</tt>, <center>...</center>, and <strike>...</strike> are also obsolete.) This proposal would eliminate that exception. Pre-existing signatures would not be affected by this proposal.

Survey (disallowing new signatures obsolete tags)

Discussion (disallowing new signatures obsolete tags)

@HouseBlaster: Please add a couple more words to the RFC question. It could be read as preventing me from changing my signature to one that has an obsolete-tag lint error, or it could be read as preventing a current user who has an obsolete-tag lint error from signing a new comment. I know the background explains that, but a word or two more might help. Johnuniq (talk) 01:16, 3 December 2023 (UTC)

  • That's been done by Alexis Jazz, thank you! HouseBlastertalk 21:56, 3 December 2023 (UTC)
  • HouseBlaster, I thought I removed the excessive substs in my signature? What's going on? — Davest3r08 >:) (talk) 01:19, 3 December 2023 (UTC)
    I just pinged you because you participated in the earlier discussion; this change would not impact you at all. HouseBlastertalk 21:56, 3 December 2023 (UTC)
  • HouseBlaster, I thought Q1 was going to go first, did I miss it? — Alexis Jazz (talk or ping me) 01:21, 3 December 2023 (UTC)
    Oops. Mentally I had this one going first... my bad. I think this order is better because this one does not require mass messages (because it only impacts people in the future). That brings two benefits: one, we only have to generate a list/write a message/etc. once. Two, people whose signature are both invalid under the current criteria and contain <font>...</font> tags would not be double mass-messaged. HouseBlastertalk 21:56, 3 December 2023 (UTC)
  • FRS recipient: My main question is how exactly would that work? If someone included <tt>...</tt> in their signature, would they just get an error message, or would it prompt them to replace the tag with {{mono|}}? Seeing as this could be one of the earliest things someone does after creating an account, we absolutely do not want to make them dive into the wikipedia help documentation to track down accomplishing their preferred signature, especially if they see existing accounts' signatures still using the deprecated functionality before they've been fixed by bot. VanIsaac, GHTV contWpWS 03:10, 3 December 2023 (UTC)
    I see nothing wrong with shoving headlong into formatting syntax documentation any newcomers whose first orders of business on the website include fancy sig customisation. Folly Mox (talk) 04:19, 3 December 2023 (UTC)
    The issue is when syntax that a new editor sees working for someone else won't work for them. The deprecated html tags work just fine when they make a comment, but for some reason there is an exception when it comes to their signature, but not anyone else's. That's a distinctly WP:BITEY behavior for the interface. VanIsaac, GHTV contWpWS 08:27, 3 December 2023 (UTC)
    Aren't bots already fixing such signatures with deprecated tags? Aaron Liu (talk) 16:03, 3 December 2023 (UTC)
    @Vanisaac, if you have a disallowed sig (and this RFC proposes to expand what's considered disallowed by software), and you leave a note on the talk page, it will just use the normal, default sig (e.g., like mine, like Folly Mox's, like Johnuniq's). It won't bother you about it; it'll just ignore your disallowed sig and quietly substitute the default.
    If you notice it and try to update your prefs, it will not let you save an improper custom sig. It will give you an error message then. Consequently, one approach is that you just try to fix it until you hit upon something that the system will accept. If solving it by the trial-and-error method seems unappealing, then the editor can ask for help. Most people do this at Wikipedia talk:Signatures or Wikipedia:Village pump (technical) or a friend's page.
    (Wikipedia:Signatures#Guidelines and policies prohibits the use of templates, including Template:Mono.) WhatamIdoing (talk) 06:02, 3 December 2023 (UTC)
    So that seems like the most unhelpful functionality imaginable. VanIsaac, GHTV contWpWS 08:27, 3 December 2023 (UTC)
    Why? The options are:
    • Don't restrict anything in software, or
    • Restrict invalid sigs in software, and if you happen to have an invalid sig, then prevent you from using talk pages until you fix it (e.g., throw an error message after you have already typed a comment), or
    • Restrict invalid sigs in software, and if you happen to have an invalid sig, then keep letting you use talk pages with a known-valid sig.
    Interfering with normal use of the wikis until you debug your sig would be my candidate for a "worst approach" prize.
    As Alexis Jazz corrects below, the first step is to stop people from adding new invalid sigs to their prefs. We could stay in that state for years. WhatamIdoing (talk) 20:18, 3 December 2023 (UTC)
    No, the options actually are:
    • Do nothing.
    • Restrict new non-standard sigs, but provide instant feedback on what the problem is and a direct link to a tool tip or the section on the help page that shows you how to accomplish what you are trying to do using current standards and has updated content that would let that user know that some of the solutions won't be valid in signatures.
    • Restrict new non-standard sigs, providing the same feedback and help AND at some time implement a system to require old editors with non-standard formatting to also update those sigs, providing the same helpful guidance thereby lessening the workload on lint fixing bots.
    • Restrict new non-standard sigs but implicitly say by your omission of any help or suggestions "ha ha, you saw something somebody else did that you want to do, but we don't allow that any more, but only for new guys, and we're not going to tell you what you did wrong or how to fix it. So fuck you as you try to track down what it is that you did wrong and how to fix it, or you can just give up and become disillusioned with a site that is so massively hostile to new contributors."
    If the choice is between fuck you and do nothing, doing nothing is vastly superior as a choice. VanIsaac, GHTV contWpWS 18:55, 6 December 2023 (UTC)
    The linter already will provide you with a help page to the relevant error when it detects lint errors. In this case, it’ll probably direct you to mw:Help:Lint error/obsolete-tag. I don’t see why you think it’s a choice between whether or not to “fuck you”.
    I just tested, and it should say “Your signature contains invalid or deprecated HTML syntax” along with a list of problems with a “learn more” link button for each. Aaron Liu (talk) 19:54, 6 December 2023 (UTC)
    Well, the "fuck you" option is what Folly Mox gave me when I specifically asked about how this proposal would be implemented. So maybe you need to get your ducks in a row and give me a straight answer on how this proposal will be implemented. What exactly does the linter tell you? When does it tell you? How does it tell you? How can we make more useful information available? Should we have a validation wizard that would output code fixing linter errors that we could point these new signature editors to? If the intent is to not give a "fuck you", then we need to actually back that up with our actions. VanIsaac, GHTV contWpWS 20:18, 6 December 2023 (UTC)
    Firstly, I think Folly Mox meant just giving them a link to the relevant doc page when they said shoving. Secondly, just look at this screenshot I found by simply searching "signature lint" on commons (though there has been a very minor difference: instead of bullet points, the extension uses a numbered list now.) Aaron Liu (talk) 23:06, 6 December 2023 (UTC)
    The behavior depends on what stage things are at. In the stage that prevents the creation of new bad sigs, you get instant feedback. That feedback may or may not be understood, but it is instant and provided in bold-faced red letters. In the stage in which old bad sigs are no longer accepted, it silently switches to the default, known-good sig. WhatamIdoing (talk) 07:21, 10 December 2023 (UTC)
    The latter stage seems like a separate RfC. The former's feedback seems pretty clear to me. Aaron Liu (talk) 16:48, 10 December 2023 (UTC)
    After the conclusion of this RfC (regardless of if it is successful or not), I plan to propose that we apply the signature validation rules retroactively (after affected users are mass messaged with pertinent info). Both of these proposals are a simple config change; the retroactive option would default invalid signatures to MediaWiki:Signature, e.g. 

    This is an example message with a default signature. Example (talk)

    HouseBlastertalk 23:19, 6 December 2023 (UTC)
    How would you know which users to mass message? Aaron Liu (talk) 12:19, 7 December 2023 (UTC)
    Quarry; you can see a partial report at toolforge (note that sig-too-long-post-subst and some of Line breaks would not be affected). HouseBlastertalk 00:15, 8 December 2023 (UTC)
    Wait, that signature length detection is possible and disabled‽ Aaron Liu (talk) 11:57, 8 December 2023 (UTC)
    No, they are not detected/disabled. That's why they would not be affected. HouseBlastertalk 16:55, 8 December 2023 (UTC)
    No, I mean that the substituted length detection is disabled. I really wonder why. Aaron Liu (talk) 17:49, 8 December 2023 (UTC)
    WhatamIdoing, looking at Note that the scope of this proposal has been narrowed to only impact newly saved signatures. it seems users who already have obsolete tags in their signature can continue to substitute that signature on talk pages, they just won't be able to adjust it in their preferences. But presumably if this passes we'll see another proposal down the line to end that grandfather clause. Unless the number of signatures that bots need to adjust ends up being really really low, in which case it could be a non-issue. — Alexis Jazz (talk or ping me) 10:05, 3 December 2023 (UTC)
  • Out of curiosity, how would one set one's username's font in their signature without the font tag? — Red-tailed hawk (nest) 05:55, 4 December 2023 (UTC)
    Wikipedia:Signatures § Font tags has a link to a page with examples. isaacl (talk) 06:03, 4 December 2023 (UTC)
    To save people the click: <font face="foobar"> can be rewritten as <span style="font-family:foobar;">. HouseBlastertalk 13:34, 4 December 2023 (UTC)
    Another curiosity: whilst HTML 3.2 allowed the <font> tag to have either or both of the color= and size= attributes, it noted Some user agents also support a FACE attribute which accepts a comma separated list of font names in order of preference. This is used to search for an installed font with the corresponding name. FACE is not part of HTML 3.2. HTML 4 formally added the face= attribute to the syntax, but immediately deprecated it along with the element itself. --Redrose64 🌹 (talk) 11:27, 5 December 2023 (UTC)
    Query: Is <strike>depreciated in favour of <s> or is there another, more convoluted way? Adam Cuerden (talk)Has about 8.6% of all FPs. 23:39, 5 December 2023 (UTC)
    [6]: Use the <del> tag to define deleted text [...] Use the <s> tag to mark up text that is no longer correct Aaron Liu (talk) 00:03, 6 December 2023 (UTC)
    And if you want a strikethrough without semantic connotations, you can use <span style="text-decoration:line-through;">. HouseBlastertalk 00:09, 6 December 2023 (UTC)
    Why stop there? We could make everything so much simpler by using <span class="mw-signature-struckthrough mw-signature-nonsemantic-strikethrough" title="nonsemantic-strikethrough" id="struckthrough-nonsemantic-qghlm11j" onclick="" style="font-size:100%; font-family: san-serif; filter: hue-rotate(0deg); text-decoration: line-through; display: inherit; text-align: inherit;" alt="Non-semantically struckthrough signature"></span>. jp×g🗯️ 13:13, 9 December 2023 (UTC)

This outcome is looking pretty snowy, and discussion seems to have reached a natural conclusion. – Jonesey95 (talk) 20:44, 15 December 2023 (UTC)

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

Post RfC: disallowing new signatures obsolete tags close

#RfC: disallowing new signatures obsolete tags was closed in support of the proposal. What is the process now to get this to be enabled as it currently is still possible to create those signatures. Gonnym (talk) 09:42, 26 December 2023 (UTC)

@Gonnym open a site configuration request in phabricator. — xaosflux Talk 10:18, 26 December 2023 (UTC)
In T140606, matmarex wrote: I updated the patch to include a config variable $wgSignatureAllowedLintErrors. It defaults to [ 'obsolete-tag' ] (which allows <font> tags etc.), and you can file a task to change this config to an empty array [] whenever the community of English Wikipedia (or any other wiki) agrees to that. I have filed T354067 to make that request, based on the RFC consensus listed above. If I have made any technical errors, feel free to weigh in with comments or corrections. – Jonesey95 (talk) 00:36, 28 December 2023 (UTC)
It seems the patch for this has stalled because nobody asked someone on Wikitech to add it to the deploy calendar (see the unresolved comment). Is there a process for asking? Could someone do that? Aaron Liu (talk) 16:50, 10 January 2024 (UTC)
Hi. I was unexpectedly out of town for a while; I will try to get this done within the next day or two. HouseBlastertalk 19:43, 11 January 2024 (UTC)
It seems like the patch is finished now. Thanks! Aaron Liu (talk) 22:00, 11 January 2024 (UTC)
The patch appears to be installed. I tried to put 
([[User talk:Jonesey95|<font color=red>talk</font>]])
in my signature, and I got an error saying that I was using an obsolete tag. This is good progress. HouseBlaster, is it time for phase 2 of this RFC? As a Linter error fixer, it can't happen soon enough for me. – Jonesey95 (talk) 23:23, 11 January 2024 (UTC)

Modify Module:Find sources/templates/Find general sources

More sources are proposed to be included in Module:Find sources/templates/Find general sources. AP has been added as a result of #RfC_on_Module:Find_sources_-_replace_New_York_Times_with_Associated_Press.

also, currently the only 2 given news sources nyt and ap are both american organisations. by adding the 4 below, there will be 3 american vs 2 british and 1 global, which will be less usa-centric as a whole.--RZuo (talk) 15:19, 24 November 2023 (UTC)

Note. The format of this RfC was discussed here and here (see talk and draft), which should satisfy WP:RFCBEFORE. Szmenderowiecki (talk) 22:54, 25 November 2023 (UTC)

i wrote proposals.
https://www.oxfordlearnersdictionaries.com/definition/english/proposal
User:Szmenderowiecki put an rfc tag https://en.wikipedia.org/w/index.php?title=Wikipedia%3AVillage_pump_%28proposals%29&diff=prev&oldid=1186856620 . whatever "should..." blah blah blah is not my concern. RZuo (talk) 08:54, 26 November 2023 (UTC)

Note. The module is rendered by the template {{find sources}} and appears as follows. Boud (talk) 19:40, 26 November 2023 (UTC)

"Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL"

Notified: WP:CENT. {{u|Sdkb}} talk 23:41, 29 November 2023 (UTC)
consensus seems to be against adding these sources. theleekycauldron (talk • she/her) 22:26, 25 December 2023 (UTC)

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.

Add reuters

Add BBC

Add WSJ

Add The Times

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.

Remove all individual news outlets

STRONG CONSENSUS
Participants strongly supported this proposal. They argued that including individual news outlets clutters the template, that search engines can provide links to many different publications at once, and that inclusion of individual outlets gave undue weight to them and the regions they represent. They also highlighted how inclusion could create various unwanted precedents in future discussions.

A small number of contributors in opposition asserted that including well-known examples of reliable sources in the template was important. Supporters refuted this position by noting that it would be difficult to provide a geographically-balanced list of individual publications.

The proposer of the change used JSTOR as an example of a search engine rather than an individual source. One participant commented that they see JSTOR the opposite way (as an individual source rather than a search engine) and suggested removing it. Overall, there was little discussion of the website, so any future changes in its regard would need additional discussion.

(non-admin closure)

Frostly (talk) 04:27, 12 January 2024 (UTC)

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.

Yikes. Let's take a step back here. As background, the module we're talking about is what produces the links seen mainly at the bottom of the 700k instances of {{Talk header}}. The goal is to help make it easier to find sources on a topic. However, that needs to be balanced with the imperative to keep the links in Talk header as minimized as possible to combat the notorious banner bloat on talk pages. So when we're thinking about which links to include or exclude, the frame should not be "might a few people find this helpful?" but rather "is this essential?"

In light of that, let's consider how people use this template. When I'm searching for sources for a Wikipedia article, I'm not interested only in what The New York Times, or Reuters, or the WSJ, or any other individual news outlet has to say on it (since Wikipedia articles are supposed to summarize all the reliable sources on a topic, not just a single source). So the main link I want to find news coverage is the Google News search, which will turn up those outlets as well as any others. And lucky me, that link already exists in the list, along with other links to places that collect works from many different publications (like JSTOR). The NYT link long stood out as the sole link to an individual source, and frankly including it was a mistake from the beginning. The way to remedy it is to remove it, along with the recently added link to AP, not to add more and more links to try to achieve some sort of balance.

What we're seeing above is the start of a path we don't want to go down, where we establish a new "worthy of Find sources inclusion" tier of source reliability and spend countless hours debating which sources to include in it and end up listing every newspaper of record across the globe to avoid the (legitimate) fears of geographic bias. Let's turn back from that and establish a simple standard that avoids all that ugliness and comports with how people actually do search: Find sources is for collections of sources, not for individual news outlets.

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL
Advanced search for: 
"Victorinox multitool"
In books/documents 
Google Books
Internet Archive  · WorldCat
In the news 
Google News: recent  · archives
Free English newspaper archives
In academic/legal journals 
and reference works 
Google Scholar: academic  · legal
The Wikipedia Library
Oxford Reference  · JSTOR
PUBMED Central
Internet Archive
World Wide Web pages 
Google Web Search  · Advanced Search
Searx 1  · 2  · 3  · 4
Bing  · DuckDuckGo  · Startpage
Yahoo
Images (free) 
Google  · Flickr
  • This is why I created {{search for}} to be a comprehensive suite of searches that one can pull out the type of searches that one wants from. And if there's something useful to add to it, we can certainly consider it.

    But {{find sources}} isn't the same thing. In the event that the multiple searches of {{search for}} are needed, simply replace {{find sources}} with {{search for}}, which is definitely the workman's multitool here. Otherwise {{find sources}} really should be focussed upon a few broad search engines. It's a spork to the multitool.

    It's somewhat questionable that it gives such prominence to Google, which is another reason that {{search for}} exists, but the very reason that I designed {{search for}} as a series of collapsing boxes is that if you add everything in a single line it becomes enormous. I tried that with {{search for}}.

    Something that is a single line mid-dot-separated list needs to be minimal, and if you keep adding more and more useful specialist searches to it you'll end up reinventing {{search for}} but badly.

    Uncle G (talk) 10:44, 25 November 2023 (UTC)

I can imagine Search for replacing Find sources. In fact, I think you could make the tool even better by integrating some tools like WP:WRS, by expanding the scholarly articles section, by integrating the subject-specific recommendations or by emphasising you may get help to find your source. But that one is very good and practically fulfills the same purpose. Szmenderowiecki (talk) 23:25, 25 November 2023 (UTC)
Comment. I just spent at least three or four minutes at maximum zoom trying to figure out whether bits three and seven (from the left) in the "multitool" photo are star drive, and I can't tell and it's upsetting my professional sensibilities. Even if they are, with only two included you're bound to run into screws you can't undo, either T15 or T20. Folly Mox (talk) 09:41, 26 November 2023 (UTC)
  • Support but replace the privacy-violating Google link by a link to either the Searx meta-search news link at Openxng.com, Searx.be and/or Priv.au (alternatively, it should be possible technically to set up a round-robin selection from the best-rated Searx instances listed at https://searx.space), or to Startpage.com (though I don't know of how to directly link to the News section there). Startpage also protects privacy, so would satisfy UCOC, but it does do some advertising, so that would count as advocacy conferring financial benefits, as in the case of Google, with a financial motive for search engine bias in its search results, affecting the neutrality of our finding sources. Boud (talk) 13:16, 25 November 2023 (UTC)
  • Support and I see no issue in a longer but more informative template. I only see the use of replacing Google with other browsers if they offer a comparable quality of search or it's slightly inferior but otherwise usable and respects privacy better. Privacy isn't a goal in and of itself, so we must weigh tradeoffs. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)
    Yeah, and we already have (sorta defunct) WP:WRS, which was supposed to be a one-stop tool to search all news.
    My general raw idea, w/o coding and so on, is here.
    Keep the number of links at the minimum, maximise searching within one custom search engine.
    It's not really possible with peer-reviewed articles, but we have Google Scholar and equivalents for that and anyway we should strive to use the best sources we have, right? Szmenderowiecki (talk) 21:10, 25 November 2023 (UTC)
    @Szmenderowiecki: Browsers are not search engines. Google's version of its web browser is getting worse and worse in terms of privacy violation, but that's an independent issue. Boud (talk) 16:31, 26 November 2023 (UTC)
    Yeah, I mistook this word, but the arguments stand Szmenderowiecki (talk) 18:42, 26 November 2023 (UTC)
  • Support for reduction of clutter. — Bilorv (talk) 20:25, 25 November 2023 (UTC)
  • Support per proposer, reduces clutter Sohom (talk) 20:55, 25 November 2023 (UTC)
  • Support strongly, especially since there's no reason to emphasize news sources by including many of them - for the vast majority of uses of {{find sources}} news sources might not even be right (let alone US based ones). Galobtter (talk) 21:00, 25 November 2023 (UTC)
  • Neutral: ok to remove individual outlets but it doesn't help much when there's a link to Google News which contains all sort of trash. Also support removing JSTOR as another individual outlet that has no business being here alone. Support replacing the links to NYT and AP with a search engine which contains them (preferably with a small manual selection of outlets rather than an automated crawling of news-like websites). Nemo 07:21, 29 November 2023 (UTC)
  • Support removing individual news outlets. Eddie891 Talk Work 15:32, 29 November 2023 (UTC)
  • Support. Less is more. This is used very widely via templates, and what gets included in it should be of exceptionally broad and global applicability. There should only be tools to actually "find sources" and not any individual source or publisher. Adumbrativus (talk) 04:19, 30 November 2023 (UTC)
  • Support per Sdkb. This is a slippery slope. Retswerb (talk) 01:31, 1 December 2023 (UTC)
  • Support per nom. Ajpolino (talk) 01:54, 1 December 2023 (UTC)
  • Support per nom Cgallagher2121 (talk) 08:59, 1 December 2023 (UTC)
  • Strongly support per nom, Galobtter and particularly the desire to reduce banner bloat. Remagoxer (talk) 15:30, 1 December 2023 (UTC)
  • Very Very Strong Support per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest "scribble" 07:36, 4 December 2023 (UTC)
  • Support - per nom and above. (I trust I don't have to individually oppose the other sections if I'm voting support here.) Levivich (talk) 16:52, 4 December 2023 (UTC)
  • Support per nom's criticism of banner bloat. The overall proposal rightfully recognizes America-centrism in a widely used template, but the solution cannot be adding the top English publications of each country BluePenguin18 🐧 ( 💬 ) 18:50, 4 December 2023 (UTC)
  • Support to avoid inappropriate product placement and because I doubt anyone actually needs these links to find sources. – Joe (talk) 13:28, 5 December 2023 (UTC)
  • Support Only including certain RS and not others violates NPOV, and the generic links are good enough for this purpose. QuicoleJR (talk) 14:19, 6 December 2023 (UTC)
  • Support - Honestly, I don't think we should be giving any outlets any undue attention, as it may violate NPOV as mentioned above. Also, as others have mentioned, this will reduce link clutter as well. Epicgenius (talk) 16:57, 12 December 2023 (UTC)
  • Support. It's prejudicial toward certain corporate "voices" in the news sphere (and certain countries' news), plus it would just continue to grow into an increasingly long list of such news outlets, which ultimately are redundant with the Google News link (though I wouldn't mind seeing that replaced by something that isn't subject to Google's own skewing, and using Microsoft's or Yandex's equivalent wouldn't help but just shift the problem of whose skew we're buying into). Maybe replace all these Google search types with DuckDuckGo ones, if we trust DDG more.  — SMcCandlish ☏ ¢ 😼  21:41, 18 December 2023 (UTC)
  • Oppose. I think picking representative examples is very important—it seems totally useless to force a less useful presentation solely to create an appearance that information need not come from anywhere in particular. We don't get to freely choose where information we can use comes from or how we can get it. Yes, you can characterize a mention of a particular entity as promoting it, sometimes obviously, sometimes only in an abstract sense—but no one can actually take the reasoning here to its logical conclusion. It is uncomfortable that we rely on certain outlets to create Wikipedia, but I'm sorry to say that there is no intellectually honest remedy for this discomfort, only ways to obscure it. This change is arbitrary; the generic links only push the problem people seem to have back a singular step. Remsense留 21:56, 18 December 2023 (UTC)
  • Oppose and I am in full agreement with Remsense. The sources in the module are helpful as the results from those links are narrowly-focused to meet the reseach needs of editors of this project, namely to provide independent, reliable source. We are frequently advised that this project does not right great wrongs, whether in terms of political or societal issues, nor in this case about the dominance of corporate voices in our media landscape. --Enos733 (talk) 00:36, 19 December 2023 (UTC)
    I don't really understand how this came to be a right-great-wrongs issue. We don't dispute NYT or AP is good, but if you need coverage from, say, Serbia, Poland or Canada, then using NYT or AP is kinda suboptimal compared to using local reliable outlets, which obviously cover local stuff better. Also, the framing about "corporate voices" is simply misguided. This is not the problem. The problem is that we choose to advertise only one voice among hundreds that are valid, and which WP:RSP recognizes are valid. It is also about creating a more versatile search tool. If among all sources they decide to choose NYT, we can't help it, but we should first offer a choice we don't really give right now. Instead we are suggesting "use NYT and AP". Adding individual outlets will just make the template needlessly bloated. Szmenderowiecki (talk) 10:37, 23 December 2023 (UTC)
    If you look at the discussion, there are several people who support removal to remove corporate voices or that somehow listing any outlet is a POV issue. - Enos733 (talk) 12:40, 23 December 2023 (UTC)
    I acknowledge that. As I said, for me the "corporate voices" thing is misguided. I can potentially agree with POV concerns for listing individual outlets if we are speaking about WP:SYSTEMICBIAS, which this diversification could help combat if only a little (the ultimate choice of sources still rests with the editors, and the source of that bias is mostly editors). Szmenderowiecki (talk) 16:20, 23 December 2023 (UTC)
    What I could agree with, if this could be implemented easily, is a way to personalize the search links. - Enos733 (talk) 01:29, 24 December 2023 (UTC)
    What do you mean by "personalise"? Doing Google's work all over again is not feasible. If you mean something like a dropdown list where you could tick the relevant boxes, I'm not sure Google's custom search engines can do that but maybe there are other techniques.
    Probably the best would be to sort these outlets by regions (North America, Latin America, W Europe, Central-Eastern Europe, Middle East, Indian subcontinent, E Asia, Australia and Oceania, Arab Africa, Central Africa, S Africa; and a general one). I think it would be beneficial for editors to see all news outlets and not simply let them cherry-pick the ones that align with their preconceived notions and POV, or for that matter only choose the most famous ones at the detriment of others thst also do good journalism. Szmenderowiecki (talk) 18:36, 24 December 2023 (UTC)
  • Support news outlets are not good general sources, full stop. (t · c) buidhe 02:17, 27 December 2023 (UTC)
  • Support removing all individual outlets, those present are too America-centric. Stifle (talk) 14:25, 3 January 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
CONSENSUS AGAINST
In this discussion, participants established a rough consensus against replacing the generic link for search. Participants who supported replacing it cited concerns about user privacy, potential systemic bias of Google's search engine, and some alternative websites were suggested. Those in opposition to the generic link being replaced argued that Google is the best overall search engine presently out there, that no suitable replacement to Google that is of comparable quality exists, and that the tradeoff here in terms of usability weighs in favor of maintaining google. Some participants noted that they would approve of adding links of general search engines in addition to the generic Google link (rather than in replacement of the generic Google link), though no affirmative consensus to do so was reached in this discussion. — Red-tailed hawk (nest) 05:54, 12 January 2024 (UTC)

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.

The generic link to Google violates Wikipedians' privacy (storing detailed private data for the purpose of sales to advertisers), which is contrary to the spirit of UCOC; like any individual search engine, it is subject to search engine bias that biases our selection of sources, and it uses filter bubbles targeted to each individual, tending to amplify existing demographic biases in Wikipedia. We could either give a link to list of search engines or choose a meta-search engine that gives high-quality general search results while protecting user privacy, reducing the bias to any particular engine, and avoiding filter bubbles. Boud (talk) 13:48, 25 November 2023 (UTC) Clarify: this section is only for the generic link, not for the specific links for news, books or scholarly sources. Boud (talk) 16:10, 26 November 2023 (UTC)

  • Support as proposer. Suggest either (1) list of search engines, or (2) the Searx generic link at Openxng.com, Searx.be and/or Priv.au, or if a pseudo-random generator can be linked up to the module (should not be difficult with e.g. /dev/urandom, which is fast), use a round-robin selection from a list of e.g. 10 of the best-rated Searx instances listed at https://searx.space), or (3) Startpage.com. The round-robin solution with Searx would keep the link compact (5 characters) and would statistically reduce the bias of any individual Searx instance implicit in the way it is configured and run. Boud (talk) 13:48, 25 November 2023 (UTC)
    • Given that Searx is not longer maintained, security vulnerabilities would not be widely reported and addressed in a timely manner. Furthermore, with such low market share, the Searx links you have provided would undoubtedly scare editors into suspecting they have been redirected to malware. While the random assignment to Searx instances increases privacy, this approach is unfamiliar to the average editor that expects links to consistently route them to the same specific site BluePenguin18 🐧 ( 💬 ) 19:11, 4 December 2023 (UTC)
      • @BluePenguin18: The main development of Searx shifted to Searxng, which is actively maintained; currently there are 882 closed bugs vs 183 open bugs and the master branch is updated every few days or so. Searx.space only lists Searxng instances. Education of editors is worth the price of protecting their privacy; those who actually check URLs are likely to know enough to be able to search further for an explanation and learn. There's also the option of Wikimedia techies running a searx instance: https://searx.wikimedia.org. Boud (talk) 02:28, 10 December 2023 (UTC)
        @Boud Thanks for the clarification on Searxng! I would support a Wikimedia instance of Searx being offered alongside Google Search to comply with WP:ASTONISH, providing curious editors an opportunity to learn about and choose meta-search engines while still offering the currently dominant option BluePenguin18 🐧 ( 💬 ) 05:10, 10 December 2023 (UTC)
  • Oppose. Google Search has plenty of problems that make it non-ideal, but it has over 90% market share. At that level, it's what editors expect, so providing anything else would go against WP:ASTONISH. Google also leverages its market dominance to provide better results in some cases, and editors' familiarity with it makes it easier for them to use. The metasearch engine idea is intriguing, but I wasn't impressed when I tested it just now. Searching for "Wikipedia" and navigating to the news tab produced results like this. Linking to the list of search engines is a nonstarter. The entire point of these links is to make searching for sources easier (to encourage more people to do it or just to add convenience). The current setup goes instantly to the Google results for the topic, whereas linking to the article would then require people to navigate to the search engine they want, click through to its article, click the external link to its site, and then re-enter the search term. At that level of inconvenience, people are just going to type the search query into their browser instead, bypassing the template and making it useless as a convenience aid. {{u|Sdkb}} talk 17:34, 25 November 2023 (UTC)
    • Just to check what the actual arguments presented here are against the Searx proposal. They seem to be: (1) Google is dominant and it's what people expect; (2) anecdotal evidence. Boud (talk) 16:26, 26 November 2023 (UTC)
      As of September, Searx's github repo is no longer maintained. I'm not real familiar with the project, but surely that's bound to be an issue moving forward if we were to use it as the sole replacement for Google search? Any replacement for the sole link should be something with staying power. Retswerb (talk) 01:29, 1 December 2023 (UTC)
      See above: Strictly speaking, Searx is closed, replaced by Searxng. When I said "Searx" above, formally speaking I was referring to Searxng software and instances. Boud (talk) 02:30, 10 December 2023 (UTC)
  • Oppose. Privacy isn't a goal in and of itself. I want to see the balance we trade between utility and privacy. If otherwise equal, obviously switch from Google but prefer utility in the balancing equation. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)
    • If we balance between utility and privacy, then privacy is a goal (among others). Boud (talk) 16:33, 26 November 2023 (UTC)
      A goal that I believe is secondary to utility, which is the primary goal (find as many sources as you can). You can believe we should prioritise privacy even to the detriment of utility, which is fine but I think few people will share your view.
      Also, {{search for}} already includes a couple of search engines outside Google. You can suggest a couple more there. Theoretically if there is independent confirmation that startpage.com is equivalent to Google but is more privacy-friendly, why not? We can change the link.
      But my testing of relatively obscure topics I mentioned (e.g. reasons why few people live in Tasmania) showed that most alternatives simply performed worse. Now whether Google (or Microsoft, Apple or whatever) abused its market dominance is basically irrelevant for me, because the point is to find data and (hopefully) let users exercise best judgment in choosing.
      I need to see that any of the SearX, Mojeek or other search engines are good enough to use. This also applies to searches in languages other than English, so if the engine is optimised for English but sucks in Russian, it's not good enough. Szmenderowiecki (talk) 18:41, 26 November 2023 (UTC)
      In principle, OK to let users exercise best judgment in choosing, but the search engine bias in the results that the users have to choose from only makes it easy for them to use judgment within that biased selection. A mix of biases (via a meta-search engine) should tend to reduce the overall bias.
      Searx is not a search engine, it is a metasearch engine. Mojeek is a search engine.
      As for other languages, given that in English a very sort of notorious example is when the Google search engine was categorizing black people as monkeys per a Princeton engineering interview, the case of Timnit Gebru's exit from Google, and the Santa Clara University advice Search engines and artificial intelligence are neither neutral nor free from human judgment, I see no reason to trust Google to be better in non-English languages than in English. Financial reasons suggest the opposite: paying fluent speakers of small-population languages of poor countries won't contribute much to Google/Alphabet advertising revenue. Boud (talk) 19:35, 26 November 2023 (UTC)
  • Oppose This proposal feels a bit wikilawyery especially bringing up the UCOC which has nothing to do with this proposal. Given everything being equal, I would definitely support using alternative engines (or atleast giving users the options to do so). However, this is not the case, instead results from other engines tend to be inferior or outright non-existent for certain search terms. Additionally, a geographical bias can actually sometimes help editors who live in specific regions find better sources (Annecdotally, I have a easier time digging up sourcing about Indian topics if I switch to my Indian registered internet connection when I am in other countries.) -- Sohom (talk) 21:09, 25 November 2023 (UTC)
    If there's consensus to continue violating UCOC - and in fact I expect that there will be consensus to continue to at least partially violate UCOC by keeping at least one or two Google links - then we'll find that out. WMF will have to fight us if it wishes to fully implement UCOC. Recommending that other Wikipedians violate their privacy is disrespectful and risky, e.g. it's inconsistent with ensuring that the Wikimedia projects are productive, pleasant and safe spaces, and contribute to the Wikimedia mission. It's not safe to be encouraged to violate your personal privacy. To make an analogy: suppose you're invited to a Wikimedia community face-to-face workshop and on entry to the room, there's someone at the door who asks you to take off all your clothes. Whether Google's privacy invasion into your mind - your browser history and browser parameters - is worse or better than a violation of your bodily privacy is a matter of judgment, but both cases are privacy violations. Boud (talk) 19:57, 26 November 2023 (UTC)
    @Boud You've lost me at the analogy. Giving up ones privacy is not akin to sexual harrasment, linking to the UCOC's harrasment clause and giving examples of sexual harrasment as a analogy is not going to change that fact.
    The {{find sources}} template links are just suggestions/convinience links for good places to find sourcing, you are welcomed to ignore it completely and use your own search engines (in fact I do so myself most of the times, even when using Google). I would liken it more to being offered a milk-coffee at a Wikimedia event, when I myself am lactose intolerant (I am not, but hypothetically speaking). Sohom (talk) 14:07, 30 November 2023 (UTC)
  • Oppose Google search/news/scholar/books are very good for finding sources and any replacement has to have similar quality. Galobtter (talk) 21:11, 25 November 2023 (UTC)
  • Oppose. A pretty normal WP:BEFORE would probably include Google news, Google books, and Google scholar. Removing links to Google would make this workflow inefficient. At a minimum, equivalent search engines that search news articles, books, and academic papers should be proposed. A general "let's get rid of Google" with no suggested replacement, in my opinion, is not the way to go. –Novem Linguae (talk) 02:00, 26 November 2023 (UTC)
    • This proposal is only for the generic link. That is independent of the specific links for news, books and scholarly sources. The above section (so far) seems to be only about news links. Boud (talk) 16:10, 26 November 2023 (UTC)
  • Support replacing Google search with (pretty much) anything else. Linking Google means we're letting advertisers decide what ends up used as source in Wikipedia, an obvious source of systemic bias. If people think a direct link to a web search is needed for people's workflows, DuckDuckGo would be an improvement on the current state. DuckDuckGo introduces less systemic bias because it generally doesn't personalise results based on user fingerprinting and doesn't serve automatically generated prose or other non-sources into the "search results" page. Nemo 07:12, 29 November 2023 (UTC)
    • This is misguided. By not personalizing, all users would get the same search results for the same query, reducing the variety of sources used on Wikipedia. While Wikipedia faces systemic bias for its disproportionate share of cis, white, and male editors, the diversity that does exist generates alternative advertiser profiles to see unique sources BluePenguin18 🐧 ( 💬 ) 19:11, 4 December 2023 (UTC)
      • So this argument is that by violating Wikipedians' privacy in tracking and recording their habits (in some cases) as being non-cis-white-male, these Wikipedians will select from sources that help create source diversity, but will to the same degree statistically out their gender/social-group profiles, whether they wish it or not. This makes the UCOC violation even worse: it's not just that Wikipedians are encouraged to give their browsing habits to an organisation known for tracking this to great detail, but those browsing habits risk being (statistically) revealed in their choice of sources. Machine learning applied to Wikipedians' selection of sources could suggest their likely Google gender/group profiles. For Wikipedians living in some countries and editing en.Wikipedia, this puts them at risk of prison or death. Boud (talk) 02:54, 10 December 2023 (UTC)
        I might be misunderstanding this argument, but are you suggesting that oppressive regimes will be targetting Wikipedians living under their rule by trawling through contributions and compiling a list of sources added per account name, and then reverse engineering those accounts' possible google profiles based on the sources they've added? Folly Mox (talk) 04:24, 10 December 2023 (UTC)
        Not will, but could; and not trawling by hand, but rather intelligently doing analysis using a mix of software and human thinking. Actions such as the Saudi infiltration of Twitter - or Google - will not always work and they risk embarrassment. To the extent that Google's filter bubbles characterise Wikipedians' profiles and improve diversity in the selection of sources (the point made by BluePenguin18), there would, in principle, be a signal, by definition.
        Suppose that Wikipedian X is LGBT, that the Downtown Post Daily Times strongly promotes LGBT content, as well as news content unrelated to LGBT issues, and is accepted as a WP:RS in Wikipedia, but X is unaware of the LGBT aspect of the DPDT (it's not obvious in the name). Then Google often gives X sources from DPDT (which buys lots of Google ads), and X often uses them in Wikipedia, unaware that other Wikipedians get DPDT links from Google much more rarely. Boud (talk) 13:47, 10 December 2023 (UTC)
        Even when machine learning models become capable of identifying editors' characteristics based on their choice of sources, it would simpler and more accurate to surveil their list of top edited pages. When the Saudi government infiltrated the Arabic Wikipedia's administrator community, they took the simplest approach to content control by looking at what specific editors were writing. BluePenguin18 🐧 ( 💬 ) 20:02, 10 December 2023 (UTC)
        Some editors may deliberately attempt to hide their interests by editing Wikipedia in a way that hides their (in this hypothetical case) LGBT profile, but some of their general non-Wikipedia searches will be for LGBT material. We get back to the case of our hypothetical editor unintentionally using DPDT as a source for a non-LGBT Wikipedia article, unaware that this is a statistical clue to being LGBT. Whether or not this is the best way to identify people to for arbitrary arrest and torture, it's available in the record. Boud (talk) 18:52, 13 December 2023 (UTC)
        @Boud: You gotta stop bringing up the UCOC thing. It's not helpful. I try not to inject myself in every conversation involving the UCoC, but I won't be able to sleep tonight if I don't correct the absolute absurdity that is your reply: If there's consensus to continue violating UCOC - and in fact I expect that there will be consensus to continue to at least partially violate UCOC by keeping at least one or two Google links - then we'll find that out. WMF will have to fight us if it wishes to fully implement UCOC.
        I've spent hours of my life having discussions with the WMF and the community about the UCOC. What you are suggesting is so far removed from anything a rational person would even consider when enforcing it. There is zero possibility of anyone of applying it to this case; most especially not the WMF. Your logic here is so twisted and nonsensical that I'm embarrassed to even feel the need to respond. –MJL ‐Talk‐☖ 06:55, 13 December 2023 (UTC)
        I don't see any arguments here explaining why encouraging Wikipedians to violate their privacy and thus put themselves at increased risk of harm is consistent with the spirit of UCOC; absurdity ... twisted ... nonsensical are not arguments. Boud (talk) 18:52, 13 December 2023 (UTC)
        The amount of logical assumptions you have to make to get where you are at is indeed absurd, twisted, and nonsensical.
        Adding a link to a Google search is not encouraging Wikipedians to violate their privacy (as has already been explained to you). Even if it was, the spirit of the UCoC (if there can be such a thing) which you keep referring to would not be violated nor enforced. I know this because I co-wrote the enforcement guidelines. –MJL ‐Talk‐☖ 18:55, 14 December 2023 (UTC)
  • Support the idea of replacing the generic google link with some sort of list of search engines. We already do this when providing links to ISBNs and co-ords. Rather than picking what search engine people use, we can present them with a list of options. I'm not convinced any Google alternative is actually good enough to fully replace the link to google, especially recognizing its sheer market dominance (it will be what many people expect to find and use). Eddie891 Talk Work 15:36, 29 November 2023 (UTC)
  • Oppose replacing Google: The top searches on Bing, and likely most other search engines is "Google". Meet the reader where they're at. Mach61 (talk) 05:41, 30 November 2023 (UTC)
  • Oppose As much as I dislike the corporation, it is the best overall source of sources. O3000, Ret. (talk) 19:38, 1 December 2023 (UTC)
  • Oppose otherwise WP:V is compromised. ~~ AirshipJungleman29 (talk) 21:06, 1 December 2023 (UTC)
    • Whether or not a search template not used in article content contains a hyperlink to Google has nothing at all to do with verifiability. Even if this template didn't exist at all, stuff could still be verifiable. Uncle G (talk) 14:56, 11 December 2023 (UTC)
  • Oppose - As much as Google may have plenty of privacy issues, that is a separate matter from whether it is useful, which it is. Thus, I don't see a reason to remove it at this time. I would support adding different search engines like Bing or Yahoo if there were consensus for it, though. Epicgenius (talk) 16:57, 12 December 2023 (UTC)
  • Support adding links to other search engines; the current google search engine is deeply flawed. The list of search engines should continue to include google -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:13, 13 December 2023 (UTC)
  • Oppose The generic search link can be valuable to editors. There is no replacement in this proposal, just removal. --Enos733 (talk) 12:44, 23 December 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Discussion (Module:Find sources)

There are two orthogonal issues here, reliability and coverage of sources (which is core encyclopedia stuff) and search engines' respect for privacy (which is a user preference). This is unlikely to lead to a productive conversation. Personally I think we should recommend source-finding techniques on a per-wikiproject basis. We need to look in different places for sources for a contemporary American biography, a 20C New Zealand law, a 19C Malay biography, an 18C German political scandal, a 17C book and an ancient Middle Eastern location. Seems likely to me that we can come up with a per-user preference for generic search engine privacy and then parameters to help find specific content (bot-assisted based on cats and wikiprojects). Stuartyeates (talk) 19:14, 25 November 2023 (UTC)

It's true that there are two orthogonal motivations, and you are probably right that a tech solution may be able satisfy both. The idea of a per-user preference parameter for search engine privacy, that would be used by the module to switch between privacy-violating and privacy-respecting search engines and meta-search engines, is good. This would need techie willingness to implement it. There would also be the question of which setting should be the default: should selecting privacy be opt-in or opt-out? Boud (talk) 20:13, 26 November 2023 (UTC)

If we think this is going to be a popular subject (~50 editors?), please copy/paste it to a subpage before adding an RFC tag. This page was recently nearly a million bytes long, and that makes it very difficult for people to read (especially on smart phones). The most popular title is Wikipedia:Requests_for_comment/YOUR-THING-HERE (see examples), but it's okay to do Wikipedia:Village_pump_(proposals)/YOUR-THING-HERE if you prefer. WhatamIdoing (talk) 18:59, 24 November 2023 (UTC)

I think this first should have an RfC tag before we move it to a subpage of VPR. People won't know of this discussion if we hide it in a subpage. Szmenderowiecki (talk) 21:12, 25 November 2023 (UTC)
If it's an RFC, people will know about it no matter where it happens. The Wikipedia:Feedback request service posts personalized messages to editors' talk pages about RFCs in subject areas that interest them. But I agree (and, more importantly, so does WP:RFC) that it would be good to keep a link here, especially if the discussion starts here and gets moved. WhatamIdoing (talk) 23:20, 26 November 2023 (UTC)
Maybe this should be done reactively rather than proactively. That is, wait for sections to get big, then put them on a subpage. –Novem Linguae (talk) 02:05, 26 November 2023 (UTC)
@Novem Linguae, do you have a preferred number for "big"? There are already more than 50 comments in this section. WhatamIdoing (talk) 23:22, 26 November 2023 (UTC)

Please consider transcluding or posting a link to what we're discussing here. Visiting Module:Find sources/templates/Find general sources doesn't show much, just some code. How does that code render? –Novem Linguae (talk) 02:04, 26 November 2023 (UTC)

{{Find sources}} Szmenderowiecki (talk) 09:08, 26 November 2023 (UTC)
The template renders as "Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL". Boud (talk) 19:36, 26 November 2023 (UTC)

Exactly how many news sources are deemed reliable by Wikipedia & which ones are they? GoodDay (talk) 16:28, 23 December 2023 (UTC)

Make Wikipedia:WikiProject Computer science/Manual of style into Wikipedia:Manual of Style/Computer science

FYI
 – Pointer to relevant discussion elsewhere.

Please see proposal at: Wikipedia:Village pump (policy)#Make Wikipedia:WikiProject Computer science/Manual of style into Wikipedia:Manual of Style/Computer science.  — SMcCandlish ☏ ¢ 😼  13:54, 12 January 2024 (UTC)

Shortening speedy deletion templates

The Template:Speedy deletion templates and Template:Speedy deletion notices are very long and not very helpful. They are one of the biggest and longest warning templates on Wikipedia, making their intended message diluted and turning them into a perennial example of WP:BITEY design. In my view, these speedy deletion templates should only be as long as Template:Article for deletion and the notices should only be as long as Template:Afd notice. CactiStaccingCrane (talk) 15:22, 11 January 2024 (UTC)

One idea I propose on how to shorten them is to rewrite the banner article template in three sentences, each in one line at normal text size, just like {{Afd}}:
  1. Stated rationale for deletion
  2. Link to contest speedy deletion
  3. Encourage editors to improve the article and link to speedy deletion process in general
And for the talk page notices {{Afd notice}}:
  1. Stated rationale for deletion
  2. Link to speedy deletion process in general
  3. Encourage editor to improve the article
  4. Reminder to not remove the speedy deletion template
CactiStaccingCrane (talk) 15:29, 11 January 2024 (UTC)
Very good idea. Maybe we could draft the messages somewhere first? – Joe (talk) 15:38, 11 January 2024 (UTC)
Absolutely. I'm making a page at Wikipedia:Village pump (proposals)/Updated speedy deletion templates to avoid cluttering the thread. CactiStaccingCrane (talk) 15:40, 11 January 2024 (UTC)
Ok, that's quite a lot of templates. I think it would be much better for individual editors to be bold and edit the templates directly, after this discussion resulted in a consensus of action. CactiStaccingCrane (talk) 15:51, 11 January 2024 (UTC)
The problem is they're all template-protected, and highly used. I think it'd be better to try to hash out at least the rough wording for each beforehand – just to reduce lots of subsequent edit requests, there doesn't have to be a big discussion of each one or anything. – Joe (talk) 15:53, 11 January 2024 (UTC)
Good idea too. CactiStaccingCrane (talk) 15:53, 11 January 2024 (UTC)

This would mean that the unbolded message at {{db-meta}} template would needs to be drastically shortened, the user notification request and the "last edited at X" be removed. {{AfD}} has proved that we don't really need these in the banner. CactiStaccingCrane (talk) 16:04, 11 January 2024 (UTC)

Listing this at Wikipedia:Centralized discussion as this is going to affect a lot of parts of the project, not just in deletion processes. CactiStaccingCrane (talk) 16:08, 11 January 2024 (UTC)
@CactiStaccingCrane, CENT-listed discussions tend to go better when there is a concrete, fully defined proposal for editors to !vote on. I'd suggest holding off on listing until you have finished crafting the proposed changes at the subpage. {{u|Sdkb}} talk 16:29, 11 January 2024 (UTC)
You're right. Reverted. CactiStaccingCrane (talk) 16:33, 11 January 2024 (UTC)

Old template:

This template may meet Wikipedia's criteria for speedy deletion{{{1}}}. See [[Wikipedia:Criteria for speedy deletion#{{{CRITERION}}}|CSD {{{CRITERION}}}]].

If this template does not meet the criteria for speedy deletion, or you intend to fix it, please remove this notice, but do not remove this notice from pages that you have created yourself. If you created this page and you disagree with the given reason for deletion, you can click the button below and leave a message explaining why you believe it should not be deleted. You can also visit the talk page to check if you have received a response to your message.

[button]

Note that this template may be deleted at any time if it unquestionably meets the speedy deletion criteria, or if an explanation posted to the talk page is found to be insufficient.

[timestamp]

And here's my proposal:

This template may meet Wikipedia's [criteria for speedy deletion{{{1}}}.] [link directly to the specific criterion for speedy deletion]

You are welcome to contest this speedy deletion by leaving a message at [link to contest speedy deletion].

Feel free to improve the article, but do not remove this notice if you have created this page. For more information, see the guide to speedy deletion.

- CactiStaccingCrane (talk) 13:03, 14 January 2024 (UTC)

I would contest that change. You're making significant change to the guidance to (non-creator) users which is contrary to the text of the actual policy. Anomie⚔ 13:28, 14 January 2024 (UTC)
Could you mention specifically what policy is being violated? I'm just trying to make speedy deletion templates follow {{Article for deletion}} templates since the AfD banner is already well-accepted by the community. CactiStaccingCrane (talk) 13:31, 14 January 2024 (UTC)
CSD tags are generally allowed to be removed by anyone except the creator. Your changed wording suggests that everyone has to go to the link to contest it. Anomie⚔ 13:43, 14 January 2024 (UTC)
Oh right! I will try to make a proper template later. CactiStaccingCrane (talk) 13:51, 14 January 2024 (UTC)

Restoring the lists of contents under the lede

Why not restore the lists of contents of pages under the lede and in bold as it was before? Now, to see the lists you have to click on that symbol to the left of the page's title. It took me several months to discover that the lists still existed and how I could make them appear by clicking on that god**** symbol. I'm convinced that, like me, zillions of occasional readers will not realize that the lengthy article they're reading actually has a useful list of contents hidden somewhere. To fulfil their purpose lists of contents should be user-friendly, that is, instantly visible, not discreetly tucked somewhere. Lubiesque (talk) 20:49, 13 January 2024 (UTC)

On most screens the table of contents is visible by default on the sidebar, but on narrow screens it is not. Are you viewing on a narrow screen (or did you accidentally hide it - you can unhide it by hitting the "move to sidebar" button). Galobtter (talk) 21:09, 13 January 2024 (UTC)
Maybe this varies by skin. I am using the legacy vector 2010 skin and the TOC appears below the lede. RudolfRed (talk) 21:11, 13 January 2024 (UTC)
I realize I should have looked around more.. After all, it was unlikely that the lists of contents would be gone for good.--Lubiesque (talk) 21:50, 13 January 2024 (UTC)
Lubiesque this occurred when the WikiMedia Foundation changed the skin of Wikipedia against the wishes of the community. You can go into your settings and switch from Vector 2022 to Vector 2010 if you want to change it back. There's also an ongoing discussion about the change where you can leave your feedback. Thebiguglyalien (talk) 23:45, 13 January 2024 (UTC)
Note that the closers of the RfC initiated before the rollout determined that participants expressed overall...positive reception to the changes. — Frostly (talk) 23:25, 14 January 2024 (UTC)
Because the Wikimedia Foundation refused to do so, instead deciding to suddenly roll out a major UI redesign with little notice and significant issues. See WP:V22RFC2. InfiniteNexus (talk) 04:43, 15 January 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_209&oldid=1207979288"