Wikipedia:Administrators' noticeboard

Welcome — post issues of interest to administrators.

For urgent incidents and chronic, intractable behavioral problems, use Wikipedia:Administrators' noticeboard/Incidents. If you are new, try the Wikipedia:Teahouse instead. Do not report breaches of personal information on this highly visible page – instead use Wikipedia:Requests for oversight. For administrative backlogs add {{Admin backlog}} to the backlogged page; post here only if urgent. Do not post requests for page protection, deletion requests, or block requests here. Just want an admin? Contact a recently active admin directly. If opening a close appeal, use {{RfC closure review}} When you start a discussion about an editor, you must leave a notice on their talk page. Pinging is not enough. You may use {{subst:AN-notice}} ~~~~ to do so. Sections inactive for over seven days are archived by Lowercase sigmabot III.(archives, search) Start a new discussion

Open tasks

XFD backlog

V	Jul	Aug	Sep	Oct	Total
CfD	0	1	12	0	13
TfD	0	1	11	0	12
MfD	0	1	8	0	9
FfD	0	1	3	0	4
RfD	0	0	111	0	111
AfD	0	0	2	0	2

• 2 bot-reported usernames for administrator attention
• 2 user-reported usernames for administrator attention
• 0 bot-generated requests for intervention against vandalism
• 14 user-generated requests for intervention against vandalism
• 54 sockpuppet investigations
• 11 Candidates for speedy deletion
• 3 Fully protected edit requests
• 8 Candidates for history merging
• 7 requests for RD1 redaction
• 41 elapsed requested moves
• 1 Pages at move review
• 30 requested closures
• 129 requests for unblock
• 0 Wikipedians looking for help from administrators
• 17 Copyright problems

Pages recently put under extended-confirmed protection

Report

Pages recently put under extended confirmed protection (30 out of 8510 total) () WATCH Page Protected Expiry Type Summary Admin Shin Bet 2024-10-05 03:22 indefinite edit,move Contentious topic restriction: per RFPP and ARBPIA Daniel Case 2024 Israel–Hezbollah war 2024-10-05 00:12 indefinite edit,move Arbitration enforcement ScottishFinnishRadish User talk:SinisterUnion 2024-10-04 23:41 indefinite edit Persistent sock puppetry Star Mississippi User talk:CrazyLoverFutbolLoko 2024-10-04 23:34 indefinite edit Persistent sock puppetry Star Mississippi SDF insurgency in northern Syria 2024-10-04 22:55 indefinite edit,move WP:GS/SCW&ISIL ToBeFree Tulkarm camp airstrike 2024-10-04 13:39 indefinite edit,move Arbitration enforcement: WP:CT/A-I; requested at WP:RfPP Elli Rawhi Mushtaha 2024-10-04 13:38 indefinite edit,move Arbitration enforcement: WP:CT/A-I; requested at WP:RfPP Elli Ibrahim Aqil 2024-10-03 22:32 indefinite edit,move Restoring protection by Favonian: Contentious topic restriction: WP:CT/A-I -- requested at WP:RFPP Protection Helper Bot Talk:2024 Israeli invasion of Lebanon 2024-10-03 15:10 2024-10-10 15:10 edit,move Arbitration enforcement ScottishFinnishRadish Subh-i-Azal 2024-10-03 06:26 2024-11-03 06:26 edit,move Persistent sock puppetry; requested at WP:RfPP Daniel Quinlan Portal:Current events/2024 June 8 2024-10-03 03:21 indefinite edit,move Arbitration enforcement Cryptic Panna Dhai 2024-10-02 20:12 indefinite edit,move Community sanctions enforcement: per RFPP and WP:GS/CASTE Daniel Case Yadavs in Bihar 2024-10-02 19:16 indefinite edit,move Community sanctions enforcement: per RFPP and WP:GS/CASTE Daniel Case Majhraut Ahir 2024-10-02 19:13 indefinite edit,move Persistent disruptive editing: per RFPP; will also log as CTOPS action Daniel Case Maratha (caste) 2024-10-02 18:51 indefinite edit Community sanctions enforcement: per RFPP and WP:GS/CASTE Daniel Case Barua people 2024-10-02 18:19 indefinite edit,move Community sanctions enforcement: per RFPP and WP:GS/CASTE Daniel Case Nevatim Airbase 2024-10-02 14:41 indefinite edit,move Arbitration enforcement: WP:CT/A-I; requested at WP:RfPP Elli Wikipedia:Articles for deletion/Gold Apollo AR924 2024-10-02 12:57 indefinite edit,move Arbitration enforcement ScottishFinnishRadish Portal:Current events/2024 October 1 2024-10-02 06:01 indefinite edit,move Contentious topic restriction: per RFPP and ARBPIA Daniel Case 29 September 2024 Israeli attacks on Yemen 2024-10-02 05:57 indefinite edit,move Contentious topic restriction: per RFPP and ARBPIA Daniel Case 2024 Jaffa shooting 2024-10-02 05:50 indefinite edit,move Contentious topic restriction: per RFPP and ARBPIA Daniel Case Thirty-seventh government of Israel 2024-10-02 03:57 indefinite edit,move Contentious topic restriction: per RFPP; will also log as CTOPS action Daniel Case October 2024 Iranian strikes against Israel 2024-10-01 23:21 indefinite edit Highly visible page as it's currently on the main page Schwede66 Ein Feshkha 2024-10-01 21:23 indefinite edit,move Contentious topic restriction: WP:ARBPIA Ymblanter Template:Calendar/styles.css 2024-10-01 18:00 indefinite edit,move High-risk template or module: 2665 transclusions (more info) MusikBot II Hezbollah Headquarters 2024-10-01 17:18 indefinite edit,move Arbitration enforcement: WP:CT/A-I; requested at WP:RfPP Elli Third Lebanon War 2024-10-01 17:17 indefinite edit,move Arbitration enforcement: WP:CT/A-I; requested at WP:RfPP Elli User talk:The Master of Hedgehogs/Fairy piece puzzle 5 2024-10-01 17:15 indefinite create Repeatedly recreated; requested at WP:RfPP Elli Timeline of the Israel–Hamas war (27 September 2024 – present) 2024-10-01 17:13 indefinite edit,move Arbitration enforcement: WP:CT/A-I; requested at WP:RfPP Elli Fatah Sharif 2024-10-01 15:32 indefinite edit,move Contentious topic restriction: WP:CT/A-I -- requested at WP:RFPP Favonian

Reliability of La Patilla closure review

After posting at WP:RS/N here at AN, I was adviced to ask for a review of the closure of the RfC on the reliability of La Patilla. If I'm counting correctly, at least eight editors (without including myself) have expressed their dissaproval with the closure at Wikipedia talk:Reliable sources/Noticeboard#Deprecation RFCs and quorums and have asked for its review and possible overturn. NoonIcarus (talk) 15:04, 6 August 2023 (UTC)

• There is clearly no community wide consensus that can be derived from a discussion with such a limited number of participants, and even in said discussion the majority view is not even for the option chosen by the closer. Overturn and change the close to not enough participation to determine site-wide consensus, certainly not enough for a source to be ruled verboten for use across the entire encyclopedia. And given the closer's repeated editing sprees removing sources from articles in which they themselves close RFCs as "deprecate", dont think this person should be closing any deprecation RFCs. Since they feel so strongly about the topic they should participate in the discussions, not close them. nableezy - 17:06, 6 August 2023 (UTC)
• Overturn closure (uninvolved with RfC) Two issues were raised in the discussion immediately after the close. One is a question regarding how many people should participate in a discussion before we agree there is truly a community consensus to apply deprecation restrictions to a source. This is a broad question that probably should be asked as part of a review of the wider deprecation practice. It also probably shouldn't be answered here. The second issue is if this discussion should actually be closed as consensus to deprecate. It clearly was not by the numbers. Thus strength of argument is the only justification for closing this topic as consensus to deprecate. However, the closing discussion didn't explain why votes for answers ranging from "1 reliable" to "3 unreliable" were discounted in favor of deprecation. I have little knowledge of the source itself. My post here is based on what was presented vs how things were closed. Springee (talk) 17:31, 6 August 2023 (UTC)
•  Comment: Want to disclose that I am the poster of the RfC regarding La Patilla and voted for deprecation after FactCheck.org showed that La Patilla reposted an article with information from Breitbart. There are multiple sources that are currently seen as unreliable, deprecated or blacklisted with similar to less participation (see Discogs, Last.fm, Rateyourmusic, Examiner.com, LiveLeak, Crunchbase, FrontPage, HispanTV, MintPress, BlazeTV and others). Some of these are more obvious decisions, but nonetheless, had little participation. If we are to begin a difference in concluding WP:RSP RfCs here with La Patilla today, we need to review the accuracy of the entire WP:RSP list in total and establish a more concrete policy surrounding the closing process (one user raised this concern here). Though I am in no way opposed to such changes, it seems that the opposition to the closure has more to do with the closure process than with the decision made. Please keep in mind, per WP:DISCARD, "Consensus is not determined by counting heads or counting votes, nor is it determined by the closer's own views about what action or outcome is most appropriate. The closer is there to judge the consensus of the community, after discarding irrelevant arguments ... The closer is not expected to decide the issue, just to judge the result of the debate, and is expected to know policy sufficiently to know what arguments are to be excluded as irrelevant". David Gerard reviewed the arguments made and with their knowledge of policy (which they obviously have), made a decision. Also, I would like to ping the users from a related discussion to include their input: @Silver seren, Sideswipe9th, Banks Irk, Andrevan, David Gerard, Alaexis, BilledMammal, JayBeeEll, Blueboar, Peter Gulutzan, SandyGeorgia, Selfstudier, Burrobert, Feminist, and Teratix: Thanks!--WMrapids (talk) 21:25, 6 August 2023 (UTC)
• Endorse closure. Disclaimer: I supported deprecation. I think if you're going to argue about vague process concerns in a situation like this you need to also make a principled argument toward why La Patilla is a suitable source for Wikipedia, and that means engaging with the fact that La Patilla republishes sources like Breitbart, RT, and the Epoch Times. The La Patilla discussion was open for two months. WP:RSN is a high-traffic, neutral venue. The discussion was lengthy, more than enough for a closer to work with. Mackensen (talk) 21:35, 6 August 2023 (UTC)

  Excuse me, six weeks, I can't count. The point stands. Mackensen (talk) 21:36, 6 August 2023 (UTC)

  And for that close being based on 4 out of 12 people in the discussion? Not even a majority for the close result. It's just funny that I, as someone who would have voted Option 3 or 4, can so easily see that it was a bad close, but I guess once involved in a discussion, it's a sunk cost issue to acknowledge anything else. Silverseren^C 21:38, 6 August 2023 (UTC)

  @Silver seren ...but I guess once involved in a discussion, it's a sunk cost issue to acknowledge anything else I beg your pardon. Mackensen (talk) 21:49, 6 August 2023 (UTC)

  When involved in a discussion, whether it be an AfD or an RfC, there is a resistance to any other outcome than the one desired, even when certain results are clearly not appropriate for the consensus shown. I've had to deal with such sunk cost feelings as well in other discussions. Silverseren^C 22:24, 6 August 2023 (UTC)

  Really? Mackensen (talk) 22:46, 6 August 2023 (UTC)

  Mackensen, those sound like very good reasons to !vote 3/4 in the original discussion. However, this discussion should not be asking if the source is reliable or not. Instead it should ask if the RfC closing process was correctly followed. Springee (talk) 22:29, 6 August 2023 (UTC)

  Yes, and I addressed this in my comment. Process is important, and so is consensus. Consensus isn't a head count. A good closer will evaluate the strength of the arguments when closing and discount those that aren't well-grounded in policy, or that don't have a good grasp of the pertinent facts. This was done here. I feel confident asserting that Wikipedia shouldn't allow a source that republishes Breitbart, RT, and the Epoch Times, and that most Wikipedians, in the light of cool reason, would agree with that. What's the principled counter-argument, and why didn't anyone make it in the original discussion? Mackensen (talk) 22:39, 6 August 2023 (UTC)

  Sure, comments have to be disregarded sometimes because they aren't based in policy, but there's some limit to how much a closer should use their own intuition to make up the difference — otherwise we wouldn't bother having RfCs at all, we would just have one person say "yes" and one person say "no" and then get a closer to decide which of them had the right opinions. Consensus isn't a head count, but four people out of thirteen saying a source sucks should not be recorded as a project-wide consensus to forbid any mention of an entire website. Deprecation is an extreme measure (in fact, the most extreme of any of the options listed) that shouldn't be done on a sorta-kinda-basically basis. jp×g 23:25, 6 August 2023 (UTC)

  I agree that a good closer should look beyond the simple !vote count. However when 2/3rd of the respondents don't say 4 (or in a hypothetical case 1) then it gives the strong appearance of being a supervote. Had the close been 3 it would be easier to understand. Certainly anyone who says deprecate would agree that means it's at least generally unreliable. But when the !vote and the closing are so far out of step it no longer looks like we are following the process. This is before we even go into the issues with deprecation that jpxg mentioned below. I mean, can anyone actually say what the standard is to qualify for deprecation (cue the "double secret probation" clip) Springee (talk) 23:36, 6 August 2023 (UTC)

• Endorse closure per Mackensen. Andre🚐 21:35, 6 August 2023 (UTC)

overturn and reopen I wonder whether deprecation should be a standard option in an initial RFC, but rather only discussed in follow up threads about sources already marked as unreliable. As to concerns of quorum I think it's depends on how serious the discussion needs to be, certainly sites that are WP:UGC or have WP:COPYVIO concerns don't need large attendance RSN could overturn the underlying policies the discussion just services as a rubber-stamp. However neither of these are valid reason for overturning. What is is that I don't believe the numbers and discussion add up to a close for deprecation. I'm not an experienced closer but "generally unreliable" seems more apt. With a note that republished articles from deprecated sources stay deprecated even if republished by another source. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:40, 6 August 2023 (UTC)

I wonder whether deprecation should be a standard option in an initial RFC, but rather only discussed in follow up threads about sources already marked as unreliable This has been said before and I completely agree. Selfstudier (talk) 22:17, 6 August 2023 (UTC)

@Selfstudier: I second this. WMrapids (talk) 22:20, 6 August 2023 (UTC)

Seems like a very good idea to me. Springee (talk) 22:27, 6 August 2023 (UTC)

I'd support this as well. jp×g 23:25, 6 August 2023 (UTC)

To be clear I do believe depreciation is sometimes very necessary. But it should be used for sources knowingly publishing falsehoods, otherwise acting in a duplicitous manner, or is an ongoing waste of time. Having more involvement from editors at RSN wouldn't hurt either. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 23:39, 6 August 2023 (UTC)

I would also suggest making it clear when Deprecation is needed. Some people seem to think deprecation is needed because we really don't like what the source has to say or because the source is really unreliable. From the opening of WP:DEPRECATE, "Deprecated sources should not be considered to be either unique or uniquely unreliable." This tells me that we should never be deciding between 3 or 4. We only use 4 when some special circumstance demands it. The Daily Mail was the first case but it was also before RSP was created. Post RSP have there been any sources that were causing issues on Wikipedia and thus required someone more than just saying generally unreliable? Looking at wp:DEPRECATE it honestly isn't very clear what qualifies for deprecation. The closest I see is a talk page comment that says it's for sources that continually come up as a problem. That seems very infrequent thus very few sources should ever qualify. Springee (talk) 00:33, 7 August 2023 (UTC)

• Overturn closure The closure doesn't line up with the discussion shown and the consensus therein, even when weighing the different stances. And double the number of people have expressed opposition to the closure since than supported the outcome the closer went with in the first place. Just a bad close overall, not much else to say about it. Silverseren^C 21:42, 6 August 2023 (UTC)

• Overturn (uninvolved) I mean, really, from zero to deprecated with such limited (persons) consensus.Selfstudier (talk) 22:23, 6 August 2023 (UTC)

• Overturn (uninvolved). Deprecation isn't a policy or guideline — it's basically an emergency measure that disregards a lot of policy and should be taken only in the most outrageous cases. Everyday decisions about whether a specific reference (an article, a story, whatever) is reliable to source a specific claim should be handled by the people who are writing and discussing the article, not a bureaucratic determination of the entire source's "reliability" based on local consensus of a dozen people at some random noticeboard some time in the last decade(!). That said, even in the event that this was a legitimate way to determine and enforce the "reliability" of sources, it's not clear that this RfC is a consensus. One person says it's a bad RfC; there are four people who support options 1 or 2 ("generally reliable" or "additional considerations"), three for option 3 ("generally unreliable") and three for option 4 ("deprecate"), plus one person who said that both 3 and 4 were acceptable. It's difficult to see how this could be seen as a consensus for anything, but extremely difficult to see how this could be seen as a consensus to deprecate (a much harsher decision that disrupts the status quo significantly). Again, deprecation is basically a IAR-style "this website is so malignantly bad, and such a persistent problem, that we must overrule all normal editorial processes to purge it from Wikipedia" — not "four people out of thirteen said they thought it sucked". jp×g 22:27, 6 August 2023 (UTC)
• Endorse - per Mackensen, etal. When reading through the arguments, 3 (Generally unreliable) had pretty solid consensus and so did 4 (Deprecate), though by a much slimmer margin. (Incidentally, just for the vote-counters out there, I went through and grouped together 1 and 2, and 3 and 4, and by doing that, 3/4 seem to have the majority. And no, no one should ever close based upon numbers like that - that was purely for the vote-counters out there.) - jc37 23:15, 6 August 2023 (UTC)

  Based upon the clarifying comments by the closer, I am no longer comfortable endorsing the close. I was broadly trusting in their discretion, in light of neutrally assessing the discussion per broader policy/process/prior consensus/etc. I'm just not seeing that in their clarification. And the disinclination to even modify the unfortunate phrasing of "majority", doesn't help things either. - jc37 09:03, 7 August 2023 (UTC)

• Overturn (uninvolved) w.r.t. the RSN thread. When reading through the arguments, it looked like there was plainly not consensus to deprecate. Additionally, the closer's claim that there was a majority for deprecation is plainly false; even though consensus is not determined by a bean count, the closer's assertion that a majority of participants favored outright deprecation is plainly false. As Silver seren aptly notes above, [t]he closure doesn't line up with the discussion, even though a basic requirement of a good RfC close is that it faithfully represent the discussion's result. — Red-tailed hawk _(nest) 23:33, 6 August 2023 (UTC)

  I agree that there were some issues with word choice in the closure. And I think clarification statement from the closer could be helpful/informative. - jc37 23:40, 6 August 2023 (UTC)

  It is not merely about word choice. The only basis for the close in favor of outright deprecation rather than characterizing it as GUNREL presented was that alleged majority vote, but no such majority exists when looking at the discussion broadly. There is no mere clarification that resolves that there was plainly not consensus to deprecate in that discussion; the only solutions for when the result is plainly wrong are either to (1) have the closer vacate the close or (2) have the current close overturned by the community. — Red-tailed hawk _(nest) 23:51, 6 August 2023 (UTC)

  And from your perspective, I can see that. I think where you and I seem to generally disagree is to how slim the margin was for deprecation (or rather, whether there was a margin at all : ) - and I'll admit I'm leaning more than a bit on "closer discretion" here, which is why I think a clarification of some type by the closer could possibly be helpful/informative - jc37 00:17, 7 August 2023 (UTC)

• Overturn, close relies on the blatantly false claim of a majority for deprecation. (commented on RSN talk but not RfC) – Teratix ₵ 00:02, 7 August 2023 (UTC)
• Overturn, there was no majority (1.5 !votes out of 10 for deprecation). If the !votes for deprecation somehow had better arguments, this should have been stated explicitly. I haven't participated in the RfC and have no opinion regarding the reliability of the source itself. Alaexis_¿question?
• Comment from closer: it was a close one, heavily argued for several weeks in multiple venues. I assessed it as between "generally unreliable" and "deprecated", leaning toward deprecation - it certainly wasn't, say, between "GU" and "considerations apply" - it was clearly considered a very bad source, and the only question is the precise class to put it into. The outlet's blithe use of sources given to fabrication (for which those sources had already themselves been deprecated) seemed to swing it more in the discussion to deprecation in its own right than merely "GU". But the outcome could reasonably have been either GU or DEP, sure. I wouldn't put it higher than "generally unreliable", though. I've also noted this discussion at WP:RSN - David Gerard (talk) 07:52, 7 August 2023 (UTC)

  Thank you for clarifying. Would you consider adjusting your close? The "majority" sentence in particular seems at issue. But also, while I do support closer discretion, perhaps, based upon what you have said, and in light of the above, you might re-look at the discussion? - jc37 08:05, 7 August 2023 (UTC)

  I think "deprecate" is a valid outcome for the discussion as was. This current discussion has been open for only a few hours, so changing it would be a bit premature, wouldn't you think? Particularly given the opener's failure to publicise it fully - David Gerard (talk) 08:11, 7 August 2023 (UTC)

  To clarify, are you maintaining there was a majority for deprecation? – Teratix ₵ 17:01, 7 August 2023 (UTC) (@David Gerard: in case you missed this) 21:12, 9 August 2023 (UTC)

• Comment: there appears to be a drive to leverage this discussion into removing the concept of deprecating sources. We had an RFC on source quality RFCs in 2019 Wikipedia:Reliable_sources/Noticeboard/Archive_275#RFC:_Moratorium_on_"general_reliability"_RFCs that kept them. If you want to remove the concept of deprecation, then a broad general RFC in the proper venue, e.g. WP:RSN, would likely be the way to swing that - David Gerard (talk) 08:46, 7 August 2023 (UTC)
• Overturn (uninvolved). It's as simple as, as has been noted above, deprecation is ou strongest possible response to a source and is site wide. As such the decision to do so must be equally strong and equally site wide. This close represented neither. SN54129 09:36, 7 August 2023 (UTC)
• Overturn and reclose (uninvolved). I don't believe the number of users and forum were particularly flawed. I am however backing a reclose because I don't see option 4/depreciate as in any way having a consensus for it. An option 3 (generally unreliable) might, as could a very strict option 2 (unlikely but possible). When having the reliability scale of options (vs a change/no-change option) discussion, it's generally reasonable to assuming that anyone backing option 4 would back option 3 if the alternative was anything less. So a consensus could be garnered that way, but the current close I don't think can do so. Nosebagbear (talk) 09:58, 7 August 2023 (UTC)
• Overturn (uninvolved), per good arguments by jpxg, nableezy, Silverseren, and others. And support ActivelyDisinterested's suggestion on deprecation not being the first step.

Side note: I'm increasingly seeing RfCs at WP:RSN for sources that aren't widely used, and have never (or only once) been discussed at RSN before. It's problematic when the source is obscure or foreign, because it can be hard to evaluate a source you're not familiar with; people might focus on whichever aspects the OP chose to highlight (whether cherry-picked or not). RfCs should be mostly a last resort, because they have this "aura" of seeming binding and settled, yet their scrutiny may be no better than if the source had been repeatedly brought up over the years in non-RfC WP:RSN discussions, each time involving different editors who discussed different aspects. A source that quotes Breitbart may be more clear-cut (and isn't an ideal example of what I'm describing), but I think the overall trend needs addressing. DFlhb (talk) 11:00, 7 August 2023 (UTC)

I'm regularly at RSN, and the vast majority of threads end in simple advice. Unfortunately misuse of the board, as with other boards, does happen. Greater attendance would certainly help. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:20, 7 August 2023 (UTC)

Worth noting that in this particular case, the RSN La Patilla discussion wasn't out of nowhere - it was a followup from a contentious discussion on Talk:La Patilla, on the issue of how to deal with a news source that was enormously popular but also reran material from Breitbart and the Epoch Times. That is, there was a genuine dispute that was squarely in RSN's remit - David Gerard (talk) 12:51, 7 August 2023 (UTC)

• Overturn closure, and encourage the original poster to follow up on advice given them at ANI before launching other RFCs. As described at ANI by ActivelyDisinterested, the way the OP has gone about creating these RFCs has assured limited participation; that, and the WP:BLUDGEONing made me at least (knowledgeable about Venezuela since I worked throughout Latin America and the Caribbean during the 1980s and 1990s) unwilling to even weigh in to the mess.
  One thing that really sticks out, given the censorship and absence of free media in Venezuela, is that WMrapids has so far not accounted at all for WP:EXPERTSPS in their campaign to eliminate Venezuelan sources. As essentially all independent media has been shut down in Venezuela (see samples sources at the ANI), a thorough analysis of how a source can be used on Wikipedia will involve looking at how often other experts cite these sources, for example in scholarly sources and highly reliable newspapers. I haven't had time to look at La Patilla, but this, for example, is the case in spades with Nelson Bocaranda and Runrunes--another source that WMrapids has targeted. (Disclaimer: I created Nelson Bocaranda when his name came up in a 2008 Featured article candidate; [1] it's somewhat impossible to have worked in Latin America during the 1980s and not know who he is.) It is equally likely to be true of Alberto Federico Ravell of La Patilla, and I don't believe this has been looked at, but some use of the source as EXPERTSPS is likely to be possible.
  I strongly encourage WMrapids to work with other Venezuela-knowledgeable editors before throwing up RFCs (the best RFCs as those that are not launched until they have ample feedback from all "sides" to avoid garbage in-garbage out, which is what we have now on the RFCs), are those editors will be more likely to be able to point WMrapids to SPSEXPERT usage and history and sources and issues they appear so far to be unaware of. They seem to have embarked upon this campaign because of issues in Peruvian articles, and Venezuela is not Peru. In a country where the absence of press freedom is on par with that of Russia, most Middle Eastern countries, Yemen, and at the bottom of the list with the likes of China and North Korea, a solid analysis of sources per WP:EXPERTSPS needs to be undertaken before establishing reliability, much less deprecation. Doing this correctly will take a lot of work, as sources are so hard to find (most formerly reliable Venezuelan news archives have been taken over by the government and scrubbed as journalists are forced into exile, and most Wikipedia articles in the entire suite have been systematically biased by a few other editors hard at work in the entire suite inserting Maduro POV.) SandyGeorgia (Talk) 17:27, 7 August 2023 (UTC)

  I failed to indicate my level of involvement. I had no historic engagement with WP:VENRS, and I did not participate on the RFC for La Patilla beyond stating on Talk:La Patilla that the RFC there was malformed. I was once actively engaged in editing Venezuelan topics, but disengaged years ago because keeping up with the rampant tendentious editing throughout makes it a timesink. It was widely known in Venezuela that Chavez had paid editors, although reliably-sourced proof of this has not yet emerged to my knowledge. SandyGeorgia (Talk) 15:59, 9 August 2023 (UTC)

• Overturn and reclose; there is clearly not consensus to deprecate the source: but there is also enough substance in that discussion to create an RSP entry, and to mark it level 2 at the very least (I have not evaluated all the posted links, which I would do if I were closing this). Reposting content from Breitbart and IBTimes is most certainly a red flag, and cannot be dismissed outright. Vanamonde (Talk) 17:22, 7 August 2023 (UTC)

  I agree that Level 2 is likely to turn out to be reasonable in this case, but I'd want to undertake the EXPERTSPS review I mention above before entering a declaration, and that takes time I don't have. SandyGeorgia (Talk) 17:31, 7 August 2023 (UTC)

  I have no objections to anybody conducting an EXPERTSPS review, but I want to be clear that I'm not supporting a level 2, I'm saying that's the best possible outcome for the source: no website that reposts content we have deprecated could ever be considered uniformly reliable, and indeed the default assumption should be of a lack of reliability. Vanamonde (Talk) 17:36, 7 August 2023 (UTC)

  Same, for clarification: I'm not intending my post to support either 2 or 3, as I haven't done the work, but it's not 1 or 4. SandyGeorgia (Talk) 17:52, 7 August 2023 (UTC)

• Overturn (involved) This might be implicit being the one that started the thread, but I wanted to explain further at any rate. Besides there not being a consensus for deprecation, as stated in this discussion, the fact that La Patilla generally publishes "questionable, fringe and propaganda content" (as stated in the closing statement) was hotly debated in the discussion, and the assertion that the outlet tended to be used as an "negative example" per WP:USEBYOTHERS (also stated in the closing statement) needs explanation as well, since this is not reflected in the discussion. --NoonIcarus (talk) 21:39, 7 August 2023 (UTC)
• Overturn (uninvolved). The RFC was malformed from the start, and the characterization of 3, or possibly 4, comments out of a dozen as a "majority" is obviously wrong on its face. There was clearly no consensus to deprecate the source. Banks Irk (talk) 02:01, 8 August 2023 (UTC)
• Overturn and reopen (involved) After reviewing the concerns addressed above, I am encouraged by the large amount of feedback and agree that the "majority" calling for deprecation was an inaccurate description. Reviewing the closer's history and experience, I initially had faith in their decision, but users make mistakes sometimes (trust me, look at my recent edit history), so that is why there should be a more community-centered process for deciding deprecation instead of having a single user decide. Seeing that this RfC has sparked more involvement, I believe its closing should be overturned and that the RfC should be reopened in order to achieve a more broad consensus. Even though the closing decision agreed with my position, my goal was not to deprecate La Patilla but to determine a consensus on its reliability, which can now be established with further participation if this discussion is reopened.--WMrapids (talk) 06:23, 8 August 2023 (UTC)
• Thanks WMrapids for the ping. I share the concerns expressed by Nableezy and others about the idea that four people could possibly represent a WP-wide consensus to deprecate a source; by Teratix and others about the use of "majority" in the close; by ActivelyDisinterested about including deprecation in a very first RfC on a source; and by DFlhb about the frequency at RSN of RfCs on the broad use of sources instead of discussion about particular instances of sources being used to support particular claims in particular articles. It's obvious that the closure should be overturned (and frankly disappointing that David Gerard hasn't already withdrawn it). --JBL (talk) 17:22, 8 August 2023 (UTC)
• Overturn (uninvolved so far, but read the previous discussions). My understanding is 4/12 participants opted for depreciate, and the close says "the majority agreed to depreciate". A Majority would 7/12, so right there - I feel the close is a problem because it's not accurate, I don't see a clear consensus other then "it's not a 1". Someone made a good point in one of the follow up discussions, that while the source had reposted content from blocked sources, it was translations of the better content of those sources, not translations of the worst content that got them blocked, and they'd even posted a retraction of one article found to be a problem later on. It does make sense to put a note that some of their content is translation of blocked sources, and those translations should not be used as a way to "get around" their block. But the examples I saw were clearly labeled with the source, so those articles would be obvious. Denaar (talk) 14:36, 9 August 2023 (UTC)

Reclose as "no consensus". There is nothing stopping one finding a better source if one exists for a statement. Also we don't use solely one source to verify a controversial statement as far as I am aware, if that were the case, then everyone could say that this is true because the president's mom said so. Aasim - Herrscher of Wikis ❄️ 00:11, 10 August 2023 (UTC)

• Snow overturn. This close has no chance of surviving community review, and further delay is purposeless.—S Marshall T/C 07:25, 10 August 2023 (UTC)
• Reopen I would have closed that as "generally unreliable" because there is clearly consensus for that, even if there is not for deprecation. But we certainly need to close it as something, and there is no consensus for options 1 and 2. More eyes would be welcome. Black Kite (talk) 07:43, 10 August 2023 (UTC)
• Overturn and reopen (uninvolved). As Black Kite noted above, a "no consensus" close also seems inappropriate (and essentially kicks the can down the road when editors clearly have some serious concerns about the source; only one editor argued for treating it as generally reliable). Dylnuge ^{(Talk • Edits)} 19:24, 10 August 2023 (UTC)

User:Qwerfjkl and non-admin closures of categories

A week and a half ago, I nominated Category:United States presidents and death for renaming to Category:Deaths and funerals of United States presidents. Earlier today, I moseyed on over to CfD to see what happened. I noticed that User:Qwerfjkl had non-admin closed the CfD as rename…but they hadn’t actually made the move, nor had they even removed the CfD template from the article. And then I noticed that this wasn’t the only CfD like this. As I see it, one or more things need to happen here:

1. Admins need to clean up some of these CfDs, completing the moves that User:Qwerfjkl has closed
2. Qwerfjkl needs to stop closing CfD discussions like that

pbp 18:52, 7 August 2023 (UTC)

After closing the discussion, Qwerfjkl listed it at Wikipedia talk:Categories for discussion/Working in this edit, in accordance with the instructions for closers, so it is already flagged for admin action. DanCherek (talk) 19:23, 7 August 2023 (UTC)

Yes, this is the standard process. It's a shame that only one person is processing that queue right now, and thus a large backlog has built up. When the crats finally implement my RfA I will definitely help clear that queue, and of course any other admins watching this are welcome to join us, but Wikipedia:Administrators' noticeboard/Archive354#WT:CFDW backlog was archived without reply. * Pppery * _{it has begun...} 03:02, 8 August 2023 (UTC)

I have now cleared the backlog of CfDs needing admin action. * Pppery * _{it has begun...} 00:17, 9 August 2023 (UTC)

Awesome. Thanks for doing that. Way to put your new tools to good use :) –Novem Linguae (talk) 12:11, 11 August 2023 (UTC)

Additions to the Bad image list

The following images were used to vandalize several pages:

Image list

01 pregnant woman.jpg Orgasm denial.jpg Smooth at the beach.jpg Stydká rýha.jpg Nude woman urinating(31318958701).jpg Chibi, 26.jpg Napletek 1.jpg Penehafada.JPG Round head.jpg Meni.jpg After male.jpg Ano masculino.JPG Bilder 2011 133.jpg Thumbnail X-20.jpg 400 Bad Request HTTP (14391721952).jpg Two Young Men by Anonymous.jpg Newborn clamp.jpg Poa Phan.JPG In need of attention.png Innie labia.jpg Klitorisvorhautpiercing horizontal.jpg Klitorisvorhautpiercing vertikal.jpg Klitoriswurzel, Klitoriseichel, Klitorisschenkel.png Labia Majora.JPG Labia Minora 123.jpg Labiamin.jpg Labios menores prominentes.jpg Labia minora.jpg Labia becoming engorged with blood as female reaches arousal.jpg Labia majora and minora.jpg Michaela.JPG Flag of Germany (1935–1945).svg

--Leonidlednev (T, C, L) 22:18, 8 August 2023 (UTC)

• Comment This is already up at MediaWiki talk: Bad image list#Multiple files. Nate • (chatter) 02:28, 9 August 2023 (UTC)

  That wasn't responded to in a while, so I posted that request here. --Leonidlednev (T, C, L) 09:07, 10 August 2023 (UTC)

User:Mrffcknt

• Mrffcknt (talk · contribs · deleted contribs · logs · filter log · block user · block log)

Perhaps an admin could take a look at Mrffcknt because it seems like there's some WP:NOTHERE going on that's being presented as "good faith" answers to various Teahouse and HD questions. It's either intentional NOTHERE behavior or newbie WP:CIR behavior. Could this be a LTA account? For reference, I didn't notify the user because it it is LTA or intentional NOTHERE, then it's unlikely anything positive will come from their participation here. -- Marchjuly (talk) 04:46, 9 August 2023 (UTC)

I'd say their first 4 edits look like they are intentionally giving Teahouse users bad advice in order to deceive them into doing something chaotic. This includes giving instructions on how to violate copyright and instructions on how to canvass. Their last 2 edits are a bit more ambiguous. I would support a WP:NOTHERE block, but wouldn't mind another opinion before I hit the button. –Novem Linguae (talk) 04:58, 9 August 2023 (UTC)

@Novem Linguae: They seem to have stopped for now so a block at this point is probably not warranted. FWIW, another user notified them of this discussion, and different user added a user warning to their user talk page. So, they at least now have been warned and perhaps won't be repeating the same behavior. -- Marchjuly (talk) 05:33, 9 August 2023 (UTC)

This is one of our frequent flyers. Indeffed, though I don't have time for a proper sleeper check right now so another CU might want to take a look. --Blablubbs (talk) 11:30, 9 August 2023 (UTC)

Even if it weren't a sock, I would also view anyone who was willfully giving bad advice to users at the Teahouse as much, much, worse than anyone who just executed their poor judgement. Teahouse abuse causes more issues, and the high likelihood of losing every user they burn. It is our spiritual equivalent to bullying children. Nosebagbear (talk) 16:41, 9 August 2023 (UTC)

There's also the username... --Blablubbs (talk) 17:08, 9 August 2023 (UTC)

Indeed. I'm sure there are some implied "u"s in there. --Jayron32 21:48, 10 August 2023 (UTC)

Global ban for Бучач-Львів

Per the Global bans policy, I’m informing the project of this request for comment: RfC/Global ban for Бучач-Львів. --Jphwra (talk) 17:04, 9 August 2023 (UTC)

Draft:Lil tay

Looking for an administrator to take a look at Draft:Lil tay and see what can be done surrounding the concern I added to the talk page:

• It seems that the draft for the correct capitalization, Draft:Lil Tay has been indefinitely set to requiring administrator privileges to create. Due to the recent news, should this be lifted to allow for this page to be moved to its correct capitalization? Is this page allowed to be created at all, or is it considered a bypass of the administrator lock? Hopefully an administrator can look into this ASAP and see what can be done from here.

B3251 (talk) 20:48, 9 August 2023 (UTC)

I've moved the draft to the correct capitalization, and reduced the creation protection on Lil Tay to extended-confirmed instead of sysop. — Ingenuity (talk • contribs) 20:51, 9 August 2023 (UTC)

Thanks. B3251 (talk) 20:52, 9 August 2023 (UTC)

A new source says the story is unconfirmed, so we need to take very good care on this and wait for a proper authority to confirm details; right now the history reads like a BLP minefield (and the subject's age is also in dispute between each source). Nate • (chatter) 23:33, 9 August 2023 (UTC)

Additionally Twitter is definitely not a source, but are some posts saying the statement 'confirming' the story and the death statement was sourced through an AI tool. We may need to move to RFP with this. Nate • (chatter) 23:52, 9 August 2023 (UTC)

@Andrevan:

User is making changes to Aileen Cannon's page that have not been agreed to by Consensus. Warned him numeous times to wait till consensus. 2600:8805:C980:9400:651E:9482:536D:FE66 (talk) 21:40, 9 August 2023 (UTC)

• The article has been extended-protected by Courcelles, and I've blocked the /64 range of the IP, which has been blocked many times in the past, for six months (same duration as the block in 2022).--Bbb23 (talk) 21:54, 9 August 2023 (UTC)

  Thanks. Andre🚐 01:00, 10 August 2023 (UTC)

JC Chasez

Last month, I removed a lengthy discography section on the page for JC Chasez as he already has a separate page for his discography. I also made edits to incorrect information in the Career section, while providing references. Since then, a user has continually attempted to add the discography back to the main article, despite multiple reverts from other editors (examples [2] and [3]). This user claims "vandalism" in their edit summaries as reasoning for re-adding the discography. The user also removed the references I added without explanation; I restored my edits and had to again remove the discography, which appeared to have been added by a sock puppet ([4]). Spectrallights (talk) 10:37, 10 August 2023 (UTC)

Since the issue is with an IP-hopping editor page protection is probably more appropriate, but since I was there I did it. Primefac (talk) 11:10, 10 August 2023 (UTC)

Thanks. Spectrallights (talk) 11:34, 10 August 2023 (UTC)

Possible user impersonation

The following discussion is closed. Please do not modify it. No further edits should be made to this discussion.

---

corcelles (talk · contribs · deleted contribs · logs · filter log · block user · block log)

I suspect that user is not genuinely operated by the real courcelles.102.157.219.237 (talk) 14:00, 10 August 2023 (UTC)

You would be correct. My thanks. Courcelles (talk) 14:02, 10 August 2023 (UTC)

You're welcome. Say, don't mind creating that user page with a block notification banner?102.157.219.237 (talk) 14:20, 10 August 2023 (UTC)

IMO a talk page is sufficient. Ymblanter (talk) 14:21, 10 August 2023 (UTC)

I do want to point out that y'all blocked an account that hasn't edited in over 11 years. I mean, yea, fine, but I highly doubt it was necessary. Whoever created that account and made a single edit with it back in 2012 isn't coming back. --Jayron32 17:58, 10 August 2023 (UTC)

Unlikely to be intended as impersonation anyway. Their sole edit seems to have been to create an article on Cermex, a company based in Corcelles-lès-Cîteaux, France. AndyTheGrump (talk) 18:36, 10 August 2023 (UTC)

This most likely isn't intentional impersonation, but I still think they should've been blocked for being too similar to a well-established admin. J.J was blocked for being too similar to J.J. (a now-vanished former admin). CLYDE ^{TALK TO ME}/_{STUFF DONE} (I will not see your reply if you don't mention me) 20:53, 10 August 2023 (UTC)

There have to be better ways to deal with unintentional 'impersonation' than a block notice that implies bad faith. AndyTheGrump (talk) 21:10, 10 August 2023 (UTC)

It. Was. Eleven. Years. Ago. Like, what's done is done, but why are we blocking 11-year-old unused account so quickly. Like, don't undo it, but what disruption was it causing that needed to be stopped? --Jayron32 21:32, 10 August 2023 (UTC)

Or do undo it. No evidence of impersonation, evidence points to the contrary, blocking was an error. Fix the error. —Alalch E. 21:52, 10 August 2023 (UTC)

See, that's the difference between {{uw-uhblock-double}} and {{uw-ublock-double}}. —Cryptic 23:45, 10 August 2023 (UTC)

Seems like downgrading from a hardblock to a regular block would be reasonable here. –Novem Linguae (talk) 12:09, 11 August 2023 (UTC)

My first choice for no apparent deliberate impersonation would probably be a message, but given they're likely inactive, let's go for a softblock. Nosebagbear (talk) 16:37, 11 August 2023 (UTC)

As it's very stale I wouldn't have done anything, personally. Secretlondon (talk) 16:53, 11 August 2023 (UTC)

There's no point unblocking a 11 year old unused account now but imho they should never have been blocked in the first place. Like what was being achieved by blocking them ? ... Probably the most nonsensical block I've ever seen here. –Davey2010^Talk 18:07, 11 August 2023 (UTC)

Is courcelles itself even seeing this, by the way? I just noticed that user, without the letter "U", made more contributions in wikimedia Commons. Here is the proof.197.0.93.65 (talk) 23:00, 11 August 2023 (UTC)

They are the one that did the block and participated in this thread. CLYDE ^{TALK TO ME}/_{STUFF DONE} (I will not see your reply if you don't mention me) 23:04, 11 August 2023 (UTC)

Not only that, once the notification was posted the user immediately rushed to the "Hard block" button and slapped the block notice on the talk page, all within a minute, but without thinking twice.197.0.93.65 (talk) 23:14, 11 August 2023 (UTC)

Changed to a softblock. I’m not sure I misread or just didn’t process the year. Courcelles (talk) 00:53, 12 August 2023 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Report on User:Thewolfchild

Am having an issue with Thewolfchild who may be heading back to old habits -he inserted some misleading names, which I restored as they're linked to the proper article title(s). I've been accused false actions (not collaborating)- I asked & suggested this and received this response - I've been referred to as being Dick. Even this source has the names spelled out. We've been back & fourth with no end in sight. And still with no consensus, reached on the talk page, he does a "clean up"...basically a total revert. Would appreciate any help - Thank you FOX 52 ^talk! 06:48, 11 August 2023 (UTC)

FYI – notified TheWolfChild. Tails Wx (they/them) 06:52, 11 August 2023 (UTC)

Thanks - FOX 52 ^talk! 06:59, 11 August 2023 (UTC)

To be fair, right before they called you a dick, you were pretty snarky with them. When they asked you to elaborate on your rationale for formatting the names the way you wanted to, your curt reply of "It's called reading" is not exactly civil. Calling you out by citing WP:DICK was a pretty mild response to your own rudeness. I don't know enough about the subject matter at hand to weigh in on the content dispute at hand (and ANI is not the place to have that discussion), but there's quite enough shit-slinging going around on both sides that neither of you comes off as particularly clean. WP:BOOMERANG and all that. I think the entire discussion could benefit from a turning down of the temperature altogether, and some dispute resolution may help break the deadlock over the issue. That's my advice; both of y'all need to bring some outside voices into the discussion and both of y'all need to back away for a while and let cooler heads contribute some new perspective on the discussion. --Jayron32 16:53, 11 August 2023 (UTC)

Yes I agree, I don't normally activate an ANI, but given then editor past behavior, I felt it should be noted. And in time am sure it'll get resolved - cheers FOX 52 ^talk! 17:42, 11 August 2023 (UTC)

Review of my unblock of Panda619

I wish to start out by saying that I absolutely agree that the behavior this user caused (like here) is absolutely unacceptable in any capacity or any way. The user came onto IRC to request an unblock per Wikipedia's standard offer. I accepted, if anything, because of WP:ROPE. If the user decides to go amok and cause havoc, the block button is simply a few clicks away. We're taught here to use sound and good judgement (of course), but that can extend anywhere. Please understand this: If I'm found to be wrong for what I did, then I'm wrong; I absolutely 100% apologize for the decision I made, and I will understand, take any and all feedback with positivity, and learn from this in order improve my imperfections.

I'm sure that everyone here knows that I'm not here to hurt anyone, and I respect every (legitimate) editor here. I want to drive the spirit of Wikipedia to fulfill our mission to the best and fullest extent - That's all. This unblock generated this discussion, which I absolutely agreed to present what I did to this noticeboard. I've re-blocked this user pending discussion. My thought is this: If someone comes back a year later to apologize and explain (off-wiki evidence that I'm happy to provide), I think that's fine. I don't understand what the alarming issue is here. This isn't a "911", which are things both we and I resolve and take care of regularly. I just want a review and a discussion, even if it means that I am found to be wrong and at fault. Discussions are a critical part of Wikipedia, and I will never stand in the way of that.

Anyone is welcome to chime in, respond, and give their honest thoughts here - even if it disagrees 100% with what I did. Thank you to everyone in advance for their responses. :-) ~Oshwah~^{(talk) (contribs)} 20:08, 12 August 2023 (UTC)

• Oppose unblock Looking at the IRC discussion, Panda619 still doesn't really understand why they were blocked. They say

she died, I was happy, I am Indian, who reads lot of history and politics, I assume you know about British empire's atrocities, so at spur of moment I did that as a joke, it was there for a second I think, then one editor gave me vandalism warning and then lot admins came in and was talking how severe it was and such, and got blocked instantly, I tried appealing, they were still like, nope

... but doesn't appear to mention that if it was a spur of the moment thing, that doesn't explain why in their later unblock appeal they referred to Queen Elizabeth as a "genocidal hag" and a "pedo defender" ([5], admin only). Let's not forget the original vandalism was replacing QE2's article with a meme image and "RIP BOZO" in article space whilst the article was the most viewed article on Wikipedia. Despite being a Brit I'm no great fan of the royal family myself - to put it mildly - but a half-arsed "yeah won't do it again honest" doesn't really cut it for me. Black Kite (talk) 20:19, 12 August 2023 (UTC)

• Noting that I raised this with Oshwah initially, and talked it over with him and a few others on Discord subsequently: Keep unblocked, without prejudice against proper community unblock request. The net result of the unblock/reblock is a restoration of talkpage access, which is fine. Panda's comments on IRC aren't really formatted in the manner of a community unblock request, nor were they intended for this audience, even if it's understood channel logs can be shared. So I think it's unfair to them to do a full unblock review without an actual community-oriented request from them. Let's close this sooner rather than later, and if they want to write up a paragraph or several for the community's consideration, they can. -- Tamzin^{[cetacean needed]} (she|they|xe) 20:28, 12 August 2023 (UTC)