Misplaced Pages

:Village pump (proposals) - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 15:14, 27 December 2023 (Archiving 2 discussion(s) to Misplaced Pages:Village pump (proposals)/Archive 209) (bot). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 15:14, 27 December 2023 by Lowercase sigmabot III (talk | contribs) (Archiving 2 discussion(s) to Misplaced Pages:Village pump (proposals)/Archive 209) (bot)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff) "WP:PROPOSE" redirects here. For proposing article deletion, see Misplaced Pages:Proposed deletion and Misplaced Pages:Deletion requests. Discussion page for new proposals
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

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

Discussions are automatically archived after remaining inactive for nine days.


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

Centralized discussion For a listing of ongoing discussions, see the dashboard.

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 Misplaced Pages?

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 17:43, 16 November 2023 (UTC)

Please see Misplaced Pages: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)

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/search/?title=Misplaced Pages%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}}  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

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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages 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 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 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 Misplaced Pages, 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)

Replace the generic link

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 Misplaced Pages. 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 "Misplaced Pages" 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}}  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 Misplaced Pages, 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 Misplaced Pages. While Misplaced Pages 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.Misplaced Pages, 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 Misplaced Pages, 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 Misplaced Pages, 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 Misplaced Pages'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 Misplaced Pages in a way that hides their (in this hypothetical case) LGBT profile, but some of their general non-Misplaced Pages 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 Misplaced Pages 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 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)

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 Misplaced Pages:Requests_for_comment/YOUR-THING-HERE (see examples), but it's okay to do Misplaced Pages: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 Misplaced Pages: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 Misplaced Pages & which ones are they? GoodDay (talk) 16:28, 23 December 2023 (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}}  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? HouseBlaster 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! HouseBlaster 21:56, 3 December 2023 (UTC)
  • HouseBlaster, I thought I removed the excessive substs in my signature? What's going on? — Davest3r08 >:) 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. HouseBlaster 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. HouseBlaster 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, GHTVWpWS 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, GHTVWpWS 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 Misplaced Pages talk:Signatures or Misplaced Pages:Village pump (technical) or a friend's page.
    (Misplaced Pages: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, GHTVWpWS 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, GHTVWpWS 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, GHTVWpWS 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)

    HouseBlaster 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). HouseBlaster 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. HouseBlaster 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)
    Misplaced Pages: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;">. HouseBlaster 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 Has about 8.6% of all FPs. 23:39, 5 December 2023 (UTC)
    : 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;">. HouseBlaster 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 10:18, 26 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 Misplaced Pages 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 Misplaced Pages 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=] (since 1969) and |otherparty=] (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.

Proposal for general change at WP:AFDHOWTO

About a week ago I got into a discussion at Misplaced Pages 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.

“ If you are unregistered, you should complete step I, note the justification for deletion on the article's talk page, then post a message at Misplaced Pages talk:Articles for deletion requesting that someone else complete the process. ”

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 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 Misplaced Pages: 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 (they|xe|she) 08:52, 27 December 2023 (UTC)

Saberov Ruslan Yuryevich

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

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