Wikipedia:Village pump (proposals)

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

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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

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

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Enable RC patrolling (aka patrolling for edits)

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? Ladsgroup^overleg 17:39, 10 October 2023 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Our current system works like this:

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

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

Imagine that we instead said:

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

In this scenario:

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

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

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

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

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

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

Or as an exaple.

1) Editor A marks a edit as approved

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 Ladsgroup^overleg 10:22, 12 October 2023 (UTC)

Two notes:

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

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

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

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

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

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

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

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

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

Another note to avoid the bot archiving it Ladsgroup^overleg 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.

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

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.

This RFC presents two questions as one, so I'm going to have to split them in order to determine consensus. First, there is no consensus to remove the NYT from Module:Find sources. There were decent arguments, and counter-arguments on both sides. Most of the discussion focused around accessibility and width of focus, with some discussion taking place about the political POV. Accessibility was the biggest bone of contention, with strong points on both sides. Cullen328 made a strong argument that quality sources often have paywalls, and that the depth and analysis provided by a newspaper, rather than by a news service, is valuable. This was echoed in many other statements. Those supporting the removal point out that the vast majority of our readers cannot access the source, and Levivich makes a strong point that the ease that some see in getting access to the NYT is certainly not true for all. The Americacentric reporting was also brought up, as was that NYT does provide international coverage, and BluePenguin18 points out that they provide international coverage that AP does not.

All of that said, while the arguments on both sides are good, neither did much to sway the other side, and neither is an over-the-top slam dunk that destroys the other. With the numbers being fairly close that leaves us at a solid no consensus.

The second question at issue is the adding of AP to the module. I see consensus to include AP in the module. Many of those opposing the removal of the NYT supported the addition of AP and other sources.

There seems to be a reasonable consensus that other sources should be included, which would have to be addressed in another discussion. That the module should provide a way to search sources, rather than for articles from a single source, was also brought up by multiple editors. This didn't gather much traction in this discussion, but it may be worth a more focused discussion in the future. ScottishFinnishRadish (talk) 23:23, 15 November 2023 (UTC)

---

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

Survey (Find sources: NYT vs AP)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  "...and removing something because it has a paywall I think is a mistake -- we should recommend the best sources, not the most accessible ones." I'm pretty sure no one has had this discussion with the small group of editors who have been allowed to WP:OWN the recent deaths lists. For years and years, I observed an obsession with replacing sources because of paywalls and "European access blocks", while at the same time observed no regard given to malicious links and links leading to geographically distant sources who regurgitate someone else's content in order to provide an additional venue for their array of clickbait ads. Sourcing in general throughout the encyclopedia leaves a lot to be desired. RadioKAOS / Talk to me, Billy / Transmissions 03:03, 13 November 2023 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  you merely said nyt is neutral.

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

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

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

  @Valereee:

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

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

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

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

• Oppose removal of the NY Times. It has a comprehensive archive and most stories contain an attributed author. Not opposed to adding additional sources. --Enos733 (talk) 21:06, 14 September 2023 (UTC)
• Oppose Absolutely not. The NYT is, in my view, the single most high-quality respected news publication in the Western world of all time. InfiniteNexus (talk) 00:43, 15 September 2023 (UTC)

  This a bit of an WP:ILIKEIT argument, and one underpinned by a healthy dose of Americo-centrism. Tomorrow and tomorrow (talk) 05:47, 1 November 2023 (UTC)

• Support defaulting to a global source focused on factual reporting improves Wikipedia's neutrality. – Teratix ₵ 00:44, 21 September 2023 (UTC)
• Oppose removal, but support addition. In general, I would have multiple newspapers listed, rather than just one. Google has been getting shittier and not pulling up everything. AP, WaPo, AFP, Reuters, etc. would all be useful, in addition to the NYT. The NYT is still a very reliable source for information, globally. SWinxy (talk) 04:13, 21 September 2023 (UTC)

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

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

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

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

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

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

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

• Oppose False dichotomy, just add both. Curbon7 (talk) 21:40, 12 October 2023 (UTC)
• Support People here might be surprised that Americans who are left of center consider the NYT to be part of the corporate media which sucks up to the PTB. Despite having Paul Klugman on its staff. (And by "left of center" I mean individuals who are far more moderate than members of the Party for Socialism and Liberation. More accurately labeled progressive Democrats.) A chronic problem of the US mainstream press is this baffling need to "present a balanced view", which always means giving more attention to conservative POVs, & the NYT is as guilty of this as practically every other US publication. -- llywrch (talk) 23:48, 28 October 2023 (UTC)
• Support adding AP Oppose removing NYT No need for this to be NYT vs. AP. An excellent pair. Perhaps add paywall as a parenthetical for NYT. O3000, Ret. (talk) 18:31, 10 November 2023 (UTC)
• Oppose removal of NYT, support addition of AP--Lukewarmbeer (talk) 11:41, 11 November 2023 (UTC)

Discussion (Find sources: NYT vs AP)

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

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

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

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

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

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

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

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

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

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

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

https://www.nytimes.com/2023/10/23/pageoneplus/editors-note-gaza-hospital-coverage.html

so much for "NYT's factual reporting is neutral", "by far the best and most comprehensive US newspaper source", "enviable world-level reputation for fair and accurate reporting"... lmao.--RZuo (talk) 20:27, 23 October 2023 (UTC)

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.

Implementation

@ScottishFinnishRadish: did you add AP to the module as per the consensus you determined?--RZuo (talk) 10:01, 19 November 2023 (UTC)

RZuo, I did not, no. ScottishFinnishRadish (talk) 14:37, 19 November 2023 (UTC)

@ScottishFinnishRadish: can you please edit the module(s)?--RZuo (talk) 08:55, 20 November 2023 (UTC)

I generally don't make edits related to RFCs I've closed due to WP:INVOLVED concerns. As Val suggests below, you should make an edit request at the module talk page linking to the RFC result. ScottishFinnishRadish (talk) 13:03, 20 November 2023 (UTC)

that's some weird way your group of users work in. RZuo (talk) 14:57, 20 November 2023 (UTC)

It needs a template editor or an admin familiar with editing modules. I wouldn't go near it myself. RZuo, you could make an edit request at the appropriate talk and reference the closing. Valereee (talk) 15:04, 19 November 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[1]

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 [2]. 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)

• @Terribilis11: If I am reading your statement correctly, this is not a proposal to make any changes to Wikipedia, whether by modifying policies and guidelines or by adding new content; you are simply calling for volunteers. If that is the case, then this belongs on Wikipedia:Village pump (miscellaneous) instead. -- King of ♥ ♦ ♣ ♠ 18:48, 10 November 2023 (UTC)

  It was crossposted there, too, and removed by GhostInTheMachine in favor of this one (I assume because it hadn't been replied to there, and had been here). —Cryptic 18:57, 10 November 2023 (UTC)

  Yep, this post had a response and I did not feel OK with moving it. We could probably swap the post and cross-link if this looks to grow — GhostInTheMachine ^{talk to me} 19:08, 10 November 2023 (UTC)

  Hi, I cross posted in both. Thank you for leaving this one. Terribilis11 (talk) 00:33, 14 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 [3] 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. [4] 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)

• 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)

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

First we need a new draft of the RfC and consensus on the RfC statement and structure

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. 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: Add Qwant Add Mojeek Add Semantic Scholar tech step 2: Add some metasearch engines that respect privacy to the list of available search engines at Module:Find_sources/links Add Startpage.com Add one or 3-4 Searx instances such as https://searx.thegpm.org policy step 1: modify Module:Find sources/templates/Find sources that defines the list of search engines at Template:Find general 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:) remove the general link to Google and replace it by Startpage, Qwant and/or Mojeek and/or [add a proposal] keep Google Books unless someone can propose a similar equivalent 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] replace Google Scholar by Internet Archive Scholar and/or Semantic Scholar and/or [add a proposal] (Other modifications) (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): 1.1 Qwant 1.2 Mojeek 1.3 Semantic Scholar 1.4 (other) 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): 2.1 Add Startpage.com to the list of available search engines at Module:Find_sources/links 2.2 Add a Searx instance such as https://searx.thegpm.org to the list of available search engines at Module:Find_sources/links 2.3 (other metasearch engines ) 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) Support (proposer). This would avoid advocacy for any particular search engine and would allow 3.2 to remove all specific search engines. Boud (talk) 17:07, 10 November 2023 (UTC) 3.2: Replace the generic Google link 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) 4 Other related changes As an open-ended component of this RfC, feel free to add other (preferably concrete) proposals or 'see also' links. See also: There is a recently opened, orthogonal discussion for advice on how to or whether to fix the AfD guideline page on the issue of WP:ADVOCACY. Boud (talk) 16:45, 10 November 2023 (UTC) 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)

• v2: version 2: s/non-mainspace advocacy/recommendations/ Boud (talk) 19:31, 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:

• News: Newspapers of record, news agencies and fact-checking websites. For guidance on how the community assessed the reliability and bias of each outlet, click here. Note. We can incorporate WP:WRS into this. The basic work is done, what is needed is further development
• Books: Use Google Books, the Internet Archive, HathiTrust to access content, or consult WorldCat to find the nearest library with the book. In certain countries, there may be centralized catalogues. Pages like these should be used to direct a user to a country-specific catalogue.
• Scholarly articles: Google Scholar, BASE, Semantic Scholar, CORE, Science.gov, ResearchGate, Web of Science (login required), Scopus (login required). Be careful when dealing with these journals and publishers. Note. can be tailored for med topics
• Free images: Google Images, Wikimedia Commons
• Other free content: Look for free subject-specific sources, free newspapers and tips to access otherwise locked-out material.

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:

• News: Newspapers of record, news agencies and fact-checking websites. For guidance on how the community assessed the reliability and bias of each outlet, click here.
• Books: Use Google Books, the Internet Archive, HathiTrust to access content, or consult WorldCat to find the nearest library with the book.
• Scholarly articles: Google Scholar, BASE, Semantic Scholar, CORE, Science.gov, ResearchGate, Web of Science (login required), Scopus (login required). Be careful when dealing with these journals and publishers.
• Free images: Google Images, Wikimedia Commons
• Other free content: Look for free subject-specific sources, free newspapers and tips to access otherwise locked-out material.

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)

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)

RFC - infobox on Fred Sullivan

There's an ongoing discussion about adding an infobox on the article of Fred Sullivan. All feedback is welcome. Thanks! Nemov (talk) 21:35, 15 November 2023 (UTC)

@Nemov How is this RfC a suitable topic here? Is it more important than any other? Doug Weller talk 08:24, 16 November 2023 (UTC)

Wikipedia:Requests for comment#Publicizing an RfC suggests notes like this at a village pump "if relevant", and we generally give editors pretty wide latitude to decide what counts as relevant. WhatamIdoing (talk) 21:59, 21 November 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)

• There's a discussion about this at Wikipedia talk:WikiProject Years#Change to the DMY date format that might be working its way to an eventual RFC. For now, I'm working on reverting the changes to recent year articles. MOS:DATEVAR is clear that date styles shouldn't be changed without clear consensus. Firefangledfeathers (talk / contribs) 13:15, 16 November 2023 (UTC)

  Done with the reverts. For the record, some rough, early local consensus developed at Talk:2023 to change to DMY, meeting the requirements of DATEVAR. As far as I'm aware, we're now in a spot where all year articles use MDY except 2023. Firefangledfeathers (talk / contribs) 14:50, 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 [5].  — 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)

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)

Background (emoji redirects)

There was a previous RfC (with the cute shortcute WP:😃↪️📊) for which I will include the relevant background here:

This section is an excerpt from Wikipedia:Village pump (proposals)/Archive 208 § Background (emoji redirects).[edit]

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

The RfC, however, was derailed when some of the options were reorganized, stricken, and combined; this caused confusion and the only consensus to be made at the end was a call for a new clean RfC without presupposed options.

Survey (emoji redirects)

Given the confusion previously, I hesitate to presuppose too many options here. Instead, if you feel like your preference is not covered here, I encourage you to add it here for easy identification for the ensuing conversation. I've transposed the options included previously, or that were brought up at the previous RfC.

The options only discuss what happens to redirects that do not have a clear article, as in the case with 😂 which links to Face with Tears of Joy emoji.

Option		Description
1		Retarget all other emoji redirects to lists of symbols by default, such as emoji which appear on Supplemental Symbols and Pictographs or Symbols and Pictographs Extended-A.
2	(a)	Retarget to pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire, and retarget ambiguous emoji to relevant lists of symbols.
	(b)	Retarget to pages where the emoji's depiction is deemed unambiguous, such as 🔥 being a redirect to fire, and delete all other emoji redirects with ambiguous meanings.
3		Do not try to prescribe this centrally, but let RFD do its thing on individual redirects based on individual consensus. (per Kusma)
4		Emoji with meanings that clearly correspond to one article should target that article. Emojis with meanings that correspond to multiple articles should target a list, disambiguation page, set index or other place where readers can follow links to the article(s) relevant to their search. Other emojis should redirect to relevant lists of symbols. Emoji should be redlinks only when we want to encourage the creation of an article about that emoji and/or its meaning. (per Thryduulf)
5		Delete all other emoji redirects without associated articles.
6		(option added 16 November 21:19 by Edward-Woodrow) Soft redirect emoji redirects to corresponding wiktionary entries; such as 🔥 to wikt:🔥.
7		(option added 18 November 20:57 by Alexis Jazz) Use a template like User:Alexis Jazz/Emoji (which would be moved to the template namespace) to provide information sourced from Wikidata about the Emoji, demos: 🔥 (revision 1185755899), 🔦 (revision 1185756571).
8		(option added 20 November 7:53 by Alexis Jazz) Use {{Character info}} which we borrowed from English Wiktionary. This has no dependencies on Wikidata. Does not provide links to Emojipedia etc. Demo (without image, image should become available after edit request is fulfilled): 🔥 (revision 1185990054)

I invite your comment here. microbiologyMarcus ^{(petri dish•growths)} 17:43, 16 November 2023 (UTC)

• Option 1: I think a list should be created that has an anchored table of the emojis with their official unicode description and things within that description can be linked. I've begun making such table at Draft:List of Emojis and, for example, where ‼️ could link to Draft:List of Emojis § ‼️ and then within the description, there is a link to exclamation mark. microbiologyMarcus ^{(petri dish•growths)} 17:43, 16 November 2023 (UTC) Stricken, option 7/8 per below. microbiologyMarcus ^{(petri dish•growths)} 17:41, 23 November 2023 (UTC)

  See also Draft:List of emojis (faces) Gonnym (talk) 17:46, 16 November 2023 (UTC)

  I have to say, I'm not particularly attached to the list I gave, I like the (faces) list as well. I think the list would be beneficial to include all as it would encompass the discussion here for all emojis. But I completely agree that having the links (under meaning) just like the descriptors are linked in the first is the most beneficial way of creating a navigable and descriptive, helpful list. microbiologyMarcus ^{(petri dish•growths)} 17:50, 16 November 2023 (UTC)

  We already have List of emojis; we don't need another (separate) one (i.e. Draft:List of Emojis) with the word 'emojis' capitalized. Some1 (talk) 23:25, 16 November 2023 (UTC)

  Stricken above. I really like option 7/8, but @Alexis Jazz: why not combine the {{Character info}} infobox with {{User:Alexis Jazz/Emoji}} template? I think I like the info provided by both and I don't think it's too much to provide links and wikidata. microbiologyMarcus ^{(petri dish•growths)} 17:40, 23 November 2023 (UTC)

  MicrobiologyMarcus, okay, I combined them. But I'm still unsure about this. Just the thumbnail looks cleaner to me. {{Character info}} feels a bit busy to me, and infobox-like templates tend to present poorly on mobile devices with narrow screens. And the next/previous character navigation seems rather pointless to me.
  I'll see if I can get the information in the text instead. — Alexis Jazz (talk or ping me) 09:27, 24 November 2023 (UTC)

  @Alexis Jazz: I can see what you mean. I'm a big infobox fan myself but those concerns are valid. I agree that next/previous navigators are unnecessary for emoji navigation. I do like the info so maybe inline in text would be good. Also, what about separating the links into two sections with a level 3 heading so it's bolded for a See also for Wiki-projects and then a External links for projects that aren't under the WMF umbrella? By all means, just a suggestion from an arm chair quarterback on Monday morning, no need to implement my suggestions, I terrible at these things so don't feel the need to listen to me.

  I do think the userspace template you've made is awesome by the way, I think it is ready for the template space and that is now my vote for what should be done with the redirects. It's a much more elegant solution than the list and it includes all the necessary information for wikipedia without adding all of the unsourced/opinion disadvantages that people have raised below. —microbiologyMarcus ^{(petri dish•growths)} 14:24, 24 November 2023 (UTC)

  MicrobiologyMarcus, thanks! 😀
  The issue with splitting the list is that a Wiktionary entry only exists for a few emojis. In that case there's only Wikidata, resulting in a list with only one link. The same thing could happen with external links if there's any emoji for which Wikidata has no external links. (the Unicode link I just added is generated locally)
  If lists with one item are okay it's no problem. All the info from {{Character info}} (not including the navigation) should be inline now. — Alexis Jazz (talk or ping me) 17:36, 24 November 2023 (UTC)

• Option 2a because some emojis have a clear meaning, like fire mentioned above. There are many others too that I wouldn't know about, and it's best to have the others redirected to the list of symbols. The 🏎 Corvette 🏍 ZR1^{(The Garage)} 17:50, 16 November 2023 (UTC) Option 4 per Thryduulf. The 🏎 Corvette 🏍 ZR1^{(The Garage)} 20:05, 18 November 2023 (UTC)

  How do you feel about Option 4? It is essentially a more nuanced version of Option 2a. Enix150 (talk) 05:23, 18 November 2023 (UTC)

• Option 1 directly contradicts fundamental policy and long-standing practice at RFD for similar cases, but all the others except 5 [and 6, which didn't exist when I wrote this] contradict it more. People who want to write about glyphs as glyphs are encouraged to contribute to our sister project Wiktionary, where that's in-scope. —Cryptic 17:52, 16 November 2023 (UTC)
  • Clarifying my position a bit (and refraining from piggybacking on LaundryPizza03's comment, since I don't actually disagree with him): any of 1, 5, and 6 are ok. 2a, 2b, and 4 are actively harmful; 3 is unacceptable since RFD has shown its local discussions can't adhere to policy - either overall, or RFD's own precedent; and 7 is no good because Wikidata is unreliable in both the Wikipedia- and non-Wikipedia senses of the word and we should never use it for content (using such a template with data pulled from our own lists would be ok). Even the non-existent wikt:👿 is more useful to our readers than our redirect from 👿 to imp: it gives its official name "IMP" and displays File:Emoji u1f47f.svg for if your browser or installed fonts can't render the emoji, gives its codepoint and html entity for if you're trying to type it, and links to adjacent emoji and to Wiktionary's list for the appropriate unicode block. They do the same (except, when not available, the image) for every single-character title that they don't have an entry for - in a very real sense, they do cover every emoji, and every other character appearing in Unicode. We can achieve the same by creating a zillion soft redirects to Wiktionary; or by leaving them as redlinks and letting our users click the automatic Wiktionary link; or by leaving them as redlinks and copying Wiktionary's machinery that displays this information on their redlinks; or by linking to a sufficiently-developed and comprehensive list (which we don't currently have). But supposing, as suggested below, that someone who types "🔥" may really be looking for information about fire but doesn't know what to call it, and further that they'd be able to get some benefit out of fire or even simple:fire in that case, is absurd. —Cryptic 03:06, 18 November 2023 (UTC)
    • Cryptic, copying Wiktionary's machinery that displays this information on their redlinks; I kinda had to make ExportAllTheThings before I could do that, but we have {{Character info}} now. Images don't work yet because of a protected page I can't edit, see Module talk:Unicode data#Edit request 20 November 2023.
      Demo (without image): 🔥 (revision 1185990054) — Alexis Jazz (talk or ping me) 06:50, 20 November 2023 (UTC)
• It's between option 1 and 2a for me. The question is really whether people searching emojis such as 🔥 are actually trying to go to Fire, or whether they're trying to get more info on the emoji itself, and I don't know the answer to that. I'd lean towards Option 2a until the list of emojis is completed – at that point, we can probably just target all emojis that don't have an article to their section on that list, which can link potential target articles such as Fire for 🔥 and give a bit of info on the emoji. Skarmory (talk • contribs) 17:57, 16 November 2023 (UTC)

  I now prefer Option 7 (or 8) to Option 2a; no preference yet between Option 7 and potentially full and more useful emoji lists. Skarmory (talk • contribs) 04:18, 22 November 2023 (UTC)

  Let me know when other glyphs that mean fire like 火 redirect there. And yes, its current target is Wiktionary material too; nearly all Chinese glyphs are correctly redlinks, not redirects to their meanings or lists like List of jōyō kanji. —Cryptic 18:10, 16 November 2023 (UTC)

  I don’t think that’s a fair argument because 火 has its own article and it redirects to its own article (I agree, I don’t think that article would meet notability guidelines at an AfD currently). That’s akin to saying that the 😂 emoji redirect to Face with Tears of Joy emoji which it does. Lacking that article, though, I don’t think the emoji should be allowed to redirect to tears or joy, so many emojis are ambiguous. microbiologyMarcus ^{(petri dish•growths)} 18:27, 16 November 2023 (UTC)

  It's not really a good example; the Chinese character for fire is simple and common enough a concept that it's very frequently used in other characters, which is what the article it redirects to is about. The parallel for 🔥 would be an encyclopedia article about emoji containing flames. A more complex character with a similarly-basic concept - and hence a better example - is 家, which should no more redirect to house or home than 🏠 or 🏡 should. —Cryptic 19:16, 16 November 2023 (UTC)

  I mentioned below but I think we're both in agreeance if I understand you correctly: 🔥 is a bad example because it's so simple, extracting policy or consensus based on the principles developed around 🔥 is not a good idea, and further, emojis should not redirect to the subject of the emojji because that adds no encyclopedic value and no one navigates by emojis; if someone searchs for an emoji on Wikipedia, they should land on a page that describes the emoji not what the emoji represents. microbiologyMarcus ^{(petri dish•growths)} 20:56, 16 November 2023 (UTC)

  Do you have a citation for this claim that no one navigates by emojis. It's been made multiple times, but given the prevalence of emojis in contemporary usage I find it extremely hard to believe. Thryduulf (talk) 21:18, 16 November 2023 (UTC)

  I think the fire emoji might be simplifying the complexity of emojis. Take, for instance 👩‍💻, I would find it hard to make an argument that people are using that to navigate to Women in computing. microbiologyMarcus ^{(petri dish•growths)} 18:39, 16 November 2023 (UTC)

  I agree; those emojis are good candidates for a target to a list of emojis, and are what I had in mind. Fire is an interesting case for me, because there's a fair bit of slang usage, but I think it's about as simple as you're going to get. I'd still prefer a good list entry for it over just redirecting to fire. (Side note: ideally, that list of emojis would also cover the same type of navigation that option 4 is looking for.) Skarmory (talk • contribs) 18:45, 16 November 2023 (UTC)

  @Skarmory: How do you feel about Option 4? It is essentially a more nuanced version of Option 2a. Enix150 (talk) 03:53, 22 November 2023 (UTC)

  I like option 2a more, mainly because I think in ambiguous cases people are unlikely to search for the emoji looking for one of the concepts (hence why I considered option 1). However, looking at options 7/8, I think I prefer those over anything besides potentially a list of emojis. Option 7 is better, though I think both could be implemented on the same page. Skarmory (talk • contribs) 04:10, 22 November 2023 (UTC)

• Option 4 seems to make the most sense for getting our readers to the information they want. I would only strongly oppose options 2b and 5, though; deleting most emoji redirects would not be useful to our readers at all. Elli (talk | contribs) 17:58, 16 November 2023 (UTC)
• Develop a set of lists like Draft:List of emojis (faces) and retarget them all there. -- Tavix ^(talk) 18:00, 16 November 2023 (UTC)
• Option 2a per Skarmory’s reasoning Yoblyblob (talk) 18:02, 16 November 2023 (UTC)

  How do you feel about Option 4? It is essentially a more nuanced version of Option 2a. Enix150 (talk) 16:42, 20 November 2023 (UTC)

• Oppose options 2b and 5 unless all relevant redirects (are 🎾 and 🎦 considered ambiguous?) are properly tagged and nominated for deletion, per WP:LEOPARD. The main question I see is whether we want to use emoji redirects only as a search help (then a list would be best) or also as something that we expect people to link to (then 2a or 4 would be best). —Kusma (talk) 18:02, 16 November 2023 (UTC)

  Option 6 is best for those cases where Wikipedia doesn't have an article about the emoji but Wiktionary does. But that is likely what the default Option 3 would find in each of these cases, so I'm not sure we need to spell this out explicitly. —Kusma (talk) 07:25, 18 November 2023 (UTC)

• Option 1 I do not see why anyone would want to learn about Fire when they see a 🔥 emoji; to me, it's much more likely they want to learn about the emoji itself, and if there's no dedicated page for the emoji, the best information can be found on the general Unicode block page. (If various lists of emojis are created in line with Tavix's suggestion, then I would support targeting there.) -- King of ♥ ♦ ♣ ♠ 18:04, 16 November 2023 (UTC)

  Responding to the WP:NOTDICT argument against 1 above: There is plenty of precedent for targeting an article (in particular, an article covering the word itself) other than the main topic when the method of referring to the topic is considered unusual or non-neutral in the English language. For example, Dubya targets List of nicknames of presidents of the United States rather than George W. Bush, and Niemcy targets Names of Germany rather than Germany. This is because English Wikipedia readers are unlikely to search for "Dubya" if they really wanted an article on GWB or the Polish name for Germany if they really wanted an article on the country. Likewise, who searches for actual encyclopedic content using an emoji? -- King of ♥ ♦ ♣ ♠ 18:24, 16 November 2023 (UTC)

  Yes. Exactly. Nobody searches for encyclopedic content with emoji, and most options take it for granted that they do. This RFC isn't about cases where we have encyclopedic content about emoji, like the 😂 shown just above the list of options. If someone's looking for information about other emoji, and there isn't anything encyclopedic to write about it, the best option is to send them where there's something at all to write about it. Like wikt:🔥, which is far more useful than fire or a local list entry that's likely only going to say "U+1F525 'fire'". —Cryptic 18:31, 16 November 2023 (UTC)

  @Cryptic: So you would like to create soft redirects to Wiktionary? -- King of ♥ ♦ ♣ ♠ 18:39, 16 November 2023 (UTC)

  I think redlinks are sufficient. If titles like 🔥 didn't uselessly redirect to articles like fire, they'd show Mediawiki:Noarticletext, which links to the Wiktionary version. Even when there's no Wiktionary version, what they display on their version of wikt:Mediawiki:Noarticletext is at least as useful as what would be put on a list here (example: wikt:🏡). A list with links to Wiktionary, set up like List of jōyō kanji, seems like an ok compromise, though I expect most users will just look at our entry that only gives the official unicode designation of "FIRE", roll their eyes at how obvious and unuseful that is, and not click through to the Wiktionary entry. With the "We have no article, here's a list of other places to look" they'd get from a redlink or failed search, they're at least a little more likely to. —Cryptic 18:51, 16 November 2023 (UTC)

  To me, a list with links to Wiktionary makes the most sense. It serves readers well when there is no encyclopedic content to write about, but also encourages the addition of encyclopedic content to list entries that might not have enough to justify individual articles. As a backup option if no such list exists, I still support redirecting to the Unicode page (and we should add Wiktionary links there as well). -- King of ♥ ♦ ♣ ♠ 19:18, 16 November 2023 (UTC)

  Update: With the addition of new options, I think Option 7 is also a very good (and creative) solution. While it does require adding a new class of acceptable mainspace pages (which currently consist of the Main Page, articles, lists, redirects, disambiguation pages, and set-index articles), I think emojis are important and distinct enough to deserve special treatment.

  This reminds me of Chinese-character disambiguation pages, which are a special exception to the rule that all pages must use Latin script. Because of competing priorities (we want to make redirects from terms in their native language, the characters have different romanizations, and ambiguous redirects should be disambiguated), the only solution is to allow disambiguation pages at non-Latin titles. Likewise, I think it is reasonable to invent a totally new paradigm here because emojis do not fit nicely into any of our existing ways of doing things. -- King of ♥ ♦ ♣ ♠ 23:37, 22 November 2023 (UTC)

  rule that all pages must use Latin script - huh? I wasn't aware of any such rule. * Pppery * _{it has begun...} 23:55, 22 November 2023 (UTC)

  Page titles must, not entire pages. WP:UE, and specifically for dab pages WP:DABNAME. —Cryptic 00:04, 23 November 2023 (UTC)

• (edit conflict) Option 4 is my first preference, with Draft:List of emojis (faces) and similar being the target for those that don't have a clear single target article or dab. I would also support hatnotes like 😗 redirects here, for information about the emoji see List of emojis (faces) as this seems the most useful to readers. Strongly oppose option 2b and option 5 as actively unhelpful to readers. Thryduulf (talk) 18:06, 16 November 2023 (UTC)
• Option 1 emoji's should not redirect to anything other than an article on the emoji or a list of emoji's article. Polyamorph (talk) 18:17, 16 November 2023 (UTC)
• Option 1 or 5 with equal preference, options 2-4 will inevitably continue the status quo of wasting way too much time arguing over emoji at RfD. _signed, Rosguill ^talk 19:23, 16 November 2023 (UTC)
• Option 4 as the best compromise. We don't know what readers are looking for, but I think this is the best guess. Certes (talk) 19:30, 16 November 2023 (UTC)
• Option 1 A reader who is looking for information on fire will search for "fire". A reader who wants information on the fire emoji will search for 🔥.There's also the messiness of trying to figure out what's unambiguous. Is 🔥 fire? flame? Should we base it on the common usage of that emoji to mean "lit" (aka Cool (aesthetic) or Hip (slang))? --Ahecht (TALK
  PAGE) 19:47, 16 November 2023 (UTC)

  See RfD: 🔥, the decision to keep was unanimous because the emoji name is unambiguous. Enix150 (talk) 07:58, 24 November 2023 (UTC)

  Technically it wasn't unanimous; I suggested soft redirecting. Edward-Woodrow (talk) 15:00, 24 November 2023 (UTC)

• Option 1 unless there is an article for the emoji already a list is a better idea. If I search for 🔥 I don't want to be redirected to Fire I'm not blind. If someone searches for the emoji they are searching for the emoji. The fire article gives no indication of what 🔥 is as a symbol, or why it might be used. -- LCU ActivelyDisinterested «@» °∆t° 20:11, 16 November 2023 (UTC)

  Obviously this should be read as opposing options 2a/b and 4, I also oppose option 5 (redirects are cheap). I do not support, but would not oppose option 3. -- LCU ActivelyDisinterested «@» °∆t° 20:14, 16 November 2023 (UTC)

  See RfD: 🔥, the decision to keep was unanimous. Enix150 (talk) 07:57, 24 November 2023 (UTC)

  Technically it wasn't unanimous; I suggested soft redirecting. Edward-Woodrow (talk) 15:01, 24 November 2023 (UTC)

• Option 2b There's always WP:IAR, but I find this most appropriate as a baseline. --BDD (talk) 21:01, 16 November 2023 (UTC)
• Option 4 or Option 2a: Every single emoji currently has a redirect on Wikipedia, and every emoji redirect discussion brought up this year has concluded in a keep/retarget decision, so deleting them would go against all the consensuses we've had so far. (See prior discussions here: 🤭, 👩‍💻, 🛋️, ⏫/⏬, 🫸/🫷, 🤪, 🙀, 👯‍♂️, 🫥, 👾, 🧑‍🦳, 👏, 💨, 😶‍🌫, 🤗, 😬, 🏚️, & 🔥) Enix150 (talk) 21:11, 16 November 2023 (UTC)

  Strongly oppose Option 2b & Option 5: Deleting everything does not serve the reader in any way, and it goes against all of the discussions we've had so far this year. Enix150 (talk) 05:27, 18 November 2023 (UTC)

• Option 5: It's unclear what people actually want when the copy/paste an emoji into the search box. Do they want information about the emoji itself, or about the concept(s) it represents? And often, there's more than one concept. Given that we can't answer this question without launching some kind of reader poll, I think it is best to delete all emoji redirects that try to guess at one answer or the other. Option 6 – soft redirect to wiktionary – is my secondfirst choice, and option 2b is my third. Okay... option 7 or 8 is my first choice; let's keep it local if we can; option 6 is my third. Edward-Woodrow (talk) 21:17, 16 November 2023 (UTC)
• I don't really have an opinion but I beg the eventual closer to find some result here, even if not a specific consensus – it doesn't need to be codified policy; even a summation of the arguments for each course of action will do. A straight no consensus is highly undesirable. In the absence of support for option 3, just like at RfD something analogous to an WP:NCRET would be appreciated. J947 † ^edits 22:27, 16 November 2023 (UTC)
• Option 3 This entire discussion feels like a lot of energy being spent unnecessarily - the community is coming its own decisions at RfD, and I see no reason why we can't just let it. * Pppery * _{it has begun...} 23:17, 16 November 2023 (UTC)

  I oppose options 7 and 8 - they amount to creating thousands of new articles by the back door without any consideration of notability criteria. * Pppery * _{it has begun...} 04:29, 22 November 2023 (UTC)

  Pppery, I view option 7 as a rich soft redirect/disambig. Option 8 could also be deployed through {{No article text}} / MediaWiki:Noarticletext and wouldn't require page creation. — Alexis Jazz (talk or ping me) 05:13, 22 November 2023 (UTC)

  Since, as Enix150 will remind us, the grand majority (if not all) emojis have redirects or pages on Wikipedia, there will be little to no actual page creation. Edward-Woodrow (talk) 13:29, 22 November 2023 (UTC)

• Any except 2b or 5 Deletion does not help our readers. As long as the target helps the reader identify the symbol, I don't have much of an opinion on whether 😀 goes to smile or Emoticons (Unicode block) or wikt:😀 or an undraftified Draft:List of emojis (faces). Anomie⚔ 23:27, 16 November 2023 (UTC)
• I'm a little irritated that this "RFC without presupposed options" has presented a long numbered list of presupposed options. I'm not sure which option to pick. King of ♥, whose sig contains an emoji, can't imagine why I'd want to use the search bar to find out what a particular emoji is. (I've got a guess about about his age, though, and it's "not quite old enough to need reading glasses".) Having 🔥 redirect to Fire and ♥ to Heart symbol are both perfectly fine. Sure, I might not be interested in reading a whole article about fire, but that's okay. Most readers only spend a few seconds on each page, because most readers are only trying to find out one or two little things, often "What's that?", and if I put that symbol in the search bar, I'll end up at Fire and have my question completely answered. In such cases, I really don't want to end up a long list of all possible emojis, so that having already searched for the emoji, I know have to search through the whole page to find out what the character is. I don't want them deleted; Wikipedia:Redirects are cheap, and these are useful (and, per WP:R#KEEP #5, I encourage editors to not tell me that you somehow know that I don't actually find them useful, even though I've just told you that I do). Even if they are used only a few times a week, they are still useful in those few times, and retaining that utility costs us nothing. WhatamIdoing (talk) 23:58, 16 November 2023 (UTC)

  I'm fine with ♥ redirecting to Heart symbol because it contains content about the heart emoji. But if it didn't exist, I would strongly oppose redirecting to Heart. -- King of ♥ ♦ ♣ ♠ 00:07, 17 November 2023 (UTC)

  Well, a symbol of love isn't really a vital organ, so I wouldn't necessarily redirect it there. I'd be more likely to choose Playing card suit or Hearts (suit). But imagine the existing Heart symbol article, only without any mention whatsoever of the emoji. That would still be my first choice for the target of such a link. WhatamIdoing (talk) 00:43, 17 November 2023 (UTC)

  On second thought, I would also support targeting a Heart symbol article that doesn't mention the emoji. But there's a big difference between that and Fire. For me, as long as the article is about a symbol then it's fine, but not if the article is about the broader topic. It's like the difference between Antidisestablishmentarianism (word) and Antidisestablishmentarianism. I got my analogy a bit mixed up; usually, the heart symbol does not represent a literal organ but rather the concept of Love. And that is the kind of target I would oppose, just like Fire. -- King of ♥ ♦ ♣ ♠ 04:20, 17 November 2023 (UTC)

  Heart symbol is the best target. More controversially, my second choice would be Heart. We shouldn't add interpretation by redirecting it to Love, and I'm not even going to think about 🍆. Certes (talk) 09:37, 17 November 2023 (UTC)

  IMHO, when people are searching for an emoji, they're not asking "What's that?" They're asking "What does that emoji mean?" If they see someone text, "Wow, that dress is 🔥🔥🔥" Searching on Wikipedia, they'll find 🔥 -> fire, so does that mean that dress is fire? Or does it mean the dress is "lit, super stylish, or even hot (as in attractive) or sexy"? [6] Some1 (talk) 02:35, 17 November 2023 (UTC)

  @Some1, when I am searching for an emoji, I'm usually trying to find out what it is. Keep in mind that I'm far more likely to be saying "Wow, that dress is machine washable, doesn't require ironing, and is on sale" than "Wow, that dress is 🔥🔥🔥". WhatamIdoing (talk) 03:47, 18 November 2023 (UTC)

• Option 2a or 4 These two seem to be the best for our readers --Lenticel ^(talk) 00:00, 17 November 2023 (UTC)
• Option 1, the meaning of emojis is not clearcut, and 🔥 is a case in point. Despite it being the standard example of an emoji with a clear meaning here, this is an emoji that receives actual everyday use and it emphatically does not usually mean fire. Dictionary.com even has an entry for 🔥: "It is used to signify that something is cool, awesome, exciting, or more colloquially, “on fire.” It can also convey that someone is sexy, (i.e., hot)...signifying that a person, object, album, movie, or so on, is “lit,”...sometimes the fire emoji is used to reference marijuana". CMD (talk) 00:56, 17 November 2023 (UTC)
• Option 1 Not all of these emojis have literal meanings that one can just redirect to. See Chipmunkdavis's 🔥 emoji example above. 💀 currently redirects to Skull even though it really shouldn't, because that emoji can also mean “I’m dying with laughter” or “I’m dead from laughing” (Dictionary.com's How Gen Z Uses Emoji: A Guide For Millennials). If an individual searches 💀 on Wikipedia to find out what that emoji means because they keep seeing their friends use it in their chats, would the Skull article really help them find their answer? I think not. Retargeting all other emoji redirects to the lists that the emojis appear on (e.g. Supplemental Symbols and Pictographs or Symbols, Pictographs Extended-A, etc.) would be the most efficient approach. The tables on those list articles could then be revised and expanded upon to include columns such as Description, Meaning, etc. (similar to the table in Draft:List of emojis (faces)). Some1 (talk) 02:24, 17 November 2023 (UTC) expanded on !vote, Some1 (talk) 00:46, 20 November 2023 (UTC)
• Option 1: If the lists would have descriptions (not just on hover) and the redirects had an anchor maybe, but if there's no better target sure.
  Option 2a: Worse version of option 4.
  Option 2b: Redirect cheap, deletion bad.
  Option 3: Meh, having some guideline is probably helpful.
  Option 4: Seems okay, this is an improved version of 2a?
  Option 5: Redirect cheap, deletion bad.
  Option 6: Seems interesting, but Wiktionary doesn't have entries for all emojis.
  How am I even supposed to vote on this. Can we like transclude the description, maybe from Wikidata, on the soft redirect so you don't have to actually follow it for the answer to the "what's that" question? — Alexis Jazz (talk or ping me) 11:02, 17 November 2023 (UTC)

  I agree, Option 2a and Option 4 should probably be merged, with Option 4 being the ideal choice. Option 6 is interesting too, but it would be a daunting task to create an entry for every emoji on Wiktionary. I strongly oppose Option 2b and Option 5 because deleting everything does not serve the reader in any way, and it goes against all of the discussions we've had so far this year. And yeah, having so many options makes tallying an actual decision pretty difficult if not impossible. Enix150 (talk) 17:42, 17 November 2023 (UTC)

• Option 2 or 6 Wiktionary does not cover every emoji, but there is no reason why it shouldn't. For example, we have wikt:💀 but no wikt:👿. –LaundryPizza03 (dc̄) 13:02, 17 November 2023 (UTC)
• Options 4 or 6, the latter for cases where the figurative meaning would turn the dab into a dictionary. Mach61 (talk) 02:08, 18 November 2023 (UTC)
• Option 6. If people want to look up the meaning of an emoji (which is what they're doing when they put an emoji into the search box), take them to an article that will explain the meaning: either a Wikipedia article about the emoji, if it exists, or, if no Wikipedia article exists, a Wiktionary article about the emoji (which will have more info than a list of emojis or no page at all). Option 6 gets the reader the information they're looking for. Levivich (talk) 02:05, 18 November 2023 (UTC)
• Option 6 is the most sensible because people pasting emojis into search are likely looking for dictionary treatment, not an encyclopedia article. Sandizer (talk) 02:24, 18 November 2023 (UTC)
• Comment: Option 6 would only work if there were Wiktionary entries for these emojis, but that isn't the case for most of them. This would require the creation of several thousand Wiktionary entries. Enix150 (talk) 05:09, 18 November 2023 (UTC)

  I agree with this; Option 6 doesn't solve this redirect problem since we'll still be dealing with emojis that don't have corresponding Wiktionary entries, which are most of them. The tables on the list articles (Options 1 and 4) could always be revised to include a 'Meaning'/'Definition' column. Some1 (talk) 12:56, 18 November 2023 (UTC)

  @Enix150 and Some1: Although, as someone (maybe Cryptic?) pointed out above, the blank wikt entries are still fairly useful, e.g. look at wikt:🤤 – it gives the unicode block number, has a big, easy-to-see picture of the emoji, and gives the name of the emoji which probably at least hints at its meaning. Edward-Woodrow (talk) 23:01, 18 November 2023 (UTC)

  Hovering over the 🤤 emoji at Supplemental Symbols and Pictographs shows the same info. As always, the tables on these articles could be revised and expanded upon e.g. to include a 'meanings' column, make the emojis larger, provide information in text to avoid having readers hover over the emojis, etc. Redirecting readers to non-existent/blank Wikitionary entries is nonsensical. Some1 (talk) 00:36, 20 November 2023 (UTC) Some1 (talk) 00:47, 19 November 2023 (UTC) Add to statement. Some1 (talk) 00:36, 20 November 2023 (UTC).

  A small part of the same info, and providing information only through hovering is inaccessible. —Cryptic 06:04, 19 November 2023 (UTC)

• Option 7 Alternatively option 8 would also be acceptable for me, likely combined with option 5, transcluding {{Character info}} through {{No article text}}. But a user who visits 🔥 or 😼 should be given something useful. — Alexis Jazz (talk or ping me) 20:58, 18 November 2023 (UTC)
• Option 7. I've been following these discussions for a bit without a very strong opinion. I think this "Emoji disambiguation" treatment is the best option I've seen yet. There'd need to be some sort of specialized dab template to use for the majority of cases where the emoji itself doesn't merit an article. —siroχo 09:16, 19 November 2023 (UTC)
• Option 7. I agree that this sort of emoji-dab layout would work quite well, and it's better than sending it directly to some sort of article when we don't have an article on that emoji. — Red-tailed hawk _(nest) 21:22, 19 November 2023 (UTC)
• Option 1 first choice, option 6 secoind choice. Redirecting 🔥 to Fire is completely absurd. Options 7 and 8 are not solutions to the question of where links/titiels like 🔥 should go, but only what to do with markup to the symbols after the user already gets to where they go, so they shouldn't even be in this list of options, and just confuse the matter.  — SMcCandlish ☏ ¢ 😼  07:53, 20 November 2023 (UTC); rev'd. 19:21, 20 November 2023 (UTC)
  • SMcCandlish, but only what to do with to markup the symbols after the user already gets to where they go I don't understand, did you make a typo somewhere?
    Option 7 and/or 8 could be shown on 🔥 instead of a redirect. For option 8 that could technically be done through MediaWiki:Noarticletext / {{No article text}}. — Alexis Jazz (talk or ping me) 08:16, 20 November 2023 (UTC)

    Yes. Fixed.  — SMcCandlish ☏ ¢ 😼  19:21, 20 November 2023 (UTC)

  See RfD: 🔥, the decision to keep was unanimous. Enix150 (talk) 07:55, 24 November 2023 (UTC)

• Option 7/8 is appealing and in my opinion the most helpful solution. If I understand it correctly, they will require little maintenance so I don't think lack of notability is a problem – I'd even be fine with formatting them in an article-like way. J947 † ^edits 03:00, 23 November 2023 (UTC)
• Option 1 - (Summoned by bot) Someone typing 🔥 would likely be looking for an article discussing the emoji itself, not the concept of fire in general. These emoji redirects should target articles about the emoji themselves. - Aoidh (talk) 18:30, 23 November 2023 (UTC)

  See RfD: 🔥, the decision to keep was unanimous. Enix150 (talk) 07:53, 24 November 2023 (UTC)

I've gone over the discussion and all the options. Here is my thoughts.

I oppose 2b, 3, 5, and 8. 2b and 5 because they support deletion of emoji redirects. I believe all emojis are valid search term. 3 adds unnecessary work at RfD. The last month or two of emoji deletion disscussions are evidence where this is compeltely unhelpful. 8 is a personal taste opinion, but I think it's just visually bad and it also doesn't help with the actual issue as it doesn't really offer enough information for it to be a non-redirect. And if it was added to the redirect, most readers won't see it anyways.

I support 1 and 4. These brings the reader to the most viable target we have to offer.

I'm neutral with 2a. This seems like 4 but with less of information on how to handle most situations.

I find 6 and 7 problamatic. 6 is under the assumption that every emoji has an entry on Wikidata. Has that been checked? What if there isn't? Do we now create one there? What if entries are deleted there, would we be informed? It's hard for me to support being dependent on a different website. While I don't dislike the style of 7, that small piece of text requires a huge amount of modules to support it. I really don't think that is necessary, but even if it was, who here is going to take over that and support it when issues arise? Also, the RfC's question is about emoji redirects and option 7 turns these into stubs. While I don't oppose that, that needs to be made clear. Gonnym (talk) 11:00, 24 November 2023 (UTC)

Gonnym, 6 is under the assumption that every emoji has an entry on Wikidata.
You mean Wiktionary. And no, they don't. Wikidata however most probably does, and if they don't it's within their scope for us to create. (and we could track this)
While I don't dislike the style of 7, that small piece of text requires a huge amount of modules to support it. I really don't think that is necessary, but even if it was, who here is going to take over that and support it when issues arise?
Option 7 can work without any of the imported modules. It can work 100% on {{Wikidata}}. I'm reworking option 7 to use Module:Unicode data if it exists for the basic information with Wikidata fallback as at least Cryptic doesn't like Wikidata. If the modules break and nobody can fix them you can quite easily switch to using Wikidata instead.
Option 8 does depend on modules, but the parts from that which we actually need are limited. I just imported {{character info}} with all its dependencies, but I don't think we'll end up using (all of) that. — Alexis Jazz (talk or ping me) 11:49, 24 November 2023 (UTC)

Yes, I meant Wiktionary for option 6. Thanks for the correction. Option 8 is just not really helpful (or visually pleasing in my opinion). If/when option 7 has a different implementation I'll check it again. I just cannot currently support it. Gonnym (talk) 12:02, 24 November 2023 (UTC)

Gonnym, do you like User:Alexis Jazz/Emoji / 🔥 revision 1185755899 now? — Alexis Jazz (talk or ping me) 12:36, 24 November 2023 (UTC)

• 6, 7, or 1 in order of preference, because they are mechanistic. Any option that involves editors discussing and interpreting the meaning of emojis without enough RS to achieve notability for a dedicated page will lead to endless 💩 Sennalen (talk) 23:38, 26 November 2023 (UTC)

Discussion (emoji redirects)

Attention @A smart kitten, ActivelyDisinterested, Awesome Aasim, BDD, BilledMammal, CaptainEek, Certes, Chipmunkdavis, ClydeFranklin, Cryptic, Edward-Woodrow, Elli, Enix150, Enos733, Espresso Addict, Firefangledfeathers, Frostly, Gonnym, Hey man im josh, Illusion Flame, Isaacl, Isla, Ivanvector, J947, King of Hearts, Kusma, LaundryPizza03, Lenticel, Levivich, Martin Tauchman, ObserveOwl, Patar knight, Polyamorph, Pppery, Qwerfjkl, Rosguill, Sandizer, Serial Number 54129, Shells-shells, Skarmory, Some1, Stifle, TartarTorte, Tavix, The Corvette ZR1, Thryduulf, Utopes, Walt Yoder, WhatamIdoing, and Yoblyblob: I'm notifying you here because you either participated in the previous discussion, or you were notified the last time. I hope I didn't miss anyone. microbiologyMarcus ^{(petri dish•growths)} 17:43, 16 November 2023 (UTC)

Yes? The 🏎 Corvette 🏍 ZR1^{(The Garage)} 17:44, 16 November 2023 (UTC) Now I understand. Thanks Marcus! The 🏎 Corvette 🏍 ZR1^{(The Garage)} 17:52, 16 November 2023 (UTC)

• My issue with these titles which comes up in nearly every discussion about them, and has again with the fire emoji above, is that very little of the information we're publishing with respect to these glyphs is verifiable. What do reliable sources say is the meaning and common usage of the fire emoji? Nobody has yet provided a source; instead many well-meaning editors have added their own opinions as to what it represents, and now we're preparing a draft list of those almost entirely unsourced opinions to publish in an encyclopedia. We're not supposed to do that. If we brought up a discussion on any other topic about how best to manage a collection of editors' unsourced opinions in mainspace, the answer would be utterly simple: delete it. If we dump the opinions out of these discussions and base them solely on information previously published in reliable sources, like we do for every other topic, then in the vast majority of cases these glyphs should redirect to a page with technical information only, because that is the limit of reliably-sourced information about them. A tiny proportion will have more reliably-sourced information available and those can be dealt with case-by-case. Ivanvector (^Talk/_Edits) 10:52, 17 November 2023 (UTC)

  Meh, we've always relaxed NOR and V with regards to names (in the form of Foobar G. Smith, also known as Foo Smith). You don't need a citation from a source specifically noting the different names Mach61 (talk) 14:53, 17 November 2023 (UTC)

  OTOH, you don't want editors redirecting an icon away from its literal meaning because "I just know that 🔥 (U+1F525) means sexy and not fire, even though it's official name is fire". But I'm sure there are sources (perhaps not of the highest quality), because someone's got to explain to Mrs Grundy what her grandchildren are saying. WhatamIdoing (talk) 03:52, 18 November 2023 (UTC)

  If Mrs Grundy does not want a formal source like "the Fire emoji (🔥) is frequently used as a positive force marker, from the positive idioms 'on fire' or 'lit'.", a source of not the highest quality can be found in this article by The Sun . On emojis as a whole, I found this interesting small survey of emoji meaning ("human agreement about the context-free meaning of emojis ranges from completely unambiguous (16 emojis) to indistinguishable from random (55 emojis), with emojis covering the whole spectrum of ambiguity"), and I recommend having a look through this paper covering the interpretation of emoji by courts. Our Emoji article drops four sources to reinforce that 🍆 means penis, while also noting that this meaning of 🍆 led to the word "eggplant" being used as a synonym for penis. CMD (talk) 07:37, 20 November 2023 (UTC)

  Yeah, we don't know what people are using emojis for. Did You Know, 😹 means ketamine? and 🤷🏾‍♀️ means WTF (Internet slang)? and 🌻 means "you're doing a good job; it's ok"? and ☃️ means "it's cold in the office; can a lead please contact maintenance to have them turn up the temperature"?

  Well, they don't mean those things. Except sometimes. We shouldn't decide things like that for the reader. Folly Mox (talk) 09:10, 20 November 2023 (UTC)

BTW, the section heading says "RFC", but it's not listed as an WP:RFC. @MicrobiologyMarcus, was that intentional? WhatamIdoing (talk) 22:08, 21 November 2023 (UTC)

Mea culpa—yup, that was my mistake, this is my first time submitting such to the VP and that escaped me in my review of the formatting. microbiologyMarcus ^{(petri dish•growths)} 13:46, 22 November 2023 (UTC)

Would you rather get it listed as an RFC (just add the template to the top of the existing section), or take the "RFC" out of the section heading? WhatamIdoing (talk) 18:48, 22 November 2023 (UTC)

@WhatamIdoing: based on the way this is going (trending no where near a consensus as far as I can tell, though I think recently people have preferred the DAB-like templates) I'm guessing this may have to be posted again if anyone wants to do any consensus building or advocacy. What would you (or the community) recommend? I've never done something like this before, so I'd like to know which makes more sense in this moment? microbiologyMarcus ^{(petri dish•growths)} 19:43, 22 November 2023 (UTC) For what it's worth, I'm okay with either happening. microbiologyMarcus ^{(petri dish•growths)} 19:44, 22 November 2023 (UTC)

@MicrobiologyMarcus, what really matters is whether people basically agree to something. Wikipedia is not a bureaucracy, so a decision like this doesn't have to be an RFC. But years later, someone looking at an archived copy of this discussion might assume from the section heading that it used the RFC system (basically an advertising mechanism), and we wouldn't want to leave them with a misconception.

You can, even at this stage, list it as an RFC, since converting an existing discussion into an RFC is explicitly and intentionally permitted. All you have to do is edit this section and paste this wikitext code at the top, above your first comment (which is already a nice RFC 'question'): {{rfc|policy|style}} Then save the page. That's all it would take. WhatamIdoing (talk) 22:47, 22 November 2023 (UTC)

Thanks!! 😊 microbiologyMarcus ^{(petri dish•growths)} 02:44, 23 November 2023 (UTC)

• Every single emoji currently has a redirect on Wikipedia, and every emoji redirect discussion brought up this year has concluded in a keep/retarget decision, so deleting them would go against all the consensuses we've had so far. (See prior discussions here: 🤭, 👩‍💻, 🛋️, ⏫/⏬, 🫸/🫷, 🤪, 🙀, 👯‍♂️, 🫥, 👾, 🧑‍🦳, 👏, 💨, 😶‍🌫, 🤗, 😬, 🏚️, & 🔥) Enix150 (talk) 06:28, 22 November 2023 (UTC)

@MicrobiologyMarcus and WhatamIdoing: Is it reasonable to have a moratorium on further options being added to the RfC, as that would only create more confusion? Edward-Woodrow (talk) 13:31, 23 November 2023 (UTC)

@Edward-Woodrow: personally, I think a better option would be to summarize the votes and drop the ones that seem to have been opposed most frequently above and then start a voting period where you have an option for (1) DAB-like templates, (2) list pages, or (3) as is/no consensus because that seems to be what is transpiring. There seems to be a clear consensus against blanket deletes (although with some supports). The votes for the list pages identify issues such that they aren't complete or that there might be multiple pages (one for all, one for just faces). That's my personal opinion, it seems that this "RfC" has turned into a proposing options one, which may be my fault: I've never formatted one before and I was just following up on the previous thread. Now that everyone has had a chance to suggest options, I think this is the logical step. But I'm not sure if that's procedure. microbiologyMarcus ^{(petri dish•growths)} 17:34, 23 November 2023 (UTC)

@Edward-Woodrow: Said with love, but I'm assuming your suggested option 6 fits nicely into one of the template suggestions. I'm hesitant to say no more suggestions, that's not really feasible and prevents suggestions of brilliant out of the box ideas that others might have missed, like the template from User:Alexis Jazz. microbiologyMarcus ^{(petri dish•growths)} 17:44, 23 November 2023 (UTC)

I understand where you're coming from, and I'm sympathetic to how complicated this occasionally is for someone who is trying to write a summary statement, but an RFC is a Request for Comment, not a "request for votes", and that means that editors can say anything during an RFC that they would otherwise be allowed to say during a non-RFC discussion. This is one of the strengths of the RFC approach, since it prevents editors from being trapped in false dichotomies, and sometimes even results in the proposal of brilliant compromise. WhatamIdoing (talk) 20:22, 23 November 2023 (UTC)

I do appreciate that fact, that's why I do think if this were to be posted again like I said above with narrowed options, I understand that 'votes' is a loaded word, which is why I suggested a as-is/no consensus option. AFAIK I don't think there's a way to actually put something to a vote. I do see other RfCs on this page from time to time that are straight up and down support-oppose which, while not votes, are a lot more simpler to keep tract of than 8 different options that each person has their own opinion on. Unfortunately, reading the above, I think a lot of people aren't happy with the status quo but there's no organized drive to or consensus to land on any alternative. microbiologyMarcus ^{(petri dish•growths)} 21:34, 23 November 2023 (UTC)

MicrobiologyMarcus, IMHO let this discussion run for a while longer (few days, a week) and create a new thread with the options narrowed down. Always include a "status quo" option, otherwise you get lesser evil or cake or death situations. I think at least SMcCandlish dismissed options 7/8 because the title of this RfC says "emoji redirects" and options 7/8 aren't redirects.
I think there's a chance of consensus emerging in a new well-worded thread with the options narrowed down. Feel free to draft that in user space and ask me (and/or others) to have a look to try and shoot holes in it. — Alexis Jazz (talk or ping me) 04:25, 24 November 2023 (UTC)

In re people aren't happy with the status quo: I'm not sure people actually know what the status quo is, but glancing through the responses and noting the comment about none of the RFDs have been ending in deletion, perhaps the status quo is what people want (namely, to not delete them). WhatamIdoing (talk) 18:52, 24 November 2023 (UTC)

With one or two exceptions, option 4 approximates the consensus of nearly all the recent RfD discussions about emoji redirects. Indeed emoji redirects that match that option don't often get nominated. Thryduulf (talk) 18:57, 24 November 2023 (UTC)

Meta: There are more than 100 comments in this discussion (the longest on this page), and as a result, this page is over 300K long (~10X WP:SIZESPLIT, and a length that some editors report having problems at, especially on a smartphone). If we expect many more comments in this discussion, please cut and paste it to a dedicated page, e.g., WP:Requests for comment/Deletion of emoji redirects. (If it feels like the conversation is dying down, then it may not matter.) WhatamIdoing (talk) 23:27, 26 November 2023 (UTC)

Comment: Just to bring up one specific case that I've found useful: redirects from flag emoji, such as 🇷🇸. Nice quick way to identify an unfamiliar flag when used as an emoji without further context. So I'd politely request that, whatever is decided for other emoji redirects, those stay. (I should note I'm utterly unfamiliar with RfD policies, so please consider this as a comment from a reader and not a substantive policy argument.) Gaelan 💬✏️ 11:31, 29 November 2023 (UTC)

Purge Block Logs after X years

While I think utilizing a block log is beneficial, people change and just like in the regular world, there should be a purge after a certain number of years. I think 5-10+ years is a good enough number to start the discussion with. Sir Joseph ^(talk) 17:56, 17 November 2023 (UTC)

How about 10 years, or twice the duration from the first block to the most recent block (including blocks of socks), whichever is longer. Jc3s5h (talk) 20:41, 17 November 2023 (UTC)

So if a person got blocked once, then in 10 years, it could be hidden, but if they were blocked twice, removing the oldest would require 10 years plus no blocks in the most recent five years? Or:

• Given a 2010 block and a 2014 block, with none since: First block hidden in 2020, second block hidden in 2024 (10 years).
• Given a 2010 block and a 2019 block, with none since: Everything remains visible (until at least 2028 [twice the duration between the first block and the most recent block]).

WhatamIdoing (talk) 23:32, 18 November 2023 (UTC)

Sir Joseph, are you talking about purging just logs or also the blocks themselves?
No unblock request will ever succeed again after a purge because everyone will simply assume the worst. — Alexis Jazz (talk or ping me) 20:45, 17 November 2023 (UTC)

The real problem is that people read too much into block logs. Or, more to the point, people read too much into their own block logs. My RfA carried no small amount of controversy, and yet no one had concerns about my indefinite block in 2012. The block log is an objective record of that incident, of the fact that for 3 hours an admin thought the project was better off without me. What point is served by hiding that? I don't think it would really change anyone's opinion of me—hopefully, after 10 years, they associate me more with something other than that block. This just seems like caving in to people's anxieties that a past block defines them. The better response is to tell people that they're judged much more by their reputation now than their reputation 10 years ago, both for better and for worse. -- Tamzin^{[cetacean needed]} (they|xe|she) 20:52, 17 November 2023 (UTC)

It's good for editors to see that admins are human, reputations are reparable, and old blocks may not even block one from becoming an admin. O3000, Ret. (talk) 21:11, 19 November 2023 (UTC)

Absolutely not. We shouldn't read too much into people's old blocks, but purging has many bad side effects. For example, if somebody has been blocked repeatedly, deleting the early blocks makes it more difficult to understand the later blocks. We also don't want people to let one of their accounts lay dormant for five years after receiving a block, just to wait out the log. —Kusma (talk) 21:10, 17 November 2023 (UTC)

No thank you, this is an important part of administrator transparency. We should not hide actions taken by administrators just because some time has passed. — xaosflux ^Talk 21:24, 17 November 2023 (UTC)

Sorry? You're proposing we reduce transparency? Edward-Woodrow (talk) 13:51, 18 November 2023 (UTC)

• Strong Oppose per the above. Good faith proposal, but this is just a bad idea. Transparency is extremely important, especially where admin actions are involved. -Ad Orientem (talk) 21:12, 19 November 2023 (UTC)
• Absolutely strong oppose. Logs are logs. They should not go down the memory hole after some specified period; they are meant to show what happened. In my experience, people are very rarely concerned with very old block log entries; I've got one in mine from 2006 and no one considers it in any way significant any more. But it is still a part of both my history and that admin's history on the project, so it should be retained. We should no more purge "old" block logs than we should purge "old" edit histories. Seraphimblade ^{Talk to me} 21:16, 19 November 2023 (UTC)
  • Seraphimblade, note that old edit histories can't be purged for legal reasons. They're needed for the "attribution" part in Creative Commons Attribution-ShareAlike. — Alexis Jazz (talk or ping me) 23:10, 19 November 2023 (UTC)

    I'm well aware of that. But even if it weren't for that, I would be firmly against any redaction or purging of public logs, be they edit histories, admin actions, or whatever else have you. The whole idea is that anyone can see what happened, be that twenty minutes or twenty years from when it was done. Seraphimblade ^{Talk to me} 23:43, 19 November 2023 (UTC)

• I can see some merit in this idea. There are times that I've blocked good editors which was necessary at the time but it seems a shame that people will draw conclusions from that block even many years after the issue was resolved. HJ Mitchell | Penny for your thoughts? 21:21, 19 November 2023 (UTC)
• I think the problem is real, but this is not the right solution. Tamzin's block log (or mine) isn't really a great example, because the unblock reason is pretty clear. What about those 24-hour edit warring blocks that just expire without explanation? Or the really immature editors who get blocked a half dozen times (for good reason), then finally grow up? A block log like that can leave you perpetually more likely to get blocked, or reported to ANI, in the future. "Oh, previously blocked twice for sockpuppetry? No need to check with CU if that's a joe-job, obviously they're just up their old habits..." or "Oh, five edit warring blocks? Yeah, this time they weren't quite at 3RR and maybe there's kinda sorta a BLP exception, but obviously this is a troublemaker...", and so on.
  Maybe, instead, just make the old blocks a little harder to find. That is, one extra click, each time, on a "show blocks older than X years" checkbox. The act of clicking will hopefully force you to slow down and think "these blocks are old, maybe this person has changed".
  Or maybe, just color the old blocks differently. As in, slightly faded (but still barely WCAG compliant) text. Again, this will just slow you down, and make you notice the date. Suffusion of Yellow (talk) 21:45, 19 November 2023 (UTC)
  • I would support this. Divide the subject into "Recent blocks" (perhaps within the last five years), with a click to get to "Older blocks", which appears only if there are older blocks. BD2412 T 22:00, 19 November 2023 (UTC)

    +1. There are times that we need to review an editor's block log, for example there could be a years-long pattern of behaviour, but forcing people into an extra click or showing logs in a different colour might make people pause before they go dredging up ancient history. HJ Mitchell | Penny for your thoughts? 22:08, 19 November 2023 (UTC)

    That idea, I could get behind. The logs should certainly not be purged entirely, but an extra step to view them which also emphasizes "These happened long ago" does not violate that and could very much work. Seraphimblade ^{Talk to me} 23:41, 19 November 2023 (UTC)

  • I like this idea. Would suggest the click over the different color, you can't fade it enough while remaining WCAG compliant. — Alexis Jazz (talk or ping me) 23:35, 19 November 2023 (UTC)
• Oppose - yes people change, but thats also demonstrated by a block log showing no blocks in ten years. I dont see the gain here, and I say that as somebody who would see all of their past indiscretions hidden away by this proposal. nableezy - 23:23, 19 November 2023 (UTC)
• Support For as long period like 10 years (not 5 years). People will inevitably read too much into them, including not factoring in for age. And something 10 years old is not relevant for any purpose for looking at a block log. North8000 (talk) 23:31, 19 November 2023 (UTC)

  @North8000 for your 10 years, when would you start counting? — xaosflux ^Talk 23:40, 19 November 2023 (UTC)

I'd go 10 years before the present date. North8000 (talk) 02:01, 20 November 2023 (UTC)

@North8000 so for example here is a block log entry, it is more than 10 years old, it is still currently active - are you proposing we should purge this, leaving the user blocked with no explanation? Special:Redirect/logid/445581. — xaosflux ^Talk 20:03, 20 November 2023 (UTC)

@Xaosflux: I hadn't thought about 10 year old still-active blocks. And the large amount of dead accounts (socks etc.) covered by that. So I'd need to change my recommendation to 8 (or 10) years after the block ended. North8000 (talk) 20:23, 20 November 2023 (UTC)

(ec) Surely it would have to be X years after the block ends? It makes no sense to purge a 10-year block which ended yesterday but not a 31-hour block which started and ended nine years ago. But I still don't support any of this anyway. Certes (talk) 20:26, 20 November 2023 (UTC)

• Does this take WP:DENY into account? Is hiding old blocks from non-sysops an (feasible) option in that case, then? FMecha (to talk|to see log) 04:59, 20 November 2023 (UTC)
• Oppose, unless this were more comprehensive, like voiding/suppressing topic bans, interaction bans, and other editing restrictions after a decade or whatever, too, not just blocks. We have no interest in hiding the fact that someone was so disruptive they got a long block, but memorializing forever that they were less disruptive and just got a T-ban or other lesser restriction. Even then I might still oppose, since I'm not sure this is ultimately in the best interests of the community as a whole, even if it would be nicer/fairer to various particular invididuals who have matured as editors. It would give a green light to too many who have not.  — SMcCandlish ☏ ¢ 😼  07:57, 20 November 2023 (UTC)

  That's a good point. We shouldn't be tricked into assessing someone with visible minor sanctions as more disruptive than someone with hidden blocks. Let's leave it to the reader to decide whether a 10-year-old block is relevant. It may be for some purposes but not for others. Certes (talk) 10:03, 20 November 2023 (UTC)

• In response to the idea of "hiding" old blocks from the logs, I would oppose anything that makes links to old blocks no longer work or require extra clicks. I could be persuaded to have a new "recent blocks" thing that is prominently displayed from the contributions page instead of the full block log, but the logs should be fully and easily accessible to those who want to see them. —Kusma (talk) 11:45, 20 November 2023 (UTC)
• Personally I think this is more of an issue with our culture. We expect that a good user to do everything perfect and we tend to forget that failing is also a way for us to learn to be better in the future. CactiStaccingCrane (talk) 11:46, 20 November 2023 (UTC)

Visibility of edit changes in mobile

When editing on my Android phone, I do not see a Changes page or display, only a Preview of rendered edit. Does functionality exist to show Changes, or can it be added? Haven't found discussion of this issue. DonFB (talk) 21:22, 19 November 2023 (UTC)

DonFB, your question isn't really a proposal. It's probably better asked at the Village Pump for technical matters. Seraphimblade ^{Talk to me} 23:47, 19 November 2023 (UTC)

I was thinking of it as a proposal to add the function, but hedged my comment, because I'm not certain it does not exist. But I can ask there also. DonFB (talk) 23:52, 19 November 2023 (UTC)

It looks like the mw:Mobile visual editor has this option, but I don't see it in the mobile wikitext editor. You don't need a community consensus to ask the mw:Editing team to improve the editing tools; they'll do the research when/if it fits in with any of their assigned projects. You can reach them through @Trizek (WMF) or leave a note at their page on MediaWiki.org. WhatamIdoing (talk) 05:28, 20 November 2023 (UTC)

@DonFB, are you editing on the Android App, or do you edit using the mobile website (in your browser)? Trizek_(WMF) (talk) 14:06, 20 November 2023 (UTC)

I don't use app; am using the mobile website. Is the app a Playstore thing or available from Wikimedia? DonFB (talk) 19:25, 20 November 2023 (UTC)

Autoprotect recent deaths on the Main Page

From what I have seen, they are usually easy vandalism targets, and semi-protecting them similarly to TFAs until they automatically get pushed off would prevent this. DrowssapSMM (talk) (contributions) 12:57, 20 November 2023 (UTC)

Compared to TFAs, these are much more likely to benefit from additional non-vandal edits. We should keep them open for editing as much as possible. —Kusma (talk) 13:55, 20 November 2023 (UTC)

• Strong Oppose not only per Kusma's reasoning but also on principle. We should not WP:PREEMPTIVEly protect pages. We are the encyclopedia anyone can edit and we should keep as close to that as possible. Edward-Woodrow (talk) 20:44, 20 November 2023 (UTC)

• Withdraw proposal. After reading these responses, I have concluded that this is definitely an idea of the bad variety. I did not know about WP:PREEMPTIVE, so thank you for bringing that page to my attention. DrowssapSMM (talk) (contributions) 01:24, 21 November 2023 (UTC)

Page moving sandbox

This page moving sandbox would be a sandbox where, mainly new, but maybe from time to time, an experienced editor, would practice their page moving. There would be a few ground rules, such as the two below:

1. The page it is moved to must stay in the Wikipedia: namespace.
2. The page it is moved to must not be inappropriate or offensive.

To reset this sandbox, a user would move the page back to "Wikipedia:Page moving sandbox" or whatever this page is named. Opinions, comments, questions, anyone? ThatOneWolf ^{(talk|contribs)} 00:41, 21 November 2023 (UTC)

@ThatOneWolf this would likely end up breaking and causing admin work; if someone wants to test how to move a page they can move their own user sandbox to another name (e.g. User:ThatOneWolf/sandbox/test to User:ThatOneWolf/sandbox/test2). — xaosflux ^Talk 01:21, 21 November 2023 (UTC)

Yes, I guess I didn't really think about that. I'm always thinking about external wikis, and one of them only needs autoconfirmed status to suppress redirects. That's not the case here, and an admin would have to delete the redirects to reset. Totally forgot that. ThatOneWolf ^{(talk|contribs)} 03:31, 21 November 2023 (UTC)

More barnstars for WikiLove

Hello, I am proposing the following barnstars be integrated towards WikiLove throughout Wikipedia:

The Most Improved Editor's Barnstar	{{subst:The Most Improved Editor's Barnstar|1=message ~~~~}}	The Most Improved Editor's BarnstarThe Most Improved Editor's Barnstar The Most Improved Editor's Barnstar is awarded as part of editor retention efforts, to editors striving to learn and adopt best practices of the project, aiming to improve their contribution. Introduced by Santasa99 on 16 January 2021.
The Anti-anon Barnstar	{{subst:The Anti-anon Barnstar|1=message ~~~~}}	The Anti-anon BarnstarThe Anti-anon Barnstar The Anti-anon Barnstar is awarded to editors who have encouraged and/or assisted unregistered users to join the Wikipedia community. Introduced by Jerium on 6 November 2023.

Jerium (talk) 19:50, 21 November 2023 (UTC)

@Jerium, I like these. I wonder if that last one could have a new name, though. IPs aren't anonymous, and people who encourage them to register aren't "anti" them. WhatamIdoing (talk) 21:56, 21 November 2023 (UTC)

Yeah, I like them. Like WhatamIdoing said, they are very nice additions, if you change the last one. ThatOneWolf ^{(talk|contribs)} 21:59, 21 November 2023 (UTC)

WhatamIdoing I based the title, partial on the criteria, and design on Template:user anti-anon. I'm fine with changing the title, someone just come up with one. Jerium (talk) 22:05, 21 November 2023 (UTC)

@Jerium: Maybe something like Recruiter Barnstar? Or, we could do something like IP account suggester. Maybe one of those? ThatOneWolf ^{(talk|contribs)} 22:16, 21 November 2023 (UTC)

@ThatOneWolf, "recruiter" seems to have the right tone. Schazjmd (talk) 22:18, 21 November 2023 (UTC)

IMO, I do like "Recruiter Barnstar" better than the other one. ThatOneWolf ^{(talk|contribs)} 22:19, 21 November 2023 (UTC)

I also like the "Recruiter" idea. WhatamIdoing (talk) 18:46, 22 November 2023 (UTC)

• Done I've gone and moved the template to "The Recruiter Barnstar", but how do these get added on the WikiLove throughout Wikipedia for everyone to use? Jerium (talk) 19:11, 22 November 2023 (UTC)

  @Jerium, it looks like the request would need to be made at MediaWiki talk:WikiLove.js. However, looking at previous requests on its talk page, they suggest getting consensus at Wikipedia talk:WikiProject Wikipedia Awards first. Schazjmd (talk) 19:40, 22 November 2023 (UTC)

Schazjmd It makes no sense getting consensus from there, when I am WP:WPWPA. I am the current lead for making new barnstars and remastering older ones to meet WP:B2G (see barnstars made) once Antonu stopped editing. Jerium (talk) 19:55, 22 November 2023 (UTC)

The names of both of these are problematic. The first implies a contest or review process by the community to select a single person as "most improved", but that's not what it is (and we wouldn't want such a process). Might be better as "Greatly Improved Editor" or something. The second is even more obviously wrongheaded, in setting itself up as opposition to anonymous editors. This should probably be more like "Registration Helper Barnstar". And the text in in it wonky as well. "Unregistered" (i.e. anon IP) users are still part of the Wikipedia community, just less integrated into it. Maybe somethign like "encouraged or assisted unregistered users to more fully join the Wikipedia community by creating accounts".  — SMcCandlish ☏ ¢ 😼  20:49, 23 November 2023 (UTC)

The Anti-anon was changed to the “ Recruiter Barnstar” already, and I like “Greatly Improved Editor Barnstar “. Jerium (talk) 21:30, 23 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/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"

Add reuters

• support because reuters is better than AP (in its scope), and NYT (in everything).--RZuo (talk) 15:19, 24 November 2023 (UTC)
• Oppose in favor of removing all individual news outlets. {{u|Sdkb}} ^talk 17:16, 24 November 2023 (UTC)
• Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)
• Neutral: Reuters is ok to add but I'm not sure we need many more links. Nemo 07:12, 29 November 2023 (UTC)

Add BBC

• support because bbc news is probably the most reputable among the most visited news websites, and the most visited among reputable news websites. and it's free, no login and whatnot.--RZuo (talk) 15:19, 24 November 2023 (UTC)
• Oppose in favor of removing all individual news outlets. {{u|Sdkb}} ^talk 17:16, 24 November 2023 (UTC)
• Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)
• Oppose in favor of something more WP:WRS-like, as suggested just above. We don't have links to individual scientific journals; why should we have links to individual news outlets? XOR'easter (talk) 17:52, 28 November 2023 (UTC)
• Oppose: BBC is usually ok but it's even more prone to the political winds of one country; not suitable. Nemo 07:12, 29 November 2023 (UTC)

Add WSJ

• support because wsj is better than nyt by having higher circulation (List_of_newspapers_by_circulation#Top_newspapers_by_circulation) and fewer scandals (nyt has a List of The New York Times controversies but wsj doesnt).--RZuo (talk) 15:19, 24 November 2023 (UTC)
• Oppose in favor of removing all individual news outlets. {{u|Sdkb}} ^talk 17:16, 24 November 2023 (UTC)
• Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)
• Oppose — the WSJ hard paywall makes the site impractical to use for a large number of editors, and it goes against Wikipedia's free-content ideals. —pythoncoder (talk | contribs) 04:15, 27 November 2023 (UTC)
• Oppose in favor of a general custom search engine, as suggested above. We go through the trouble of identifying "generally reliable" sources; we might as well benefit from all that work. As to the point about controversies raised above, plenty of those at the NYT have been about its editorial positions rather than its reporting, and, well, the WSJ is no stranger to that, either. I don't see why circulation is relevant in this context. XOR'easter (talk) 17:44, 28 November 2023 (UTC)

Add The Times

• support because The Times is better than nyt. for example, a company has created an archive of it for scholars to study it. do you see people doing that for nyt? as the most important newspaper of a country that once ruled many countries around the world, it reported a lot more on news around the world for a much longer period, compared to the usa-centric nyt.--RZuo (talk) 15:19, 24 November 2023 (UTC)
• Oppose in favor of removing all individual news outlets. {{u|Sdkb}} ^talk 17:16, 24 November 2023 (UTC)
• Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)
• Oppose in favor of a general custom search engine, as suggested above. We go through the trouble of identifying "generally reliable" sources; we might as well benefit from all that work. XOR'easter (talk) 17:45, 28 November 2023 (UTC)
• Oppose, it seems even more paywalled. Nemo 07:12, 29 November 2023 (UTC)

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 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.

• Support as proposer. {{u|Sdkb}} ^talk 17:02, 24 November 2023 (UTC)
• Support: hell, same. jp×g🗯️ 20:39, 24 November 2023 (UTC)
• that's exactly my point when i raised my objection to nyt back on 13 July 2023 Wikipedia:Village_pump_(proposals)/Archive_203#Replace_nyt_with_reuters. there had never been any argument for why it's chosen over all other sources. yet it took 125 days(!) for enwp to come to a conclusion of adding AP and not removing nyt, and no one has over the 125 days come up with argument for why nyt was chosen over other organisations but only some condescending jokers kept lecturing me.

  so here they go, to balance out the 2 american sources, at least 2 non-american must be added. :) RZuo (talk) 07:12, 25 November 2023 (UTC)

  • remarkably, after seeing that enwp would reach no agreement to replace nyt, i had already said nyt should be removed on 31 August 2023 Wikipedia:Village_pump_(proposals)/Archive_203#Remove_nyt. "i told you so..." :) RZuo (talk) 07:18, 25 November 2023 (UTC)

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

• 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)

  • @Uncle G: somewhat questionable that it gives such prominence to Google - see Searx + Startpage.com, as per my comment below. Boud (talk) 13:19, 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)

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 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)
• 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)
• 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)

• 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)

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)

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)

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

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)