The policy section of the village pump is intended for discussions about already-proposed policies and guidelines, as well as changes to existing ones. Discussions often begin on other pages and are subsequently moved or referenced here to ensure greater visibility and broader participation.
If you wish to propose something new that is not a policy or guideline, use Village pump (proposals). Alternatively, for drafting with a more focused group, consider starting the discussion on the talk page of a relevant WikiProject, the Manual of Style, or another relevant project page.
For questions about how to apply existing policies or guidelines, refer to one of the many Wikipedia:Noticeboards.
If you want to inquire about what the policy is on a specific topic, visit the Help desk or the Teahouse.
This is not the place to resolve disputes regarding the implementation of policies. For such cases, consult Wikipedia:Dispute resolution.
Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after 7 days of inactivity. To keep this page's size accessible, discussions with more than about 100 comments should be split to a separate page.
Though the new AI policy technically only applies to editing, Grokipedia is an AI-generated encyclopedia. Would its use as a reference be prohibited according to the rules on AI? (also, since it's a Wikipedia clone, it'd likely cause citogenesis).
Grokipedia is not (considered) a Wikipedia. Wikipedias are an example of wiki, wikis in turn are (almost always) examples of user-generated content. It is user-generated content that is regarded as unreliable. Grokipedia is not directly user-generated content (although as a partial derivative of Wikipedia it does contain such content) but that is only a minor consideration in why it is considered unreliable, the major ones being that it is a combination of machine learning (WP:RSML) and a derivative of Wikipedia (see WP:CIRCULAR and WP:CITOGENESIS). Thryduulf (talk) 13:15, 2 June 2026 (UTC)[reply]
I'm also 100% sure it has digested all of Wikipedia and often spits out barely reworked versions of the same page. Citing it would be just like citing a Wikipedia clone. GeogSage (⚔Chat?⚔) 05:35, 4 June 2026 (UTC)[reply]
Yes, it's prohibited. Grokipedia is not a reliable source, just like Wikipedia is not a reliable source. But a Grokipedia article might be an excellent place to look for reliable sources. I would even suggest that a link should be automatically put atop every Wikipedia article's talk page, cross-referencing Grokipedia (and any other pertinent online encyclopedia), to help Wikipedia editors find stuff they may have missed. Anythingyouwant (talk) 10:04, 7 June 2026 (UTC)[reply]
That could be a useful suggestion for links to Britannica and similar works. The existing Template:Authority control might be a good place for it. However, including Grokipedia in such a feature wouldn't add value for our readers, because its content is AI generated and/or a (possibly outdated or redacted) copy of the Wikipedia article which would link to it. Certes (talk) 10:53, 7 June 2026 (UTC)[reply]
I will check out VPI. I have very rarely visited Grokipedia, but did just now to check your assertion. I've recently been doing a little work on the Wikipedia BLP for journalist Nick Bilton, and I found lots of in-depth analysis of his work at Grokipedia just now, that's not in his Wikipedia BLP. As you can imagine, a journalist does a lot of writing, and Grokipedia is able to read a lot faster than I can. Anyway, I haven't incorporated any of Grokipedia's sources into the Wikipedia BLP, and probably won't because I don't have time to do all the reading that Grokipedia did, but if I had more time I would likely do so. Anythingyouwant (talk) 11:37, 7 June 2026 (UTC)[reply]
Frankly, given the explicit views of Grokipedia's founder, even using it to look for more sources would likely be ill-advised, as said views pretty much require it use unreliable sources. Beyond the standard caveats of LLMs being good at looking correct well beyond their abilities to be correct, I'd trust the source assessment of just about any other LLM before that of Grok. Sesquilinear (talk) 20:43, 7 June 2026 (UTC)[reply]
True. Even LLMs released in good faith make innocent errors, which can be hard to spot as we mistake confidence for competence. Then we have LLMs from providers with an agenda to push, which can open a whole new level of incorrectness. Certes (talk) 21:25, 7 June 2026 (UTC)[reply]
Should we allow stewards to view deleted pages for non-steward roles?
The English Wikipedia's global rights policy says about stewards: "They may use their global rollback permission on the English Wikipedia, and may use Special:Undelete to view deleted revisions in the course of their duties as stewards. ... According to m:Stewards, stewards will not use their technical access when there are local users who can use that access, except in emergencies."
I propose changing view deleted revisions in the course of their duties as stewards to view deleted revisions to combat abuse (Option 1).
An alternative, more concise option would be to replace
They may use their global rollback permission on the English Wikipedia, and may use Special:Undelete to view deleted revisions in the course of their duties as stewards.
with
They may use their global rollback permission and may view deleted revisions on the English Wikipedia. (Option 2)
An English Wikipedia SPI clerk, A09, was elected as a steward this year. As our policy says stewards may view deleted revisions only "in the course of their duties as stewards" and SPI clerking is not a steward duty, A09 has refrained from using his steward access to view deleted revisions for SPI. However, I believe stewards can be trusted to view deleted revisions here, and it would be incredibly useful for A09 to be allowed to do so. Therefore, I think we should broaden the language of our policy to allow stewards to view deleted pages whenever they are combatting abuse, be that on behalf of the English Wikipedia or on behalf of the global community. Toadspike[Talk]11:24, 2 June 2026 (UTC)[reply]
Are there any steward duties where viewing deleted revisions is necessary/useful but which are not combatting abuse? My guess is that it might be relevant when determining if someone is eligible for vanishing? If so then I oppose the proposal and suggest instead adding language about combatting abuse rather than replacing the existing wording. Thryduulf (talk) 11:37, 2 June 2026 (UTC)[reply]
Ah, so you would prefer view deleted revisions in the course of their duties as stewards or to combat abuse? Let's call that Option 3. (At that point I find Option 2 much cleaner, though; I can't imagine anything that falls outside of Option 3 worth using so many extra words to prohibit.) Toadspike[Talk]11:56, 2 June 2026 (UTC)[reply]
Deleted content is presumably hidden from view mainly to 'protect' the general reader and possibly also casual editors from stuff that isn't fit to be seen, but anyone with advanced roles/perms can IMO be trusted to see it. (In fact, I've argued in the past that NPP/AfC reviewers would find this a useful ability in identifying socks, determining G4 speedy cases, etc., but that's a separate argument.) So yeah, I'm in favour. -- DoubleGrazing (talk) 12:03, 2 June 2026 (UTC)[reply]
Deletion is also used to protect other parties, such as in cases of copyright violation and sensitive/personal information. The latter cases are the ones I would expect needing higher security. ~2026-32802-12 (talk) 13:52, 2 June 2026 (UTC)[reply]
To my mind, that still comes within the 'not fit for general consumption but okay for users with advanced perms to see' rationale. If an admin can see a deleted copyvio, I can't think why a steward shouldn't be able to. And if something is so sensitive or bad that neither admins nor stewards should be able to see it, oversighters are there to deal with it. -- DoubleGrazing (talk) 14:23, 2 June 2026 (UTC)[reply]
Though our global rights policy says stewards should only use oversight to suppress abusive usernames or in emergencies, they theoretically have access to that tool as well, so I don't find the "access to private information" argument convincing. Anyone who can be trusted to (occasionally) see oversighted information can be trusted to see deleted information. Toadspike[Talk]14:50, 2 June 2026 (UTC)[reply]
Stewards have full permissions on every project, but we don't use it. So yes, we could see oversighted content, but we're not nosey enough to abuse this privilege. A09|(talk)15:01, 2 June 2026 (UTC)[reply]
Eh, I know plenty of stewards who have looked at content I suppressed because it came up in a list. Or they just stumble across it. The joke I’ve made before is that the quickest way to get a ton of eyes on something is to revdel or suppress it because people are nosey. It’s not an issue: the view function of the steward role is a legitimate exercise in oversight of even large projects against abuse, and serves as a check against the local functionary group as you have additional people with the capacity to report to ombuds. That’s why I think this is a pointless policy change. Stewards have been clicking on crossed out revisions on en.wiki for decades at this point and no one has thought anything of it. TonyBallioni (talk) 15:14, 2 June 2026 (UTC)[reply]
Does this matter? It’s a non-logged action that I’m sure they do anyway without needing permission, and that I’m all but positive that in the entire history of en.wiki no one has spent a second thinking about until today. Seems like an update of policy for the sake of updating policy. Oppose updates because there’s no need to create a policy to permit something that is unenforceable to prohibit. TonyBallioni (talk) 15:02, 2 June 2026 (UTC)[reply]
@TonyBallioni At least one English Wikipedia functionary told A09 that he is not allowed to view deleted revisions here outside of his steward duties, and Xaosflux disagrees below that this is already allowed. "No one has spent a second thinking about [this] until today" is sadly not true. Nosy stewards indeed cannot be prohibited, but writing on-wiki comparisons of deleted pages to extant ones can be. I'd prefer if we rebalanced this in favor of useful work. Toadspike[Talk]15:36, 2 June 2026 (UTC)[reply]
Again, how is that point of view enforceable? Even if someone takes a less commonsense approach and insists that for something to be actionable on-wiki an admin has to view the diffs… an admin has to view them to block anyway. Maybe they shouldn’t post on-wiki prudentially if they are concerned with a there being controversy in a specific case, but for socks stewards have much easier ways to communicate with local CUs than SPI, so again, it doesn’t really matter. Strongly opposed to any change here as it will have the practical effect of further restricting what can be done by making it appear we have to list out everything explicitly. TonyBallioni (talk) 15:47, 2 June 2026 (UTC)[reply]
Yah, that’s kinda my point. By listing out something that has been done forever and that to the best of my knowledge is not controversial, you’re essentially making it harder to use tools in a commonsense way. TonyBallioni (talk) 18:17, 2 June 2026 (UTC)[reply]
I trust our stewards to view deleted revisions for any purpose they think is appropriate, and we should update our policies to allow that. Tazerdadog (talk) 16:04, 2 June 2026 (UTC)[reply]
Option 2, and I agree with WAID. To Tony's point, I think this change removes an unenforceable policy—the limitation to only using viewdelete for steward stuff. Best, HouseBlaster (talk • he/they)01:00, 8 June 2026 (UTC)[reply]
Recently, the Reader Growth team announced rolling out Image Browsing as a beta feature for mobile users. This feature displays a carousel of images on top of articles, with each image being clickable to access a more detailed view.
Image Browsing provides controls to hide a specific image from a page, with either class=notpageimage excluding it from thumbnail previews, or class=noviewer excluding it from MediaViewer. The carousel can also be disabled from a page, with the magic word __NOMEDIAVIEWERCAROUSEL__, and logged-in users have access to a preference turning off the feature everywhere.
The choice of where to place these controls carries policy implications, and ties back to repeated discussions about the possibility of a "hide images" functionality. On its face, it would make sense to hide unexpected images of gore or pornography that the feature would suddenly bring at the top of an article. However, to take more extreme examples, some of our readers may also wish for pages on queer topics, or featuring religious imagery, to hide images they perceive as offensive. Drawing the line, or figuring out whether a line should be drawn at all, is certainly not an easy question, but it is one the community should address before the full rollout of the feature.
I'm not sure it's possible to neutrally choose which images to exclude and include, especially if the images are divorced from their broader context in the article. It may be best to restrict image hiding to only ones which would be duplicates or would be low quality when scaled, it's a neutral approach at least.
As an aside, the whole feature feels like scope creep. Maybe needing to curate sufficiently pleasant image carousels for mobile Image Browsing users is just part of what being an encyclopedia means now, but it doesn't feel that way to me. I'm also unimpressed with some of the stated reasoning for the feature, like the bold claim that Many new readers are visual learners, as though it were settled fact (it's not, the concept of learning styles is academically contentious, at worst it's regarded as harmful myth). fifteen thousand two hundred twenty four (talk) 02:24, 4 June 2026 (UTC)[reply]
I agree with you about the fact that learning styles is, um, a word I'm not going to say in polite company. However, as a reader, I have to confess that I've sometimes just gone straight for the pictures (especially if the subject is one that lends itself to images). So I think I'm probably going to use this feature a lot, and curating which images sounds fine by me; I'm not worried about scope creep.
Just to go back on track: I'm hoping nothing other than maybe something "consider hiding unexpected gorey, sexual, or hateful images" is needed at this stage; I think we might need to settle the more subjective matters of offense/NPOV on an article by article basis for a while, and then we'll ideally see what proves contentious and what we need site-wide guidance on.
In terms of more firm rules, maybe something about taking into account BLP context might be a good idea to figure out now; if we have a mugshot of a person, it may or may not be a good idea to include that image at the very top of the article. For some high profile examples, let's consider Justin Bieber. His mugshots are in the article; should we put those at the top? If we pretend he's alive for a few minutes, how about O. J. Simpson's? How about Ted Stevens? (Again, pretend he's alive for a moment). Does that change if you ask yourself whether or not the mugshots should appear at the tops of Murder of Nicole Brown Simpson and Ron Goldman or Trial of Ted Stevens? GreenLipstickLesbian💌🧸03:06, 4 June 2026 (UTC)[reply]
The stated goal of Image Browsing is to [make] it easier for a wider variety of new readers to find Wikipedia useful to learn from, it's supposed to be a learning tool, but is it a neutral tool if it necessitates exclusion of entire categories of otherwise encyclopedic content, or puts extra emphasis on that which is "safe"? If this is a lens through which many mobile users are expected to learn, then the idea that it will be a non-neutral one feels fundamentally wrong. I think if we find ourselves needing to answer questions of "which due information do we need to excise here for palatability", then something has gone awry.
It's a question we already need to ask when adding mugshots and such to leads. Honestly, I already view some articles by leafing through all the images; this just seems like a better version of that. Especially if it means there's a path to letting me cut out those random not-really-related to the article images that show up at the bottom of the page; think [1] or [2]. GreenLipstickLesbian💌🧸04:30, 4 June 2026 (UTC)[reply]
The difference as I see it is that adding a mugshot to the lead is an opt-in process dependent on an editor first choosing to do so, and the lead also provides space for needed contextualization. Image Browsing's opt-out nature forces the question while also not appearing to provide the same space for context.
But readers can already do what the image merry go round does, just with no ability for enWiki editors to curate what they see? And with no ability to toggle the system off per article? GreenLipstickLesbian💌🧸06:02, 4 June 2026 (UTC)[reply]
That begs the question of why the carousel exists then, if readers can already do what it does, and I think the answer is that it's fulfilling a different purpose. It's targeting engagement and retention by placing a much larger emphasis on images than exists currently, while also canonizing the gallery as an intended primary co-medium for parsing an article (or to quote, before, visual learners would still need to interact with mostly textual content, now they have the opportunity to balance text with images ...fifteen thousand two hundred twenty four (talk) 06:43, 4 June 2026 (UTC)[reply]
Putting aside the PR speak for a minute: Trying to increase reader retention ain't a bad thing. Giving enWiki editors more power over a system people have already hacked out because they like using it ain't a bad thing. Letting interested readers skip directly to galleries ain't a bad thing. GreenLipstickLesbian💌🧸06:49, 4 June 2026 (UTC)[reply]
Thanks for all the thoughtful engagement here @GreenLipstickLesbian. First, I agree with what you said about this feature being meant to provide readers a way to access images more easily (7-8% of readers engaged with the feature during our experiment, which is quite high for mobile web) while also giving editors control to help curate the carousel. Also, with respect to the discussion about mugshots, are there instances when the class=notpageimage would not be sufficient for mugshots or similar use cases (i.e., the community would be okay with the image showing up in the thumbnail for search but not in the carousel)? Interested to hear your perspective on how applying that tool might work and/or where you might need a different one. SherryYang-WMF (talk) 18:37, 4 June 2026 (UTC)[reply]
Thanks @Fifteen thousand two hundred twenty four for your feedback. To the question of needing to curate images specifically to the mobile image browsing carousel, that is not our intent here. The carousel will automatically bring in the images already in the article, honoring all exclusions already defined by editors for MultiMediaViewer. We hope that following the same logic will allow the feature to bypass issues on images with NSFW, gore, and other areas that require editor oversight to ensure both neutrality for article content and safety for readers. So ideally, this will not result in scope creep for editors on either existing or future articles since editors are already doing that MMV work.
There will of course remain questions around potential specific cases (BLPs as mentioned below are a good one), and we expect to have to hash these out together. As you mentioned, too, we still very much want the carousel to adhere to neutrality guidelines. Do you think we would need a different set of tools from the image class exclusions (like class=notpageimage and class=noviewer) to do that? SherryYang-WMF (talk) 18:45, 4 June 2026 (UTC)[reply]
The automation/opt-out nature is the problem, we should not be automatically extracting and flattening encyclopedic content, and then presenting this inadequately contextualized repackaging as a valid way to engage with a subject. The idea that we now have to bypass issues on images with NSFW within articles where said images were determined to be encyclopedic, is bad. That's not a neutral approach.
But in the interest of providing feedback for reality as-is, reusing class=notpageimage, a class intended to choose which images to hide outside an article, to determine which images to hide inside an article (the carousel is very much part of the article, and is intended as a learning tool after all) is plainly a misuse of the feature. Even if it was an appropriate use it still leads to unintuitive results, no 53rd Fighter Squadron insignia on 53rd Fighter Squadron, no communist symbols on bans on communist symbols, lots of penises on human penis except the lead one, etc. For that last one consider that lead images are often the ones tagged as notpageimage, and lead images are also selected to be of least shock value, so another issue with misusing notclasspage can be that potentially shocking imagery in the carousel automatically ends up more concentrated. Though maybe this is all of little concern, since the tag is so rarely used.
class=noviewer is never used to exclude "NSFW" images, there is a policy that might have something to say about that. It's used to exclude low-quality, repetitive, or less-relevant images, such as at sexual intercourse where it hides an icon and not, say, any sexual intercourse.
The policy linked to does not prevent curating which images appear and where they appear on Wikipedia. Indeed, the MOS:SHOCK pages you go on to link to, and our guidelines on offensive material very much support the idea that Wikipedians are capable of editorial choices regarding shock/offence/safe-for-work/appropriateness/etc. Any discussion about how the images on such an image browsing carousel could best be curated would be infinitely better if that policy was actually forbidden from being mentioned, per xkcd: "someone once said that defending a position by citing free speech [i.e., WP:NOTCENSORED] is sort of the ultimate concession; you're saying that the most compelling thing you can say for your position is that it's not literally illegal to express." Colin°Talk07:21, 5 June 2026 (UTC)[reply]
Thanks @Fifteen thousand two hundred twenty four and @Colin for this discussion. I really appreciate the care around interpreting policy for our new feature! One quick clarification: as they do currently, images with class=notpageimage and/or class=noviewer will still appear within the article. We would not interfere with editor discretion on content like that. Exclusion from the carousel will not remove images or alter their placement within the article.
Also yes, the usage of those tags is fairly low right now. We would like to give control to editors on whether/which images are shown, so we are hoping this beta period can serve as a jumping off point for that.
As stated, the carousel is part of the article, it shows up big and bold right at the top, and is explicitly intended as a lens through which visual learners [sic] may engage with a subject. Images are encyclopedic content, encyclopedic content should not be automatically flattened and decontextualized in this way.
@Colin the positioning of all potentially objectionable imagery on the project is the result of editorial discretion, I agree that this is a good thing. However, this new feature takes those past considered choices, and disregards them by flatten all images to the top of articles by default. I don't believe reusing notpageimage or noviewer alleviates any issues with this on-by-default approach, partly because those features have undesirable side effects since they were intended for different purposes, partly because they are so very rarely used to being with.
(And for what it's worth, I don't believe using noviewer to exclude relevant content from media viewer (not talking about the carousel) is appropriate. If a reader chooses to open an image, they should get the same enriched experience for that image as any other. If they choose to flip through all images on a page, they should be allowed to.) fifteen thousand two hundred twenty four (talk) 23:13, 5 June 2026 (UTC)[reply]
@Fifteen thousand two hundred twenty four, I see that you use the desktop site (so none of this will affect you personally, just in case that wasn't already clear). When you go to an article with pictures showing, and you click on one of the pictures, what happens? What do you see on your screen? WhatamIdoing (talk) 23:43, 7 June 2026 (UTC)[reply]
I know this won't affect my personal reading experience (more frequent use of noviewer and notpageimage aside), I just care how this could impact reader experience and information presentation regardless of platform.
what happens
I would expect my experience is much the same as yours. Using Ulysses S. Grant as an example, when selecting the lead image the media viewer shows the image and its caption in a larger form without loading a new page, other information like its position (1/37) and commons info is provided. I see controls to cycle to other images, fullscreen it, download it (varying sizes can be selected, and attribution information is made easy to copy), and share the image. There is a control to close the viewer in the top right which immediately returns to the article.When selecting an insignia in the "Dates of rank" section which has noviewer, an entirely new page is loaded, the image displayed is larger (though I tested, and the media viewer would actually display it even larger by automatically selecting a bigger resolution that better fits my window size), not applicable here but if the image had a caption it would now be absent, there is no information about which image in the page it was. There are no controls to cycle to other images, fullscreen it, download it, or share it. Returning to the article requires use of the browser's back button which then reloads the article which is slower.Overall the goal of the media viewer, to [improve] the viewing experience for readers and casual editors on Wikipedia ... seems to have been met, and accessing images without it offers a degraded experience that is slower (2x+ on my computer, sometimes much slower), smaller, less information rich, less accessible, less discoverable, and less shareable.
Our experience is different, because I have MediaViewer turned off on this wiki. I also have "Redirect image links to Commons for files hosted there" enabled as a gadget, but that seems to have stopped working. The main change from what you have now is that there would be a strip of pictures across the top of the page, and clicking one would take you into more or less what you've got now if you click an image. This is a visible change, but I doubt that readers will be unhappy after they've had a couple of weeks to get used to it. For high-traffic articles, I suspect that it will actually be popular. We've had readers tell us in research and spontaneous feedback for at least 15 years that they want to see more images in articles. WhatamIdoing (talk) 02:32, 8 June 2026 (UTC)[reply]
So to be clear - this is an effort to increase viewership/learning by linking/ directing readers away from English Wikipedia to Commons before the lead of articles to random (yet related) file information pages?Moxy🍁05:25, 4 June 2026 (UTC)[reply]
Sort of. The metric of success is the number of readers who use an image ("engage further with the image they selected") to leave the article ("promising clickthrough rate, which we think signals reader benefit"). However, clicking that image technically goes to the media viewer, not Commons. Not included in the brief summary at mw:Readers/Reader Growth/Image Browsing are metrics on whether the x was clicked following which readers engaged further with the article. CMD (talk) 07:18, 4 June 2026 (UTC)[reply]
I'm going thru the options at that page.... I see we have millions of articles to go through to choose which images are seen (if we don't want the default selection). is it possible to make an image link to the relevant page? Like if someone sees the Jack pine painting at the top of the Canada article is it possible for us to provide a link to that The Jack Pine article rather than to a media page that takes our readers away from anything educational? Basically will there be a |link=The Jack pine type option as we have right now with our images?Moxy🍁11:51, 4 June 2026 (UTC)[reply]
As is currently the case with images embedded within the prose, I think it's desirable for editors to make any appropriate follow up links visible as a linked phrase in the image caption. This will handle the image carousel too. isaacl (talk) 17:15, 4 June 2026 (UTC)[reply]
@Moxy thanks for the note. I just want to confirm that this feature is not intended to draw readership away from Wikipedia or toward Commons. Readers will be able to open a close-up detail view of the image while staying on the same article page, so that if they finish looking at the images and dismiss the detail view, they are still in the article and can keep reading. SherryYang-WMF (talk) 18:49, 4 June 2026 (UTC)[reply]
Thank you to everyone who has shared feedback here! Your input is already helping us make improvements to the Image Browsing feature. To that end, as we announced on VPT, we are aiming to get the carousel into beta on Monday, Jun 8, at which point logged-in users who opt into the beta can test the feature (Note: all you have to do to see it is opt in to beta; images from the article page will automatically show unless excluded via the image classes, so no editorial effort needed to seed the carousel). Our hope is that seeing the feature in beta will help volunteers visualize the experience ahead of full rollout, helping to clarify some of the questions we've seen come up and grounding the discussions around how to use the image exclusions. We'll be continuing to listen for questions and suggestions here, thanks again! SherryYang-WMF (talk) 22:26, 5 June 2026 (UTC)[reply]
Simple factual question here. Does this functionality take readers to an article that uses a particular image? That way, the captioning of the image goes through all the Wikipedia verifiability checks. If not, we are exposed to all the captioning errors that you find on Commons, where there is no principle of verifiability. If the latter, this is not a very good learning tool. ThoughtIdRetiredTIR07:42, 4 June 2026 (UTC)[reply]
The feature adds an image carousel at the top of articles that consists of the images used in the article. So readers are already viewing the article where those images are used. isaacl (talk) 08:25, 4 June 2026 (UTC)[reply]
Sounds like it needs a reasonably prominent "skip down to the content" button, i.e. a button that takes you directly to the first paragraph of the lead. (Long infoboxes need this, as well.)—S MarshallT/C14:53, 4 June 2026 (UTC)[reply]
Thanks @S Marshall. I hear you on wanting to be able to skip past an image carousel and/or long infobox (super interesting idea, which the mobile apps have implemented a version of already!) to get into article text. Just to clarify, since the carousel has the images arranged horizontally, it does not push the article lead below the fold and the lead will still be easily visible so readers who want to head straight there can do so. Also, if you want to turn off the carousel permanently for your account, you can do so (during beta, this will be found in Preferences → Beta Features, and after the beta period, this will be found in mobile settings via the hamburger menu at the top of the page).
I haven't been following this - apologies. Am I right in saying it applies only to mobile web users (typically users who don't have the iphone or Android apps installed) on their phones? MichaelMaggs (talk) 15:12, 4 June 2026 (UTC)[reply]
That's right, it's linked to the mobile web browser. Presumably a mobile user without the app who views an article in Desktop mode will also not see the carousel. CMD (talk) 15:22, 4 June 2026 (UTC)[reply]
@Chaotic Enby-- interestingly, this feature was partially inspired by the mobile apps -- right now, if you tap the big image at the top of an article on the mobile app, you can scroll horizontally across the various images in the article. We saw that that was a popular thing that mobile app readers do, which helped prompt us to think about this for the web. Now that we've built the web experience, it's more fully featured than the app experience, so maybe we'll have learnings/improvements to bring back to the apps.
Regarding the proportion of app vs. mobile web: the mobile apps only represent single-digit percents of our reader traffic. You can see the proportions with this graph. This is sort of a bigger conversation, but a lot of our product plans right now have to do with the fact that there are lots of people out there who would be happy users of our mobile apps but they don't even know they exist. For instance, whenever we mention our mobile apps in our social channels (e.g. Instagram) there are all these fans of Wikipedia commenting like, "You guys have an app??? How did I not know??" MMiller (WMF) (talk) 21:15, 4 June 2026 (UTC)[reply]
@MMiller (WMF) elsewhere, I see that the rollout of this beta feature was slated for last week, but I don't see it among the beta features? I assume the rollout was delayed? I have some possible concerns but I'd have to see it in action to say definitively. I did go and test drive the app thanks to this conversation...which revealed a major bug imo. When clicking on an image in the app, it displays the file's description text from Commons, not the local caption. That may have been by design, but if so, that's a bad design. The Commons captions are typically poor quality, not appropriately localized, and not customized to the article. CaptainEekEdits Ho Cap'n!⚓05:43, 5 June 2026 (UTC)[reply]
Commons captions are not just poor quality, many are simply wrong. More importantly, there is no policy of verifiability in Commons. If this initiative really shows Commons captions, it goes against one of the Core content policies. Surely that is unacceptable. ThoughtIdRetiredTIR07:48, 5 June 2026 (UTC)[reply]
Wondering if we can do what we do for short description vis-a-vis wikidata where we can update the caption in commons from enwiki's interface? – robertsky (talk) 13:02, 5 June 2026 (UTC)[reply]
The issue is that the captions on Commons and on en.wp should not always be the same as they serve different purposes - those on Commons are to describe the image on its own terms while those on en.wp describe the image in the context in which it is used in the specific article. For example File:SandrineNosbé (cropped).jpg is captioned "Sandrine Nosbé in 2024" when used on Sandrine Nosbé and "Handbag over the shoulder" when used on Handbag. Thryduulf (talk) 13:18, 5 June 2026 (UTC)[reply]
Agreed. Commons needs to keep the original caption. That's also important for archival photos. For example, there is a large archive of historical German photos which keep the original caption for archival purposes (and which of course notes the original caption may be incorrect or biased), but I would not typically use the original on an EnWiki article (because they were frequently written by a Nazi or a GDR officer for propaganda purposes). I also don't think WikiData is the solution, as WD also doesn't require verifiability and isn't situation specific (a la the handbag example). CaptainEekEdits Ho Cap'n!⚓17:45, 5 June 2026 (UTC)[reply]
Hi @CaptainEek you’re correct that we delayed the rollout and are now aiming for Monday. That’s a very helpful flag on the Apps, we’ve shared with the team and created a Phab task for work addressing this.
I appreciate the concern about Commons captions that you, @ThoughtIdRetired, @Robertsky, and others on this thread raised and want to address that here for our mobile web Image Browsing feature: the captions we show when readers tap on the images in the carousel will come from the language wiki’s article. There are no instances where we show Commons captions outside Commons for images on mobile web (as with current image detail views in article, readers can tap Details to go to the Commons page with all the context provided there). You can test this on testwiki (please note testwiki behavior does not always match behavior on real wikis because we have to “fake” the content for testing) here: https://test.wikipedia.org/wiki/Triton_(moon) SherryYang-WMF (talk) 18:43, 5 June 2026 (UTC)[reply]
On testwiki, https://test.wikipedia.org/w/index.php?title=Triton_(moon)&useskin=Minerva&mobileaction=toggle_view_mobile one caption (or no useful caption) is shown when one clicks on a picture in the carousel, but another caption when the picture is first clicked on down in the article (and then again in the carousel). Maybe the action for clicking in the carousel should be the same as clicking on the original image thumbnail.
A nice feature would be being able to jump from the carousel to (the section) where the image is shown in the article: currently, the carousel pictures sit in a vacuum, there's little context provided. Ponor (talk) 15:00, 5 June 2026 (UTC)[reply]
Hi @Ponor, I wasn't able to reproduce this issue with the images we tried in the testwiki article. Sometimes testwiki can be finicky. Could you point us to which image triggered this discrepancy or say more about the steps you took?
We did include a “jump to section” option in our test, but it saw low engagement (only 1.5% of readers who tapped into the Detail View then selected View in Article, roughly a fifth of the 7.5% who wanted to see the image at full size). As a result, it’s not in this initial version of rollout but we’re definitely still looking for more ways to improve the feature. SherryYang-WMF (talk) 19:11, 5 June 2026 (UTC)[reply]
@SherryYang-WMF I think it has to do with whether the section where the image is is collapsed or expanded. I'm only seeing the issue on my phone. Steps to reproduce: on your phone, load testwiki:Triton (moon); all sections should be collapsed; click on the first image in the carousel; the caption is "Unknown authorUnknown author · Public domain" (this is not a typo!); close the viewer; uncover "Discovery and naming" and click on the carousel image again; the caption now gets another line, saying "William Lassell, the discoverer of Triton"; collapse the section again and click on the first image in the carousel: back to one line, no description. Tested in Firefox Beta for Android and Chrome for Android. Ponor (talk) 19:39, 5 June 2026 (UTC)[reply]
@Ponor thanks for that info! We recently fixed a bug related to lazy loading of images that sounds similar. I wonder whether there's some peculiarity with how the fix may have reached testwiki. The engineering team are done for the week at this point but I'll keep an eye on this issue. SherryYang-WMF (talk) 21:30, 5 June 2026 (UTC)[reply]
I think that if there's an uncontestable problem (here I am using the WP:NEWCSD understanding of "uncontestable"), then we should use the tools at hand to address the problem. Otherwise, I suggest avoiding it for about two weeks. That's how long it takes most casual users to adjust to a visible change to a website. After folks have settled in (so it's easier to separate "I hate this whole new thing" from "Maybe this specific instance is a problem") and editors have some experience with its advantages and disadvantages, then we could create some sensible advice to put in MOS:IMAGES. WhatamIdoing (talk) 20:31, 8 June 2026 (UTC)[reply]
Its only being put in beta, so I think the problem is not urgent. I agree that we should give it a few weeks to see how things shake out before taking our next step, unless an immediate problem develops. So, no, I don't think we should pre-emptively hide anything. If it does get hidden on some local pages, I don't think we have to rush to undo that; it'll be information we can use for our next steps. CaptainEekEdits Ho Cap'n!⚓20:44, 8 June 2026 (UTC)[reply]
I agree about not pre-emptively hiding anything, and also about not worrying too much about the occasional page.
I think that large-scale changes should be avoided until two weeks after full (not just Beta) deployment. There's always someone ready to yell about a change on the first day or two, because a change like this is visible. WhatamIdoing (talk) 22:54, 8 June 2026 (UTC)[reply]
Just wanted to note that the beta feature is now live on mobile for anyone who would like to take a look. You can either access this by logging into mobile web, with your user settings beta feature for Image Browsing toggled on, or on desktop scroll down to "mobile view" at the bottom of an article, again with your user settings for Image Browsing beta toggled on. Please let us know your thoughts and ideas as you explore the feature! EBlackorby-WMF (talk) 22:06, 8 June 2026 (UTC)[reply]
So the first thing I'm seeing is that sometimes...an image isn't shown in the carousel. For example, in Vietnam War, the first image (helicopters inserting troops) doesn't show up. Or in Cactus wren, the first image in the body (bird in a honey mesquite) doesn't show. I can't square why that's happening, given that there is no obvious code excluding either from the article. Any clues as to whether that's a feature or a bug? CaptainEekEdits Ho Cap'n!⚓23:46, 8 June 2026 (UTC)[reply]
I'm having "automatically enable most beta features" in my settings, but switching to mobile view doesn't seem to show the carousel, and I don't have a specific Image Browsing setting (even grayed out) in my preferences. What might be happening? Chaotic Enby (in solidarity · talk · contribs) 16:23, 9 June 2026 (UTC)[reply]
@Chaotic Enby I had the same issue on desktop. What worked for me was go into mobile view, go to my settings, uncheck auto enable most beta features, uncheck and recheck image browsing, save. No idea why it's so convoluted! Also be sure that the article you're looking at has at least 3 images. EBlackorby-WMF (talk) 16:32, 9 June 2026 (UTC)[reply]
I think what might be happening is that checking the automatic list on desktop only subscribes you to the desktop features, as the carousel only shows up when the settings are viewed in mobile view.Good thing, I can confirm it works now, and replicate the same issue in Cactus wren. Testing other articles, I'm having the same issue in Ascidiacea, where the first image after the lead doesn't show up. In Tunicate, however, it's the second image after the lead that is missing, alongside all of the cladogram images! Chaotic Enby (in solidarity · talk · contribs) 16:49, 9 June 2026 (UTC)[reply]
I don't know whether "automatically enable most beta features" still applies only to desktop (I'm certain that was true back in the day; I just don't know whether it's still true). However, even if it did handle mobile features, the "automatically enable most beta features" setting only works when your prefs are updated in some way (includes some prefs settings changed on other pages). WhatamIdoing (talk) 16:56, 9 June 2026 (UTC)[reply]
In re "be sure that the article you're looking at has at least 3 images": This means, in practice, that it won't show on most articles, but it should show on most popular articles. WhatamIdoing (talk) 16:57, 9 June 2026 (UTC)[reply]
I've identified another issue: [3] the image carousel shows up in diffs. I think that is unhelpful, as it considerably slows down a diff's loading time to have to pull all the images, and is a distraction I then have to scroll past. CaptainEekEdits Ho Cap'n!⚓18:20, 9 June 2026 (UTC)[reply]
99.9% of the time this is indeed a distraction, although the 0.1% of diffs that do affect the carousel (say, if you're debugging why some image doesn't show up) might be impacted if we remove it altogether. Not sure if that's even relevant enough to consider, but maybe an option would be to remove it from the side-by-side diff view but keep it when looking at a single old revision? Chaotic Enby (in solidarity · talk · contribs) 18:33, 9 June 2026 (UTC)[reply]
Noting that the carousel is going against MOS:NOETHNICGALLERIES on some articles: Articles about ethnic groups or similarly large human populations should not be illustrated by a photomontage or gallery of images of group members. Some only result in a few flags and maps, but the Black people article currently opens with a carousel whose first five images are photographs of two Haratin women, an Ibenheren woman, some South African school children, Tiger Woods and Kamala Harris. Perhaps some article categories could be excluded from this. Belbury (talk) 18:53, 9 June 2026 (UTC)[reply]
@Belbury @Chaotic Enby thanks for raising! This is the sort of use case we had in mind for the magic word. While we considered a programmatic exclusion for articles about ethnic groups, there are limitations to that approach and it seems like each community making updates based on their own MOS would be preferable. What do you think about that approach? SherryYang-WMF (talk) 20:48, 9 June 2026 (UTC)[reply]
The algorithm that selects images is including icons from sidebar navboxes, which often aren't very relevant. Some are low quality icons (the second carousel image on pizza is a crude drawing of pizza intended to be used at small pixel sizes) and others are only indirectly related to the article subject (the second carousel image on hot dog cart is a photo of an apple pie and a baseball bat).
These will be particularly confusing to a mobile user, as navboxes don't appear on mobile. To that reader, the carousel is displaying an image which isn't shown anywhere in the article body. Belbury (talk) 08:30, 10 June 2026 (UTC)[reply]
Another issue I'm encountering: previewing articles doesn't show us the preview of the carousel, only the saved version. I hoped that having the image inside a <div class="noviewer"> would prevent it from displaying, otherwise it looks like it won't be as easy to do from the metatemplate (or the associated module) as the full image syntax is written directly into each daughter template. Chaotic Enby (in solidarity · talk · contribs) 08:08, 11 June 2026 (UTC)[reply]
If this is about the sidebar navboxes, then there's also the problem of changes to templates not propagating instantly. That module is used on nearly half a million pages. Even if it looks like it's not working on any given page, that doesn't prove that your change didn't work. WhatamIdoing (talk) 18:00, 11 June 2026 (UTC)[reply]
I didn't end up testing on the module itself (to which I only updated the config page before realizing that I wouldn't see the carousel when previewing pages from the module's edit window), but on its sandbox, which thankfully isn't used on as many pages. Chaotic Enby (in solidarity · talk · contribs) 20:06, 11 June 2026 (UTC)[reply]
Testing this, but no idea why we would want this. It pushes the actual article down just to prettify it in a dubious way. Even non-free images are removed from their context and just shown as decoration, which goes against our rules for them. For articles where deliberate image placement was done to e.g. put certain images below the first screen, they now appear at the top anyway. It's also completely unclear why some images are included and some aren't (at Willibrord, only 3 of the 6 images are used?), and at Anatomy the second image in the carrousel isn't even in the article (in mobile view at least)? Cattle only starts with the 5th image? As for the prettification, at Lionel Messi I get a blurry signature, an image of his torso, a somewhat blurry action photo, another image of his torso, ... Images are often carefully created, cropped, chosen to be representative, interesting, and even artistic. Turning them all into square snaps shows disrespect to the photographers, the article creators, and the readers. Please either disable this or make it opt-in only. It's not an improvement. Fram (talk) 08:58, 10 June 2026 (UTC)[reply]
Totally agree. When I saw the this for the first time I thought it was a bug or something. It made zero sense to me that we would ever displace the text of the article for a carousel of contextless poorly-cropped images. For example, on wiki you see a miscropped screenshot of a wiki, some unknown guy, a picture of a bus, and a miscropped screenshot of the front page. This would leave the reader with many questions. Who is this person? Why is there a bus? What's wrong with the cropping? Why are these pictures here? Our readers come here to read an article, after all. I suppose confusing the reader into reading more drives engagement or keeps them on the site longer or whatever but it worsens the experience considerably for people trying to get the information they are looking for. People do not come here looking for photo galleries. There are plenty of other places to find those, including Commons.
One reason this so-called feature was developed, according to the info page on Meta, was that research showed that the vast majority of readers skim through articles and require a quick overview of the content before diving more in depth. This makes no sense, considering that there is a quick overview (the lead) that we are displacing with contextless images that provide nothing even resembling a quick overview. Another provided reason is that we should support visual learners, since visual learners would still need to interact with mostly textual content on Wikipedia, and this allows them to balance text with images. This again makes little sense. If we want a better balance of images to keep the visually-inclined reading, why not encourage adding more images to the article? This doesn't add any information, it just concentrates contextless images at the top of the page, completely throwing off the balance of text and images.
Wikipedia is a written work. We use images to enhance the written work. Our manual of style page on images calls for restraint in adding images and to ensure the images work within their context. The carousel ignores this in favor of a distraction at the top of every article. Image browsing should be discontinued. I don't think it is salvageable. If we are to go forward with this, it should be opt-in. Ideally, it would be off on all articles until someone checks to make sure the carousel doesn't violate MOS or other PAGs and actually adds to the article before it gets enabled on the page.
Also, it was pretty confusing that there was a carousel of images appearing without there being anything in the wikitext putting it there. If we are to implement this, why not implement this as a template that we can add to articles in a controlled manner? IsCat (talk) 00:40, 12 June 2026 (UTC)[reply]
It is not true that all of "Our readers come here to read an article". Many of our readers come to find a single, isolated fact (e.g., "What was that actor's name?" or "What kind of animal is that?"). The median time spent on "reading" an article is a very small number of seconds, which is consistent with someone wanting to glance at a picture or find something in an infobox, and is not consistent with someone wanting to read a long-form article.
I've checked it out and while it leaves a lot to be desired in its current state I found that it can be rather nice on some of the articles it works on, and I actually don't find it too intrusive. That said, it is obviously a better fit for some articles than others (very nice on geographic articles with landscape pictures, not as much on economics ones that only have graphs), which gives me some reservations as I don't want tons of articles being made to look sloppy and poorly thought-out to readers due to the automatic generation of galleries giving subpar results for those articles.Also, I would seriously recommend adding an option to turn it off in the settings for all users (like the size of text and light or dark modes). Some readers will certainly not be fans of it and I would find it very frustrating if I was one of them and there was seemingly no way to turn it off (it's not like they would know it can be done if they make an account), and I'm thinking it shouldn't be too difficult to add such an option. ⹃Maltazarianᚾparleyinvestigateᛅ16:20, 10 June 2026 (UTC)[reply]
The feature definitely looks nicer on some articles than others; this is an area where we hope to lean on editors' expertise and judgement. For articles that are not as visually compelling or educational, we would encourage considering using the "magic word" __NOMEDIAVIEWERCAROUSEL__ to turn off the feature for a particular page.
In a full feature rollout, there will definitely be an option in user's account settings to fully opt out of this feature and have it turned off for all articles by default.EBlackorby-WMF (talk) 18:43, 11 June 2026 (UTC)[reply]
Apologies if this was mentioned in the above discussion and I missed it. Can the image captions from the article be added to the carousel? I just tested it on today's featured article and captions of what we're looking at would be very helpful. PositivelyUncertain (talk) 20:12, 11 June 2026 (UTC)[reply]
Hi @PositivelyUncertain, thanks for asking! You should be able to see the associated image captions when you tap on any image in the carousel to open it. If that's broken for you, could you share an example so we can take a look? SherryYang-WMF (talk) 19:01, 12 June 2026 (UTC)[reply]
Hello, at the BLP talk page, I proposed adding 17 words to the policy. That was a couple days ago, and there's been no comment. So here I am!
I would like to suggest a small modification: "A living person accused of a crime is presumed innocent until convicted by a court of law, and upon conviction there is an exception to the usual BLP policy on the inclusion of denials." This would clarify an exception to the usual BLP policy ("If the subject has denied such allegations, their denial(s) should be reported too"). We shouldn't feel obliged to always include denials of convicted people.
This small modification matches what the essay WP:NOTMANDY has said for years: "the Biographies of Living Persons (BLP) policy does not require denials be mentioned if a person has been 'convicted by a court of law', in which case they can be presumed guilty" (N.B. I was the lead author of that essay). Of course, this BLP clarification would still allow denials to be included in the rare case of convicted people whose denials are still reported after conviction, in reliable sources. Nor would this clarification apply in the rare case that a conviction is overturned (i.e. the clarification applies "upon" conviction, not forever "after" conviction).
Have you considered the possibility of a wrongful conviction? Why wouldn't we include denials, such as:
He was convicted but plans to appeal.
He was convicted but continues to claim that he is innocent.
Even including a sentence such as "He entered a plea of not guilty" is including the accused's denial of the allegations in the article.
I think that a small change might be appropriate: It might be better to say that "their denial(s) should normally be reported too". I wouldn't weaken it beyond that. WhatamIdoing (talk) 00:00, 8 June 2026 (UTC)[reply]
If there’s RS reporting about a wrongful conviction or an appeal, then that can be included per usual Wikipedia editing rules. But most convicted felons will always say they’re innocent, I don’t see the point in including that, the presumption of innocence no longer applies to people who have been convicted. I feel that invariably requiring a denial be included in a BLP even for convicted felons leads to people just ignoring WP:DENIALS altogether. There is also not generally a tradition among journalists or scholars of mentioning denials of people who have been convicted. Note that I haven’t suggested any change to the language of WP:DENIALS, but you’ve done so; I think your insertion of the word “normally” would make more people ignore WP:DENIALS than already ignore it…which is the exact opposite of what I’m trying accomplish. Every situation is abnormal in some sense. Anythingyouwant (talk) 00:13, 8 June 2026 (UTC)[reply]
If RSes are reiterating the denial of guilt by the convicted, there's zero reason to not include it. MANDY was a dangerous essay and we should avoid going there in BLP. Masem (t) 03:06, 8 June 2026 (UTC)[reply]
I agree about reiteration, but consider there’s an arrest of John Doe, and a not guilty plea which are both recited in RS. Then after a fair trial and unanimous conviction by a jury, the RS’s stop talking about any denial. Do we have to keep saying it? That’s what the policy currently requires, Anythingyouwant (talk) 10:52, 8 June 2026 (UTC)[reply]
If John Doe pleaded guilty at the trial we would undoubtedly mention that, so why would we not mention a not guilty plea? I'm struggling to understand how a lack of mention would improve the article? Thryduulf (talk) 11:04, 8 June 2026 (UTC)[reply]
If someone is convicted, it’s normal to drop any mention of the trial, including the plea. We just say the person served 10 years in jail for embezzlement. Do we have to say, he served 10 years for embezzlement, although he argued at his trial that he was innocent? Even though no post-conviction RS’s discuss the denial? Anythingyouwant (talk) 11:11, 8 June 2026 (UTC)[reply]
Dropping coverage of the trial would depend on how much coverage the trial got. Some persons have had very public trials (Weinstein, Cosby, for example), and just because the end result is a conviction doesn't mean it would be appropriate to remove any discussion of the trial (and of course their plea of innocence before it). But this is usually the exception, most people are convicted with a relatively quiet coverage of the trial itself, and in that case, yes we can jump to the conviction and likely not have to worry about any claims made by the convicted if there's no significant coverage of that.
A key to remember is that the decision from a trial is only a legal determination of any guilt. The decision should not be taken as a factual account of the actual events, only whether the person is guilty on the legal presentation of those events to a judge or jury. Masem (t) 11:29, 8 June 2026 (UTC)[reply]
If no RS covers the claim of the convicted suspect that they are innocent after the trial concludes, I would agree we should not cover that as well. Masem (t) 11:25, 8 June 2026 (UTC)[reply]
@Anythingyouwant, I don't think it's actually true that most convicted felons will always say they’re innocent. Plea bargaining happens precisely because so many convicted felons were willing to admin that they were guilty. I've read that in the US, that's 98% of convictions. WhatamIdoing (talk) 20:52, 8 June 2026 (UTC)[reply]
I'll confess I am having a hard time imagining a situation in which a denial of a noteworthy criminal conviction would not itself be a noteworthy part of the story. Are there some recent examples where this has been controversial? Is this limited to situations where the only source for the denial is a primary one? (That is, situations where the denial is verifiable but has not been reported in any reliable secondary source?) If so, I think the proposed language would be improved by clarifying that. -- Visviva (talk) 03:00, 8 June 2026 (UTC)[reply]
As I just mentioned to Masem, consider there’s an arrest of John Doe, and a not guilty plea which are both reported in RS. Then after a fair trial and unanimous conviction by a jury, the RS’s stop talking about any denial. Do we have to keep saying it? Anythingyouwant (talk) 10:54, 8 June 2026 (UTC)[reply]
The key here is determining how much WEIGHT to give the denial, not whether to include/exclude. I can see the argument that we should give less weight to a post-conviction denial than we would to a denial at the accusation stage. But that doesn’t mean we should not mention the denial at all. Blueboar (talk) 12:42, 8 June 2026 (UTC)[reply]
Your comment about weight brings up a couple related points. It seems obvious to me that whenever WP:DENIALS requires us to include a denial, the denial ought to be in the same paragraph as the accusation, not hidden far away, maybe even in a footnote where it’s almost completely useless. Another thing that seems obvious is that editors should be sanctioned for violating WP:DENIALS, claiming WP:IAR shouldn’t cut it. (I actually was sanctioned for insisting it be followed despite local consensus to ignore it.) The USSR had a wonderful constitution that protected all kinds of civil liberties, but it was never enforced. I often get that feeling about Wikipedia’s policies and guidelines. Anyway, there’s probably a category for living convicted felons, and I bet you not 10% of those BLPs mentions their denials. Nor should they be mentioned, if no post-conviction RS’s mention them. I don’t see why we must. If there’s consensus to do so in a particular case, that’s fine. Anythingyouwant (talk) 13:11, 8 June 2026 (UTC)[reply]
A relevant and topical article is Wrongful conviction of Andrew Malkinson. In this case, recently concluded when the actual offender was convicted, Malkinson actually served 10 years longer than necessary in jail because to apply for parole, he would have had admit that he committed the crime, which he refused to do. Black Kite (talk)11:22, 8 June 2026 (UTC)[reply]
I appreciate such concerns, and I think my proposal can be improved. But in the vast majority of Wikipedia articles that mention people who have served jail time for crimes, nothing like that is involved. They typically have a trial where they claim innocence, then there’s a conviction, and the claim of innocence is never mentioned in RS’s after the conviction. So I would tweak my proposal: “A living person accused of a crime is presumed innocent until convicted by a court of law, and upon conviction there is an exception to the usual BLP policy on the inclusion of denials unless the relevant reliable sources are post-conviction.." That doesn’t mean such details cannot be included, just that they don’t have to be included, in a BLP. My experience is that WP:DENIALS is still widely ignored at Wikipedia (even at BLPN!), so I would like to get rid of aspects of WP:DENIALS that are overkill. Then maybe people will adhere to it. Anythingyouwant (talk) 11:53, 8 June 2026 (UTC)[reply]
Can you give 3 example articles where this would make a difference? I'm having a hard time imagining articles where we mention a conviction and shouldn't at least briefly include the position of the convicted, but having actual examples where this should be removed (or not be included if it isn't there now) might convince me or others otherwise. Fram (talk) 13:03, 8 June 2026 (UTC)[reply]
I am disinclined to name particular BLPs. I do not relish the thought of being accused (not by you) of trying to manipulate policy to advance my position in any particular content dispute, which of course I am not trying to do. Anyway, I don’t think it should require examples to see that it’s silly to require we mention a denial when no post-conviction RS does so. Allowing inclusion of such denials is fine, but requiring them is absurd. And we rarely do require it, even though it’s plainly required by the policy. I would prefer to have a policy that we can rely on, and that means what it says. Anythingyouwant (talk) 13:29, 8 June 2026 (UTC)[reply]
There are many things that should (not "must") be included but often are not (yet). The policy mainly protects those wanting to include it from others wanting to remove it "because they are convicted" or "because they are obviously lying" or whatever reason is given for the removal. It should not get undue weight, we don't strive for equal balance between conviction and denial in most cases, but there's nothing silly about including it even if post-conviction it is no longer mentioned by the sources. Fram (talk) 13:39, 8 June 2026 (UTC)[reply]
News reports about an accusation typically include denials, so when we omit a denial in that situation, it implies the person does not dispute guilt. That situation is entirely different after conviction, there is no journalistic practice of mentioning denials after conviction. So that aspect of our policy is absurd, and is often rightly ignored. That undermines the policy. As for the idea that the policy protects any editors, that’s a sweet notion, but untrue. For example, I was banned from American politics articles for five years merely because I insisted on reinserting an obvious denial into a BLP. But I agree with you that the policy *should* protect editors who follow it, and so I’m striving here for a policy that makes good sense and can command respect. Anythingyouwant (talk) 14:01, 8 June 2026 (UTC)[reply]
We are not journalists, we don't do journalism. We take a wider view. Sources from before or during a case don't become inadmissible because we also have sources from after the case. Of course, we should present up-to-date information wherever possible, but without an indication that they no longer claim to be innocent (or often that they claim to be innocent of certain aspects), there is no reason to ignore these previous sources. As for your topic ban, as far as a brief search informs me it was (after a series of escalating issues I haven't checked) for edit warring about the inclusion of denial in the lead, not simply for including the denials in the article (where they already were), on a page with an editing restriction against all edit warring. That's not an issue with this policy or its application, but about which aspects of an article are important enough to also be in the lead. The policy just says that they should be included, not that they should be given equal weight or position. I don't think changing policy on this basis is a good idea. Fram (talk) 14:37, 8 June 2026 (UTC)[reply]
I mentioned above that, “It seems obvious to me that whenever WP:DENIALS requires us to include a denial, the denial ought to be in the same paragraph as the accusation, not hidden far away, maybe even in a footnote where it’s almost completely useless.” Obviously, the edit that I am proposing here does not address that problem. So I’m not proposing to change “policy on this basis”. My proposal here is simply that, after conviction, we should give editors some flexibility about whether to include denials if no post-conviction RS’s say anything about any denial. But I suppose this is a trivial BLP requirement if it can be satisfied by sticking the denial in a footnote. Or perhaps we can even put it in a sub-article instead of a footnote? Is that a proper interpretation of BLP? Anythingyouwant (talk) 14:59, 8 June 2026 (UTC)[reply]
Belonging in the same paragraph of the body doesn't mean it should also be in the lead. Take as an example Marc Dutroux, one of the most notorious Belgian criminals. The lead says nothing about his denial, the section on "Dutroux's testimony" gives his denials. As it should be. It's not hidden away in a footnote, but it's also not given equal weight or emphasis. Fram (talk) 15:52, 8 June 2026 (UTC)[reply]
I have no problem with the Dutroux BLP. He’s been convicted of various crimes, so the allegation in the lead that he committed those crimes doesn’t need to be accompanied by his denial in the lead. When someone has been convicted, it means the denial has been adjudicated and found legally void. If this were an article about a Belgian accused serial killer, instead of a convicted one, then the denial should accompany the accusation in the lead for at least two reasons: (1) he’s entitled to a presumption of innocence, and (2) reciting the accusation without the denial gives the impression that he hasn’t denied it, because such things are customarily described together for people who haven’t been convicted. Anythingyouwant (talk) 17:23, 8 June 2026 (UTC)[reply]
Presumption of innocence is something that the accused are entitled to only within the legal system. The accused is not entitled to a presumption of innocence from his accusers, his mother, his employer, his bank, or (relevantly for us) newspapers and other reliable sources. I think therefore that we can dispense with your reason #1.
Your reason #2, on the other hand, is important to Wikipedia. We don't want to give the impression that the accused has confessed to guilt, when that's not true. However, that doesn't mean that a denial always has to be described along with the first mention of the accusation. After all, it's only "customarily" done, which is another way of saying that it's "not always" done, and the custom, when I flip through some news articles, is "in the same article" rather than "right at the start". (Examples: 4th paragraph, 4th paragraph, subhead plus 4th paragraph, 15th paragraph, 3rd paragraph, 12th paragraph, 3rd paragraph, 4th paragraph, 4th paragraph, 15th paragraph, 7th paragraph, 13th paragraph. If the main point of the article is the denial, then it may appear in the 1st sentence [ example, example ].)
Deciding how much prominence in a Wikipedia article to give to a denial should be handled like anything else: very prominent in some cases (e.g., trumped-up prosecutions of political dissidents in repressive countries), given some space in other cases (e.g., when most reliable sources suggest that factual innocence is a significant possibility), mentioned briefly in others (e.g., all the information we can source amounts to 'He denied it'), and barely mentioned at all in others (e.g., most people post-conviction: "He entered a plea of not guilty in March, and was convicted of six of the nine charges at the trial the next month" or "As of Octember 2025, he is appealing the conviction"). There isn't a one-size-fits-all answer. Editors will have to use their judgment to decide where and how to handle denials. WhatamIdoing (talk) 22:47, 8 June 2026 (UTC)[reply]
WhatamIdoing, I didn’t suggest one size fits all, that’s why I’m suggesting an exception for the particular situation where a person has been convicted and there’s no post-conviction RS’s that discuss the denial. So I would weaken WP:DENIALS to fit that common circumstance, and let editors decide in the usual way. Conversely, where an accusation is in the lead, I would strengthen WP:DENIALS to fit that circumstance. Consider that WP:LEAD correctly says this: “The lead is the first thing most people read upon arriving at an article, and may be the only portion of the article that they read…. The lead should stand on its own as a concise overview of the article's topic. It should identify the topic, establish context, explain why the topic is notable, and summarize the most important points, including any prominent controversies.” If editors decide to put an accusation in the lead, then it seems obvious that the denial should be briefly mentioned there too (putting aside situations where there’s been a conviction). Putting it in the lead still leaves lots of room for discretion, it might be a whole sentence, or it might be just three words (“which she denies”). If WP:DENIALS is so elastic that it can be evaded by putting an accusation in the lead while the denial is put in a footnote or a sub-article or buried in a subsection, then WP:DENIALS seems pretty much useless to me. Readers who just read the lead will be misled, because readers are accustomed to seeing any denials in conjunction with accusations. Anythingyouwant (talk) 09:18, 9 June 2026 (UTC)[reply]
You want to change DENIALS to require mentioning any denial in the lead, if the allegation is in the lead. This is not ordinary practice in reliable sources. You are proposing DENIALS have a one-size-fits-all rule that if an allegation is mentioned in the lead, then the denial should also be mentioned in the lead. The way that we avoid WP:GEVAL problems with denials is precisely letting editors decide for each article individually and not according to any one-size-fits-all rule at DENIALS:
whether, if the lead mentions the allegation, the lead should also include the denial, or if the denial should only appear in the body, and
whether the denial should be described expansively or if it should be mentioned only in passing or be "buried in a subsection".
In other words, the current wording ("If the subject has denied such allegations, their denial(s) should be reported too") provides the flexibility that we need. Expanding it to say something like "If the allegations are mentioned in the lead, then the denial has to be mentioned in the lead, too" would mean making some articles less compliant with NPOV. WhatamIdoing (talk) 17:58, 9 June 2026 (UTC)[reply]
Thanks for the discussion. We disagree. WP:NPOV also says, “Wikipedia aims to describe disputes, but not engage in them.” Putting accusations in the lead without even three or four words on the other side of the dispute (“which she denies” or “which she implausibly denies”) does not seem consistent with that philosophy, nor with WP:LEAD, nor with WP:DENIALS, and I don’t see any issue about false balance either, because we can make crystal clear that RS say the denial is implausible or dishonest or what have you, which is also quite revealing about the BLP subject. Anythingyouwant (talk) 22:38, 9 June 2026 (UTC)[reply]
If the sources treat the denial as unimportant or irrelevant or as a throw-away comment, then Wikipedia should, too. And one of the ways that we treat information (of any kind, including denials) as being unimportant or irrelevant or as a throw-away comment is to omit it from the lead. Ergo, if we are, as best we can, providing a fair and unbiased summary of the sources, then that will occasionally mean omitting the denial from the lead.
Additionally, facts that require complex and nuanced explanation don't belong in the lead. "He denied everything" is just three words, but what about when he admits that as a matter of ordinary fact, he did kill someone, but there were mitigating circumstances, or he thinks the world's a better place now that the victim is dead, so he doesn't feel guilty, and besides, the charges are against his strawman instead of against the real him, because he's a sovereign citizen?
I'm planning on discussing this issue of splitting up the accusation and the denial, in the essay WP:NOTMANDY if the other editors there don't mind. If and when that's done I'll give you a heads up so we can discuss further, and/or you can edit that new essay section if you want. WP:BLP (especially combined with other policies) properly treats denials as a special aspect of a BLP, not merely a routine editing decision. If sources include a denial, mindreading the importance the s0urces attach to it is often difficult, whereas it's not difficult to conclude that many times a Wikipedia editor will like or dislike a BLP subject and edit accordingly. This policy on denials is a rare obstacle to subjective editing, to protect BLP subjects and give them a small voice. I don't understand your comment about being a sovereign citizen. As to admitting a kill, but claiming mitigating circumstances, or claiming he thinks the world's a better place now that the victim is dead, so he doesn't feel guilty, you seem to be arguing that WP:DENIALS should either be broadened or abolished, but I think keeping it a narrow requirement is the best and most practical compromise so it's not burdensome but does have a real impact in our BLPs. Anythingyouwant (talk) 12:36, 10 June 2026 (UTC)[reply]
I gave you an example in which a denial can't be presented in just "three or four words". You seem to be treating all denials alike. Here are two scenarios in which that doesn't work:
Sometimes a denial is not really a denial. Sometimes the "denial" is an admission ("I killed him") while claiming that the admitted facts do not rise to a legal violation ("but it was in self-defense" or "but my client was legally insane at the time") or even that the person does not recognize the court's authority ("I believe a conspiracy theory that says you can't prosecute me").
Sometimes a denial is complex, e.g., admitting some and denying others. Especially when the allegations are a minor part of the article (e.g., allegations made during the course of a celebrity divorce), then it might not be appropriate to highlight this in the lead, especially if doing so would require a long explanation.
Remember that there are two ways to end up with WP:UNDUE attention to a denial:
Giving too much "space" to the denial: If sources mention the denial briefly, or only once, then the Wikipedia article should be concise, too. That includes not repeating the denial multiple times in the same article (e.g., lead plus body).
Giving too much "prominence" to the denial: If sources mention the denial at the end of an article, then the Wikipedia article should not put the denial in the lead. Conversely, if the sources focus on the denial, then the Wikipedia should make the denial prominent in the article.
Understanding how a source treats a denial doesn't require "mindreading". Editors should understand how all the sources are treating the denial (the same way you should understand how all the sources treat anything about the subject), and they should consider these general views or trends in reliable sources when writing the article. If the sources tend to emphasize the denial (e.g., it's at the top of the news articles, it's the main subject of some news articles, it's given a lot of space in the news articles), then the Wikipedia article should equally emphasize the denial (e.g., put the denial in the lead, give the denial a whole section, or at least a whole paragraph). If the reliable sources downplay the denial (e.g., mention it only in passing, place it at the end of the news article), then the Wikipedia article should do the same (e.g., omit the denial from the lead, use only three or four words in the body of the Wikipedia article to mention it).
This isn't difficult. Editors manage to do this all the time. If you personally struggle to do this, then I suggest that you step back from that and let other editors take the lead on this point. WhatamIdoing (talk) 23:30, 10 June 2026 (UTC)[reply]
If you somehow got the idea that I think every denial in a BLP should go in the lead, that’s incorrect, I don’t think that. I’m saying that if the accusation is in the lead, then the denial should be mentioned in the lead too, however briefly. Whatever the proper resolution to this issue is, it ought to be made clearer in at least one relevant policy or guideline, because right now editors could easily think that an accusation in the lead should be accompanied by its denial; BLP does not say otherwise but it does indicate that a denial is an important feature of a BLP, and policy on the lead says the lead should be able to stand on its own. It’s obvious that a denial is often simple and straightforward and wouldn’t require more than three words. I don’t need to take a step back, it seems a perfectly legitimate topic of discussion here, and I hope the situation will be improved one way or the other. Perhaps we can agree that if an error is made regarding whether to put a denial in the lead of a particular BLP, it would be better to err by putting it there than to err by only having the accusation in the lead. Anythingyouwant (talk) 03:03, 11 June 2026 (UTC)[reply]
The community generally recognizes that it is good practice to provide notification of a discussion at a centralized noticeboard when a specific article is being discussed, but the community is generally against requiring notifications. For example, they aren't required for any of the deletion processes. voorts (talk/contributions) 02:20, 10 June 2026 (UTC)[reply]
Bizarrely, we require notifications if you're dragging an editor to AN/I or Arbcom (but not if you're saying they're a sockpuppet). But you don't have to tell the talk page if, for example, you're discussing the sources on RSN, or the formatting at some obscure subpage of the Manual of Style where a "consensus" of three editors is about to reach a decision that will bugger up thousands of pages. I think these rules aren't very well thought out, though.—S MarshallT/C17:23, 10 June 2026 (UTC)[reply]
That's what has bugged me a while. There is A) no uniformity/standard and B) what we have seems decidedly arbitrary.
Like, if you're sending an article that has 3000 watchers to RSN, NOR, BLP or FTN boards for content issues (especially with no prior talk and editing engagement there in any recent memory), it feels really odd to bring in outside consensus views without allowing the local talk watchers to be fully aware and participatory.
You're conflating a lack of notification requirement with editors being in favor of not providing notice. As I said, the community thinks notifications are a best practice but routinely rejects extending those requirements to new areas. It is what it is. This discussion won't go anywhere IMO. voorts (talk/contributions) 17:43, 10 June 2026 (UTC)[reply]
What's your basis for saying the community routinely rejects extending notification requirements to new areas? Have there been RFCs or something about this recently? FWIW, I think OP's idea is a good one, at least for certain types of noticeboard threads (particularly content ones, like RSN, NPOVN, etc.). Levivich (talk) 18:12, 10 June 2026 (UTC)[reply]
Yes, there have at least been other discussions like this. I don't remember where. It may have been regarding speedy deletion. I'm fine requiring notifications, but I think it would be an uphill battle. voorts (talk/contributions) 18:23, 10 June 2026 (UTC)[reply]
Notifications are required for deletion processes: when an article is AfD'd, there's a notice on the article itself. (And also, centralized notification at WikiProject pages and elsewhere.) Seems to me to make sense to post, eg, a notification at article talk pages when sources used at that article are being discussed at RSN. (I'd rather have a bot or script do it, à la XfD, rather than require a human to do it manually.) Levivich (talk) 18:16, 10 June 2026 (UTC)[reply]
At least some notification is required. For example, tagging the article (which is notification) is required by AfD Step 2. The same step also requires listing it in the AfD log (a centralized notification). Step 3 is called "notify interested parties" (delsorts, WikiProjects, and individual contributors), and while Step 3 is not required, it is almost always done, because Twinkle does it and almost everyone uses Twinkle. My point is that under XfD procedure, some notification is required, the notification that is not required is nevertheless widely done, and all of that says to me that the community does indeed want and value notification. I do not believe the community is generally against notifications. Levivich (talk) 21:22, 10 June 2026 (UTC)[reply]
All I'm saying is that there are many editors who have been vocally against requiring notifications in other contexts. I'm not opposed to such a rule, but I doubt it will gain consensus. voorts (talk/contributions) 21:45, 10 June 2026 (UTC)[reply]
Do you recall if they objected to the action requirement being directly on them to do the thing, or was it opposition to a proposed standard that if Article whatever gets invoked for a discussion on say WP:RSN, that the local Talk:Article whatever folks must be informed/told so they can participate in the "off venue" chat?
It's two different things. I can see resistance (though I can't fathom why anyone would resist it) to the rule being on THEM to do it, but I can't possibly see any justification for the latter. If no one opposed the latter then this is a bot-level problem to fix probably? — Very Polite Person (talk/contribs)21:55, 10 June 2026 (UTC)[reply]
I don't know exactly how notification bots work but I assume they are triggered by the structured nomination templates at forums like RM and XFD. Almost all other notice boards and discussion forums I can think of have pretty much free-form posts and not formal "nominations". And I would object to complicating the discussion procedure by introducing formalized, structured nominations as a requirement for posting on most discussion pages. —Myceteae🌈 (talk) 23:53, 10 June 2026 (UTC)[reply]
From what I recall, the context of the discussion was CSDs and the objection was that this should be discretionary, while acknowledging the norm that it's usually appropriate to notify relevant pages. I can't find the discussion. voorts (talk/contributions) 23:58, 10 June 2026 (UTC)[reply]
Yes, that is the choice of each WikiProject. Some WikiProjects are okay with talk page notices; some do not want them at all. I don't see any reason to change the status quo. voorts (talk/contributions) 00:17, 11 June 2026 (UTC)[reply]
Just to be totally clear, my suggestion was Article talk page notifications if the article came up on a central board - specifically to prevent isolated clusters of competing consensus and so all editors are nominally /forced/ to equal procedurally/awareness footing at all times. — Very Polite Person (talk/contribs)00:21, 11 June 2026 (UTC)[reply]
What we quite often get is people bringing things to policy talk pages, but stripped of context. Two editors get in an argument over whether the Patterson-Gimlin tape was faked, and then one of them comes to WT:V to ask, "Should Wikipedia publish unproven speculation and rumour?" and the other one goes to WT:NOT to ask, "Should we censor widely published information just because some people don't believe clear evidence?" (Basically, if anyone comes to a policy talk page or RSN to ask a question "in principle", it's best to go over their recent contributions and work out what arguments they're currently involved with before you reply.) I think that any proposed rule requiring notification on the article talk page would need quite thoughtful phrasing to ensure it has the intended effect.—S MarshallT/C19:06, 10 June 2026 (UTC)[reply]
I think that any proposed rule requiring notification on the article talk page would need quite thoughtful phrasing to ensure it has the intended effect. I agree. There should almost always be a notice on the talk page of an article that is being discussed at a content notice board. For behavior issues, it's perhaps a little more complicated. If an editor's current or recent behavior at a particular article or its talk page generates an ANI report then other editors who have been involved or impacted should be made aware but I don't know that this should always be memorialized on the article talk page. For content notice boards, this would seem uncontroversial and I think it is not too onerous most of the time but there may be exceptions and I would want to think through the scope, purpose, and implications of following or not following a new requirement for notification. —Myceteae🌈 (talk) 23:44, 10 June 2026 (UTC)[reply]
We would need to word it so that it covered only actual discussions and not just calls for attention. A non-trivial portion of the posts at noticeboards are of the "We could use eyes on this article" or "we could use experienced input on this talk page" variety, and that really shouldn't require a notice. What are the other editors from the article going to say, "no, we don't want anyone else looking at it, stay away"? That's different from an actual discussion on the noticeboard. -- Nat Gertler (talk) 12:43, 11 June 2026 (UTC)[reply]
Forgive me, in what theoretical scenario of a discussion (vs a notification) of something going down on a talk page of an article, related to content, that is discussed on a noticeboard... where the article/talk participants shouldn't be made aware of the bridged/side discussion? — Very Polite Person (talk/contribs)16:14, 11 June 2026 (UTC)[reply]
For example, where you have reasonable grounds to suspect that a high proportion of the article/talk participants have a point of view or what Wikipedians miscall a "conflict of interest".[1]—S MarshallT/C17:46, 11 June 2026 (UTC)[reply]
I don't know that I would go so far as to say that article/talk participants shouldn't be notified. But I see a material difference between posts that reduce to "What should we do with this article?" versus "Please take a look at this". In the first instance, where there is a substantive discussion about the article content that generates (or may generate) a decision about how to edit the article, I think there should generally be a notification on the talk page of the article in question. In the case of "Please take a look" where there is no additional discussion or decision making, I think it is probably best to leave a notice but is less important. And even in the first instance ("What should we do?") there probably needs to be room for discretion and practical consideration. For example, a discussion on the talk page of a WikiProject or policy or guideline may impact dozens, hundreds, or even thousands of pages and notifying each and every one may be impractical. —Myceteae🌈 (talk) 20:06, 11 June 2026 (UTC)[reply]
Imagine that you run into a situation where an article talk page has huge problems -- an editor bludgeoning the discussion, a couple of editors flinging insults at each other, someone pushing a company, religion, or political view, or maybe just a bunch of well-intentioned new editors who think "reliable source" means "source that agrees with me."
In the middle of this huge fight you see something that makes you think "Hmmm. Is that source reliable for that claim?" so you pop over to RSN for a calm, reasoned discussion with a group of experienced editors who understand the subtleties of evaluating sources. In some cases inviting the disruptive editors who are tearing up an article talkpage to come on over and pull the same shit on the noticeboard is a very bad idea.
It's good practice to notify relevant pages, whether that's an article's talk page, a WikiProject, or any other places that's relevant, but I don't think this should ever be made a requirement. Not only does this not fit with other expectations, there's very places that say editors 'must' do something, but would likely to open to abuse and wikilayering over what should have been notified. -- LCU ActivelyDisinterested«@» °∆t°17:14, 14 June 2026 (UTC)[reply]
References
^What Wikipedians call a "conflict of interest", isn't. Wikipedia is not your client. It is not your customer. You do not owe Wikipedia a fiduciary duty. You do not owe Wikipedia a higher duty than you owe to your employer, or employees, or your country, or your monarch or republican equivalent. You have a basic moral responsibility to tell the truth, and we'd prefer it if you owned up to your financial interests or biases, but that's laughably far from adding up to a "conflict of interest" situation.~~~~
I have often thought that our system of using ref tags in discussions and reftalk at the bottom is confusing to new editors. It used to be OK when the references were on the bottom of the section where they were used, but somebody decided that they have to go on the bottom (I think that some sort of bot or script has problems otherwise). So a new user writes up a new section, and when they hit publish there are suddenly extra words at the bottom that they didn't write, and it looks like those extra words are in the section they just wrote! Confusing.
I have ignored this annoyance when it was used for citing sources, but now I am seeing a comment enshrined at the bottom of this page using ref tags and ref talk. Is this what we want? What happens when someone decides to place a reply to the comment down there? [ example refs deleted -- no longer needed ] we could have a whole threaded discussion with comments disappearing as the section with the ref tags get archived. --Guy Macon (talk) 08:24, 12 June 2026 (UTC)[reply]
Eh, what? Since when can't reftalk templates be placed at the end of sections anymore? I do it all the time. If that breaks something, fix the thing being broken. --Elmidae (talk · contribs) 11:04, 12 June 2026 (UTC)[reply]
Reftalk can go at the end of sections, that's where it's meant to go. See Template:reftalk "It is most useful when the list of references needs to appear close to the text where the references are used, for example at the end of a section or right after a quoted passage."
The comment that Guy saw at the bottom of this page that shouldn't have been there was there because someone hadn't used reftalk in the section that the comment was part of. I added reftalk to that section, so now the comment appears where it should, and not where it shouldn't. DuncanHill (talk) 11:26, 12 June 2026 (UTC)[reply]
I distinctly remember several times when I tried to put the reftalk in the section and someone insisted that it has to be at the bottom of the page. I agree that is is not only OK but quite useful in the section. If I can figure out what page that happened on I will post it here, but it looks like this is a non-problem and we can drop it. Thanks for the help! --Guy Macon (talk) 17:52, 12 June 2026 (UTC)[reply]
{{reflist-talk}} should definitely be at the end of the section containing the references, it even says so in the templates documentation. Putting it at the end of the talk page would be redundant as any references will appear there automatically, just as they would in an article without {{reflist}}. -- LCU ActivelyDisinterested«@» °∆t°17:19, 14 June 2026 (UTC)[reply]
A bit of background: I primarily edit medicine articles on Wikipedia. There are not many people who are regular contributors to WP:MED, only ~100-150 in the past month, but these pages are relied on by countless thousands of users. There is a need to keep them updated, high-quality, and well-supported, but not enough qualified people to make those edits.
LLMs are a force multiplier. They allow us to conduct literature reviews, draft text, and produce high-fidelity articles that are both scientifically accurate and readable by a general audience. They allow us to make meaningful expansions to a section or page in under half an hour, on a lunch break or a day off. And there is a way to do this that is quite productive: feeding the LLM academic articles, and instructing it to use that text to add the type of content you want. Let me give you an example. This diff, which I have self-reverted after reading the recent LLM policy update, was the product of feeding Sonnet 4.6 (a robust flagship LLM) the cited article and instructing it to add content to the existing version of the pathogenesis section. As a result, it was a major expansion of the section, completely compliant with the source. I believe it is very hard to claim that this diff was detrimental to the page or non-compliant with Wikipedia policies other than the policy preventing LLM usage wholesale; and since that non-compliance is the ostensible reason justifying the blanket ban, I think this diff also demonstrates why the recent version of the policy needs major revision.
I also acknowledge the problem of slop. This affects medicine pages too, but I'd bet it is a bigger problem on articles that are less technical in nature, since people tend not to feel qualified to edit technical articles on unfamiliar subjects. This serves as the foundation for my second idea, outlined below.
To find a more balanced equilibrium, I have the following (draft) proposals, which at this time are generalized ideas on how to edit the policy, and which I think could be discussed and built into something more concrete. I am also willing to volunteer my time to create prompts, rulesets, etc as needed, if some or all of these were to go through.
Create an official Wikipedia prompt for LLM use in editing. System prompts are guidelines for LLMs that have high impact on how they function, and which are rarely if ever violated by the LLM. A robust system prompt can implement guardrails against all specific objections I have seen in previous RfC discussions about allowed LLM use. This would be a major project, probably involving multiple people who are familiar with both LLM functionality and Wikipedia editing principles.
Restrict LLM editing usage to certain domains and/or projects on Wikipedia. WP:MED is the one I'm familiar with, but I'd imagine that many other scientific domains will benefit in similar ways. This may be a good option because people making large contributions to these pages already tend to be abiding Wikipedia policy, have higher standards for references, and are capable of cross-checking output text against peer-reviewed articles. This could also be taken a step further, by only whitelisting active and listed participants in scientific WikiProjects; I dislike this sort of gatekeeping, but I think it could assuage some concerns.
Expand allowed forms of LLM editing to allow LLM-generated content under specific conditions. The primary condition I'd propose is the one seen in the diff I linked above: already having found an appropriate reference, feeding it to the LLM with the intent of making specific directed edits based solely on the contents of that reference document. I'd also like for literature searches to be explicitly allowed (I think the current guidelines allow for this, but it's not clear).
Limiting LLM editing to specific models. I would propose these be Claude Sonnet 4.5+, Claude Opus 4.5+, and GPT-5.4+ (note: this is not the same as ChatGPT, which is a different OpenAI model). I don't think it's necessary or appropriate to exclude GPT-5.X (non-pro) and Claude Sonnet, since beyond this point cost becomes prohibitive and the differences in quality when references are provided are negligible at best. This already represents a massive step up above the models that are most commonly used for editing on Wikipedia.
I don't think I'm ready to formulate these into a concrete and actionable proposal yet, and would like to get some additional input before doing so. My intent is to create a framework that helps people to use LLMs for appropriate, beneficial, and policy-compliant Wikipedia page editing and creation, with well-elaborated rules that establish clear lines between what is and is not acceptable use. As it stands, the policy is overly restrictive and is detrimental to technical articles. Just-a-can-of-beans (talk) 20:09, 13 June 2026 (UTC)[reply]
was the product of feeding Sonnet 4.6 (a robust flagship LLM) the cited article and instructing it to add content to the existing version of the pathogenesis section. Why not just feed the LLM the articles and ask it to generate notes with page citations for yourself so that you can then read those particular pages and write your own NPOV and MEDRS compliant content? voorts (talk/contributions) 20:58, 13 June 2026 (UTC)[reply]
Re: [Slop] affects medicine pages too, but I'd bet it is a bigger problem on articles that are less technical in nature, since people tend not to feel qualified to edit technical articles on unfamiliar subjects. and the proposal to restrict this to MED and similarly technical topics – I'm skeptical of the premise. One of the problems with LLMs is that they facilitate the generation of massive amounts of superficially good-sounding text by people who lack the domain expertise (or writing proficiency) to effectively evaluate the end product. The LLM ban maintains the barrier to entry that, in your experience, is what keeps problematic contributions to a minimum. I also don't agree that it's true in the first place that MED articles don't attract problematic content, whether LLM-generated or otherwise. This is probably true for a rare disease like adrenoleukodystrophy but many alternative medicine and general medical or scientific topics are magnets for fringe claims. Many topics and articles that are not strictly under the MED umbrella contain biomedical information that is subject to higher WP:MEDRS standards. This includes many hot button "culture wars" topics that attract readers and editors with a wide range of backgrounds and motivations. I do think you raise some valid issues and I've not yet thought through the rest of it. I have some concerns about over-broad bans restricting quality contributions but I also understand that LLM-generated content is flooding the site and that creating too many loopholes or exceptions creates additional problems. —Myceteae🌈 (talk) 21:01, 13 June 2026 (UTC)[reply]
Just running this up the flagpole to see if anyone salutes (might be a terrible idea); what if we gave certain trusted editors permission to use AI, maybe after some training or perhaps passing a test? Take the permission away the first time they screw up. Maybe make them post the first N AI edits as a draft in userspace and ask someone else to review it and post it? --Guy Macon (talk) 21:44, 13 June 2026 (UTC)[reply]
Not saluting. What trusted editors can do is use LLMs for their behind the scenes research… this is OK because we trust them to double check what the LLM generates, and then take what they have checked and re-work it into something appropriate for WP. Blueboar (talk) 22:15, 13 June 2026 (UTC)[reply]
Wikipedia must maintain high standards where possible. LLM use is a way to degrade and join the morass of AI slop, garbage and misleading text that is already prevalent now in journalism and on the internet. We need our editors to take full responsibility for the content. If LLM output is thoroughly checked by the contributor then it could be used. Our problem is when LLM output is not checked and the problems slip past. Graeme Bartlett (talk) 22:56, 13 June 2026 (UTC)[reply]
While I have my reservations regarding the proposed policy (for example, the vast majority of regular LLM users will not be the kind of power users knowledgeable enough to configure a system prompt, and a much clearer line is needed to stem the tide), a more fundamental disagreement lies in what Wikipedia itself means, in the future. Our decision to ban LLM content was very positively received, and it is becoming clear that a Wikipedia by humans, for humans is desperately wanted, especially as people are increasingly skeptical of the "AI revolution" accentuating divides and making tokens the world's new currency. Like many others, I don't want a future where meaningful Wikipedia editing is contingent on having enough to spend on generating content at scale. Let's see the bigger picture here. Chaotic Enby (in solidarity · talk · contribs) 23:56, 13 June 2026 (UTC)[reply]
Keep in mind that this whole business of "pay one of six giant companies a boatload of money to run crappy AI on giant racks of servers in data centers" will inevitably turn into "pay the price of an evening out on a computer you own that runs pretty good AI free in your bedroom forever" and those six companies will collapse. I was there when the company I was working for bought a Wang Word Processor (see Wang Laboratories#Word processors). It was very expensive, but so was retyping entire documents on a typewriter, which is what it replaced. Anyone reading this editing text on a Wang? Anybody? We will need to rethink things as the technology changes. --Guy Macon (talk) 01:15, 14 June 2026 (UTC)[reply]
On the other hand… I can remember when the laser disk was being touted as future of home entertainment. LLMs may turn out to be a dead end… tech nobody wants. Blueboar (talk) 01:37, 14 June 2026 (UTC)[reply]
The only way LLMs end up that way is if an even better AI platform supplants them, in which case we will be debating the use of that platform on Wikipedia. BD2412T12:18, 14 June 2026 (UTC)[reply]
"I'd bet it is a bigger problem on articles that are less technical in nature, since people tend not to feel qualified to edit technical articles on unfamiliar subjects" doesn't gel with how llms seem to be used. People make the most use of them in topics they don't understand, relying on the llm to do the understanding. The promoted example of WMF's own experiment with llm text in mainspace was a MEDRES article. CMD (talk) 02:22, 14 June 2026 (UTC)[reply]
As it stands, the policy is overly restrictive and is detrimental to technical articles.
I appreciate your concerns about this "policy" (ahem... guideline), and I admire your acknowledgment on issues with AI slop. Nonetheless, the consensus overwhelmingly favored extending the rule from only new LLM-generated articles to rewriting an existing one with LLM-generated content. I even favored extending the scope of the rule. I dunno how many threads like this we will see in the future, but I can't stop them until this matter will be considered a perennial issue. Better yet, we're still in a very long road until the time the consensus changes its mind about LLMs. —George Ho (talk) 03:10, 14 June 2026 (UTC)[reply]
I'm not convinced that creating official system prompts or whitelisting models is the right fix. System prompts might help the AI fit in, maybe even get it to use higher quality sourcing, but they never stop hallucinations and inaccuracy. Limiting LLM use to specific topics does nothing as well AI can and will introduce inaccurate info na matter the topic and most people wont check even on medicine articles. I do agree that the current AI guidelines and rules are to restrictive in some ways but I do not think this is how or the way to fix it. I find it acceptable when LLM output actually is checked by someone knowledgeable, but most of it isnt. Like Graeme Bartlett said Wikipedia must maintain high standards where possible. This proposals does not address these issues. Luka Maglc (talk) 06:50, 14 June 2026 (UTC)[reply]
One of the problems is the particular type of hallucination; an experience from work had an LLM cite a paper. Correct paper, incorrect author list. Unless you know about the field, those sort of errors can be hard to catch. Red Fiona (talk) 07:43, 14 June 2026 (UTC)[reply]
Comment: The best way to use AI I've found is as a reviewer. A prompt I've used is "You are an expert of ______ known for being harsh, precise, and demanding. You are asked to peer-review the following text: ____." Another is "You are an expert of _____ asked by a colleague to proof read their writing. Review the following draft and provide recommendations for improvement: ____." I use these as a filter before sending text off to be proofread by a human. I've found that changing "a colleague" to "your student" sometimes gives better results, but not always. This is the kind of use I can see AI being helpful with on Wikipedia, not generating original text. Fundamentally, Wikipedia was likely used to train most if not all of these models, so we're just feeding Wikipedia back into itself if we use it to liberally to generate new content. GeogSage (⚔Chat?⚔) 08:48, 14 June 2026 (UTC)[reply]
NO. LLM-generated content, especially medical content, should never be permitted here under any circumstance. I can't believe this is even a discussion. JoelleJay (talk) 13:26, 14 June 2026 (UTC)[reply]
Policy clarification on transition from IP editor numbers switched now to Temp account designations
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.
General policy clarification question of why Wikipedia has decided that issuing Temp accounts is better than listing the IP accounts directly for these types of anonymous editors without regular accounts. What was the general motivation behind this decision? Previously, for example, I was able to do inquiries given the IP destination numbers as to find the county, state, and major institutional information of the origin of the IP accounts. Now its not possible to do this with Temp account numbers. Why was this seen as an improvement for Wikipedia in general? ErnestKrause (talk) 15:30, 14 June 2026 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
You are invited to join the discussion at Wikipedia:Administrator elections/May 2026/RFC workshop. Chaotic Enby (in solidarity · talk · contribs) 14:35, 7 June 2026 (UTC)
Comment: The best way to use AI I've found is as a reviewer. A prompt I've used is "You are an expert of ______ known for being harsh, precise, and demanding. You are asked to peer-review the following text: ____." Another is "You are an expert of _____ asked by a colleague to proof read their writing. Review the following draft and provide recommendations for improvement: ____." I use these as a filter before sending text off to be proofread by a human. I've found that changing "a colleague" to "your student" sometimes gives better results, but not always. This is the kind of use I can see AI being helpful with on Wikipedia, not generating original text. Fundamentally, Wikipedia was likely used to train most if not all of these models, so we're just feeding Wikipedia back into itself if we use it to liberally to generate new content. GeogSage (⚔Chat?⚔) 08:48, 14 June 2026 (UTC)
![[1]](https://en.wikipedia.org/wiki/Barack_Obama#/media/File:Yellow_flag_waving.svg){kind=link}
![[2]](https://en.wikipedia.org/wiki/Human_sexuality#/media/File:People_together.svg){kind=link}
.jpg){kind=link}
