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.
WP:DRNC should be more of a formal policy. Some editors revert without providing any rationale for the revert and do not participate in talk page discussions. I have seen this happen many times. Even when new changes are introduced, editors revert them, saying "no consensus". They do not explain why it needs consensus or why they object to the change.
If the material or revert is disputed by the editor claiming no consensus, and there are no other editors involved, making it a a 50/50 split, what is wrong with that? Isn't that how the process is supposed to work, through BRD? DN (talk) 00:14, 17 May 2026 (UTC)[reply]
We don't want editors to revert with no reason (citing "no consensus"). No consensus isn't a reason to revert; consensus isn't based on a show of opinions but the balance of policy based arguments. When editors revert due to "no consensus", they are effectively saying "I (or some number of people) disagree, but I (we) don't have a reason for it". Katzrockso (talk) 00:20, 17 May 2026 (UTC)[reply]
Absence of evidence isn't evidence of absence, though. If someone want to make a change, shouldn't they be the ones responsible for building consensus? Personally, I always try to add at least some specific details as to why I don't agree with changes, but I'm not sure why I need to do the work for someone else's requested change. I don't think that's being petty or nit-picking. DN (talk) 00:26, 17 May 2026 (UTC)[reply]
Yes, this ties back to the dozens of discussions we have been having on ONUS lately. If an editor provides a reason to revert (they have to have some sort of reason, even one that the other editor doesn't find very convincing), the ONUS is now on the person wanting to include the disputed content. "No consensus" isn't a reason.
Editors need to provide an actual reason objecting to the change because otherwise this explicitly endorses stonewalling as a legitimate tactic. Katzrockso (talk) 00:47, 17 May 2026 (UTC)[reply]
I sort of agree but I don't think this rises to the level of needing a policy or guideline. I find it kind of annoying when editors revert with "no consensus" and nothing else but I don't think it should be prohibited. —Myceteae🍄🟫 (talk) 00:32, 17 May 2026 (UTC)[reply]
Currently, it has one sentence that says should generally avoid terse explanations (such as "against consensus") - but it's more of a directive. But it should be more stern that an editor cannot revert saying there is no consensus (especially for new content). They should always give an explanation. Maybe it was because it was previously discussed and no consensus was formed. But editors should be clear about that.
@Asilvering recently said this It doesn't give license to editors to revert for no reason other than a lack of discussion; - maybe you have some thoughts on this? 🐈Cinaroot00:42, 17 May 2026 (UTC)[reply]
Sharply oppose. I think the essay is frankly incorrect, as is WP:ONLYREVERT. Their advice is just simply wrong. Reverting to the stable version in case of doubt is the standard for controlled versioning systems in general. Changes need to be actively justified. --Trovatore (talk) 00:46, 17 May 2026 (UTC)[reply]
My point is that there is already too many editors who think that reversion is a personal affront or that complete reverts are to be avoided. That isn't true. I would agree with the narrow point that "no consensus" by itself is not a good edit summary for a revert. However "I don't think this is an improvement" is good enough note: just "not an improvement" is enough; doesn't have to be "actually worse", and at that point the editor who wants the change should usually open a discussion on the talk page. --Trovatore (talk) 00:53, 17 May 2026 (UTC)[reply]
Yes, I agree that "I don't think this is an improvement" should be good enough to trigger ONUS and require the editor wanting to include the material to obtain a consensus. Katzrockso (talk) 01:07, 17 May 2026 (UTC)[reply]
“No Consensus” might not be a good reason to revert… but it is perfectly fine as a request for editors to engage in a discussion to determine whether the material has consensus (or not). Blueboar (talk) 16:38, 17 May 2026 (UTC)[reply]
Regarding reversion: Yes. While I may have an internal emotional reaction to a revert, it's a revert. It's not (at least not supposed to be) a personal affront, it's just working on an article.----3family6 (Talk to me|See what I have done) 13:02, 19 May 2026 (UTC)[reply]
If you have a doubt, simply explain what your doubt is in the edit summary when reverting. "no consensus" or "talk first" is never a valid reason. 🐈Cinaroot00:55, 17 May 2026 (UTC)[reply]
Are we really just talking about edit summaries here? If that's all that's at stake I don't care much. I agree that those edit summaries by themselves are not great. My point is that, other things being equal, the preference should be for the stable version, and any change has to add some identifiable value to overcome that preference. I don't want the language around edit summaries to make editors even more resistant than they already are to reverts. --Trovatore (talk) 01:01, 17 May 2026 (UTC)[reply]
Given the volume of edit wars and reverts, I hardly think editors are too resistant to revert.
Also, being cautious of reverting is a good thing. Research has found that new editors have their edits reverted is one of the top reasons we have such poor editor retention. Given the slowly declining number of editors and lackadaisical emphasis on editor retention on Wikipedia, I hardly think editors are too resistant to revert. Katzrockso (talk) 01:10, 17 May 2026 (UTC)[reply]
Not really. The user research indicates that many of these editors believed that their contributions just aren't good enough, so they give up. WhatamIdoing (talk) 17:09, 18 May 2026 (UTC)[reply]
I wouldn't mind language that is more explicit that reversions should cite reasons policy/MOS/etc reasons, rather than process/workflow reasons why a reversion is justified. At the same time, we should be more explicit that once something is reverted, it is not acceptable for editors to simply restore the material without showing a clear consensus to restore or an clear effort to address teh problem. If material is removed for say a claim of OR or failing WP:V then an edit note+ changes that address the OR/V concerns would be acceptable. If the challenge is something more complex or weight then editors who wish to restore must start a talk page discussion (or respond if one already exists) and shouldn't restore until it's clear a new consensus has been reached. Restoring without a clearly addressing the concern or a clear talk page consensus for inclusion should be seen as problematic editing/editor behavior. While I do see some cases of editors reverting just saying "NOCON" it seems to be something that is often reverted by others. More frequently I see good faith objections that should be viewed as NOCON, ignored because say 2 editors have implicitly decided 2:1 makes for a consensus. Springee (talk) 04:36, 17 May 2026 (UTC)[reply]
I don’t want to place a burden on editors who revert when vandalism is evident. They are able to revert without needing to provide a reason. However, all other explicit reverts should have clearly stated reasons. I don’t want to hinder the BRD process either. For example, if editor A reverts with reason X, then editor B can correct that and restore the content without any discussion. We already have a policy like WP:ONUS to discourage the restoration of disputed content. My suggestion is to more strictly discourage or ban revert with phrases like "talk first," "no consensus" or "discuss first" etc.. while they take a break. Many editors who revert may take hours or even days or don't respond at all, which can slow down the editing process. I want to prohibit such practice. That is no good - I see no reason to do this. 🐈Cinaroot05:18, 17 May 2026 (UTC)[reply]
Oppose. While it is pretty obviously true that one shouldn't revert solely due to no consensus, I oppose making this obvious behavioral principle into a practical rule. How would such a rule be enforced or practiced? Would every revert have to include a substantive policy rationale? That might sound attractive in the abstract, but in practice many reverts are routine cleanup: restoring clearer wording, removing awkward additions, undoing unexplained changes, or returning to a version that was otherwise simply better. A brief summary, like "discuss first", "restored better version", or even "restored consensus version" should be enough. The problem with formalizing DNRC is that it risks shifting the burden onto editors doing ordinary cleanup, including in cases where the reverted edit itself gave no substantive reason. I agree that reverts solely due to no consensus are poor practice, especially in real content disputes where the objection is not apparent. But that should be handled as advice about good editing and communication, not elevated into a rule that creates a new procedural basis for restoring disputed changes.Sławomir Biały (talk) 08:54, 17 May 2026 (UTC)[reply]
If it’s so obvious - why do editors keep doing it? No - not "substantive policy rationale" - but reasonable policy rationale or just a sound or better rationale. Something like “I think this is not a good idea because of XYZ". If it’s an unexplained change - just say it’s "unexplained changes". Reverts solely due to no consensus is never a good practice. There is always something better you can say to help the editor whose edit is being reverted. 🐈Cinaroot10:19, 17 May 2026 (UTC)[reply]
Reverts solely due to no consensus is never a good practice. is an opinion you are entitled to, but that doesn't make it objectively correct or mean that this opinion needs to be codified as a policy. Thryduulf (talk) 10:23, 17 May 2026 (UTC)[reply]
I agree that in many cases "no consensus" is a poor rationale in an edit summary (although I am reluctant to say "always" here: I would think that certain things require affirmative consensus or are against explicit affirmative consensus such as the outcome of an RfC). My primary objection is to turn what is an essay on typical best-practices into a procedural basis for restoring content based on that edit summary. I mean, if an editor can put disputed content in with no edit summary at all, why should the burden for removing that content be asymmetric in such cases? That seems to create exactly the wrong incentive: editors would litigate revert summaries rather than the merits of the content. Sławomir Biały (talk) 10:30, 17 May 2026 (UTC)[reply]
You can always say "this is against an RFC - consensus required" or “Its already reverted once - the page is under affirmative consensus restriction - Please use talk" - if an editor placed a content without an edit summary - and you do not understand the edit - just say "unexplained changes" - if it’s pure vandalism - just revert without any reason. No problem there. My reason for a policy change is to prevent stonewalling and discourage bad behavior by editors.
If such a policy exists - it can be used to revert editors who stonewall. It will also encourage good behavior by the community. If you provide something more- than "no consensus or take it to talk" - then the editor who you reverted will not have a reason to reinstate disputed content per WP:ONUS. 🐈Cinaroot19:16, 17 May 2026 (UTC)[reply]
Just no I edit the front page so that it displays a blinkingmarquee directing people to buy Musk Coins. Someone reverts me because there is no consensus to include such blatant promotion on Wikipedia. I could now restore the blinking marque because 'no consensus isn't a reason to revert, therefore this must stay.' Headbomb {t · c · p · b}09:07, 17 May 2026 (UTC)[reply]
The reason for reverting here is not "no consensus", but rather - "it is a blatant promotion and needs consensus" . There is a difference. The later tells the editor that promotion is not allowed. "no consensus" tells nothing. 🐈Cinaroot10:12, 17 May 2026 (UTC)[reply]
Are you saying that editors have some kind of right to revert because they have no valid reason to revert and just want to make it harder for the edit to be made because they just don’t like it? 🐈Cinaroot10:23, 17 May 2026 (UTC)[reply]
Oppose. In addition to the above good points, there are situations where reverting due to a lack of consensus can be appropriate. For example when there is an ongoing discussion seeking a consensus about this, or when a very recent discussion found no consensus for the change that was made (e.g. a proposal to change X to Y is made, the subsequent discussion found no consensus to make that change, but an editor made it anyway). Thryduulf (talk) 09:45, 17 May 2026 (UTC)[reply]
You can always say - "there is ongoing discussion seeking a consensus about this" or "very recent discussion found no consensus for the change". Now that's helpful to the editor whose edit is being reverted. But saying "no consensus", "take it to talk" etc... is never acceptable. 🐈Cinaroot10:08, 17 May 2026 (UTC)[reply]
While in some contexts other edit summaries might be more helpful the examples are not wrong and in other contexts will be more than sufficient for other editors to fully understand what is going on and why. Also, there is no practical difference between "take it to talk" and "I disagree with this change, we should discuss it first". Thryduulf (talk) 10:22, 17 May 2026 (UTC)[reply]
Whatever is your disagreement - you can always give some hints and briefly explain your thinking and then ask to take it to talk. You might not think "take it to talk" is not a big deal - but it is to the editor whose edit is being reverted. It’s very discouraging especially if they are new to Wikipedia. If an edit is contentious - say this edit is contentious edit - we need to discuss. That’s all 🐈Cinaroot10:39, 17 May 2026 (UTC)[reply]
"take it to talk" and "this edit is a contentious edit - we need to discuss" mean exactly the same thing. The former might not make as much sense to a very new editor as the latter, but to an experienced editor the latter might be seen as patronising. This means that whether one is (more) appropriate than the other is context dependent and thus not at all appropriate for the bright-line policy you seek. Thryduulf (talk) 10:43, 17 May 2026 (UTC)[reply]
Is "take it to talk" not patronizing to an experienced editor? If anyone is willing to give me one edit - that say "no consensus" or "take it to talk" - then if I can’t come up with a better edit summary for it- I will shut up. I continue to believe that - there is always something better you can say - other than "no consensus" or "take to talk" etc.. 🐈Cinaroot10:52, 17 May 2026 (UTC)[reply]
Is "take it to talk" not patronizing to an experienced editor? Not in every situation, no.
continue to believe that - there is always something better you can say - other than "no consensus" or "take to talk" etc.. that's your opinion, and you are entitled to it. I and most of the other people contributing to this discussion disagree. Even if nobody did disagree though that still wouldn't make it automatically suitable for a policy. Thryduulf (talk) 11:03, 17 May 2026 (UTC)[reply]
But your point is understandable. Would you agree that editors should be free to revert edits saying "take it talk" if they do not understand why? 🐈Cinaroot10:55, 17 May 2026 (UTC)[reply]
Absolutely not. If you don't understand why reverting someone because you don't understand (or don't like) their edit summary is an fundamentally atrocious idea then Wikipedia is not the project for you. Thryduulf (talk) 11:05, 17 May 2026 (UTC)[reply]
That's exactly my point — no editor has some inane right to say "take it to talk". Wikipedia is not a dictatorship either. It’s also as atrocious to revert someone without giving a sound or better rationale. I have made my point. Ty 🐈Cinaroot11:12, 17 May 2026 (UTC)[reply]
You have made your point, but almost nobody has agreed with you and you have either not listened to or not understood the points other people have made. Thryduulf (talk) 11:18, 17 May 2026 (UTC)[reply]
That's the whole point of talk pages. See WP:BRD for best practice. Don't encourage communication by edit summary. I will not answer questions that you should be perfectly capable of answering yourself. Phil Bridger (talk) 10:42, 17 May 2026 (UTC)[reply]
Don't encourage communication by edit summary. Is this for real? Where does it say that?
BRD says In the edit summary of your revert, briefly explain why you reverted.
You're suggesting that people should simply revert more by saying “Take it to talk.” Can you not see how that will lead to more disruption? If they "Take it to talk" - you still need to provide a reason. Can't you just provide it in edit summary in the first place. 🐈Cinaroot11:02, 17 May 2026 (UTC)[reply]
I don’t know if it should be heavily policed. But it needs to be said - so that editors don’t abuse it and use it for stonewalling. If someone is stonewalling - policy can be used to revert them. Yes - sometimes people revert it without providing edit summaries if they think it’s obvious. Sometimes people make mistakes by not providing edit summaries. But if an editor routinely does it and is being disruptive - policy can be used against them. But it will also encourage good behavior if we are more stern about it. 🐈Cinaroot18:55, 17 May 2026 (UTC)[reply]
It seems like a really bad idea to restore some bit of content because one feels the objecting editor is just stonewalling. If they are stonewalling it should be easy to get a consensus to include the content. If such a consensus can't be reached then we should assume the problem is real and use other dispute resolution methods, ideally getting more editors involved. Sometimes a claim of stonewalling is nothing more than both sides can't agree but their is just 1 vs 2. I can think of a case where editors seemed very convinced I was totally wrong to object to some content[1]. When a RfC was run the results were overwhelmingly against those editors[2]. Springee (talk) 19:09, 17 May 2026 (UTC)[reply]
I don't think it can encourage people to revert each other; that sort of has to be decided by consensus and our other policies. The reason to spell it out is for user conduct disputes. Simply being in the minority isn't a conduct issue, obviously. Even being a bit stubborn is reasonable (as Springee referenced above, you might be proven right, either due to WP:CCC or seeking wider opinions.) But when someone is constantly stubborn in 1AM situations across a variety of articles, and they're making arguments that seem clearly structured to drag out discussions rather than reach consensus, that's a conduct issue; integrating WP:DRNC more clearly into policy would make it easier to deal with those situations and would, indirectly, encourage people to be more communicative in ways that would hopefully avoid situations escalating to the point where they need to be dealt with as conduct issues in the first place. But we shouldn't have policies that just say "if the other editor uses bad argument XYZ, you win automatically and should immediately revert their edits"; that doesn't work and just makes the problem worse. --Aquillion (talk) 18:00, 24 May 2026 (UTC)[reply]
I agree with Cinaroot in principle, but think WP:EDITCON is the place to make a small tweak rather than promoting the essay. As a general principle, I'd like to spell out somewhere (whether related to documentation of consensus or somewhere else) that there must be a reason for disputing content. That is, it isn't disputed because I reverted; it's disputed because I had a reason to revert it. The threshold for that reason must be very, very low, but you do need a reason other than "it's a change and I'm undoing the change because it's a change" (barring extraordinary contentious articles that need such barriers). — Rhododendritestalk \\ 14:20, 17 May 2026 (UTC)[reply]
Oppose and the essay is wrong - I'm with Trovatore here. That essay is just wrong. It's totally fine to revert due to a lack of consensus. That a change lacks consensus is a perfectly good reason to revert it. Headbomb's example of changing the front page to advertise crypto is instructive: all changes on Wikipedia require consensus, and while sometimes a change can be taken to have consensus simply by being an improvement, this is not necessarily true. In particular, reverting due to no consensus is a crucial part of the WP:BRD cycle. If you couldn't revert just because you disagreed that a change was an improvement any bold change would stay forever with no option to revert. Loki (talk) 14:32, 17 May 2026 (UTC)[reply]
Maybe I’m guilty of reverting thinking it’s obvious. But it might be obvious to you. But not to the editor whose edit is being reverted. Again - if it’s obvious vandalism - no reason is required to revert. 🐈Cinaroot19:39, 17 May 2026 (UTC)[reply]
Ideally even reverting vandalism should include an edit summary that states as much. I'm not sure I've always followed that rule but I suspect everyone would agree that ideally we should always include some level of edit summary. Springee (talk) 23:15, 17 May 2026 (UTC)[reply]
Oppose If the edit summary is insufficient in some way, it can be questioned either on the reverter's talk page or on the article talk page.--Wehwalt (talk) 15:45, 17 May 2026 (UTC)[reply]
Short, blunt edit summaries like “No Consensus” or “Discuss first” should not be seen as justification for a removal of text, but as requests to engage in further discussion about the removed text. Such summaries should begin a conversation, not end one. If you don’t understand an edit summary… ASK! Blueboar (talk) 16:11, 17 May 2026 (UTC)[reply]
It is only stonewalling if the reverting editor ENDS the conversation with “no consensus”. But if we BEGIN with “no consensus” and discuss, we often find that a new consensus can be quickly established. Reaching that new consensus might mean some compromising… but that is how consensus building works. Blueboar (talk) 16:53, 17 May 2026 (UTC)[reply]
I think such short summaries may be OK if another editor has already restored without showing consensus. They shouldn't be the only justification for an initial revert/removal. I would be careful about "stonewalling". I think that is often a claim used by editors who don't want to follow the process to gain consensus. Springee (talk) 16:54, 17 May 2026 (UTC)[reply]
Again… Such terse summaries should not be considered a Justification at all… they are a request to join in a discussion where the “justifications” (for and against the edit) can be more fully outlined and discussed. They start the consensus building process, they don’t end it. Blueboar (talk) 18:58, 17 May 2026 (UTC)[reply]
"should not be seen as justification for a removal of text" But if the summary is not accompanied by any other rationale (in the summary or on the talk page) then its hard to see it as not being the reverter's justification.
Oppose DRNC is best practice, but I don't think it should be in policy. If there has just been an extensie discussion on the talk page, directing a new editor to that discussion is justified. -- LCU ActivelyDisinterested«@» °∆t°16:57, 17 May 2026 (UTC)[reply]
Even if there haven’t been previous discussions… an edit summary requesting that a discussion take place is perfectly reasonable. I agree that we shouldn’t leave a terse summary and then walk away, but it is fine to start a conversation with one. Blueboar (talk) 19:05, 17 May 2026 (UTC)[reply]
But they do walk away. I think experienced editors are so averse to my proposal because they don’t want the burden of explaining a revert on them or just revert, and the other person might not take it to talk or discourage bold edits altogether or someone else might explain it for them on talk. 🐈Cinaroot19:24, 17 May 2026 (UTC)[reply]
I agree that many editors seem to have an aversion to starting discussions. It's just astonishing to see people say things that amount to "No, my WP:UPPERCASE says you have to start the discussion, and I don't have to do anything". WhatamIdoing (talk) 19:26, 17 May 2026 (UTC)[reply]
"If you have reverted someone else's edit or are otherwise in a dispute, do not to tell the other editor to start a discussion. Instead, start the discussion yourself, and invite them to join you. Do this even if all you can think of to say is 'I didn't like that last edit' or '@User, we should talk about this instead of risking an edit war." ? WhatamIdoing (talk) 20:18, 17 May 2026 (UTC)[reply]
It depends. If you understand why someone might want to add/remove that material and can clearly express why you disagree with the inclusion/exclusion or whatever else your objection is with relevance to that, then yes, starting the discussion yourself is usually going to be best. However if you don't understand the motivation behind the edit then you're as likely to begin a discussion with a bunch of strawmen as anything relevant, which is liable to get the discussion off on the wrong foot and less likely to lead to a quick and easy consensus (e.g. due to other editors getting the wrong impression when they skimread). Thryduulf (talk) 01:08, 18 May 2026 (UTC)[reply]
Because the answer to that will be something like "because it improves the article". Asking instead "Why do you think this edit improves the article?" is liable to come off as aggressive. Thryduulf (talk) 02:33, 18 May 2026 (UTC)[reply]
I don't think that's the likely response. I think the likely response will provide a little more detail, like "because I thought the article should include ____". WhatamIdoing (talk) 02:35, 18 May 2026 (UTC)[reply]
How does such a question come off as aggressive? You're just politely asking another editor for the motivation behind an edit, because every edit should be made with the intent to improve Wikipedia. SuperPianoMan9167 (talk) 13:34, 19 May 2026 (UTC)[reply]
I think that we need to define "no consensus" before we can have a sensible conversation. I oppose reverts for "no consensus" when the meaning is "Bold editing is not allowed here, so you must get written permission before changing this page". But I can accept reverts for "no consensus" when the meaning is "The RFC literally closed as 'no consensus' yesterday, so why are you implementing your failed proposal as if you had consensus for it?!" WhatamIdoing (talk) 19:20, 17 May 2026 (UTC)[reply]
Yup, it discourages bold editing. If it’s against a recently closed RFC - it’s most likely that the editor didn’t know. So just say “it’s against an RFC - here is the link - get consensus" - problem solved. Again, "no consensus" is never a good edit summary in 99 or 100% of the time. 🐈Cinaroot19:27, 17 May 2026 (UTC)[reply]
Why does everything need to be spelled out in an edit summary?
If there is a previous RFC, I think it fine to summarize a revert with a terse “Not consensus” - as long as you follow up with a talk page thread pointing to that previous RFC. Blueboar (talk) 19:58, 17 May 2026 (UTC)[reply]
Why not? Why do you need to as long as you follow up? Why that editor has to wait for you to as long as you follow up
No sir - Reverting is Not a inherent Right - Your comments are only reaffirming how the community thinks and why a change might be warranted. Experienced editors are becoming more comfortable treating reverting as a default tool, when it should be a last resort. This attitude — that you can revert first and explain later — is exactly what discourages editors from contributing and is disruptive. 🐈Cinaroot20:19, 17 May 2026 (UTC)[reply]
I absolutely disagree with your contention that reverting should be a “last resort”. Editing involves both adding, and removing material. Removing is just as important as adding. That’s why we are called “editors” and not “writers”. Blueboar (talk) 20:50, 17 May 2026 (UTC)[reply]
Yah - maybe you are right about the last resort part - but if it’s a first resort - then explain in edit summary. 🐈Cinaroot21:25, 17 May 2026 (UTC)[reply]
This is a strawman argument. No one will complain about an editor who supplements a "no consensus" edit summary with a talk page post pointing to the prior consensus. - Butwhatdoiknow (talk) 23:25, 17 May 2026 (UTC)[reply]
True enough, but there are also editors who think that they shouldn't ever have to supplement their "no consensus" edit summary with a talk page post of any kind. WhatamIdoing (talk) 01:47, 18 May 2026 (UTC)[reply]
Edit summaries used to be short - so short that the generated part sometimes filled up the whole summary. WMF lifted the size to allow longer edit summaries. But carrying on a discussion through edit summaries is a really bad idea, because edit summaries are much harder to search than talk pages. Hawkeye7(discuss)03:49, 18 May 2026 (UTC)[reply]
And there is still a limit on the size of edit summaries, just a slightly higher limit than there used to be. I don't understand why the OP is so obsessed with the idea of communicating via edit summaries rather than talk pages. Phil Bridger (talk) 08:35, 18 May 2026 (UTC)[reply]
It may do, but as soon as someone wants to say something that doesn't fit in an edit summary we get problems. Policy should steer people away from such problems. Edit summaries are not designed for this—not least because it is impossible to leave an edit summary without editing the article—but talk pages are. Phil Bridger (talk) 18:36, 18 May 2026 (UTC)[reply]
Communication shouldn't happen in edit summaries. The purpose of edit summaries is to briefly describe what changes were made (and, if not obvious from context, briefly explain why). An edit summary is a statement of fact, not a conversation. Thryduulf (talk) 19:26, 18 May 2026 (UTC)[reply]
Communication does happen in edit summaries, and there's no value to telling editors that they "shouldn't" do so. The only way to stop this will be to get rid of edit summaries. WhatamIdoing (talk) 04:50, 19 May 2026 (UTC)[reply]
While you might think there is no value is discouraging using edit summaries for something it was not intended for and is ill-suited for, that is very different to explicitly mandating using edit summaries for that purpose (which is what the OP apparently desires). Thryduulf (talk) 10:59, 19 May 2026 (UTC)[reply]
No, there is some important value to this. Establishing a general principle that all edits must have rationales, and that "no consensus" or "take it to talk" are not sufficient, means that an editor's history of such edits can be used as an argument that they're WP:STONEWALLing or making tendentious edits on WP:AE or WP:ANI. And beyond that, the threat of that eventuality would encourage editors to generally be more communicative. AE and ANI are not, like, rubber stamps for policy; they're not going to ban someone for occasionally saying "take it to talk" in situations where the reason is glaringly obvious. But stonewalling and tendentious editing are some of the most frustrating and hardest-to-prove behaviors, so having another clear identifier for one of the tactics that enables them, coupled with at least a general "do not do this" guidance, might help at both discouraging them and making it easier to identify editors who do not respond to discouragement. --Aquillion (talk) 02:12, 20 May 2026 (UTC)[reply]
There is clearly not consensus that an edit summary of "take it to talk" or "no consensus" is not sufficient. A pattern of reverting while refusing to explain or participate in discussion may be evidence of WP:STONEWALLing or tendentious editing, but that depends on the surrounding conduct, not on any particular edit summary. Sławomir Biały (talk) 12:37, 20 May 2026 (UTC)[reply]
The purpose of edit summaries is to briefly describe what changes were made (and, if not obvious from context, briefly explain why). That's a form of communication between editors. Edit summaries are a form of communication by definiton, as they communicate to other editors the reasons for making a change. SuperPianoMan9167 (talk) 13:32, 19 May 2026 (UTC)[reply]
Technically true but irrelevant to this context, which is about discussion of reasons for disagreeing with the addition or removal of content because one or more editors feels that a consensus is required before making that change. Thryduulf (talk) 13:41, 19 May 2026 (UTC)[reply]
I don't think it's completely irrelevant. "Rv duplicate" tells you exactly what the "reasons for disagreeing with the addition" are. But even "no consensus" (which I hate, and would cheerfully put an AbuseFilter warning on if it weren't so expensive) tells you something. It's unclear whether it communicates something closer to "Danger, frayed nerves and twitchy trigger fingers around here" or "The editor who reverted me is an entitled jerk who will be the first up against the wall when the revolution comes", but it does communicate some useful information. WhatamIdoing (talk) 01:47, 20 May 2026 (UTC)[reply]
Oppose. The essay is sometimes right and sometimes not right. WP:ONUS is the only real guiding policy in this area, along with WP:3RR. (And despite what some think, WP:BRD has never been any sort of guideline or policy, except in limited areas such as WP:RMUM). Either way, we don't need extra WP:CREEP or confusion, so keeping this as an essay is just fine. — Amakuru (talk) 20:59, 17 May 2026 (UTC)[reply]
WP:ONUS is the only real guiding policy in this area - it certainly is not. We have literal years of discussions about this on the contradiction between ONUS and NOCON on Wikipedia talk:Verifiability, none of which have ever reached a consensus, but one thing that everyone has always agreed on (as far as I know) is that a revert of just "rv. per ONUS" with no further explanation is never appropriate; someone who does that constantly should and will be blocked for failing to communicate properly when editing. As a general rule I'm shocked that people are giving ONUS so much weight; to me, it is a heavily-disputed policy which we've never really managed to reach a consensus on in any real respect, meaning that it is usually a poor idea to cite it in discussions for any purpose beyond the most trival meaning of "verifiability does not guarentee inclusion" (which was its original purpose and original intent.) --Aquillion (talk) 19:22, 25 May 2026 (UTC)[reply]
Actually, the original “verifiability does not guarantee inclusion” section (as I first wrote it) was distinct from ONUS. My original language merely noted that verifiable information could be removed when there is consensus to remove it. In my original language the unstated assumption was that an actual consensus to remove existed that we could point to. The assumption was that there wasn’t a dispute.
ONUS on the other hand, assumes that there is a dispute. It is focused on a different scenario. That is one reason why I eventually split ONUS and “VNOT” into two distinct sections. Blueboar (talk) 19:59, 25 May 2026 (UTC)[reply]
Oppose Blunty, there's already enough bureaucratic nonsense that prevents well-meaning editors retaining the status quo against POV newcomers who want to use our policies against us. We don't need to give them more ammo. Even the original essay is flawed in this manner. — Czello(music)11:13, 19 May 2026 (UTC)[reply]
Irony is that - your reply itself reads as bureaucratic. "POV newcomers" - "use our policies against us", "retaining the status quo" etc.
"We (established editors) are right"
"They (newcomers) are trouble"
"We shouldn't have to explain ourselves"
The irony is huge — complaining about bureaucracy while defending the bureaucratic behavior: reverting without reasonable explanation or saying "discuss first" etc...
And I'm not saying people, including myself, won’t make mistakes by reverting without adequate edit summary. But it sucks - how experienced editors frequently abuse their privileges by reverting without adequate explanation and making it hard for other editors who have different POV.
I am also concerned about the tendency to believe that our articles are good. Some reviewers look for near-perfection in the additions, without considering that the "mediocre" new contribution might have been the best thing in the whole article. WhatamIdoing (talk) 01:55, 20 May 2026 (UTC)[reply]
When I'm talking specifically about POV newcomers - yes, I do believe that. They generally are trouble, and we generally know what's best for our articles. This isn't at all about them having a different POV - they shouldn't be bringing any POV at all into the article. Retaining the status quo should be easier, not harder, in the face of that. — Czello(music)13:38, 21 May 2026 (UTC)[reply]
What about when the article is already bad? If an article is full of the Republicrat POV, then maybe what we actually need is someone to "push" a little Demican POV into the article. Retaining the status quo should only be easy if the article is in good shape to begin with. WhatamIdoing (talk) 22:05, 21 May 2026 (UTC)[reply]
Firstly I don't think the solution to POV is more POV from a different side of the isle. But in answer to the broader question - yes, the article needs to be fixed, and TA editors are capable of doing that (though, again, not by bringing POV and creating a POV battlefield), but we don't need additional policies that are going to make it harder to protect the good articles. — Czello(music)08:34, 22 May 2026 (UTC)[reply]
When editors are following the advice in Wikipedia:Consensus (e.g., making "an effort to address editors' legitimate concerns through a process of compromise") – which I will grant does not necessarily happen as often as we could wish in POV-oriented articles – then sometimes what we really need is "more POV from a different side", so that the existing "winner" can't have it all his way.
On that first point we fundamentally disagree. A POV article is rarely improved by introducing more POV; the solution is bringing it back to neutrality. I think what you're describing sounds more like WP:FALSEBALANCE.
On your second point, though, I think most articles on Random are passable at least and not improved by POV editors. However, the articles I'm talking about are rarely come across on Random; most articles don't invite POV, but those that do are the ones which become battlegrounds for it. — Czello(music)07:18, 23 May 2026 (UTC)[reply]
When the POV article fails the NPOV policy due to missing information, then "introducing more of the missing POV" and "bringing it back to neutrality" are the same thing. WhatamIdoing (talk) 18:53, 23 May 2026 (UTC)[reply]
So you have an article that presents everything from the POV of the deontologists. I say the solution (per WP:YESPOV) is adding information about the missing consequentialist POV. You say that adding information about the missing POV is a FALSEBALANCE, and that the solution is – blanking the article? Because that's what will happen in we "remove the existing POV". Maybe you'd like to re-consider your statement? WhatamIdoing (talk) 18:47, 25 May 2026 (UTC)[reply]
If it's a legitimate opposing view like that then it's fine. But that's not what I'm talking about, and we've gone way off topic. I'm simply talking about not making it harder for decent editors to protect articles against drive-by POV editors. That's all. — Czello(music)17:43, 28 May 2026 (UTC)[reply]
I feel like the underlying policy, if there is one, would be something like "you should provide a policy-compliant rationale for your reverts" (and some things, like "no consensus" on its own, are not enough.) But stating it like that makes it clear, I think, that we'd have to be careful - it's a reasonable guideline, and I think it reflects overarching practice; someone who constantly goes around reverting stuff without a valid reason is going to face sanctions eventually, and "no consensus" is not itself a valid reason in a vacuum. When there's a clear established consensus or when an edit is obviously, clearly controversial and the history on the page makes that context clear it's more reasonable, but even then, it'd be better to point to the existing consensus or lay out the skeleton of the argument against that edit to progress discussions. Perhaps if we were going to boil this down to an underlying principle or guideline, that would be it - reverts (of non-vandalism, when dealing with stuff that is contested) should, when possible, focus on progressing discussion, presenting your argument, etc. Sometimes this is difficult but a revert that makes no attempt to move things forwards is a potential indicator of WP:STONEWALLing or other issues and cuts at the worst sort of revert-warring. --Aquillion (talk) 01:59, 20 May 2026 (UTC)[reply]
Also, I vaguely alluded to this above, but another possibility to actionize this principle would be to add it to WP:STONEWALL and / or WP:TEND as a possible indicator of stonewalling or tendentious editing (ie. editors may use "rv, no consensus" to stonewall by making discussions difficult; or they may use it for reverts where they don't want to articulate their reasons because those reasons are not appropriate, ie. tendentious.) Adding it there avoids the issue of making it a hard-and-fast rule - nobody would accept the idea that an editor is tendentious solely because they occasionally use inappropriately terse edit summaries. But it would turn it into another valuable point that could be used to make the case for larger misconduct, while also generally encouraging editors to be more communicative. --Aquillion (talk) 02:15, 20 May 2026 (UTC)[reply]
I'd define it from the second sentence in Wikipedia:Consensus: An editor's participation is constructive if they're making an effort to address editors' legitimate concerns through a process of compromise while following Wikipedia's policies and guidelines.
But STONEWALL doesn't really need to figure out whose behavior is constructive. It really just needs to be able to figure out whose behavior is clearly unconstructive, and that's usually easier (e.g., WP:IDHT, inappropriate accusations of vandalism, WP:REHASHing the same points endlessly, demanding that there be WP:NORFC, etc.). WhatamIdoing (talk) 03:42, 20 May 2026 (UTC)[reply]
One case where I have seen editors reverting with instruction to seek consensus on the talk page is where the variety of English has been changed. The reverting editor is strictly following our guideline: Unjustified changes from one acceptable, consistently applied style in an article to a different style may generally be reverted. Seek opportunities for commonality to avoid disputes over style. If you believe an alternative style would be more appropriate for a particular article, seek consensus by discussing this at the article's talk page (MOS:STYLERET) Hawkeye7(discuss)22:14, 21 May 2026 (UTC)[reply]
I made a proposal at WP:TEND that is slightly inspired by this, here, although as I was writing it out I realized the broader point that vague or misleading edit summaries are a potential indicator of tendentious editing is actually more important than the question of whether WP:DRNC edits are vague. --Aquillion (talk)
OpposeWP:BRD is not called WP:BD. While reversion for no reason should be minimized, if the editor believes the modification is actively making an article worse, reversion can be justified. Having what may be detrimental content in an article for potentially weeks to months while it is debated is not a net positive. "No consensus" generally implies "I believe this is detrimental and consensus should be established". ᴢxᴄᴠʙɴᴍ (ᴛ) 08:58, 26 May 2026 (UTC)[reply]
I have realized what is bothering me about this thread. People are using edit summaries to convey the wrong type of information. Edit summaries are great for telling other editors what someone did in an edit (“added info”, "reverted”, “copy edit”, etc.)… But they are not great for explaining why someone did it. If the why isn’t blatantly obvious… or if there is any question as to why someone made an edit, that should be explained or asked about on the talk page, not in the edit summary. Blueboar (talk) 12:20, 20 May 2026 (UTC)[reply]
I’m not saying you can’t explain “why” in an edit summary… I am saying that an edit summary is not the best place to do so. I am saying that the talk page is a better place to explain “why”. We should be encouraging more use of talk pages for explanations - and not encouraging using edit summaries for this. Especially for anything close to complex. Blueboar (talk) 19:27, 21 May 2026 (UTC)[reply]
When the "why" can be easily explained in edit summary form, it's more efficient. Other editors see the change and its reason in the same diff, whereas the other editors are less likely to go hunting on the talk page to see if there's an explanation there. The talk page is probably best for a complex "why", but isn't the best place when a simple "why" can be stated in the edit summary. I don't think we want to state that the talk page is always preferred for the "why". Schazjmd(talk)14:12, 22 May 2026 (UTC)[reply]
Nor should we mandate that the edit summary always explain the why. With this edit I didn't need more than the edit summary and a talk page section would have been overkill, but if someone disagreed with that edit for reasons that cannot be expressed in a few words I would expect them to use the talk page. Similarly, if someone did disagree in a concise manner but I disagreed with that then I would take it to the talk page not an edit summary. If in doubt though, the talk page is the better place than the edit summary. Thryduulf (talk) 14:24, 22 May 2026 (UTC)[reply]
In a general sense, most additions of new material only need a "what" summary, because the "why" -- that this is additional material that belongs in the article -- is implied. "Why" is largely needed for deletions and changes to existing material. And in 90%+ of the cases, the edit summary can make clear why or it will be clear between the edit summary and the diff, which is just as easy to get to as an individual talk page message. While there are certainly times where a very brief summary and "see Talk" is called for ("this was cited to seven different sources, each not valid for a different reason, see Talk"), they are very much in the minority. -- Nat Gertler (talk) 14:30, 22 May 2026 (UTC)[reply]
People explain `why` an edit was made all the time using edit summaries.
I made a bold edit to WP:CCC - I explained `what` and `why` in edit summary.
Not going to use talk to explain every edit I made. So instead of spending little effort explaining in edit summary - you want people to make more effort explaining in talk? This is not at all helpful. 🐈Cinaroot05:16, 21 May 2026 (UTC)[reply]
It seems to me that as long as edit summaries are optional, an editor who feels that leaving one has become too laborious a process will opt to leave none at all...or worse, will leave one that's more unhelpful than what they might have used for a summary otherwise. Similarly for the Talk page, especially, I suspect, for newer editors. DonIago (talk) 13:29, 21 May 2026 (UTC)[reply]
I disagree in general: in many cases, what was changed is more easily described directly by the diff. As an edit summary is a brief overview of the change, often it's more suitable to use it to describe the motivation for the change. There will of course be cases where a full description is lengthy, and so the edit summary can only provide an outline, with more details provided as needed on the talk page. isaacl (talk) 03:19, 23 May 2026 (UTC)[reply]
In general, this discussion is about reverts or removals (and by removals we mean contested removals, which are generally reverts.) Per WP:REVEXP, you're supposed to explain those. This is particularly relevant to WP:ONUS because many people have started to use it as a rationale to revert or remove things with no further explanations beyond demanding that people get consensus. As a general rule, I don't think that that's collaborative behavior. Additions don't usually require explanations because it is a given that if something is verifiable and due then adding it has at least a reasonable potential to be an improvement (and those things can be inferred from associated sourcing.) Uncontroversial copyediting also doesn't usually require an explanation because the advantage to simple fixes is obvious. But reverts and removals generally do, as do contested or obviously-controversial changes that alter the direction of the text. --Aquillion (talk) 17:50, 24 May 2026 (UTC)[reply]
Much has been made above of editors reverting (whether because of "no consensus" or otherwise) and then not participating in talk page discussion. Could we please have some examples of this? And how this change could fix it? Phil Bridger (talk) 21:29, 25 May 2026 (UTC)[reply]
Support, for what it's worth - I've definitely seen this. It serves to lock-in the initial position of a page and prevents the page from evolving at all. The people who do it often aren't even opposed to the edit you are making - they just believe that there's a formal process that has to be followed in all cases on Wikipedia which famously(ish) isn't that, and that RFCs closed by an admin (or even a team of admins) are the only way in which a consensus can possibly arise.
Support, but I may end up opposing depending on the exact language of the proposal. If the reverter (and everyone else) declines to give a substantive reason at the talk page after being asked for one, then that should definitely be against policy. The reason might be merely a couple words, like "already discussed", or "too wordy", or "violates NPOV" or something like that. But reverts need to be actively justified, just like challenged changes need to be actively justified. An edit summary like "against consensus" doesn't say why it's allegedly against consensus, and should not count as an explanation. It's more like a power flex than an explanation. Anythingyouwant (talk) 09:57, 7 June 2026 (UTC)[reply]
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]
I am resisting attempts to include an uninformative Infobox including a direct link to the site at the motherless.com page. This is not just another mainstream porn site like Pornhub, xvideos etc, which have strong moderation and policies against illegal content. The content is user provided and historically at least has not been well moderated. It has a well-deserved dodgy reputation and has hosted plenty of illegal content, including in the recent past content related to drug-induced sexual abuse of intimate partners (per the CNN report). In my opinion Wikipedia should not directly link to sites like this. MaxBrowne2 (talk) 07:13, 29 May 2026 (UTC)[reply]
Worth pointing out that linking to porn sites in general is not the same as Motherless specifically. I don't think there should be any prohibition on linking to porn sites generally, but there is obviously a case for Motherless given the illegality of some of its content. Though, then again, the URL is literally the article name, so there's that. — Czello(music)08:19, 29 May 2026 (UTC)[reply]
I don't see a reason to not follow the guideline for an official link, since we also allow shock sites to have the official link (see our articles on Ogrish.com or Goregrish.com as examples). Giving an official link back to the official site of an article is helpful to readers, regardless of how distasteful the content of that site may be.
WP:ELNO #3 states Sites containing malware, malicious scripts, trojan exploits, or content that is illegal to access in the United States. So yes, it should be removed, though as mentioned above that is somewhat moot given the article title. Black Kite (talk)08:32, 29 May 2026 (UTC)[reply]
True, but it also states in the same section Except for a link to an official page of the article's subject and further down These links are normally exempt from the links normally to be avoided, but they are not exempt from the restrictions on linking.
Regarding our restrictions on linking to sites that violate copyright, it seems Motherless is one of the adult sites that complies with takedown requests (see Stanford), but also removes anything deemed illegal or did at one time (see Bloomberg) - But the court affirmed a lower court’s ruling that Lange’s screening out and removing obviously illegal content, such as infringing material and child pornography, granted him safe harbor protection.
The latest CNN update posted May 15 says Update: One week after being taken offline, Motherless has returned. On its website, Motherless said it had “strengthened our moderation systems and processes to more effectively prevent illegal content.” On May 15, a cursory CNN search found that several terms previously identified during our investigation appear to be now banned in English, however not in other languages. Motherless has previously deleted videos and banned other search terms related to DFSA following the work of investigative journalists in Germany on this issue.
That seems to be the exact response we as editors would want to show if a site is doing its part to remove illegal content, no?
"content that is illegal to access in the United States" != "some content that is illegal to access in the United States". All websites with user-submitted content (Twitter, Reddit, Wayback Machine, etc.) have some content that is illegal under US law, because moderation is never perfect, but we still link to them because the majority of content is legit. I don't see why Motherless should be treated differently because most content there is also legit.--~2026-31844-41 (talk) 16:02, 29 May 2026 (UTC)[reply]
Per CNN, the site describes itself as a moral free file host where anything legal is hosted forever (emphasis added). The original CNN investigation only said the legality of some material was in serious doubt, not that it had definitely uncovered illegal videos on the site. As ~2026-31844-41 points out, all websites with user-submitted content have some content that is illegal under US law, because moderation is never perfect. Motherless.com should be treated no differently than Reddit or Facebook in this regard. ~Sangdeboeuf (talk) 03:13, 30 May 2026 (UTC)[reply]
They claim that anything they host is legal. But in practice much of it is not, and this has resulted in frequent court cases. Besides the obviously gross illegal material, they also frequently host copyvio. MaxBrowne2 (talk) 11:17, 30 May 2026 (UTC)[reply]
Besides the obviously gross illegal material, they also frequently host copyvio
Can you provide sources to back this up? They have a noted history (per the CNN update and the appeals court links in my previous reply, and seemingly this) of actively removing anything that is illegal when notified, policing the content themselves, as well as removing copyrighted content.
From the discussion on this, this site seems to simply be a not well moderated file hosting site. As long as linked content from this site in a specific instance is not in direct violation of Wikipedia policy, and also per WP:CENSOR, this content clearly should be allowed on Wikipedia. Ilov3gam3z (talk) 16:01, 30 May 2026 (UTC)[reply]
Before that CNN report, I would question whether we should have an article about this subject at all (perhaps a link to a detail in the Amanda Todd article). Now that it's here, plus the follow-ups, plus the other networks that have picked up the story, etc., I'd say it's primarily notable for illegal activity. I don't think we need to delve into the wikilaw particulars to decide that is not a site we want to connect readers to. That said, by covering the subject at all, we're providing the URL regardless, so whether we also include a hyperlink doesn't really make much of a difference. Here's an outside-the-box thought: since the investigation that confers notability on the subject is also about a Telegram group, is this worth proposing a merge into drug-facilitated sexual assault, at which point an official link becomes moot? — Rhododendritestalk \\ 14:19, 30 May 2026 (UTC)[reply]
Could you provide links to some of those sources? There's currently a lot of social media misinformation about a purported "online rape academy" connected with the website, despite the original CNN report never definitively claiming to have found illegal material there. Meanwhile, Snopes quotes a journalist saying there were dozens of Telegram groups with up to 70,000 members and rape videos reaching millions of views. Yet so far no one has suggested we shouldn't link to Telegram.org. ~Sangdeboeuf (talk) 15:30, 30 May 2026 (UTC)[reply]
One option that we've used in similar circumstances is to provide the link in the infobox, but make it non-clickable: |website=motherless.com . WhatamIdoing (talk) 18:13, 30 May 2026 (UTC)[reply]
I think we're kidding ourselves when the link is in the title... non-clickable is probably the best option. Also, for the general principle, illegality has never stopped us before; we link tons and tons of piracy sites in their articles, The Pirate Bay, Anna's Archive, etc. PARAKANYAA (talk) 19:40, 30 May 2026 (UTC)[reply]
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 [8] or [9]. 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: [10] 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.
^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]
![[8]](https://en.wikipedia.org/wiki/Barack_Obama#/media/File:Yellow_flag_waving.svg){kind=link}
![[9]](https://en.wikipedia.org/wiki/Human_sexuality#/media/File:People_together.svg){kind=link}
.jpg){kind=link}
You are invited to join the discussion at Wikipedia talk:Speedy deletion § Proposal to expand G8 to pages that are completely blank and have no use for Wikipedia. RaschenTechner (talk) 18:04, 5 June 2026 (UTC)