The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was keep. Jay 💬 10:19, 27 March 2024 (UTC) reply

• Two Areas → Sudanese conflict in South Kordofan and Blue Nile  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

This redirect could apply to too many topics to be valuable. Significa liberdade (she/her) ( talk) 19:04, 12 March 2024 (UTC) reply

• Delete per nom as way too ambiguous to be useful. Four of the first ten hits on my google search were related to anti-wrinkle injections (which I really did not expect!) but that's not enough for primary topic and nothing else got more than one hit. Thryduulf ( talk) 21:59, 12 March 2024 (UTC) reply
• Keep: I'm not super invested in this, but it's a widely-used term for the topic that I had redirected it to. I don't see how it hurts to keep the redirect, whereas deleting it makes the topic almost impossible to find by that (common) name for it. Wikipedia has lots of articles with titles which can refer to other things, particularly in cases such as anti-wrinkle injection lingo, where the topic isn't necessarily fit for a Wikipedia article. If there are multiple possible relevant topics it could refer to, shouldn't that mean it needs a disambiguation page, rather than being deleted? GeoEvan ( talk) 22:58, 12 March 2024 (UTC) reply

  Can you share any reliable sources that use this term? Significa liberdade (she/her) ( talk) 02:14, 15 March 2024 (UTC) reply

No problem: [1] [2] [3] [4] [5] [6] [7] GeoEvan ( talk) 22:16, 16 March 2024 (UTC) reply

• Delete per Thryduulf, very generic -- 65.92.247.66 ( talk) 05:11, 13 March 2024 (UTC) reply
• Keep per GeoEvan, and possibly disambiguate (at Two areas, per WP:DIFFCAPS) if someone can identify a good set of targets. -- Paul_012 ( talk) 00:30, 17 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, CycloneYoris ^talk! 21:22, 19 March 2024 (UTC) reply

• Keep per GeoEvan due to the lack of any notable examples of other areas being referred to in this manner. - Presidentman talk · contribs ( Talkback) 13:58, 20 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was keep. Withdrawn by nominator. (non-admin closure) CycloneYoris ^talk! 01:18, 27 March 2024 (UTC) reply

• Vanderwaltia → Hanseniaspora  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Hanseniaspora is not a current synonym for this genus. A redlink would be more helpful to recognize the need to create an article here or at the species level. This genus currently contains one species, Vanderwaltia alma-atensis which would be an appropriate redirect for this genus once that article has been created. Source: Catalog of Life at [8]. RecycledPixels ( talk) 19:48, 19 March 2024 (UTC) reply

The type species of Vanderwaltia was Vanderwaltia vineae, which has since been transferred to Hanseniaspora, thus, it should remain a redirect. Vanderwaltia alma-atensis is an orphaned species that has not yet been studied molecularly and not placed into a different genus. I don't think CoL has a policy for orphaned species, so it's unclear (to me at least) what should happen if someone makes the article for Vanderwaltia alma-atensis. Also, according to Species Fungorum ( link), Vanderwaltia is a generic synonym of Hanseniaspora. Esculenta ( talk) 20:16, 19 March 2024 (UTC) reply

I'll defer to the obviously more-qualified opinion and withdraw this nomination. Thank you for the feedback. RecycledPixels ( talk) 20:23, 19 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was Delete * Pppery * _{it has begun...} 17:09, 31 March 2024 (UTC) reply

• Wikipedia:Wikipedia Signpost/Archives/Years → Wikipedia:Wikipedia Signpost/Archives  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

I deleted this page as a G6, and it was requested that I instead formally nominate it for RfD.

There does not need to be a redirect here. I manually retargeted every incoming link when I retitled this page last October. There is no way for someone to access this internal Signpost page from Wikipedia. There are no inbound links from other websites that I know of. There is nobody trying to access this page. The existence of this redirect provides no benefit and creates additional burden for maintenance of the Signpost, as it is yet another one-off exception that has to be written into every script and template that uses this directory, every external tool that works off a list of pages, et cetera, et cetera. Every additional piece of special-case whoopsie-doozie only-used-for-one-page-ever code increases the maintenance burden for myself, as well as every future maintainer of the Signpost codebase -- there have to be extra lines of code to deal with this single anomalous redirect, and everybody who deals with the code (to modify it, to replace it, to add a feature or to remove an existing one) must spend time going over these additional lines.

The page title got about 16 views total in the months of November and December; a good number of those were probably from me as I was delinking it from other pages. The rest could have come from anywhere; people click on entries in the deletion log, web scrapers give normal browser user agents, et cetera.

The structure of the /Archives/ directory is very simple: Wikipedia:Wikipedia Signpost/Archives/ contains yearly archive pages. It does not contain anything else. The index page for these yearly archive pages is located at Wikipedia:Wikipedia Signpost/Archives. There is no need to have a separate /Years subpage. That's why we don't have one -- it's just at the base URL. Anyone who, for some reason (let's say someday a person clicks a link to this archive page from some external website) gets a 404 from a sub-URL can just follow the URL structure one level up and get to the place they want to be.

For further reference, there have been hundreds and hundreds of useless Signpost pages subjected to speedy deletion in the last year as I've been cleaning up the space, and consensus (whenever a discussion was required) has always been in favor of doing this. Last year someone demanded that I take these pages through formal processes, to prove with complete thoroughness that the community accepted them being deleted. The main outcome of this was that all these maintenance processes and cleanup were brought to a halt for about a month while these noms percolated through XfD, and all of them were approved, and it just consumed a lot of time (mine but also that of all the XfD participants, closers, etc). Here is a list of all of those formal nominations:

• Keep as an {{ R from move}}, for the reasons stated by myself at the deletion review. Prior to being moved to Wikipedia:Wikipedia Signpost/Archives in October 2023, the archives page had been at this title since 2007. Per WP:R#K4, redirects as a result of pagemoves should not normally be deleted without good reason due to the risks of breaking incoming links; and [l]inks that have existed for a significant length of time...should be left alone in case there are any existing links on external pages pointing to them. Given that the page was at this title for over 17 years, and given the >100,000 pageviews the archive page received while at this title, it seems very plausible that offwiki links have been made to the previous archives page of a notable newspaper, which will be broken if this redirect is deleted. With respect to JPxG, there's no way of knowing how many external links have been made to a page, so the statement that there are none from other websites that [they] know of doesn't sway me towards deletion.
  I'm unfamiliar with the Signpost's scripts/templates/external tools and why this page would need to be filtered from them, but I don't think we should be deleting pages on the basis that they will break scripts - we should be building tools around the wiki, not the wiki around the tools. Especially in this case, I don't believe that that is a sufficient reason on its own to delete a redirect when such a deletion might cause harm (in this case, as a result of dead external links). Regarding the previous nominations, I believe that this page is substantially different to the previously nominated redirects, for the reasons I explained in a DRV comment in response to the list. All the best, ‍—‍ a smart kitten_{[ meow} 15:43, 11 February 2024 (UTC) reply

Forgive me for a moment of bluntness, but I don't expect you to be familiar with the Signpost's scripts, templates, and tools. Nobody is: furthermore, nearly everyone who tries to maintain them eventually becomes burnt out and stops. It's great to think "we should be building tools" in a particular way; if you would like to take a few months refactoring the Signpost's dozens of templates and scripts to reflect this philosophy, I'd love to bring you up to speed at Wikipedia talk:Wikipedia Signpost/Technical. But I do not expect that. What I would appreciate is that, if the person who maintains a codebase repeatedly says "doing this thing will cause a hassle and require additional spaghetti code to handle the stupid one-off edge case", you did not respond with "well I didn't look at any of the code but I bet it wouldn't".

You have not articulated any reasonable way in which this "might cause harm". I have shown the pageviews: immediately after the page was retitled, they dropped to nothing. What is the hypothetical situation in which this causes harm? If somebody clicks a link to the archive page at the old location (virtually nobody has done this, but they might, hypothetically)... they get a "Wikipedia does not have a project page with this exact name" message, and then directly below the page's header, there's a prominently-placed blue link back to the correct location. The page's URL is also obviously formatted in a way that lets you go one level up. But even the situation with somebody sitting there is unlikely. In reality, those pageviews are almost certainly background noise from web scrapers and clicks on the deletion log, and pages (if there were any) which referenced them from an external site either didn't exist or were updated very quickly. The major problem facing the Signpost is not that we're losing a couple pageviews per month to someone who clicks a link to a relocated page and can't figure out how to click up to the main Signpost page and find the archives link from there: it's that we're losing thousands of pageviews per month due to lacking features other newspapers have, having things render incorrectly, et cetera. I have been spending a lot of time on coding stuff, and I haven't written an article myself in ages.

The biggest actual issue the Signpost faces is that everything is built on twenty years of quick fixes and workarounds and weird one-off edge cases. Implementing a new feature (i.e. having bylines on the front page, having images on the front page, retrieving the lost subheadings for ten years of articles) pretty much always requires me to climb over a pile of "one little edge case"s. I realize that for you, "one little edge case" from a random redirect in a directory it doesn't belong in may not seem like a big deal, but they add up quickly for me, especially when there are thousands of Signpost pages to keep track of across multiple namespaces.

I don't think that " Russell's teapot might have a Signpost URL written on the bottom" justifies a blanket prohibition on relocating or renaming Signpost pages unless a full copy of the 2007 directory structure (or the 2013 directory structure, or for that matter the 2022 directory structure) is preserved with redirects on top of the new locations in the same place and in the same namespace. I really don't think it's reasonable to have an open-source software project -- note that the Signpost's software structure is not in fact distinct from its content structure -- where maintainers have to spend weeks writing persuasive essays to justify every time they move a file. jp× g 🗯️ 20:13, 11 February 2024 (UTC) reply

@ JPxG: With the greatest respect, this is a lot of text in response to my !vote; so while I will try not to miss anything in this response, I apologise if I have.

I am not requesting that you writ[e] persuasive essays to justify every time [you] move a file. As I've mentioned before, I think the work you've been doing to clean up Signpost-space is genuinely admirable. I have not previously noticed any similar deletions that gave me cause for concern, and this discussion is about this one redirect in particular. With respect, this characterisation seems like a stretch here.

I appreciate that building in an exception for this redirect may be a hassle. However, my view is that, in this case - given the specific circumstances surrounding this redirect - this does not outweigh the presumption in favour of keeping it given by K4. I do not believe that this is a Russell's teapot-esque reason for keeping - rather, it is applying the Redirect guideline to the current redirect. I am not trying to make an undisprovable statement here; but rather, attempting to apply my best interpretation of wider community consensus (i.e. WP:R) to this specific case.

You also assert that [I] have not articulated any reasonable way in which this "might cause harm", which I disagree with. In my view, it is highly reasonable to think (for example) that a page which accumulated over 100,000 views over the course of its life will have had its link copied - links which will no longer work if this redirect is deleted. The deletion would therefore cause harm by breaking these links to a long-standing historical title (quoting Godsy below) - historical both in terms of the length of time the page was at this name for, and because the page in question is an archive.

Furthermore, I disagree that the log snapshot provided when visiting a deleted redirect is a suitable substitute for the redirect itself - and certainly, the Redirect guideline does not recognise it as such. I also strongly disagree with your assertion that the log links are prominently-placed - they are located in small text, in a log format that I can easily see being confusing to anyone not previously familiar with it.

In addition, there is no evidence regarding what pageviews to the redirect since its undeletion either are or are not; and I am therefore skeptical of your assertion that they are almost certainly background noise. I am similarly skeptical of the seemingly baseless assertion that pages...which referenced [the redirect] from an external site either didn't exist or were updated (which, to give only one example, doesn't take into account blog-type posts made on other websites at previous points in time - which would understandably have low current traffic).

Finally, I don't assert that the deletion of this redirect would be [t]he major problem facing the Signpost. I'm worried that the linkrot left behind by doing so might be a problem for future readers, though.

All the best, ‍—‍ a smart kitten_{[ meow} 05:06, 20 February 2024 (UTC) reply

I do not need you to admire me; I just want you to not actively prevent me from fixing technical debt.

It's a lot of text because I am the editor-in-chief and primary technical maintainer of the Signpost, and you are asking that maintenance be subordinated to individual committee discussions on each page based on some entirely hypothetical notion that somebody might click on a page link and you think the text that tells them to go somewhere else isn't big enough.

The text that's displayed, when the page tells somebody that the resource has been moved, is not big enough. Can you explain why this -- in the current situation -- justifies adding a page to the directory permanently, without simply gesturing to a guideline?

You say that there were "100,000 views over the course of its life", but in reality there were 16 views (including me viewing the page) the month after it was moved. The number we should be discussing is less than sixteen. These less-than-sixteen page loads the month after the page was moved is the thing that you are requesting that I be forced to write additional code (and permanently make the directory structure more useful) in order to handle.

In a comment below, I have explained how this kind of thing messes up queries and scripts. Yes -- I understand -- it can be worked around. I understand this. I am saying that working around it requires additional lines of code to be crammed into everything that handles it, and makes the overall codebase incrementally more difficult to deal with.

Since the Signpost is entirely a volunteer project, and technical maintenace on the Signpost is a subset of an already-niche area of the project, adding arbitrary "trivial" obstacles to doing it results in even fewer people being willing or able to undertake it. I do not enjoy doing this anymore; I am extremely burnt-out, and discussions like this are the main reason why. You may think you are heroically maintaining the legibility of the archives to future generations. That's fine. But it was technical maintenance that retrieved all the previously-inaccessible subheadings from articles between 2011 and 2023; it was code that got every article from 2005 to the present indexed in the module; it was code that made it possible to read the archives in full. If you want to create arbitrary roadblocks to technical maintenance, and you think it's extremely easy to write and maintain all the scripts for the project within a directory structure that's forced to be confusing and redundant, please feel free to do that. jp× g 🗯️ 17:27, 20 February 2024 (UTC) reply

I was pinged here by something, probably one of the deleted/obsolete pages. I think JPxG should have some leeway to do the cleanup deemed necessary. The Signpost archives are a bit of a mess. I don't care about saving any prior archive layout or any legacy scripts/templates. ☆ Bri ( talk) 19:02, 12 February 2024 (UTC) reply

• Delete. Due to my belief that JPxG has the qualifications necessary to determine the necessity of such a page due to being a frequent contributor, and the explanation above. Cheers, UnexpectedSmoreInquisition aka USI ( talk) 19:08, 12 February 2024 (UTC) reply
• Keep. I applaud the nominator's effort to clean up subpages in a way that makes sense, as I tend to get in the weeds of the project namespace myself in the same manner from time to time. However, since this is a {{ R from move}}, I cannot validate me supporting the deletion of this redirect. In addition, unless this redirect is intended to be reused for something else, WP:CHEAP applies. Steel1943 ( talk) 21:50, 12 February 2024 (UTC) reply

  I have explained why it does not apply. If the price of being applauded is to be actively prevented from fixing issues, I would prefer obscurity. Every single issue that gets published involves about a half-dozen pages being moved without creating redirects.
  
  

  In this case, /Archives/ is a suburl of the main Signpost page, which should be something you can query to see how many archive pages there are. Since the Signpost was never subject to any sort of actual architecture decisions, there is a substantial amount of validation required to keep it functioning. For example, the number of issues is calculated by a database query for pages WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/____-__-__". How might we see if there are issue pages that don't have archives? Well, we can see how many archive pages there are total; maybe we will use SELECT COUNT(*) as "Number of archives" WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/Archives/%" AND page_title NOT LIKE "Wikipedia_Signpost/Archives/____" AND page_title LIKE "%SPV%", or use {{#expr: }} parser functions to subtract the output of a different template. I mean, I don't know -- I haven't written the software yet.
  

  It should noted that the /SPV/ pages in the archive index are redundant to the /Single/ pages in the normal index which I've created for them, so I hope to deal with those in the future, and there would only be one NOT LIKE in this statement. It's true that I could put an additional NOT LIKE in the statement to account for the lonely /Years/ redirect, or add another clause that selects based on the page_is_redirect entry in the page table. But if you look at mw:Manual:page table you can see that features are often added, removed or changed (the actor table has had a lot of changes over the years, for example). The fewer moving parts that a database query has, the less it needs to be maintained in the future (and the easier it is for someone else, who didn't write it, to do so when necessary). Moreover, there could become bogus redirects (i.e. from pagemove errors) that would be excluded from the metrics if we just say AND page_is_redirect = 0.
  

  One would expect it to be possible to get a full list of archive issue titles by SELECT COUNT(*) WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/Archives/____-__-__", but what I have learned in the course of writing software to deal with this stuff is that the simple tasks will sometimes unexpectedly become complicated due to unforseen edge cases -- so it is best to keep open as many options as possible by using simple, consistent conventions wherever possible.
  
  

  Here is a concrete example -- last January I went through the index of all pages, and found that there were upwards of a hundred useless redirects with no incoming links. Article names had been originally created with typos, or they were postponed, and whoever retitled them forgot to check the button to move without a redirect (or didn't have extended pagemover). This meant that SQL queries for e.g. {{ Signpost/Number of articles}} was inaccurate by about a hundred, and that the module indices had hundreds of entries in them for nonexistent articles (and, similarly, that PrefixIndex results for Signpost articles would give incorrect results). Any attempt to analyze or graph output by year/issue would be inaccurate. Any attempt to make a list of articles would include nonsense. It took most of an afternoon to fix these, but now they are fixed and the problems no longer exist. Note that it did not take a month to engage multiple people in a formal discussion process to seek approval for each individual item, nor was the work prohibited on the basis of an abstract idea that redirects are always good. They were not "cheap", they made it impossible to do many tasks so long as they existed. Now, however, you can see the output of {{ Signpost/Number of articles}} which is obtained using SELECT COUNT(*) as "Number of articles" FROM page WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/____-__-__/%" AND page_title NOT LIKE "%/SPV"; and produces an accurate number of (currently) 5,503. Note, furthermore, that this is four lines of SQL, and not five, or six, or ten, because there are no workarounds necessary except for the /SPV pages (which I am working on anyway; when these are fixed the report should only be three lines of SQL).
  
  

  Another example: I found a bunch of ghost articles in 2023, i.e. titles Wikipedia:Wikipedia Signpost/2006-09-12/News and Notes when there was no corresponding issue at Wikipedia:Wikipedia Signpost/2006-09-12. There were also ten ghost issues -- issue pages that had no subpages, corresponding to daily editions that weren't actually published, or created in error, or at the wrong location and moved. Again, these caused inaccurate statistics and broke some features. Any code that generated a list of issues was giving a list of nonsensical ghost issue links. Here, too, the pages were fixed without issue. This process was made possible by the fact that the number of redirects in Signpost article space was zero. Some backlinks did need to be fixed, which I was happy to do. As a result, {{ Signpost/Number of issues}} returns 690, and not some other incorrect number. Similarly to the other template, it is a very small SQL query (SELECT COUNT(*) as "Number of issues" FROM page WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/____-__-__"). This is a very small query, that requires virtually no documentation or specialized knowledge to understand. If there were a bunch of random unrelated crap pages in the directory, it would be a longer query, with confusing one-off edge-case handling.

  
  jp× g 🗯️ 17:06, 20 February 2024 (UTC) reply

• Medium keep - I do not see a reason to delete a long-standing historical title (e.g. broken external links, the preservation of wiki. history, etc.). I am, however, sympathetic to the idea that this would need to be deleted on technical grounds to prevent undue maintenance; if anyone can articulate that a bit more clearly and briefly, I would consider changing my opinion (please ping me as well). Could it not simply be ignored in such code? —  Godsy ^{( TALK} _CONT) 03:27, 20 February 2024 (UTC) reply

@ Godsy: See my comment above; I've tried to explain how inconsistent directory structures can cause issues. jp× g 🗯️ 17:28, 20 February 2024 (UTC) reply

It seems that many of the past deletions and likely future ones have been and will likely continue to be useful maintenance. However, in this case it does seem that there is benefit to retaining the page as a redirect or some other sort of landing page with an explanation. If queries into the article count show a single (or even a few extra) articles than there really are, that doesn't seem too bad (and it seems there is a technical solution). I also sympathize with attempting to cleanup something that has, shall we say, unique challenges in this format. However much I tend to seemingly agree with A smart kitten, I always try to keep the bicycle-shed effect in mind, so I guess I will go down to the elusive 'medium keep' (certainly not feeling strong or weak, but slightly less than a normal keep). When redirects should be kept and deleted, especially after moves, is an oft misunderstood concept. If some of the other regulars at this venue are persuaded, I may reconsider, but for right now I'm pretty firmly where I am at. —  Godsy ^{( TALK} _CONT) 00:53, 23 February 2024 (UTC) reply

• Keep per A smart kitten, Steel1943 and Godsy. There are well articulated reasons to keep this content easily accessible via these titles and clear potential harm from deletion that combined far outweigh the reasons presented for deletion. Thryduulf ( talk) 05:23, 20 February 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: While I do think there is currently enough of a consensus to keep, I want to give this more time to play out based on the nominator and their rational.
Please add new comments below this notice. Thanks, Hey man im josh ( talk) 18:49, 20 February 2024 (UTC) reply

@ Hey man im josh: I'm confused - the last three !votes have been to keep. I'm not seeing how there's currently consensus to delete. All the best, ‍—‍ a smart kitten_{[ meow} 19:06, 20 February 2024 (UTC) reply

Sorry @ A smart kitten, I wrote it backwards. I've corrected this mistake. Hey man im josh ( talk) 19:08, 20 February 2024 (UTC) reply

• Delete. My first Wikipedia edit in a long time as I was pinged on this as the original creator of some subset of the pages under discussion. I don't understand why something that is clearly administrative in nature requires a wall of text of justifications to satisfy old-timers obsessed with pedantic details of links you can't even prove exist. Res Mar 05:13, 21 February 2024 (UTC) reply

  Because there are arguments against the deletion of this redirect which mean it is not purely administrative in nature - if it was, this discussion wouldn't exist. My reasons for !voting to keep it are outlined above. (Also, to be clear, no pages created by yourself are nominated here.) All the best, ‍—‍ a smart kitten_{[ meow} 03:33, 26 February 2024 (UTC) reply

• Comment - I would ask that the closer of this discussion considers taking into account the unintentional notifications caused by a list of previous XfD nominations being copied into this one, which seems to have pinged the original creators of those Signpost-related pages. All the best, ‍—‍ a smart kitten_{[ meow} 06:54, 21 February 2024 (UTC) reply
• Delete: The underlying purpose for keeping an r from move, per the template info at Template:R from move, is: "to avoid breaking links, both internal and external, that may have been made to the old page name." More often than not when it pertains to mainspace articles, incoming links are a valid concern. But when it comes to switching from one internal archiving system to another, success is measured from a fresh start. As the person who's seemingly undertaken the reallotment of the Signpost archives, I trust Jpxg's judgement here (as the editor-in-chief of the Signpost, which this redirect falls under) and see no reason to keep this leftover which will have zero benefit as an "r from move", which is invisible to all after the updating of 100% of links, and only more struggles and headaches for the people that actually deal with this on a regular basis, i.e. Signpost regulars. Utopes _{( talk / cont)} 18:04, 1 March 2024 (UTC) reply
• Delete per Utopes and jpxg. The falloff in traffic noted by jpxg suggests that there are few, if any, links pointing people to this page that would be broken by this change. _signed, Rosguill ^talk 18:11, 4 March 2024 (UTC) reply
• Delete: I agree with Utopes – volunteers working on Signpost should be relatively free in management of pages their readership uses to access what Signpost volunteers produced. Someone looking for archives of the Signpost surely won't be discouraged by a deleted, weirdly named "Years" subpage; they won't have trouble finding the archives, e.g. by reading the footer Explore Wikipedia history by browsing The Signpost archives on the front page. —⁠ andrybak ( talk) 00:31, 8 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: The majority opinion seems to be shifting from keep to delete, so I'm relisting to give others more time to chime in. Have the Signpost's maintainers sufficiently demonstrated that the undue maintenance debt of this disused page title, and the presumption of curatorial freedom by internal projects' lead volunteers, should outweigh WP:CHEAP?
Please add new comments below this notice. Thanks, Deryck C. 15:15, 19 March 2024 (UTC) reply

Delete as per nom and Utopes. There's no reason to expect that an important external link might exist that might be broken by deleting this redirect, meanwhile, I trust jpxg in that he's already cleaned up any existing internal redirects. Further... the entire point of WP:CHEAP is that keeping a redirect typically poses no undue burden on the userbase or editors. jpxg has already written extensively on how he, by contrast, would need to undertake a lot of undue burden in order to work around this redirect. That's not cheap, people. That's expensive. 𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 ( talk) 15:57, 19 March 2024 (UTC) reply

• Delete. Our guidelines and policies are here for the purpose of Wikipedia's readers first, and editors second, and not at all for the purposes of bureaucracy alone. When applying a guideline makes it harder for editors to maintain the encyclopedia while providing no benefit to readers, it's on us to ignore the guideline. -- asilvering ( talk) 17:13, 21 March 2024 (UTC) reply
• Delete, I don't think this redirect matters enough to outweigh the cost in this case; WP:CHEAP only applies if the redirect is, in fact, cheap. Rusalkii ( talk) 01:06, 22 March 2024 (UTC) reply
• Delete - The purpose of K4 and CHEAP is to avoid deleting redirects that cause little harm, not to prevent deleting redirects that are causing harm. The notion that we should be building tools around the wiki, not the wiki around the tools is an empty platitude if nobody is actually willing to do the work. This is an endemic problem on en-pedia - it is much easier to tell others how to do the work than to do it yourself, and so we end up with too much policy and not enough volunteers. We can discuss the broader implications of that problem in another venue. In this case, it is obvious that deleting this redirect will cause no meaningful harm, and the volunteers who are actually doing the work would greatly prefer for it to be gone. So we should get rid of it. It really is that simple. -- N Y Kevin 20:47, 29 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was delete. Jay 💬 10:25, 27 March 2024 (UTC) reply

• RainbowTwtr → Twitter#Privacy, security and harassment  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Not mentioned in target article, leaving the connection between the redirect and the target unclear. Steel1943 ( talk) 12:23, 19 March 2024 (UTC) reply

Delete Oh boy, this was a doozy.

• Searching for what the heck RainbowTwtr was revealed a rather nasty exploit of the site that ended up being deemed newsworthy. Seemed like it had plenty of sources-- why WASN'T this in the article?
• According to the redirect's history, this was DEFINITELY mentioned as recently as January 2019 (when the redirect creator, User:Philippe Depesch, used it as justification to return the {{R from Twitter username}} tag to the article), and the section it pointed to-- which doesn't show up in the current version of the article-- did exist as late as July 2021, when Cewbot removed the Oxford comma from the redirect in order to properly target it to the correct section header.
• Diving into the history of Twitter was a wild ride due to the EXTENSIVE history of the article.
• The section header "Privacy, security and harassment" ceased to be on May 12, 2022, when User:Samuel Wiki split the section up-- the information on RainbowTwtr lived on under the brand-new Twitter#Security section.
• The section then received a major rewrite and self-described 'clearing-out' by User:DFlhb on November 8, 2022, who (in the edit summary) justified his edit by saying that the information he removed was outdated, excessively long, failed WP:10YT, and that precedent leaned against keeping information on every single bug experienced by a piece of software. Included in this trimming was RainbowTwtr, which ceases to show up in the history of the article at this point exactly.

Given the justification given in DFlhb's edit summary was sound, I don't feel the need to return the deleted information to the page. Instead, delete the redirect. 𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 ( talk) 14:39, 19 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was delete. Hey man im josh ( talk) 12:44, 26 March 2024 (UTC) reply

• Maestro (upcoming film) → Maestro (2023 film)  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Delete per WP:UFILM. Target released over a month ago, redirect has next-to-no page views. Steel1943 ( talk) 12:08, 19 March 2024 (UTC) reply

• Delete. Three page views this year, none of them within the past 30 days, is indeed "next-to-none" and I'm not aware of any other need to keep this around. Thryduulf ( talk) 20:17, 19 March 2024 (UTC) reply
• Delete per nom. InfiniteNexus ( talk) 05:47, 22 March 2024 (UTC) reply
• Delete per WP:UFILM. InterstellarGamer12321 ( talk | contribs) 16:59, 22 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was delete. Hey man im josh ( talk) 12:56, 26 March 2024 (UTC) reply

• Powerpuff Girls (upcoming TV series) → The Powerpuff Girls#Live-action  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Unless the plan is to retarget this to The Powerpuff Girls#Cancelled live-action adaptation, which has be canceled since 2023, this redirect does not describe anything in the target article. Steel1943 ( talk) 12:02, 19 March 2024 (UTC) reply

• Delete. The page views fell to a trickle after July/August last year and stopped almost entirely in early January this year. Thryduulf ( talk) 20:19, 19 March 2024 (UTC) reply
• Delete per nom. InfiniteNexus ( talk) 05:48, 22 March 2024 (UTC) reply
• Delete in the spirit of WP:UFILM and the lack of pageviews. InterstellarGamer12321 ( talk | contribs) 16:52, 22 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was retarget to British people. (non-admin closure) CycloneYoris ^talk! 19:56, 26 March 2024 (UTC) reply

• Uk public → United Kingdom constitutional law  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

R3 declined due to not recent (February vs November), this is an otherwise vague search term which doesn't exclusively apply to constitutional law, from my understanding. Utopes _{( talk / cont)} 05:53, 12 March 2024 (UTC) reply

• Delete: unclear meaning, not a useful disambiguation. Kk.urban ( talk) 06:41, 12 March 2024 (UTC) reply
• Retarget to British people (same target as UK people) as a near-synonym. PleaseStand ( talk) 08:13, 12 March 2024 (UTC) reply
• Retarget as per PleaseStand. 𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 ( talk) 08:18, 12 March 2024 (UTC) reply
• Retarget per PleaseStand. The terms aren't quite identical, but they're close enough. Thryduulf ( talk) 16:19, 12 March 2024 (UTC) reply
• Retarget per PleaseStand as most plausible target -- Lenticel ^{( talk)} 21:21, 13 March 2024 (UTC) reply
• Delete. Unclear on how or why there is an expectation of the word "public" equaling "people". Also, UK public does not exist. Steel1943 ( talk) 18:55, 16 March 2024 (UTC) reply

  ...Or retarget to Government of the United Kingdom, the target of UK public sector, since that seems to be the base subject of the redirects mentioned below by Wbm1058. Steel1943 ( talk) 18:11, 18 March 2024 (UTC) reply

• Delete. US public does not exist either. This is a partial title match which interferes with getting optimal search results: UK public sector, UK public services, UK public law, UK public spending, UK public debt. – wbm1058 ( talk) 16:34, 18 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Hey man im josh ( talk) 11:46, 19 March 2024 (UTC) reply

• The optimal search result for this search term is the current target UK people, not any of the partial title matches. It is never used to mean the public sector or public services but actually refers to the people of the United Kingdom. Among countless other examples: The UK public elects 650 Members of Parliament..., ...an exclusive survey of the UK public..., Around half (49%) of the UK public say they have confidence in the civil service, Does the UK-public's aversion to inequalities in health differ by group-labelling and health-gain type?, Northern Ireland: Majority of the UK public are against the Troubles Bill - New Poll, The UK public wants to contribute to net zero..., UK public's inflation expectations fall in February. The UK public thinks high prices and lower incomes are here to stay. Thryduulf ( talk) 20:28, 19 March 2024 (UTC) reply

  Wait, is that in support of retargeting to British people in order to match UK people as per PleaseStand, or in support of keeping the current target, which... is United Kingdom constitutional law? 𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 ( talk) 23:46, 19 March 2024 (UTC) reply

  The former. I've corrected my comment. Thryduulf ( talk) 23:57, 19 March 2024 (UTC) reply

• Retarget to British people: seeing as they're collectively the UK public (y'know, the general public, members of the public, etc) I guess. 🔥HOTm̵̟͆e̷̜̓s̵̼̊s̸̜̃🔥 ( talk・ edits) 12:13, 20 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was retarget to Luminary (podcast network). Nominally no consensus, defaulting to retarget in the absence of support for the status quo. _signed, Rosguill ^talk 20:06, 5 April 2024 (UTC) reply

• Midnight Miracle → 2022 Peach Bowl  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Not mentioned at target. This redirect was created shortly after a relevant / similar discussion was closed at Wikipedia:Redirects_for_discussion/Log/2024_January_24#Georgia_Bulldogs'_Midnight_Miracle. Hey man im josh ( talk) 17:27, 9 February 2024 (UTC) reply

This is a different redirect. It just says Midnight Miracle. Abhiramakella ( talk) 18:03, 9 February 2024 (UTC) reply

• Delete. This is far from the primary topic for the search term. Topping the list is a podcast, mentioned in a table at Luminary (podcast network)#Programming but that's not sufficient to anchor a redirect, and on the articles about all three of the hosts (targetting any one of the hosts would present XY issues; I can't rule out the podcast being notable. After that comes a skin oil/cream that doesn't appear to be mentioned on Wikipedia at all (and doesn't seem like it should be). Excluding both those brings up a myriad of different things, but none of them relate to American football. Thryduulf ( talk) 19:28, 9 February 2024 (UTC) reply
• Delete. Not found in target article. - Dyork ( talk) 21:10, 9 February 2024 (UTC) reply
• Weak retarget to Miracle at Midnight. Jay 💬 18:02, 16 February 2024 (UTC) reply

  Is there any evidence that Miracle at Midnight is called this? If not delete * Pppery * _{it has begun...} 17:42, 21 February 2024 (UTC) reply

  I don't know, hence "weak". Jay 💬 07:01, 23 February 2024 (UTC) reply

  Struck off, for better consensus. Jay 💬 06:35, 16 March 2024 (UTC) reply

• Delete per WP:V, attestation as a name for this event has not been verified with a sourced mention at the article. Attestation as a form of Miracle at Midnight has also not been established. -- Tavix ^{( talk)} 03:03, 23 February 2024 (UTC) reply
• Retarget to Luminary (podcast network). "Midnight Miracle" is mentioned 4 times in enwiki: at the podcast article, and at the articles of the 3 co-creators whose articles are all linked from the podcast article. Shhhnotsoloud ( talk) 09:18, 24 February 2024 (UTC) reply
• Retarget to Luminary (podcast network) per Shhhnotsoloud. -- BDD ( talk) 18:52, 26 February 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, CycloneYoris ^talk! 20:37, 26 February 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Retargeting to Luminary (podcast network), while not the most !voted numerically, has been unchallenged since the !votes to retarget here began. However, the concern that the entry does not have sufficient content to anchor a redirect has not been addressed.
Please add new comments below this notice. Thanks, Utopes _{( talk / cont)} 05:19, 11 March 2024 (UTC) reply

• Comment I still feel that mentions of the podcast network are insufficient to make this a useful redirect. Thryduulf ( talk) 13:23, 11 March 2024 (UTC) reply
• Weak retarget to Luminary; it at least puts the title in context. 19:48, 15 March 2024 (UTC) — Preceding unsigned comment added by Rusalkii ( talk • contribs)

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Final relist. Still no consensus after the previous two.
Please add new comments below this notice. Thanks, CycloneYoris ^talk! 08:45, 19 March 2024 (UTC) reply

• Comment. A note to the closing admin: This one is in need of a WP:BARTENDER. There's no consensus, but not a single Keep vote, either, the consensus split is between Delete and Retarget. 𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 ( talk) 09:24, 19 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was delete. theleekycauldron ( talk • she/her) 03:45, 12 April 2024 (UTC) reply

• List of arunachal pradesh cricketer → List of Arunachal Pradesh cricketers  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Delete. I can't see how this serves any purpose. It is lower case and singular, so who would enter that as a search term? Batagur baska ( talk) 21:28, 11 March 2024 (UTC) reply

Keep. Someone who doesn't hit the caps lock key and accidentally hits Enter before the last character? Seems plausible to me. 𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 ( talk) 21:56, 11 March 2024 (UTC) reply

• Keep Very plausible that someone limited in English proficiency would use this term to get to that page. Nate • ( chatter) 01:11, 12 March 2024 (UTC) reply
• Weak keep per WP:CHEAP, but the lack of pageviews (virtually 0 before this RfD) indicates this is an unlikely search term and may push me into supporting deletion. InterstellarGamer12321 ( talk | contribs) 07:38, 12 March 2024 (UTC) reply
• Delete per nom and creator (especially because of the singular), who admitted the mistake, and corrected it, one minute after creating it. If not for the keep votes, this would have qualified for WP:U1. Jay 💬 15:24, 18 March 2024 (UTC) reply

  U1 only applies to pages in the user namespace, so this would definitely not have qualified for that criterion. Thryduulf ( talk) 15:44, 18 March 2024 (UTC) reply

  Oh right. R3 then. Although created in November, the nom brought it to RfD now, only because it was tagged with capitalization. Jay 💬 16:03, 18 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Keep or delete?
Please add new comments below this notice. Thanks, CycloneYoris ^talk! 08:40, 19 March 2024 (UTC) reply

• Delete - could have been deleted via R3 or G7 earlier in its history. Arguments that this is a plausible search term ignore that the correct search term will also populate for this string. _signed, Rosguill ^talk 20:05, 5 April 2024 (UTC) reply
• Delete. The poor grammar and capitalization make this an implausible search term. — TechnoSquirrel69 ( sigh) 21:42, 5 April 2024 (UTC) reply
• Delete implausible and not useful with this typing. Utopes _{( talk / cont)} 00:23, 8 April 2024 (UTC) reply
• Keep per WP:CHEAP; this isn't a terribly unnatural modification. Duckmather ( talk) 16:17, 8 April 2024 (UTC) reply
• Delete Too many errors. * Pppery * _{it has begun...} 22:34, 8 April 2024 (UTC) reply
• Delete per Jay et al. Implausible redirect with incorrect capitalization and grammar. CycloneYoris ^talk! 01:23, 10 April 2024 (UTC) reply
• Delete per nom Okmrman ( talk) 19:39, 10 April 2024 (UTC) reply
• Delete redirects may be cheap, but this one is pointless. LEPRICAVARK ( talk) 02:30, 12 April 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was retarget to Flour massacre#Subsequent attacks.. There is a relevant mention a the target, so in the absence of objection the retarget suggestion carries. _signed, Rosguill ^talk 20:02, 5 April 2024 (UTC) reply

• Deir el-Balah bombing → Al-Rashid humanitarian aid incident  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Not mentioned anywhere in the article, and comments on the talk page indicate that there are no plans to add it. These are different events. QuicoleJR ( talk) 17:49, 4 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Hey man im josh ( talk) 18:04, 11 March 2024 (UTC) reply

• Retarget to Flour massacre#Subsequent attacks. Jay 💬 05:39, 18 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Thoughts on retargeting to Flour massacre?
Please add new comments below this notice. Thanks, CycloneYoris ^talk! 08:40, 19 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was support for disambiguation. The nominator will be converting the page to a disambig. Jay 💬 05:49, 4 April 2024 (UTC) reply

• Notre Dame de Miséricorde → Cotonou Cathedral  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 
• Notre-Dame-de-Miséricorde → Cotonou Cathedral  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Far too ambiguous to point directly to a particular church. See for example fr:Église Notre-Dame-de-la-Miséricorde, which lists many of these churches, none of which are the cathedral in Benin. asilvering ( talk) 04:32, 11 March 2024 (UTC) reply

• Retarget. Clearly Notre-Dame-de-la-Miséricorde, Notre Dame de la Miséricorde, Notre-Dame-de-Miséricorde and Notre Dame de Miséricorde should be a disambiguation page, even if it would largely be full of redlinks at the moment — Preceding unsigned comment added by OwenBlacker ( talk • contribs) 10:42, 11 March 2024 (UTC) reply
• Comment: I checked "Our Lady of Mercy", which is the English translation of the same phrase, and am appropriately redirected to Virgin of Mercy. I see that Mother of Mercy redirects to the same place. I think it would make the most sense if all of these redirected to a dab page, with Virgin of Mercy listed clearly as the main topic and other uses such as churches, etc grouped below that one. -- asilvering ( talk) 19:45, 11 March 2024 (UTC) reply
• I'd DAB with a note that this is the french equivalent of "Our Lady of Mercy", one of the many catholic titles for the Virgin Mary aka the Virgin of Mercy. Then several churches and parishes bare the name. Headbomb { t · c · p · b} 02:29, 13 March 2024 (UTC) reply
• Comment: Perhaps rename these two redirects to "Notre Dame de Miséricorde de Cotonou" and "Notre-Dame-de-Miséricorde de Cotonou", respectively, with the same target of Cotonou Cathedral, which should resolve the initial ambiguity. Agree also with having a separate dab page with appropriate redirects to it, but deciding and implementing that need not hold up renaming the two redirects being discussed.  — Archer1234 ( t· c) 11:17, 15 March 2024 (UTC) reply

  @ OwenBlacker, @ Asilvering, @ Headbomb. Any objections to renaming the redirects as:

  • rename Notre Dame de Miséricorde as Notre Dame de Miséricorde de Cotonou
  • rename Notre-Dame-de-Miséricorde as Notre-Dame-de-Miséricorde de Cotonou

  This would avoid the ambiguity of the current names. What do you think?  — Archer1234 ( t· c) 00:49, 21 March 2024 (UTC) reply

  @ Archer1234 it's fine from the perspective of the redirects not being ambiguous, but I doubt anyone is going to type that into the search bar. -- asilvering ( talk) 03:25, 21 March 2024 (UTC) reply

  @ Asilvering, I think I get your point. What do you think about just deleting them?  — Archer1234 ( t· c) 17:03, 21 March 2024 (UTC) reply

  @ Archer1234 It's preferable to rewriting them as you proposed, I think. But the best thing would be to have a dab page. I'm happy to start one at Notre Dame de Miséricorde if we all agree that's the right idea. Pinging @ OwenBlackerand @ Headbomb to check. -- asilvering ( talk) 17:09, 21 March 2024 (UTC) reply

  I am fine with you starting a dab page.  — Archer1234 ( t· c) 05:37, 26 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, CycloneYoris ^talk! 08:36, 19 March 2024 (UTC) reply

• @ Asilvering: Can I close this saying you will be starting a disambiguation page? Jay 💬 15:54, 3 April 2024 (UTC) reply

  @ Jay sure thing. Ping me when you've done so with a link back to this, please! -- asilvering ( talk) 20:24, 3 April 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was keep. _signed, Rosguill ^talk 20:00, 5 April 2024 (UTC) reply

• LGBT reproduction → Use of assisted reproductive technology by LGBT people  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 
• LGBTQ reproduction → Use of assisted reproductive technology by LGBT people  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 
• LGBT Reproduction → Use of assisted reproductive technology by LGBT people  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 
• Lesbian reproduction → Use of assisted reproductive technology by LGBT people  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 
• Gay reproduction → Use of assisted reproductive technology by LGBT people  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 
• LGBTQ+ Production of Family → Use of assisted reproductive technology by LGBT people  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

(please also add LGBTQ reproduction, LGBT Reproduction, Lesbian reproduction, Gay reproduction and LGBTQ+ Production of Family to this discussion)

As noted in the move discussion at Talk:Use_of_assisted_reproductive_technology_by_LGBT_people#Requested_move_4_February_2024, this is an odd phrase and can have multiple meanings. Without going into original research, the best thing to do is to delete this redirect as a possible WP:NEOLOGISM. – GnocchiFan ( talk) 22:14, 3 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Bundled the five mentioned.
Please add new comments below this notice. Thanks, Jay 💬 02:59, 11 March 2024 (UTC) reply

• Support per nom —  OwenBlacker (he/him; Talk) 10:39, 11 March 2024 (UTC) reply
• Keep. I agree these are imprecise terms, but the article existed under that title for a few years, so per WP:RKEEP#4 we'd need a good reason to delete them. I don't think the nom makes a strong enough case for that. Is there another subject these titles could be referring to? I see some halfway plausible Google hits for this title. And LGBTQ+ Production of Family was merged into this article at AFD, with some significant history, so we shouldn't delete that (RKEEP#1). —  The Earwig ( talk) 04:06, 12 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Keep or delete?
Please add new comments below this notice. Thanks, CycloneYoris ^talk! 08:32, 19 March 2024 (UTC) reply

• Keep, unless a better article is made encompassing the term. BD2412 T 21:58, 20 March 2024 (UTC) reply
• Keep per BD2412, or unless it is shown what are the multiple meanings these titles represent. Jay 💬 15:58, 3 April 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was keep. Jay 💬 16:00, 3 April 2024 (UTC) reply

• Funny book → Comic book  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Not mentioned in the target article. Without a specify code mention tying the redirect as an alternative name of the target page, the redirect is ambiguous since the only type of book which may be funny is not exclusive to Comic book. Steel1943 ( talk) 23:28, 4 March 2024 (UTC) reply

Delete. The only thing I can think of as to why this exists is this definition for 'funnies' on Wiktionary. The issue (ha) is, the adjective "funny" is thought of a lot more than the noun. Not only are comic books not inherently funny, there are plenty of comedy books out there that aren't comic books. This sort of ambiguity kills the redirect. Lunamann 🌙🌙🌙 The Moooooooniest ( talk) 03:12, 5 March 2024 (UTC) reply

• Delete per nom -- Lenticel ^{( talk)} 07:11, 6 March 2024 (UTC) reply

Weak keep Not all comics are funny, but “funny book” used to be a standard term for comic books, a la “the funnies”. I would never expect this term to lead anywhere but to comic book… but I say “weak” keep because I CAN imagine a different person less familiar with historical comics terminology who expected to end up at something like comic fiction or some existing pages about novels that are funny. ~ L 🌸 ( talk) 17:31, 8 March 2024 (UTC) reply

very very weak retarget to comic novel or all star "the goddamn" batman & robin, the boy wonder, or delete as vague. if i read super mario 64's manual and get a laugh out of it, that would make it a "funny book"

i don't think whether or not it had some niche use before matters because that use is very much gone cogsan _{(nag me) (stalk me)} 18:24, 8 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, ✗ plicit 05:03, 12 March 2024 (UTC) reply

• Delete: stupidly vague ngl 🔥HOTm̵̟͆e̷̜̓s̵̼̊s̸̜̃🔥 ( talk・ edits) 23:39, 12 March 2024 (UTC) reply
• Keep. As LEvalyn pointed out, "funny book" was once used interchangeably with "comic book", just as newspaper comics were once called "funnies" and occurred on the "funny pages". The fact that this use is dated doesn't make it incorrect; people might run across the term and try to look it up. Unless there is another plausible target, it should stay where it is. And even though not all comic books are funny, and non-comic books may also be funny, I don't believe there has ever been a time when this specific phrase referred to anything else, and I don't find it plausible that most readers will expect it to go to a different target. P Aculeius ( talk) 22:40, 13 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Jay 💬 06:02, 19 March 2024 (UTC) reply

• Keep. Come on, not everyone using Wikipedia is under the age of 40. For attestation that "funny book" is synonymous with "comic book", see wikt:funny book. If you'd prefer a non-user-generated source, here's Merriam Webster: [9]. -- asilvering ( talk) 03:33, 21 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was delete. Hey man im josh ( talk) 14:52, 8 April 2024 (UTC) reply

• Brookville Police Department → Brookville, New York  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

no mention on target page, plausibly notable. asilvering ( talk) 05:38, 5 March 2024 (UTC) reply

DeletE as per nom. WP:REDLINK. I uh, think you put this new RfD nomination right in the middle of an existing nomination, which means you stole the original version of this comment from Master of the TreboN Altarpiece ^^; That said, no harm no foul, as my vote for this one is mostly the same anyways! Lunamann 🌙🌙🌙 The Moooooooniest ( talk) 04:42, 5 March 2024 (UTC) reply

@ Lunamann: What happened was the first non-bot edit of the day broke the top text that Twinkle uses to detect where to put new RfD nominations. But ... this is odd since apparently, per other nominations on this page, XFDcloser ... knew where to put the relisted nominations, even with the top matter looking abnormal. Maybe Twinkle could take a bit of code from XFDcloser to utilize for new RfD nominations in the same manner that XFDcloser determines where to place a relisted discussion? (Eh, might as well ping Novem Linguae so they are aware of this as they seem to be one of the most active editors at monitoring both tools these days.) Steel1943 ( talk) 13:40, 5 March 2024 (UTC) reply

Huh. Weird. Lunamann 🌙🌙🌙 The Moooooooniest ( talk) 14:20, 5 March 2024 (UTC) reply

Huh, weird! I didn't realize that's what happened and was wondering why your initial comment didn't seem to make sense. -- asilvering ( talk) 17:19, 5 March 2024 (UTC) reply

I can add a mention of the department on the target page a little later today. I thought I did so already but I guess I am mistaken. My apologies. Infrastorian ( talk) 16:17, 5 March 2024 (UTC) reply

I'll note, for the record, that this proposed edit would change my vote from Delete (er, DeletE) to Keep (or perhaps, Refine.) Lunamann 🌙🌙🌙 The Moooooooniest ( talk) 16:23, 5 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, CycloneYoris ^talk! 07:26, 12 March 2024 (UTC) reply

Refine to Brookville, New York#Government, which now has a mention. 𝔏𝔲𝔫𝔞𝔪𝔞𝔫𝔫🌙🌙🌙 𝔗𝔥𝔢 𝔐𝔬𝔬𝔬𝔬𝔬𝔫𝔦𝔢𝔰𝔱 ( talk) 08:23, 12 March 2024 (UTC) reply

• Retarget to Brookville. The Indiana, Ohio, and Pennsylvania Brookvilles (at least) also have police departments, and the Ohio Brookville is about double the New York one's population. No telling which Brookville Police a reader is likely to be looking for. (Alternatively, if someone wants to put in the work, this could be a disambiguation page just among the four (?) Brookvilles with police departments.) -- Visviva ( talk) 02:03, 13 March 2024 (UTC) reply
• Delete. The mention added at Brookville, New York is so brief that it's hardly useful at all. There's no point retargeting to the place name's disambiguation page. -- Paul_012 ( talk) 01:32, 17 March 2024 (UTC) reply

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Also notified of this discussion at the talk page of proposed target Brookville.
Please add new comments below this notice. Thanks, Jay 💬 05:49, 19 March 2024 (UTC) reply

• Delete as ambiguous without content, and per Paul_012. Jay 💬 16:03, 3 April 2024 (UTC) reply
• Delete per Jay, Paul, and the reasoning of Visviva's !vote, which suggests possibilities for even more confusion for readers (and no improvement in the amount of relevant content actually available for them). _signed, Rosguill ^talk 19:59, 5 April 2024 (UTC) reply
• Delete no mention of police departments. Utopes _{( talk / cont)} 00:24, 8 April 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was retarget to Thalassic. Hey man im josh ( talk) 12:58, 26 March 2024 (UTC) reply

• Thalassic (album) → Ensiferum#Discography  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Needless disambiguation, let alone the wrong target. The album, by Ensiferum, already has an article and is the primary topic. dannymusiceditor ^oops 01:31, 19 March 2024 (UTC) reply

• Retarget to Thalassic as a harmless {{ r from unnecessary disambiguation}}. - Eureka Lott 14:30, 19 March 2024 (UTC) reply
• Speedy retarget not sure why this needs to be discussed. Crouch, Swale ( talk) 19:39, 19 March 2024 (UTC) reply

  Actually, I fail to understand why Wikipedia even recognizes {{ r from unnecessary disambiguation}}. Why have another when one does the trick? Nobody is going to type out the longer disambiguation to find the page. I am of the belief that all such redirects should be deleted. Seems I'm in the minority on that, though. dannymusiceditor ^oops 05:50, 20 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was delete. ✗ plicit 03:54, 26 March 2024 (UTC) reply

• 2023 Mother's Day photograph by Catherine, Princess of Wales → Where is Kate?#Mother's Day photograph  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Suggesting Delete as an implausible search term. The photograph was taken in 2024, not 2023, and is of, not by, Catherine, Princess of Wales. The redirect was likely created as a result of an editor's !vote to rename Where is Kate? to the redirect in the AfD discussion, evidently mistaking the year and preposition. IgnatiusofLondon (he/him • ☎️) 01:28, 19 March 2024 (UTC) reply

• Delete: wrong year smh my head 🔥HOTm̵̟͆e̷̜̓s̵̼̊s̸̜̃🔥 ( talk・ edits) 02:08, 19 March 2024 (UTC) reply
• Delete not a helpful enough search aide for it having incorrect information. Skynxnex ( talk) 16:15, 21 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.

The result of the discussion was retarget to Lumberjack#Lumberjack fashion. Nominator agrees with this uncontroversial retargeting. (non-admin closure) Skynxnex ( talk) 16:35, 21 March 2024 (UTC) reply

• Lumbersexual → Lumberjack#Lumbersexual aesthetic  ( talk · links · history · stats)     [ Closure:  keep/ retarget/ delete ] 

Currently points to a busted anchor, not sure where to redirect it to maybe Hipster (contemporary subculture) or 2010s_in_fashion — blindlynx 00:36, 19 March 2024 (UTC) reply

• Retarget to Lumberjack#Lumberjack fashion, which seems to be the new name of the original section. Rusalkii ( talk) 01:22, 19 March 2024 (UTC) reply
• Just redirect to Lumberjack#Lumberjack_fashion --- Another Believer _{( Talk)} 01:24, 19 March 2024 (UTC) reply

  christ i'm dumb...not sure how i didn't see that— blindlynx 20:22, 19 March 2024 (UTC) reply

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).