Open main menu

Wikipedia talk:Criteria for speedy deletion

  (Redirected from Wikipedia talk:CSD)


Provide for CSD criterion X3: Mass-created portalsEdit

Clearly both sides feel strongly about this question and both have advanced reasonable arguments. Those in favour typically cite the large amount of community effort required to clean up these portals through the normal MfD process, while those against often do not want to see useful content thrown out with the useless. There is also a significant minority who see a need for some fast-track process to avoid wasting community time, but think that this proposal goes too far. As it seems likely that a less-aggressive proposal would gain the support of most of the supporters as well as a large segment of those opposed, the arguments in opposition seem somewhat stronger. So, while there is a small majority in favour of the change, there is no consensus for it. GoldenRing (talk) 10:28, 4 April 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

  Administrator note: This proposal is being advertised at WP:VPP and WP:CD, and it has been requested that it stay open for at least 30 days. ~Swarm~ {talk} 05:14, 17 March 2019 (UTC)

I am entering and numbering this proposal in order to get it into the record, but am requesting that action on it be deferred until the current round of MFDs are decided.

As per User:UnitedStatesian, Create Criteria for Speedy Deletion criterion X3, for portals created by User:The Transhumanist between April 2018 and March 2019. Tagging the portals for speedy deletion will provide the notice to users of the portals, if there are any users of the portals. I recommend that instructions to administrators include a request to wait 24 hours before deleting a portal. This is a compromise between the usual 1 to 4 hours for speedy deletion and 7 days for XFD. The availability of Twinkle for one-click tagging will make it easy to tag the pages, while notifying the users (if there are any). Robert McClenon (talk) 04:21, 3 March 2019 (UTC)

This proposal should be posted in a wider venue, such as WP:VPR or WP:MFD. Many of those portals have been in place for months, making WP:AN too narrow a venue for them. CSD notices wouldn't be placed until after the discussion is over, and therefore would not serve to notify the users of those portals of the discussion. A notice to the discussion of this proposal, since it is a deletion discussion, should be placed on each of the portals, to allow their readers to participate in the discussion. The current round of MfDs are not a random sampling of the portals that were created, and therefore are not necessarily representative of the set. The portals themselves vary in many ways, including scope, the amount of time they've been accessed by readers, quality, number of features, picture support, volume of content, amount of work that went into them, number of editors who worked on them, length, readership, etc.    — The Transhumanist   07:09, 3 March 2019 (UTC)
How would you suggest to get a representative sample? Legacypac (talk) 07:20, 3 March 2019 (UTC)
Thank you for asking. That would be difficult now, since there are already a bunch of portals nominated for MfD. If those were included, then the sample would already be skewed. I expect a truly random sample would reveal that some portals are worth keeping and others are not. A more important question would be "How would we find the portals worth keeping? Which is very similar to the question "what should the creation criteria for portals be?", the very thing they are discussing at the portal guidelines page right now. Many of these portals may qualify under the guideline that is finally arrived upon there. For example, they are discussing scope. There are portals of subjects that fall within Vital articles Level 2, 3, 4, and 5, and there are many portals of subjects of similar scope to the subjects at those levels. And many of the portals had extra work put into them, and who knows how many had contributions by other editors besides me. Another factor is, that the quality of the navigation templates the portals are powered by differs, and some of the portals are powered by other source types, such as lists. Some have hand-crafted lists, as there are multiple slideshow templates available, one of which accepts specific article names as parameters. Another way to do that is provide a manual list in the subtopics section and power the slideshow from that. Some of the portals are of a different design than the standard base template. Some are very well focused, contextually, while others are not. For example, some of the portals have multiple excerpt slideshows to provide additional context.    — The Transhumanist   07:46, 3 March 2019 (UTC)
  • Support in principle. Looking at the existing MFD discussions, TTH seems determined to drag and wikilawyer as much as possible to try to derail the discussions, even for blatantly and indefensibly inappropriate microportals like those discussed at Wikipedia:Miscellany for deletion/Portals for Portland, Oregon neighborhoods; it's not a good use of anyone's time to go through the same timesink 5000+ times. (The cynic in me says that a speedy criterion wouldn't work as while the creators wouldn't be able to decline the templates themselves, TTH and Dreamy Jazz would probably just follow the tagger around removing the speedy templates from each other's creations.) In practice, it would probably be more efficient to do what we did with Neelix and have a streamlined MFD nomination process, in which "created by TTH" is considered sufficient grounds for deletion at MFD and they default to delete unless someone can make a strong argument for keep. MFD is less gameable and also gives a space for people to defend them in those rare cases where they're actually worth keeping. (Every time I look, I find that the flood of inane and pointless TTH portals has spread further than I thought; shipping containers portal, anyone?) ‑ Iridescent 08:26, 3 March 2019 (UTC)
    Dreamy Jazz seems unlikely do that, having already decided during this debate to stop donating their time to Wikipedia. Certes (talk) 18:06, 3 March 2019 (UTC)
  • Comment – Another option would be to move these to draft space. The templates and lua modules could be modified so that the portals render right in that namespace (I wish I would have thought of this before). Being in draft space would give time to fix their various problems (keeping in mind that micro-scope is not fixable), and identify the ones worth keeping. I would agree not to move any of them personally, and would propose/request such moves after the new creation criteria guidelines for portals are settled upon. I would also be willing to tag those that did not meet those guidelines with CSD (as creator), saving Legacypac the trouble of nominating them at MfD (he mentioned somewhere that he thought I should help clean up this "mess"). Another benefit of this strategy is that if any of them sit in draft space too long without further development, they automatically become subject to deletion per the draft space guidelines, and those that reach that age without any edits can be deleted en masse without time-consuming effort-wasting MfD discussions. This course of action would of course need the participation of some lua programmers to add the necessary functionality to the modules, which would be a good upgrade for those, to allow for portal drafts to be created in the future.    — The Transhumanist   09:15, 3 March 2019 (UTC)
P.S. @Iridescent and Legacypac: (pinging)    — The Transhumanist   09:28, 3 March 2019 (UTC)
  • Absolutely not. The problem is that hundreds of portals on obscure topics makes an unmaintainable mess. Passing it to another namespace does not solve the problem which is that the portals are not helpful and are not maintainable. Automated creation of outlines/portals/anything must stop. Johnuniq (talk) 09:36, 3 March 2019 (UTC)
  • No. I tried moving one broken portal to Draft as a test and it broke even more stuff. Not worth the effort to modify everything for draft space and then let the same little group of editors release them willy nilly back into portal space. Since this group ignored their own Wikipedia:Portal/Guidelines "portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers." why should anyone trust them to follow stricter guidelines? Legacypac (talk) 09:57, 3 March 2019 (UTC)
  • Definitely not. What possible benefit would there be to cluttering up another namespace with ≈5000 pages that will never serve any useful purpose? If you want to goof around with wikicode, nobody's stopping you installing your own copy of Mediawiki; we're not your personal test site. ‑ Iridescent 15:38, 3 March 2019 (UTC)
  • As a general rule, Portal pages should not be draftified. In fact, we should not usually move anything not designed to be an article to draft space. Draft portals should be in portal space, just like draft books should be in book space and draft templates in template space (pages with subpages are a pain to move, and many namespaces have special features that suggest keeping drafts in the same space if possible). If a portal is not ready for viewing by the general public, tag it with a relevant maintenance template and make sure it is not linked to from mainspace or from other portal pages.
  • In the case at hand, TT's mass created portals do not seem like they will all be soon made ready for wider consumption, so deleting them seems the better option. —Kusma (t·c) 20:15, 3 March 2019 (UTC)
  • How is this the "only way" to be "sure"? What about actually viewing the portals themselves, as opposed to mass deleting them all sight unseen? North America1000 03:08, 26 March 2019 (UTC)
  • Could you provide any evidence that all of the portals are "broken"? Many of them that I have viewed and used are fully functional, and not broken at all. North America1000 03:09, 26 March 2019 (UTC)
  • Support, too many, too quickly, not enough thought went into their creation. Nuke these, revert other portals that were better before TTH "restarted" them. Automation should help with portal maintenance, not replace portal maintenance or move the maintenance burden to navboxes or other places. —Kusma (t·c) 14:57, 3 March 2019 (UTC)
  • Support, sensible and fair way to deal with these. Johnbod (talk) 16:53, 3 March 2019 (UTC)
  • Support: MFD could never handle the overwhelming amount of unnecessary and unsustainable portals, considering the magnitude of TTH's portal creation entering the thousands. –eggofreasontalk 20:12, 3 March 2019 (UTC)
  • Support nuking. Beyond My Ken (talk) 20:30, 3 March 2019 (UTC)
  • Transcluded to Wikipedia talk:Criteria for speedy deletion. {{3x|p}}ery (talk) 20:31, 3 March 2019 (UTC)
  • Support mass creation of portals on these topics isn't appropriate without wider discussion, and the automated/semi-automated method used to create them doesn't produce high quality output. Portal:Sierra County, California, for example, is about a county with a population of 3,240, and consists of the lead of the main article, a few random contextless images grabbed from that article (mostly maps or logos) and portal boilerplate. Cleaning these up will require a temporary speedy deletion criterion, I don't think MfD could handle the load. Hut 8.5 22:25, 3 March 2019 (UTC)
  • Support as proposer. I had already suggested deferring, but am satisfied that it is going ahead to mass-delete. I will add that, after a consensus is reached on whether and how to use portals, any that were deleted and are needed are available at Requests for Undeletion. Robert McClenon (talk) 01:01, 4 March 2019 (UTC)
  • This mass page creation went against WP:MEATBOT and at least the spirit of WP:MASSCREATION if not the letter. An appropriate remedy for automated script and semi-automated creation is speedy deletion. Did you know they were driving for 10,000 portals at a rapid pace? It's here [1] Legacypac (talk) 04:44, 4 March 2019 (UTC)
  • Oppose any and all notions of creating new CSD criteria at any drama board. Discussions here are too rushed, too emotive, too reactionary. Use WT:CSD. Consider using a WT:CSD subpage RfC. Do not attempt to mandate the detail of policy from a drama board. --SmokeyJoe (talk) 04:52, 4 March 2019 (UTC) Transclusion is not good enough. The discussion needs to be searchable from WT:CSD, and the specifics of any and all new criteria need to address the Criteria for a new CSD criterion. --SmokeyJoe (talk) 04:55, 4 March 2019 (UTC)
Many editors at the Village Pump discussion, the Tban discussion above, and at MfDs also supported this. We do not need to fragment this discussion further. Legacypac (talk) 05:12, 4 March 2019 (UTC)
Proposal 1 will make this Proposal 4 moot. This Proposal 4 is not a proper CSD implementation. --SmokeyJoe (talk) 05:41, 4 March 2019 (UTC)
@SmokeyJoe: Proposal 1 is about stopping TTH from creating new portals. Proposal 4 is about deleting those he created in the last couple of months. How is P1 going to make P4 moot? —Kusma (t·c) 10:19, 4 March 2019 (UTC)
List them all in an MfD, if they must all be deleted. A CSD that enables self appointed decision makes for which should go and which might be ok, is inferior to MfD. MfD can handle a list of pages. —SmokeyJoe (talk) 11:24, 4 March 2019 (UTC)
If you want them all at MfD stop objecting to the listing of specific Portals at MfD. Legacypac (talk) 01:34, 11 March 2019 (UTC)
No. Some of the Portals I would support for deletion, and others definitely no. This makes the proposal for a CSD invalid. It fails the CSD new criterion criteria. The proposal is neither Objective or Uncontestable. It would pick up a lot of portals that should not be deleted. --SmokeyJoe (talk) 01:44, 11 March 2019 (UTC)
  • Support. No care at all went into these portals, they are mindless creations with loads of errors and little actual benefit for our readers. I would also support the restoration of all pre-existing portals to the pre-transhumanist version, the new "single page" version may require less maintenance, but is way too often clearly inferior (see e.g. this, which is more like vandalism than actual improvement, and has been reversed since). Fram (talk) 10:31, 4 March 2019 (UTC)
  • Comment. Anyone restoring old multi-subpage portals should bear in mind that they will require maintenance. If there is no-one willing to maintain them, they, too are likely to be MfDed. No old-style portal with a willing and active maintainer has been converted as far as I know, so I suggest that anyone restoring them should be willing to maintain them. · · · Peter Southwood (talk): 16:47, 4 March 2019 (UTC)
    • No. Converting an unmaintained but well-designed portal into an unmaintained semi-automated worse portal is not the way forward. Any claims that the new portals are maintained or don't need maintaining is false, as the many problematic new portals demonstrate. Fram (talk) 17:00, 4 March 2019 (UTC)
    • Portal:Germany was converted (more than once) although it has maintainers. To make sure your portal isn't "improved", you need to put a specific template on the page, which isn't very obvious. There are old-style multi page portals that require only minimal maintenance, and where the conversion removed specific features. All those should be reverted, also to protect the subpages from overzealous deleters (the worst is deleting the /box-footer subpages; this breaks all old revisions by removing a necessary closing div). —Kusma (t·c) 17:21, 4 March 2019 (UTC)
  • Oppose A mass-deletion of the new generation portals. Listing them at MfD will be sufficient for any that do not meet the criteria laid out in the portal guidelines (which are still under discussion). It makes little sense to remove the whole batch because some of them are problematic. They would need to be properly triaged to ensure the good ones are not caught in the process. I would of course, help with said triage. We're not trying to create more work for the community, just preserve good content. — AfroThundr (u · t · c) 23:47, 4 March 2019 (UTC)
  • Comment - You created more work for the community by creating thousands of portals, some of which do not work, and with no intention to maintain them. I see no evidence that this effort created good content that needs to be preserved. Robert McClenon (talk) 04:17, 5 March 2019 (UTC)
There is no new content in the automated portals, it's all poorly repackaged bits of existing content. Legacypac (talk) 04:40, 5 March 2019 (UTC)
All portals, old or new, good or bad, manual or automated, repackage existing content. That's their job. New content belongs in articles. Certes (talk) 11:20, 5 March 2019 (UTC)
  • Strong oppose per wumbolo below: criterion P2 already covers a number of these, the rest should be discussed. I still stand by my original comment which follows this addition. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 22:37, 13 March 2019 (UTC) Original comment: Weak oppose on principle. CSD is a necessary evil, and I don't think we should be hasty to add another criterion that skips our usual consensus process. I'm fine with nuking these portals and not opposed to deleting them, any diamonds in the rough will prove their worth by being created again, but I would prefer one big MfD with the rationale "created by The Transhumanist" which allows proper determination of consensus and gives those who want to spend their time triaging a chance to do so. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 08:03, 5 March 2019 (UTC)
Building multipage MfDs like Wikipedia:Miscellany for deletion/Portals for Portland, Oregon neighborhoods is time consuming and tedious. A temporary CSD is rhe way to go. Consensus against this mess of new portals has already been established at VP, AN and in the test MfDs. Legacypac (talk) 17:20, 5 March 2019 (UTC)
  • Support due to the massive amount of time it would take to put the ~4500 portals through MfD. MfD has been swamped with portal deletion requests from some time ago, and I can't see all this stuff removed via MfD in the foreseeable future (as someone said earlier, there is still a lot of Outlines left over from one of TTH's previous projects, so who knows how long it would take for MfD to delete all of this). This CSD X3 would streamline the process, and it would probably only take a few days to a week. It would help, as also mentioned earlier, to extend the criterion to the other users involved in the mass creation of these portals. Rlin8 (··📧) 03:31, 6 March 2019 (UTC)
    • MfD has never had an issue to nominations of list of pages. 4500 separate MfD nominations would be absurd, but a list would be OK. If each is new, and has a single author, notifications of the author will be trivial. A CSD proposal shortcuts a discussion of the merits of the new portals, and pre-supposes deletion to be necessary, contrary to deletion policy. --SmokeyJoe (talk) 04:01, 6 March 2019 (UTC)
TTH demands we place notification on every portal. We can skip notifying him, but building even 20 page MfD's is very time consuming. How do you propose to discuss 4500 or even 100 assorted portals at a time? These took 3 min to make - but far more than 3 min to list, tag, discuss and vote, then delete - when you add up all the time required from various editors and Admins. The test MfDs are sufficent and the very strong opposition to this automated portal project justifies this temporary CSD. Legacypac (talk) 04:16, 6 March 2019 (UTC)
"TTH demands we place notification on every portal"? Legacypac, I have missed that post by him. If he did that, it needs to be repudiated. If these are new pages, and he is the only author, it is sufficient to notify him once. If all 4500 are essentially variations on the same thing, as long as the full set is defined, and browsable, we can discuss them all together at MfD. --SmokeyJoe (talk) 05:34, 6 March 2019 (UTC)
User:SmokeyJoe during the Portland Oregon neighborhood MFD I specifically said I was not tagging all the related portals but he insisted I tag here [2] I could not get support in the section above to relax the MfD tagging because others wanted this CSD. During the Delete Portals RFC TTH went all out insisting every portal including the community portal be tagged for deletion - then he did it himself. That brought in all kinds of casual infrequent editors who were mostly against deleting the community portal. (Even though that was Pretty much pulled out of consideration for deletion before the tagging project). That massive tagging derailed the deletion RFC. By making cleanup as hard as possible TTH is making a lot of people want to nuke everything. Legacypac (talk) 06:11, 6 March 2019 (UTC)
Legacypac's analysis is erroneous and misleading. The WP:ENDPORTALS RFC was a deletion discussion, and posting a notice on each page up for deletion is required by deletion policy. Note that the Community Portal was only mentioned twice. A portal that was the basis for about 50 oppose votes was the Current Events portal. Neither the Community Portal nor the Current Events portal were exempted in the proposal at any time. If you didn't count those, that left the count at about 150 in support of eliminating portals to about 250 against.    — The Transhumanist   07:25, 6 March 2019 (UTC)
@SmokeyJoe: (edit conflict) See the top of this section for the referred to statement, which is not exactly as he quoted. A notice posted at the top of the portals slated by this proposal would be appropriate. Legacypac has been posting notice for his multi-page nominations using the {{mfd}} template, which auto-generates a link to an mfd page of the same title as the page the template is posted on. Rather than following the template's instructions for multiple pages, he's been creating an MfD page for each, and redirecting them to the combined mfd. Then a bot automatically notifies the creator of each page (me), swamping my user talk page with redundant notifications. Thus, Legacypac believes he'll have to create thousands of mfd redirect pages, and that I somehow want 3500+ notifications on my talk page.    — The Transhumanist   07:10, 6 March 2019 (UTC)
You want us to manually tag pages for deletion that you used an automated script to create? You flooded Wikipedia with useless pages in violation of WP:MEATBOT but you are worried about having to clean up your talkpage notices? Just create an archiving system for your talkpage like we did for User:Neelix's talkpage. If you don't want notices you could start tagging pages that fail your own guidelines with "delete by author request" instead of commenting on how we will do the cleanup. Legacypac (talk) 08:37, 6 March 2019 (UTC)
TTH, if you don't want so many deletion notices on your talk page, then remember in future not to create thousands of spam pages. Please help with the cleanup, rather than complaining about it.
@Legacypac: good work MFDing the spam, but it does seem that you are using a somewhat inefficient approach to tagging. Have you tried asking at WP:BOTREQ for help? In the right hands, tools such as AWB make fast work of XfD tagging. --BrownHairedGirl (talk) • (contribs) 12:21, 15 March 2019 (UTC)
  • Support whatever course of action that will result in every portal created in this manner being deleted with the minimal of time and effort required. TTH has set up his automated tool, created a massive mess, and left it unattended for others to sort out. It should take less time to clean up this mess than it did to make it, not more. Nuke the lot and if there is anything of value lost then TTH can manually request pages to be restored one at a time at DRV. Fish+Karate 11:19, 6 March 2019 (UTC)
  • Support per Fish and karate. RGloucester 14:20, 6 March 2019 (UTC)
  • Strong oppose as written. I could support something that explicitly excluded portals which are in use and/or are being developed, but the current proposal to indiscriminately delete everything, including active portals, unless the admin chooses to notify any editors and the ones notified happen to be online in a narrow time frame is significantly overly broad. Thryduulf (talk) 01:54, 7 March 2019 (UTC)
  • Support Not that portals are that bad, but I don't think we need portals on smaller subjects. (Portal:Spaghetti when we already have Portal:Pasta? Portal:Nick Jr., anyone?) Some might be worth keeping, but a lot are unneeded and unmaintainable. At least it's not a Neelix case. SemiHypercube 16:57, 8 March 2019 (UTC)
    • @SemiHypercube: "Some might be worth keeping" is actually an argument against this proposal. Thryduulf (talk) 12:08, 11 March 2019 (UTC)
      • @Thryduulf: Kind of, but that might be a reason not to just mass delete all at once. In the Neelix case there were some redirects that were actually useful, so a separate CSD criterion was used to keep some redirects at the admins' discretion, so this might be a similar case (before you say that contradicts my "it's not a Neelix case" statement, I meant that in terms of what the redirects were about) SemiHypercube 12:23, 11 March 2019 (UTC)
      • It violates points 1 and 2 of the requirements for CSD criteria: objectivity and unconestability. Unless all the portals covered should be speedily deleted then none of them should be. If you only want to delete some of them then you should be opposing this criterion (just like you should have opposed the subjective Neelix criterion). Thryduulf (talk) 12:34, 11 March 2019 (UTC)

*Support Only realistic way to deal with these. Johnbod (talk) 01:57, 11 March 2019 (UTC) Duplicate !vote struck. GoldenRing (talk) 10:16, 4 April 2019 (UTC)

  • Request the posting of a notice at the top of each of the pages being nominated here for mass deletion, as required by the Deletion Policy. This proposal is currently a gross violation of the deletion policy because it is a discussion to delete 3500+ pages, that have been created over the span of a year, that are presently being viewed hundreds of thousands of times per month (projected to millions of times over the coming year) by readers of Wikipedia. The proposal for mass deletion has been made without the required notice being posted at the top of the pages to be deleted. This is being decided by a handful of editors unbeknownst to the wider community, namely, the readership of the portals to be deleted. It may be that those reading such notices would decide that the portals should be deleted, but the point here is that you are denying them the opportunity to participate in the deletion discussion as required by the deletion policy.    — The Transhumanist   21:12, 11 March 2019 (UTC)
Request you stop wasting people's fucking time. Only in death does duty end (talk) 21:41, 11 March 2019 (UTC)
  • He switched back to Outlines Special:Contributions/The_Transhumanist which are another unpopular plague for Wikipedia. The assertion that hundreds of thousands of readers a month are looking at his 3500 portals is fanciful at best and not supported by readership stats. Legacypac (talk) 21:58, 11 March 2019 (UTC)
Support opposing anything TTH says from now on. Per OiD. ——SerialNumber54129 13:30, 12 March 2019 (UTC)
Strong oppose taking ad hominem arguments into consideration. Thryduulf (talk) 13:49, 12 March 2019 (UTC)
Oppose WP:BLUDGEONING. ——SerialNumber54129 15:48, 18 March 2019 (UTC)
  • @Legacypac, technically he's probably telling the truth. Even obvious drivel like Portal:Coconuts averages around five views per day, thanks to webcrawlers and people who have the articles watchlisted and are wondering "what's this mystery link that's just been spammed onto the article I wrote?"; multiply that by 3500 and you have 500,000 pageviews per month right there. ‑ Iridescent 22:52, 11 March 2019 (UTC)
  • Comment Neelix created about 50,000 redirects, which were reviewed by the community. The number of portals is an order of magnitude smaller. If X3 is to be introduced, it should involve a similar review process. We should certainly delete portals which have too narrow a scope or are of poor quality and cannot be improved. However, systematic deletion of all portals which qualify for consideration, purely on an ad hominem argument, would be as wrong as semi-automatic creation. Certes (talk) 10:51, 12 March 2019 (UTC)
Absolutely not. Look at the rate these were created [3] sometimes several dozen an hour, and sometimes an average of 12 seconds each. If so little thought went into creation, why make deletion so difficult? The Neelix cleanup took far too long (I was a big part of it) and we deleted the vast majority of those redirects anyway the extra hard way. As far as I could see the editors who insisted we review everything did none of the reviewing. Also, these were created in violation of WP:MEATBOT which is a blockable or at least sanctionable offense Legacypac (talk) 11:04, 12 March 2019 (UTC)
Two wrongs do not make a right - it is much more important that we get the cleanup right than it happens quickly. Whether or not TTH is blocked or otherwise sanctioned is completely irrelevant. While many (maybe even most) of the created portals should be deleted not all of them should be, and this needs human review: see requirement 2 for new CSD criteria at the top of WT:CSD. Thryduulf (talk) 12:07, 12 March 2019 (UTC)
@Thryduulf, Certes, SmokeyJoe, and Legacypac: Concerning the rate, Legacypac's observation is not accurate. What the edits he is citing do not show, is the method by which the pages were created: they were created in batches, in tabs. Before saving, all the pages/tabs were inspected. For the pages that did not pass muster, such as those that displayed errors (this did not catch all errors, because lua errors can be intermittent or turn up later due to an edit in source material being transcluded), the tabs for those were closed. In a batch of 50, 20 or 30 might survive the cull (though batch sizes varied). Some tabs got additional edits in addition to inspection, to fix errors or remove the sections the errors were in, or further development. After all the tabs in a batch were inspected and the bad ones culled, the remaining ones were saved. That's why the edits' time stamps are so close together. If you look more closely, you'll see the time gap is between the batches rather than the individual page saves. Therefore, WP:MEATBOT was not violated.    — The Transhumanist   18:55, 12 March 2019 (UTC)
He claims [4] he created 500 portals in 500 to 1000 minutes. and is using a script Wikipedia:Miscellany_for_deletion#User:The_Transhumanist/QuickPortal.js If this is not MEATBOT we should refind MEATBOT as meaningless. Legacypac (talk) 19:07, 12 March 2019 (UTC)
A minute or two per portal of the new design sounds about right. Note that the script doesn't save pages. It puts them into preview mode, so that the editor can review them and work on them further before clicking on save.    — The Transhumanist   19:39, 12 March 2019 (UTC)
@Legacypac and The Transhumanist: As I said above, the method of creation is irrelevant to this proposal, as is what (if any) sanction is appropriate. Likewise discussions of WP:MEATBOT don't affect this at all. What matters is only that these pages exist but some of them should not, this proposal needs to be rejected or modified such that it deletes only those that need deleting without also deleting those that do not. Thryduulf (talk) 20:42, 12 March 2019 (UTC)
  • Procedural note I have advertised this discussion at WP:VPP and would encourage others to add links where they think interested editors might see. I think this should remain open for 30 days, as it is quite a significant policy change. GoldenRing (talk) 09:24, 13 March 2019 (UTC)
  • Support now that the MfDs (here, here, here, here, here, here, here, here, here, here and here) are closing with strong consensus around delete, it is clear this is the fastest path to improving the encyclopedia (which is what we are here for, remember?) Any argument that 3,500 more portals have to go through MfD is strictly throwing sand in the gears. It is going to be enough manual labor pulling the links to the deleted portals from all the templates and pages they have been added to. UnitedStatesian (talk) 15:15, 13 March 2019 (UTC)
    • That shows that a speedy deletion criterion is possibly warranted for some, but several comments on those discussions - including your own at Wikipedia:Miscellany for deletion/Portal:Spaghetti - indicate that this proposed criterion is too broad. Thryduulf (talk) 15:33, 13 March 2019 (UTC)
      • You misunderstand my comment at that MfD: I strongly support that portal's deletion and all the others that would be covered by this proposed criterion. UnitedStatesian (talk) 15:37, 13 March 2019 (UTC)
        • You supported the deletion of Portal:Spaghetti because the topic was covered by Portal:Pasta, even though Portal:Pasta would be deleted under this criterion? That's rather disingenuous at best and very significantly and unnecessary disruptive at worst. Portal:Pasta is an example of a portal that should not be deleted without discussion. Thryduulf (talk) 16:00, 13 March 2019 (UTC)
          • Again, you misunderstand my reasoning: I was specifically pointing out to another editor that the existence of Portal:Pasta could NOT be a reason to delete Portal:Spaghetti, since in my opinion Portal:Pasta would likely also be deleted. Instead, I think the current Wikipedia:Portal/Guidelines provide ample OTHER reasons for deleting both portals (and many, many others, of course). Hope that clarifies. UnitedStatesian (talk) 17:55, 13 March 2019 (UTC)
  • Strong oppose and keep all. WP:P2 covers unnecessary portals, and there is no rationale presented other than WP:IDLI to delete a large proportion of all of them, which were all kept after a RfC in 2018. The next time content policies are created at AN by the cabal of admins, I am retiring from Wikipedia. wumbolo ^^^ 16:40, 13 March 2019 (UTC)
    @Wumbolo: Well, if it came to that, take it to WP:RFARB first. Given the past history of WP:FAITACCOMPLI and WP:LOCALCONSENSUS extremism (i.e., WP:FALSECONSENSUS) cases, I have little doubt that ArbCom would agree to take a case about a gaggle of anti-portal people WP:GAMING the consensus-formation process by inventing sweeping policy changes out of their butts in a venue few content editors pay attention to and which is clearly out-of-scope for such a decision, even if it somehow had sufficiently broad input (e.g., via WP:CENT). I'm skeptical any alleged consensus is going to come out of this discussion, anyway.  — SMcCandlish ¢ 😼  17:33, 14 March 2019 (UTC)
  • Support This is a repeat of the Neelix situation. ―Susmuffin Talk 00:01, 14 March 2019 (UTC)
    • @Susmuffin: The situation has similarities, but the proposed criterion is not comparable. Criterion X1 applied only to redirects created by Neelix that the reviewing administrator reasonably believed would be snow deleted if discussed at RfD (i.e. they had to evaluate each redirect), this criterion would apply to every portal created by TTH in the timeframe without any other conditions and without the need for anyone to even look at anything other than the date of creation. Thryduulf (talk) 00:13, 14 March 2019 (UTC)
      • Honestly, there are far too many portals to be deleted through the usual channels. However, an quick evaluation would be reasonable, provided we keep the portal system itself. ―Susmuffin Talk 00:24, 14 March 2019 (UTC)
Unlike Neelix who created some reasonable redirects along the way, these autogenerated portals are of uniformly low quality. The community has looked at representive samples across a variety of subject areas at MFD and the community has already deleted 143 of the 143 portals nominated at closed MfDs. The yet to be closed MfDs are headed to increasing that number. No one has suggested any alternative deletion criteria for X3. Legacypac (talk) 00:45, 14 March 2019 (UTC)
That nobody has suggested an alternative is irrelevant - it's not up to those who oppose this proposal to fix it, and those who support it are by-and-large ignoring the objections. The MfDs have been selected as a representative sample of those that, after review, are not worth keeping and have been reviewed by MfD participants. This does not demonstrate that deletion without review is appropriate - indeed quite the opposite. Remember there is no deadline, it is significantly more important that we get it right than we do things quickly. Thryduulf (talk) 09:59, 14 March 2019 (UTC)
Not particularly similar to the redirect situation that occurred; portals are vastly different in nature and composition from simple redirects. North America1000 03:16, 26 March 2019 (UTC)
  • Oppose as unwarranted and dangerous (and circular reasoning). First, we do not modify CSD without a strong community (not admins' star chamber) consensus that an entire class of material is not just categorically unwanted but so unwanted that it should be deleted on sight without any further consideration. It's our most dangerous policy, and a change like this to it should be an RfC matter at WP:VPPOL. In theory, it could be at WT:CSD, except there is not yet any establishment of a consensus against these portals, and VPPOL is where that would get hashed out, since it's a project-wide question of content presentation and navigation (and maintenance, and whether tools can permissibly substitute for some manual maintenance, and ...). The cart is ahead of the horse here; we can't have a speedy deletion criterion without already having a deletion criterion to begin with. I strongly agree with SmokeyJoe: "Oppose any and all notions of creating new CSD criteria at any drama board. Discussions here are too rushed, too emotive, too reactionary."  — SMcCandlish ¢ 😼  17:05, 14 March 2019 (UTC)
  • OpposeWP:P2 covers problematic portals just fine. A concerning issue here is that some users herein appear to simply not like portals in general, and so there are several arguments above for mass deletion as per this "I don't like it" rationale. Mass deletion should be a last step, not a first step, and portals should be considered on a case-by-case basis. North America1000 22:22, 14 March 2019 (UTC)
You created some with the same tools. One or two of your creations are now at MfD which is why you are now engaging against this solution. We will consider each of your creations at MfD. Legacypac (talk) 02:34, 15 March 2019 (UTC)
My !vote here is based upon my view of the matter at hand, and as such, it stands. Period. Regarding my portal creations, so what? You come across as having a penchant for scolding content creators on Wikipedia if you don't like the medium that is used. Please consider refraining from doing so, as it is unnecessary, and patronizing. North America1000 01:12, 16 March 2019 (UTC)
  • @Northamerica1000: I agree - for example, I actually welcome the creation of Portal:Economics because I think econ should be established as distinct from business as in Portal:Business and economics. Qzekrom 💬 theythem 02:20, 18 March 2019 (UTC)
  • Oppose - this CSD seems have to no more objective criteria than "shoot unless someone defends it". For this to be justified, they'd have to explain how no-one reacting within 24 hours was sufficient reasoning. As far as the initial proposal included, it didn't contain any acceptable objective criteria for something warranting deletion on quality grounds. Far worse, it didn't contain suitable justification (whether popularity/quality) for these portals to impose such a major hindrance to Wikipedia as to warrant a process with as few eyes (per consideration) as CSD. The nominator might have had more luck with a PortalPROD mechanism. Nosebagbear (talk) 23:09, 14 March 2019 (UTC)
This CSD exactly meets each criteria for CSD's at the WP:CSD page. It is clear. It is easy to decide if the page meets the CSD. We ran 145 of these portals through MfD already and none survived. Numerous editors suggested this CSD in the Village Pump discussion. These mass created portals universally have the same flaws. Therefore this oppose rational is flawed. Legacypac (talk) 02:34, 15 March 2019 (UTC)
  • Support: will allow to quickly manage the auto-created portals of zero utility. --K.e.coffman (talk) 02:23, 15 March 2019 (UTC)
  • Support enthusiastically. Taking all these portals through MFD would be a massive drain on community resources. TTH created these portals at sustained speeds of up to 40 per hour, so even the time taken to apply a CSD tag and assess it 24 hours later will require more editorial time than TTH took to create them. --BrownHairedGirl (talk) • (contribs) 07:23, 15 March 2019 (UTC)
  • Strong oppose - There are good quality portals that will be excluded, few maybe, but deserve to remain. For example Portal: Cities, Portal: Architecture Portal:Sculpture.Guilherme Burn (talk) 11:40, 15 March 2019 (UTC)
    • @Guilherme Burn, maybe those are worth keeping. Or maybe not. But even if they are good, they are not worth the price of the community committing huge amounts of time to individually debating every one of the thousands of useless portals which members of the portal project have spewed out over the last year (often as drive by creations, and which project members have then piled into MFDs to keep.
If the Portals Project had exercised discretion so far, then we would be in a very different place. But it's utterly outraegous to ask the community to devote more time to assessing this spam than the Portal Project put into creating them. --BrownHairedGirl (talk) • (contribs) 12:10, 15 March 2019 (UTC)
Could these portals be marked to be spared?Guilherme Burn (talk) 13:03, 15 March 2019 (UTC)
@Guilherme Burn: not according to the proposal as written. The only chance of saving is if an admin chooses to notify and wait 24 hours and somebody objects within those 24 hours and someone spots that CSD has been declined previously if it gets renominated. Thryduulf (talk) 14:01, 15 March 2019 (UTC)
@Guilherme Burn: Portal:Cities is totally moribund and unread, and has never had a single participant. Portal:Architecture dates from 2005 and wasn't created by TTH or this tag-team, so wouldn't be deleted regardless (although I imagine the enormous wall of pointless links which TTH's bot dumped onto the page a couple of months ago would be reverted). ‑ Iridescent 14:08, 15 March 2019 (UTC)
@Iridescent and BrownHairedGirl:One portal that does not meet Mfd criteria is enough for me to keep my opinion. Portal:Cities Although poor visualized is an important and good quality portal and the Portal:Sculpture (erroneously I quoted another portal) as well.Guilherme Burn (talk) 13:20, 20 March 2019 (UTC)
@Guilherme Burn: please can you clarify that statement that One portal that does not meet Mfd criteria is enough for me to keep.
Are you saying that you are willing to personally scrutinise a few thousand drive-by Portals at MfD in order to find the one which should be kept? Or do you want others to do that work?
TTH as made it very clear that these portals took on average between one and two minutes each to create ([5] Have you tried creating 500 portals? It is rather repetitious/tedious/time-consuming (from 500 to 1000 minutes)). So many multiples of that-one-to-two minutes per portal do you think it is fair to ask the community to spend scrutinisng them? And how much of that time are you prepared to give? --BrownHairedGirl (talk) • (contribs) 14:12, 20 March 2019 (UTC)
So many multiples of that-one-to-two minutes per portal do you think it is fair to ask the community to spend scrutinisng them?Yes. The community also failed to set criteria for creating portals. What is the difference of Portal: Lady Gaga to Portal: ABBA? For me both should be excluded. If the community not had problems to create a portal for a unique singer, why now have problems with someone who has decided to create portals for lot of singers? And to be honest I do not think so much work like that, Mfd can be executed in blocks excluding several portals at the same time.Guilherme Burn (talk) 17:11, 20 March 2019 (UTC)
  • Oppose per SmokeyJoe et al. Completely unnecessary to override already existing procedure. Paine Ellsworth, ed.  put'r there  17:12, 15 March 2019 (UTC)
    • @Paine Ellsworth: the administrative work of trawling through several thousand drive-by-created micro-portals is huge. Cleaning up this flood of portalspam through MFD requires a huge amount of editorial time, vastly more than was involved in creating the spam.
If you think that existing procedure is fine, why aren't you devoting large hunks of your time to doing the cleanup by the laborious procedure you defend? --BrownHairedGirl (talk) • (contribs) 02:33, 16 March 2019 (UTC)
  • Because...? I don't know, I guess I think this whole thing is rather more of a knee-jerk reaction than a brainy, measured response. Sure I've done my share of big, teejus jobs for the project and plan to continue (on my terms). I have a lot of respect for editors like yourself and TTH who've been lifting this project out of the primal soup of its beginnings even longer than I have (I went over ten in January, or was it Feb? whatever) and I'm tired of seeing good, solid editors get reamed for their work and retire, just leave or get banned. Don't think it can't happen to you, because as good as you are, neither you nor the rest of us are immune to the gang-up-on-em mentality that turns justice into vengeance 'round here. Think you should also know if you don't already that I'm about 95 farts Wikignome and 5 parts other, and it takes a lot less for us to think we're being badgered and handled. I voted correctly for me and my perceptions, and I don't expect either of us will change this unwise world one iota if you vote you and yours! WTF ever happened to forgiveness? REspectfully, Paine Ellsworth, ed.  put'r there  13:28, 16 March 2019 (UTC)
  • @Paine Ellsworth: Thank you for adding the words that I dared not write in case I was next against the wall. Certes (talk) 16:31, 16 March 2019 (UTC)
But it seems to me that the unintended effect of what you are both saying is something like "I am not making any effort to assist the cleanup of this mass portalspam, but I will take the effort to oppose measures which reduce the huge burden on those who are actually doing that necessary cleanup work".
As I say, I do not believe that is what either of you intend. But all I see from either of you is opposition to any restraint on the portalspammer, and opposition to anything which would assist the cleanup. I respect the fine principles from which you two start, but I urge you to consider the effects on the community both of not easing the cleanup burden and of continuing to describe the likes of TTH in positive terms. Look for example at my post in a thread above about the #Lack_of_good_faith_from_User:The_Transhumanist, and at Iridiscent's observation above that of TTH's previous history of spamming useless pages.
As to lifting this project out of the primal soup of its beginnings ... that's an extraordinary way to describe TTH's spamming of hundreds, if not thousands, of useless, unfinished micro-portals.   --BrownHairedGirl (talk) • (contribs) 22:53, 16 March 2019 (UTC)
I am not making any effort to assist with mass deletions, beyond !voting to delete the clearer cases. We already have enough enthusiasts working in that department. Until recently, I had been adjusting individual portals and enhancing the modules behind them to improve quality, but I slowed down when it became obvious that my contributions in that area will be deleted. Certes (talk) 00:19, 17 March 2019 (UTC)
So that's as I feared, @Certes: members of that WikiProject are leaving it to others to clean up the mess created by the WikiProject and its members.
That only reinforces my impression of a collectively irresponsible project, which doesn't restrain or even actively discourage portalspam, doesn't try to identify it, and doesn't assist in its cleanup.
That's a marked contrast with well-run projects. --BrownHairedGirl (talk) • (contribs) 02:06, 17 March 2019 (UTC)
To BHG: not a surprising perspective, possibly a hasty generalization, however that's not your worst move. Your worst move is to consider "mass deletions" of what you deem "portalspam" as better than the "mass creations" of portals. Who's really to say? As an editor mentions below, "...these portals are doing no harm so great that they can be deleted without due process." So maybe you're wrong about those mass deletions that portray some portals as WMDs instead of the harmless windows into Wikipedia that they were meant to be? No matter, at present you are part of the strong throng. If you're right, you're right. But what if you and the strong throng are wrong? May things continue to go well with you! Paine Ellsworth, ed.  put'r there  07:01, 17 March 2019 (UTC)
  • Support and also apply it to those created by Northamerica1000, who has made such useless portals as Portal:Strawberries and Portal:Waffles. Reywas92Talk 08:26, 16 March 2019 (UTC)
    • @Reywas92: Northamerica1000 has created only 70 pages in the portal namespace (excluding redirects) in the relevant timeperiod. In no conceivable scenario does that justify a speedy deletion criterion. Thryduulf (talk) 11:58, 16 March 2019 (UTC)
  • Support per F&K (whatever course of action that will result in every portal created in this manner being deleted with the minimal of time and effort required) and SN (nuke from orbit). I'll be honest I don't know enough to know whether it should be a X3 or a P2 or a single MfD list with 4,500 entries... but it should not need to involve manually tagging pages that were created by a bot or otherwise spending any real time figuring out which should be kept and which should not be kept. Delete them all. If editors feel like this portal or that portal should be kept, let them make the case for undeletion afterwards which can be examined on a case-by-case basis. (If that process is followed, it goes without saying that the portal creator should be banned from making any such undeletion requests.) Levivich 17:25, 16 March 2019 (UTC)
    How are we supposed to work out what is worth undeleting, short of downloading all portals in advance lest they be deleted? Certes (talk)
    If an editor is not aware of a portal existing, then that editor shouldn't be asking for it to be kept. If there are particular portals that editors know they want saved, then they should have an opportunity to request that it be saved. But there should be no one-by-one examination of thousands and thousands of portals created by one user using semi-automatic methods. Levivich 19:39, 16 March 2019 (UTC)
    Kill them all and let God sort them out is very much not the way Wikipedia works and is very much not the way it should work. Why should the review be restricted to administrators (as your proposal would require)? Why is it preferable to significantly harm the encyclopaedia by deleting good portals than to do the job properly and delete only those that actually need deleting (which are doing significantly less harm by existing than deleting good ones would cause)? Thryduulf (talk) 18:06, 16 March 2019 (UTC)
    So let me create several thousand pages semi-automatically, and then I'll put it to you to go through them one by one and tell me which should be deleted and why? I don't think that's how it should work. It should work in reverse. The default should be delete them all, with some process for allowing people to request that particular portals not be deleted. BTW, when I say "all portals" I mean all portals covered by this proposal, not all portals that exist on Wikipedia. Levivich 19:39, 16 March 2019 (UTC)
    If an editor created several thousand pages semi-automatically, the correct sequence of events is to analyse a representative sample to determine whether consensus is that they are (a) all good, (b) mostly good, (c) all bad, (d) mostly bad, or (e) a mixture. If (a) then no action is necessary, if (b) then individual deletion nominations are the correct response. If (c) then a CSD criterion to remove all of them is appropriate, if (d) or (e) then a CSD affectingly only the bad ones should be explored. In this the situation is somewhere between (d) and (e) depending on your point of view, but this proposal is treating them as (c). As I've said several times, I'm not opposed to a criterion proposed (in the right place) that caught only the bad ones and allowed for objections - that is not this proposal. This situation is frequently compared to Neelix, but the proposal is very different - this one: All pages created between Time A and Time B, unless anyone objects to the optional tagging within 24 hours. Neelix: All pages created between Time A and Time B that would be snow deleted if nominated at RfD, retargetting would not lead to a useful redirect and no other editor has materially edited the redirect. Do you now understand the fundamental difference? Also remember that pages can be tagged by bot. Thryduulf (talk) 20:56, 16 March 2019 (UTC)
    Yes. We also need to clarify one important detail of the proposal: would an editor be required to look at the portal before applying CSD, or is there an assumption that everything created by this editor in that time period is automatically rubbish and does not deserve assessment? Certes (talk) 22:29, 16 March 2019 (UTC)
    If a human being didn't spend a lot of time making a page, then human beings should not spend much time deciding whether to keep it. I put it to you again: suppose tomorrow I create 5,000 new pages and ask you to go through them and decide which to keep and which to delete. That would be insane; this is a website of volunteers; my doing such a thing would be disruptive. It would make work for others. Nobody reading this thinks it would be a good idea for me to do such a thing. Yet this is what is essentially being asked of us. Insofar as I have a !vote, I !vote no. Delete them all. They are all bad. Any that are good can be recreated as easily as they were created in the first place. Letting people flag keepers in one way or another is a perfectly reasonable way to prevent the baby from being thrown out with the bathwater. But yes, my starting point is that all of them should be deleted because none of them should have been made in the first place, and they do not have content value. Some portals are the product of careful creation and extensive work, but not 5,000 or however-many automatically created by one editor. The quantum portal idea is a much better idea, anyway. Levivich 02:38, 17 March 2019 (UTC)
    I've alreadyanswered this immediately above, but as you apparently don't like the answer I'll respond again. If you create 5000 new pages in good faith (which TTH did), then the correct response is for others to go through and look at a representative sample, then gain a consensus about whether they are all bad, mostly bad, a mixture, mostly good or all good. This has been done with TTH's portals and while you may think they are all bad that is not the consensus view, especially as others have taken over some and either have improved them or are working on improving them. This means that it is important that only the bad ones are deleted meaning any proposal (such as this one) to delete all of them is overbroad and needs to be opposed. Thryduulf (talk) 10:03, 17 March 2019 (UTC)
    This statement by Thryduulf is incorrect on many levels. Who has taken over and improved any of his creations? Where is the concensus view that they are not all bad when so far zero of his creations have been kept at MfDs. Where is the proof any of this was in good faith when he admits several sections down that no one (including him) has followed WP:POG Legacypac (talk) 10:38, 17 March 2019 (UTC)
    Are you even reading the comments made by those who disagree with you because I'm not seeing evidence of it, especially when it comes to the MfDs (to reiterate, a reviewed selection of the worst pages being deleted by consensus but not unanimously in all cases does not provide evidence of the need for deletion of all of them without possibility of review). Thryduulf (talk) 16:36, 17 March 2019 (UTC)
    Thryduulf, so I spend less than 1 minute per page creating 5,000 pages; you and others spend–what, an hour, cumulatively, at least?–per page to analyze it, discuss it, vote it, close it, and delete it. I spend 5,000 minutes; the community spends 5,000 hours. With all due respect I am flabbergasted to hear such a high-ranked Wikipedian express the view that this is OK or preferred. Even with your representative sample approach, say it's 100 portals that are looked at, that's still 100 hours of labor forced upon volunteers. In my opinion, no one should be allowed to make 5,000 pages without going through something like a BAG process to seek community approval. There was once a time, years ago, when it made sense to, for example, automatically create a stub for every known city and town in the world. I believe that time has long since passed; there are not 5,000 pages that can be created automatically that we need to have that we do not already have (IMO). And as for consensus, if they're not being kept at MfD, the consensus is clear. Those portals that people maintain manually are the same ones that can be flagged as exceptions to a mass-deletion. So I feel like we're on the same page about consensus, but I'm saying the consensus to keep a particular portal can be effectuated by allowing people to flag them as exceptions to mass deletion, whereas you seem to be suggesting: let's get together and spend an hour per portal to decide if it should be kept, even though nobody spent anywhere near that time creating it in the first place. If that's where we are, we'll have to agree to disagree, because I fundamentally don't believe these portals are worth a one-by-one analysis, and I believe the representative sample approach you advocate has been done and has led to the conclusion that these are worth mass deleting with exceptions. I guess that's for a closer to make the ultimate decision about, but for my part, from uninvolved editors, I'm seeing a lot more support than oppose for mass deletion. Levivich 14:42, 17 March 2019 (UTC)
    @Levivich: If you're just going to ignore all the explanations I give in response to you (twice) and all the explanations elsewhere from me and others about why a reviewed selection of the worst being deleted (and not unanimously in all cases) is not evidence of the need for all of them to be deleted without possibility of review by others then it is clear we will never agree. Fortunately, per WP:VOLUNTEER, nobody is being forced to do anything they don't want to do - including you - and it's really disappointing that someone as experienced as you feels the need to prevent that work being done by others just because you don't want to. Perhaps between now and the time this is closed those in support of this overbroad proposal will actually choose to address the points in opposition but unless they do the only possible outcomes are no consensus or consensus against. Thryduulf (talk) 16:36, 17 March 2019 (UTC)
    Thryduulf, I heard you say: pick a representative sample and decide if they're all bad, some bad, etc. As I understand it, a representative sample has been sent to MfD with consensus to delete almost all of them, if not all of them (I'm not sure if lists I've seen are complete). Then you say that just because the sample is all-delete doesn't mean the whole category is all-delete. I infer you think the sample is not well-chosen? By TTH's admission there are like 4,500–5,000 portals, and a tiny tiny percentage of those are being manually maintained–like less than 5%. Are we on the same page about the facts so far? If so, where do you see consensus other than "delete 95% of these things"? Why can't we tag the 100 that are manually maintained and delete the remaining 4,500? I am reading what you're writing, but I am not understanding it. Levivich 16:44, 17 March 2019 (UTC)
  • Support: these portals are easy to create semi-automatedly and contain no information not found in articles so we're not losing any information from Wikipedia, which sets this apart from most other CSD criteria. An alternative proposal I would support is to expand the remit of P2 to apply to any portals with fewer than one-hundred pages under their scope (or alternatively, fewer than one-hundred notable topics if there is evidence that the portal creators and users are planning to create such topics as articles). If a topic doesn't have 100 pages on it at the bare minimum, there's absolutely no reason to focus a portal around it. Even for portals covering tens of thousands of articles, reader interest is very, very low and the current semi-automated busywork is not serving the readers. Bilorv (he/him) (talk) 19:05, 16 March 2019 (UTC)
    • @Biorv: a proposal for expansion of speedy deletion criterion P2 is being discussed currently at [[Wikipedia talk:Criteria for speedy deletion}} (which is where proposals related to speedy deletion criteria should be held, not AN), so I will refrain from explaining here why I oppose your suggestion to avoid splitting the discussion. Thryduulf (talk)
  • Support with exceptions. I support the speedy deletion of all portals auto-created in recent months as it seems excessive and unnecessary. However, those few portals which are manually maintained in good faith should be kept. Down the line we need to take another look at a notability threshold to keep a lid on portalmania. Bermicourt (talk) 22:37, 16 March 2019 (UTC)
    • If you believe there should be exceptions for portals maintained in good faith (and I agree there should be), then you should be opposing this proposal in favour of an alternative one that allows for that. Thryduulf (talk) 22:59, 16 March 2019 (UTC)
    X3 only covers the mass created automated portals started by TTH so already excludes the type of portal User:Bermicourt wants to exclude. Thryduulf is muddying the facts. Legacypac (talk) 23:08, 16 March 2019 (UTC)
  • Oppose because a) on procedural grounds this shouldn't be discussed at the AN "closed shop" and b) because these portals are doing no harm so great that they can be deleted without due process. It is not TTH's fault that the guidelines for portal creation are permissive. Triptothecottage (talk) 02:56, 17 March 2019 (UTC)
  • Comment: I have already voted here but I just wanted to provide an example of how much thought was going into the creation of these portals. Portal:Aquatic ecosystem was created by TTH on Aug 15 2018 and in classified as "Complete" despite having 4 selected images. An identical portal was created at Portal:Aquatic ecosystems by TTH on Nov 24 and is classified as "Substantial" (the portalspace equivalent of B-class). One wonders, which portal is of better quality, how was this determined, and how was this oversight not caught? — pythoncoder  (talk | contribs) 13:33, 17 March 2019 (UTC)
  • Oppose: Criteria are supposed to be uncontestable - almost all pages could be deleted under this criterion, according to consensus. Looking at the most recent 50 portals created by TTH, I see a lot of frivolous ones, but I also see Portal:Pumpkins, Portal:Woodpeckers, Portal:International trade, and Portal:World economy, all of which represent subjects with well-populated categories. And I could add at least as many that are debatable. If TTH, now under a topic ban, were to create more portals, they could be speedy deleted under WP:G4. But the pages considered here were created before the ban, so they should stand or fall on their own merits. RockMagnetist(talk) 06:05, 18 March 2019 (UTC)
    • @RockMagnetist: I think you mean WP:CSD#G5 (Creations by banned or blocked users) rather than WP:CSD#G4 (Recreation of a page that was deleted per a deletion discussion). Thryduulf (talk) 14:49, 18 March 2019 (UTC)
      • WP:CSD#G5 cannot be used here. The locus of G5 revolves around obliterating the edits of LTA's and sockpupeters and for ban-evasion in a generalized scope. << FR (mobileUndo) 15:12, 18 March 2019 (UTC)
        • G5 can be used to delete pages created in violation of a topic ban, if deletion is the best course of action. I would never use G5 on a page that was a borderline violation, but that's not relevant here (I can't think of any page creation that would be anything other than clear-cut one way or the other). It's all theoretical though as TTH hasn't created any pages in violation of his ban and I think it unlikely they will. Thryduulf (talk) 15:37, 18 March 2019 (UTC)
        • @FR30799386 and Thryduulf: My point in mentioning G4 (oops - G5!) was that it is a more appropriate standard for deleting pages based on who created them. The current proposal is too broad. RockMagnetist(talk) 16:09, 18 March 2019 (UTC)
  • Oppose I have gone over many of the portals. It seems that there are a mix of topics which are mainstream and some which should not have been created. This isn't a white or a black issue, the wheat must be carefully separated from the chaff. << FR (mobileUndo) 12:04, 18 March 2019 (UTC) !vote from sockpuppet struck. GoldenRing (talk) 10:17, 4 April 2019 (UTC)
  • FR, is there some issue with deleting them without prejudice to re-creating existing ones? These were basically made by a bot in what amounts to a single spasm, so deleting them all could be seen as a BRD reversion. The next step would be to let uninvolved editors recreate any worth keeping. Yes, that might take a while. There is no deadline and if some potentially useful portals have gone uncreated up til now, it's fine if they stay absent a little longer. (talk) 04:07, 19 March 2019 (UTC)
  • Oppose - the proposal assumes that none of the portals should have been created, and that is an incorrect assumption. Certainly the are some that perhaps should not exist, but equally there are some that definitely should, and some that need a bit of discussion to determine consensus. Speedy deletion is not the way to resolve this. WaggersTALK 16:45, 18 March 2019 (UTC)
    • No, the proposal assumes (correctly) that 95% should never have been created, and that the tiny amount of time spent on those few that might be worth keeping doesn't justify the hours needed to discuss them all at MfD. The ones that get speedy deleted and would be an acceptable portal anyway can easily be recreated if someone really wants them. No effort has gone into creating these portals (usually not even the effort of checking if the result was errorfree, never mind informative or not a duplicate of existing portals), so demanding a week-long discussion for all of them because sometimes the mindless effort created an acceptable result is putting the cart before the horse. Fram (talk) 08:28, 19 March 2019 (UTC)
    Throwing out the baby with the bathwater is not a sensible solution. Also, given WP:PAPER, could you explain why the existence of these portals is such a problem? This is nothing more than a massive exercise in punishing a user for the crime of trying to improve the encyclopaedia and getting a bit overenthusiastic. It's horrible to see and I honestly thought the Wikipedia community was better than this. WaggersTALK 11:42, 2 April 2019 (UTC)
    The existence of these portals is a problem because they add extra clutter to already link-intensive articles (the lower part of our articles has become more and more overcrowded over the years, with authority links, navboxes, links to sister projects, ...) and removing links with no or very little value makes the articles better and avoids sending readers to utterly useless pages created in a completely mindless manner without oversight or care. Deleting pages which are useless is not "punishing a user", that is a WP:OWN approach you show there which should not be taken into consideration when debating whether to keep or delete pages. Punishing the user would be blocking or banning them. Fram (talk) 12:10, 2 April 2019 (UTC)
    And that is happening (or has happened) too, so my point very much stands. Describing an editor's good faith hard work as "useless" isn't exactly conducive to a civil discussion either. Certainly some of the portals created are worthy of deletion, others are worthy of being kept. I could support a new PROD criterion, but CSD is not the right tool for this job. WaggersTALK 12:51, 3 April 2019 (UTC)
  • Oppose—CSD is for stuff where there's zero grey area. At best, this should be a specialized PROD. Gaelan 💬✏️ 14:42, 20 March 2019 (UTC)

Arbitrary break (CSD criterion X3)Edit

  • Oppose Although the vast majority may not be needed: that does not mean they should just be deleted (without oversight or consensus). The arguments for this critera seem to be centered around: 'so little work was put into them, therefore we shouldn't need to put in any work to fix it'. Why not just let them sit there then? Is there a deadline? Seeing as portals themselves are an auxiliary aide to our main focus (of writing articles) this seems unnecessary. I'm surprised that this is (at least) the second time that a Private Bill has been proposed for the cSd, I guess times have changed a bit. It seems uncollegial to respond to opposers by saying: "then you better help out with all the MfD's'. I agree with the points made by SMcCandlish and RockMagnetist among others. Crazynas t 23:54, 20 March 2019 (UTC)
    • "Why not just let them sit there then"? Have you actually looked at the pure drivel many of these portals are? Most of these portals are not an "auxiliary aid", they are random shit, bot generated without bot permission but without actual human oversight. Sending any reader to such total shit is a disgrace. The below image is how one of these portals looks right now, after it has existed for 7 months and after this discussion highlighting many problems has run for a month. Time spent discussing these (time spent looking at these) is time wasted. Any portal which people think is necessary after all can be recreated (in a much better fashion) afterwards, the speedy deletion of these doesn't restrict this. But keeping the shit an editor mass produced because their may be some less shitty pages included is doing a disservice to the people who actually wander to these portals and can only stare in dsbelief at what we show them. "'Calamba, officially the ', (Tagalog: Lungsod ng Calamba), or known simply as Calamba City is a class of the Philippines in the province of , . According to the ?, it has a population of people. " Fram (talk) 09:16, 21 March 2019 (UTC)
have you looked at all the shit that sits in the mainspace (some of it for years)? There are like 182,000 unreferenced articles live right now, but this is the hill we're choosing to die on? Crazynas t 21:57, 21 March 2019 (UTC)
Large in-line image
Thank you for identifying a problem with a small number of Philippines portals where the lead contains {{PH wikidata}}, a technique designed for use in infoboxes. I'll pass your helpful comments on to the relevant WikiProject. Certes (talk) 11:02, 21 March 2019 (UTC)
No, please pass my comment on to all people supporting these portals, but not bothering to actually look at what they propose or defend. Creating and supporting pages with such blatant problems is basically the same as vandalism. There are e.g. also quite a few portals which confront their readers with the below "selected article" (as the default selected article, not even when scrolling deeper). Or with the same image two or three times. Or... The list of problems with these portals is near endless (selected categories only consisting of one redlink? Sure...). The fact that adding a category can cause a page to look completely different and generate different errors (like in the example above) should be a major indicator that this system, used on thousands of pages, is not as foolproof and low in maintenance as is being claimed. Fram (talk) 11:36, 21 March 2019 (UTC)
Large in-line image
Thank you for your continued help in identifying portal issues. I have found and fixed three pages which had repeated "Read more" links. If you could be kind enough to reveal which portal you have depicted as "PortalShit2.png", we may also be able to fix that case and any similar ones. Certes (talk) 12:20, 21 March 2019 (UTC)
There are two very simple solutions: either support X3, and all these portals are instantly fixed. Or actually take a look at all these low maintenance, automatic portals of the future, find the many issues, and fix them. Which still won't solve the problem that many of them are utterly pointless, mindless creations of course. I've noted more than enough problems with these portals to wholeheartedly support speedy deletion, since spending any time "corecting" a portal like the Calamba one is a waste of time (as it should be deleted anyway, speedy or not). Fram (talk) 12:42, 21 March 2019 (UTC)
@Fram: You are clearly not understanding the opposition to this proposal. It is not about supporting the inclusion of poor content, it is about opposing a speedy deletion criterion that fails the criteria for new and expanded criteria and would delete content that should not be deleted in addition to content that should. Thryduulf (talk) 13:41, 21 March 2019 (UTC)
No, I often have trouyble understanding burocratic opposition which creates tons of extra work for very little actual benefit. Furthermore, I'm not convinced that this actually fails the four criteria: it is objective and nonredundant (I guess we all agree on these two?), it is frequent (in the sense that having 3K portals at MfD is quite a heavy load, it's not just one or two pages), so we are left with "Uncontestable", which doesn't mean that as soon ass someone opposes it, it becomes contested, but that "almost all pages that could be deleted using the rule, should be deleted, according to consensus.". Looking at this discussion and the MfDs, I believe this to be true. Opposing this new CSD rule "because it is contested" is circular reasoning, as you are then basically saying "it is contested because it is contested", which is obviously not a valid argument. Having a significant number of portals which fall under the X3 but should not be deleted (which doesn't equal "should never exist", only "should not exist in the current form or any older form in the page history") would be a good argument, but I haven't seen any indication of such. Fram (talk) 13:57, 21 March 2019 (UTC)
(edit conflict) Frequent is not an issue (it wouldn't be as a permanent criteria, but as a temporary one it's fine), non-redundant is not an issue for most (although a few might be caught by P2 that's not a significant proportion so not a probelm). This proposal (unlike the ones being discussed at WT:CSD) is objective as written (created by a single user within a defined time period). Uncontestable however very much is, the requirement is "It must be the case that almost all pages that could be deleted using the rule, should be deleted, according to consensus. CSD criteria should cover only situations where there is a strong precedent for deletion. Remember that a rule may be used in a way you don't expect, unless you word it carefully." It is very clear from this discussion and others around these portals that not all of them should be deleted - several have received strong objections to deletion at MfD, some are argued to be kept and others merged. "it is contested because it is contested" is exactly the point of this requirement - nobody argues in good faith against deleting copyright violations, patent nonsense, recreations, or specific types of articles that don't assert importance. There is consensus that were these to be discussed they would be unanimously deleted every time. There is no such consensus about these portals. Some, perhaps most, should be deleted but not all of them. Thryduulf (talk) 15:47, 21 March 2019 (UTC)
I am pleased to report that a recent module change should eliminate the problem where articles too short to be worth featuring occasionally appear as "Read more... Read more...". This should fix the mystery portal depicted above next time it is purged. Certes (talk) 11:26, 22 March 2019 (UTC)
User:Thryduulf your opposition to X3 is baffling. You oppose it basically because some topics where Portals were mass created using automated tools against policy may warrant portals. But none of these pages have any original content to preserve. They are mindless spam poorly repackaging existing content. Kind of a poor Wikipedia mirror effort. MFDing these has proven they are unwelcome - yet you want to force us to spend a week debating pages that the creator spent seconds to create without even checking for compliance against their own criteria or for major errors? If these deletions were actually controversial (the only one of the 4 CSD criteria you say is not followed) we would expect a significant number of the MfDs to close Keep. We might expect the creator to defend and explain, but instead the creator freely admits he ignored WP:POG. Seriously makes me doubt your competence and judgement. Admins should show better judgement then this. Legacypac (talk) 17:12, 21 March 2019 (UTC)
@Legacypac: Assuming you mean X3, then I have explained every single one of my reasons several times and you have either not listened or not understood on every single one of those occasions so I Will not waste even more of my time explaining them again. Thryduulf (talk) 17:16, 21 March 2019 (UTC)
Second Legacypac. Additionally, part of what I meant by "some might be worth keeping" is that they can be deleted, but if any were actually worthy they could be recreated, perhaps with more care and effort than this. SemiHypercube 17:19, 21 March 2019 (UTC)
  • It seems like a lot of what is objected to can be covered by a judicious use of P2, G1, and A3 (via P1) but there's probably something I'm missing. @Fram:, I'm not here to support bad content, but bad policy (and precedent) can be far more harmful to the project than 'repackaged nonsense' existing for a bit longer than some people want it to. This would have the side effect of saving the portals worth saving. Crazynas t 22:07, 21 March 2019 (UTC)
  • Oppose let's discuss deletion based on content and merit of individual portals. No need to throw the baby out with the bath water, this is not how we do things here. You're proposing deletion of many very good portals here. ɱ (talk) 15:41, 21 March 2019 (UTC)
Please identify 35 out of the 3500 (1%) that are "very good portals" so we can run them through MFD to test your statement. Also there is no baby - there is no original content at all. No work done by humans is lost with X3 deletions because they were created using an automated script that was used without BAG approval to repackage existing content. Therefore WP:PRESERVE is not an issue. If someone started creating thousands of articles called "Foo lite" that just copied Foo mindlessly we would CSD them without debate. These are just in another mainspace but they are really Foo lite. Legacypac (talk) 17:12, 21 March 2019 (UTC)
Except that's not comparable at all. The point of portals (which the community has repeatedly endorsed) is to duplicate article content and provide links to related content - which is exactly what these portals are doing. They might be doing it poorly in many cases, but that's qualitatively different to one article duplicating another. Thryduulf (talk) 18:10, 21 March 2019 (UTC)
Wouldn't it be faster to delete them all and then recreate the ones that need recreating, rather than go through them one by one to see which to keep? Because the number of "keeps" is like 5% or 10% and not 50%? (It would have to be 50% to be equal time between the two approaches.) If you're not convinced that it's 5-10% keep and not 50% keep, what sort of representative sampling process can we engage in to test the theory? Levivich 19:13, 21 March 2019 (UTC)
Yes it would be faster, but there is no deadline so it is very significantly more important to get it right than it is to do it quickly. Deleting something that doesn't need deleting is one of the most harmful things that an administrator can do - and speedily deleting it is an order of magnitude more so. As only administrators can see pages once they have been deleted, and doing so is much harder, deleting it first makes the job of finding the good portals very significantly harder. Thryduulf (talk) 21:30, 21 March 2019 (UTC)
Timing matters because this issue is being discussed in several forums at once. If the first debate to close decides to delete, the portals may be gone by the time another discussion reaches a consensus to keep them. Certes (talk) 21:48, 21 March 2019 (UTC)
  • CommentI listed The Transhumanist's portal creations, latest first, and examined the top entry on each page, i.e. every 100th portal.
Assessment of a sample of TTH's recent creations
  1. Portal:Polar exploration – decent appearance; no obvious errors. 50 excerpts with more links at the bottom. Four other images, plus plenty more in the 50 leads. Manual input: refining the search criteria for Did You Know and In the News (DYK+ITN).
  2. Portal:Nick Jr. – Lua error: No images found. (To be fair, there may have been images before a recently requested module change to suppress images without captions.) 13 excerpts. No manual input: the wikitext matches that generated by {{bpsp6}}.
  3. Portal:Alternative metal – decent appearance; no obvious errors but a narrow scope. 11 excerpts; one other image. Manual input: refining DYK+ITN.
  4. Portal:Modulation – decent but minimal portal with no obvious errors. 30 excerpts; four other images. Several manual improvements.
  5. Portal:Spanish Civil War – potentially good portal but with a couple of display errors which look fixable. 30 excerpts; 20 other images. Manual input: routine maintenance, probably of a routine technical nature rather than creative.
  6. Portal:Carl Jung – decent appearance; no obvious errors. 40+ excerpts; six other images. Routine maintenance.
  7. Portal:Reba McEntire – decent appearance; no obvious errors but a narrow scope. 40+ other excerpts; six images. Routine maintenance.
  8. Portal:Romantic music – decent appearance; no obvious errors. 40+ excerpts; two other images. Routine maintenance.
  9. Portal:Anton Chekhov – decent appearance; no obvious errors. 36 excerpts; 17 other images. Routine maintenance.
  10. Portal:Media manipulation – decent appearance; no obvious errors but a narrow scope. 40+ excerpts; no image section. Routine maintenance.
  11. Portal:Desalination – decent appearance; no obvious errors but a narrow scope. 15 excerpts; six other images. Manual input: refining DYK+ITN.
  12. Portal:Abuse – This portal has display errors which make it hard to evaluate properly. It's had plenty of manual input, possibly in attempts to fix it.
  13. Portal:Emmy Awards – decent appearance; one minor display error which looks fixable.(fixed) 50 excerpts; two other images. Routine maintenance.
  14. Portal:Shanghai cuisine – decent appearance; no obvious errors but a narrow scope. 19 excerpts; four other images. Routine maintenance.
  15. Portal:Saab Automobile – decent appearance; no obvious errors but a narrow scope. 40+ excerpts; 14 other images. Routine maintenance.
  16. Portal:High-speed rail – decent appearance; one minor display error which looks fixable.(fixed) 40+ excerpts; 30+ other images. Routine maintenance.
  17. Portal:Tetris – decent appearance; no obvious errors but a narrow scope. 30+ excerpts; two other images. Routine maintenance.
  18. Portal:Azores – decent appearance; no obvious errors but a narrow scope. 20 excerpts; 18 other images. Some manual improvements.
  19. Portal:Musical instruments – decent appearance; no obvious errors. 40+ excerpts; 13 other images. Routine maintenance.
  20. Portal:Hidalgo (state) – decent appearance; no obvious errors but a narrow scope. 11 excerpts; 16 other images. Routine maintenance.
  21. Portal:Sporting Kansas City – decent appearance; one minor display error which looks fixable;(fixed) narrow scope. 11 excerpts; 7 other images. Routine maintenance.
  22. Portal:Piciformes – decent appearance; no obvious errors but a narrow scope. 9 excerpts; one other image. Routine maintenance.
  23. Portal:Birds-of-paradise – decent appearance; no obvious errors. 50 excerpts; five other images. Some manual improvements. Currently at MfD with the rationale that woodpeckers are not a family.
  24. Portal:Coffee production – decent appearance; no obvious errors but a narrow scope. 40+ excerpts; 11 other images. Routine maintenance.
  25. Portal:Albanian diaspora – decent appearance; no obvious errors but a narrow scope. 30+ excerpts; three other images. Routine maintenance.
  26. Portal:University of Nebraska–Lincoln – decent appearance; no obvious errors but a narrow scope. 18 excerpts; eight other images. Routine maintenance. Currently at MfD with the rationale that Portal:University of Arkansas at Pine Bluff contains only two articles.
  27. Portal:University of Gothenburg – decent appearance; no obvious errors but a narrow scope. 10 excerpts; two other images. Routine maintenance.
  28. Portal:Transformers – decent appearance; no obvious errors but a narrow scope. 40+ excerpts; two other images (everything else is non-free). Some manual improvements.
  29. Portal:Boston Celtics – decent appearance; no obvious errors but a narrow scope. 40+ excerpts; 16 other images. Routine maintenance.
  30. Portal:Newbury Park, California – decent appearance; no obvious errors but a narrow scope. 16 excerpts; 34 other images. Routine maintenance.
  31. Portal:Vanessa Williams – decent appearance; no obvious errors but a narrow scope. 30+ excerpts; two other images. Routine maintenance.
  32. Portal:Bette Midler – decent appearance; no obvious errors but a narrow scope. 40 excerpts; seven other images. Routine maintenance.
  33. Portal:Ozzy Osbourne – generally decent appearance but several minor display errors;(fixed) narrow scope. 50 excerpts; 17 other images. Routine maintenance.
  34. Portal:Carnegie Mellon University – decent appearance; no obvious errors but a narrow scope. 15 excerpts; 28 other images. Routine maintenance.
  35. Portal:Milwaukee – decent appearance; no obvious errors. 15 excerpts; 47 other images. Some manual improvements. Too few excerpts but potentially good.
  36. Portal:Billings, Montana – decent appearance; no obvious errors but a narrow scope. Four excerpts; 27 other images. Some manual improvements.
  37. Portal:Empire of Japan – decent appearance; no obvious errors but a narrow scope. 40+ excerpts; 20 other images but with a couple of repeats. Routine maintenance.
  38. Portal:Cheese – decent appearance; no obvious errors. Nine excerpts; 50+ other images. Extensive manual improvements. Too few excerpts but potentially good.
It appears that most of the portals have a narrow scope and should go but a significant minority are either already of a good enough standard to keep or show sufficient potential to merit further attention. This impression is based not on cherry-picking but on a random sample. Certes (talk) 21:42, 21 March 2019 (UTC)
Thank you for this, this is a very good illustration of why this proposal is too broad - it will delete portals that clearly should not be deleted, and others that may or may not need to be deleted (e.g. I've !voted to merge several of the portals about universities). Thryduulf (talk) 21:58, 21 March 2019 (UTC)
  • Query Why don't we have a CSD for pages created by unauthorized scripts or bots? WP:BAG exists for a reason right? (And this seems to be a good example of it). Crazynas t 21:50, 21 March 2019 (UTC)
    • @Crazynas: because not all of them should be deleted, as [[user:|Certes]] analysis immediately above demonstrates perfectly. Thryduulf (talk) 21:58, 21 March 2019 (UTC)
@Thryduulf: You're missing my point. Just like we have a policy that banned users are to be reverted in all cases not because they might not make good edits (to game the system or not) but because they are a disruption to the community; so we should have a policy that pages created (or edited I suppose) by unauthorized bots are inherently not welcome, because of the potential for disruption regardless of their merit (by disruption I'm talking about this AN thread as much as the pages themselves). This is the whole reason we have a group dedicated to overseeing and helping with bots right? Crazynas t 22:12, 21 March 2019 (UTC)
No bots were involved. The pages were created using a template. One of your last page creations was a user talk page, where you welcomed a new editor using Twinkle. You did a very professional job, by applying a template which introduces the new editor with the sort of carefully considered and neatly arranged prose that we don't have time to write every time a new contributor appears. Using a template is not a valid rationale for mass deletions. Certes (talk) 22:22, 21 March 2019 (UTC)
Curious, what template did you use? I guess the difference I see is the twinkle is highly curated and subject to extensive review (as are the templates it calls). If all these pages were manually created, then what happened in the example of (what to me looks pretty much like G1) that Fram posted above? Why didn't the human that pressed the button take responsibility for that (so to speak) pile of rubbish? To clarify, Bot here covers scripts, AWB (which is 'manual'), java implementations etc. In short: "Bot policy covers the operation of all bots and automated scripts used to provide automation of Wikipedia edits, whether completely automated, higher speed, or simply assisting human editors in their own work." The policy explicitly references mass page creation as being under the purview of BAG here. Crazynas t 22:39, 21 March 2019 (UTC)
I haven't used any of these templates myself but recent portals have been created by variants on {{Basic portal start page}}. The numbered versions such as {{bpsp6}} cater for portal-specific conditions such as there being no DYKs to feature. Certes (talk) 23:07, 21 March 2019 (UTC)
@Crazynas: I was simply answering your question about why we do not speedy delete every page created by an unauthorised bot, etc - simply because not every page created by such means should be deleted. You are also mistaken about banned users - they may be reverted but they are not required to be. Certes analysis shows that some of the portals created by the script have been improved since, sometimes significantly. Thryduulf (talk) 22:46, 21 March 2019 (UTC)
@Thryduulf: Sure, and this is tangential to the proposal here (which I'm still opposing, if you noticed). In any case the thought I'm having wouldn't be applied ex post facto but it would make it explicitly clear that mass creation of pages by automated or semi-automated means without prior approval is disruptive. Crazynas t 23:02, 21 March 2019 (UTC)
  • Comment. The problem with many of these recently created template-based portals is that it is difficult or impossible to improve them. I've edited portals for over a decade but cannot work out how to change the portal code to include or exclude a particular article or image. (For articles I believe one has to change the template or mark the article as stub to exclude it; for images I believe it just harvests those from the main topic article.) Thus they are not drafts that could be further improved, they are static uneditable entities for which the only solution is to start from scratch. There is no thought to be preserved that is not equally present in the list of articles in the template/images in the root article. Espresso Addict (talk) 02:12, 22 March 2019 (UTC)
  • The key issue is that traditionally, portals are viewed as entry points to broad topic areas. However a page generated by the helper templates that draw content from an underlying navigation box is more akin to a second screen experience: it provides an X-ray view into the navigation box. It's not clear this is the experience the community wants to provide for readers visiting something labelled a portal. isaacl (talk) 20:47, 24 March 2019 (UTC)
  • the automated scripts are so easy to fool. Even if everything looks perfect when the portal is set up, as soon as someone adds an new link to a nav box (that may make sense in the nav box but not for the portal), adds an image to a page, or creates a DYK completely unrelated to the topic which includes the five letters "horse" within someone's name behind a pipe, you get random inappropriate stuff in an automated portal. The editor adjusting the nav box, adding a picture without a caption per WP:CAPTIONOBVIOUS or creating the DYK has no idea the portal is being busted. There is no edit to the portal to review so watch listing the portal does not help. You have to manually review the portal display regularly. That is before looking at lua errors. Autogenerated content is a bad idea. Forcing other editors to review your auto generated crap is wrong. Ignoring the guidelines because they are "outdated" and leaving 4500 pages that need to be checked and discussed against the guidelines by other editors is wrong. The only reasonable solution is to nuke these from orbit. Then if someone willing to follow the guidelines and use intellgently designed and applied tools want to recreate some titles, that is fine. Legacypac (talk) 21:23, 24 March 2019 (UTC)
    • Everything you say before "The only reasonable solution..." may be true but is irrelevant to this proposal as written. "Nuking them from orbit" is not the only reasonable solution, as fixing the issues so that the portals don't break is also reasonable. As is not deleting the ones that have been fixed so that the errors you talk about don't occur. Thryduulf (talk) 00:46, 25 March 2019 (UTC)

      Portal creation ... is down to about a minute per portal. The creation part, which is automated, takes about 10 seconds. The other 50 seconds is taken up by manual activities, such as finding candidate subjects, inspecting generated portals, and selecting the portal creation template to be used according to the resources available. Tools are under development to automate these activities as much as possible, to pare portal creation time down even more. Ten seconds each is the goal.
      — Portal Update #29, 13 Feb 2019

      Someone spent less than 50 seconds creating the page; requiring editors to spend more time than that to delete it has an extortionate effect, even though there's a good faith intent. If we don't nuke from orbit, then those who want these automatically-created portals deleted will be forced to spend far, far more than 50 seconds per portal discussing them one by one (or ten by ten, or one hundred by one hundred, it'll still be a lot of time). 50 seconds "taken up by manual activities" is how we end up with a Portal:Sexual fetishism that includes Pedophilia as one of the selected articles–probably not the best selection–but that's been there for five months now. Levivich 03:04, 25 March 2019 (UTC)
      • Two wrongs do not make a right and there is no deadline. The only reason for deleting them all you seem to have is that you don't like that these portals were created so quickly, and that some of them are bad. That's fine, you are entitled to your opinion and some of them are bad. However that does not equate to a reason to delete all of them without checking whether they are good or bad. If you have problems with specific portals then they should be fixed and/or nominated for deletion, as I see you have done in this case, but just because X is bad doesn't mean that the entire set of pages of which is a part should be speedily deleted. Thryduulf (talk) 09:35, 25 March 2019 (UTC)
        • "There is no deadline" is a complete non-argument. There is no deadline to have these portals either. Knowingly advocating for keeping problematic portals around until someone not only notices it but also decides to MfD it is exposing readers to shitty, thoughtless reproductions of content for no actual benefit (the benefits" of these portals are addressed dequately by the navigation templates they are based on) and with the risk of showing them all kinds of errors which gives a very poor impression. Luckily very few people get actually exposed to these pages, but this also means that the very hypothetical damage deleting some of these pages would do is extremely minimal. Fram (talk) 10:09, 25 March 2019 (UTC)
          • There was indeed no deadline for their creation, now they have been created that is irrelevant. If we follow your logic though we should delete every article and then just recreate the ones that admins vet as meeting an undefined standard. Yes, deleting more slowly does increase the risk that some readers will see errors, but thtat's exactly what happens in every other namespace without a problem. Thryduulf (talk) 16:35, 27 March 2019 (UTC)
            • No, that's not my logic. Your use of "no deadline" when it suits you, and the dismissal when it doesn't, is quite clear though. Deleting articles is losing content, deleting these auto-portals is losing nothing. Furthermore, we have in the past speedy deleted large groups of articles by one or two creators once it became clear that too many contained errors. This has been done with thousands of articles by Dr. Blofeld, with thousands by Jaguar, and with thousands by Sander v. Ginkel (the last ones moved to draft and then deleted afterwards). Once we know that with one group of creations by one editor, there are many problems, we had no qualms in the past to speedy delete them. That didn't mean that they can't be recreated, or that admins will first vet them, no idea where you get those ideas. Please don't make a caricature of what I support here, and please don't make absolute statements which don't match reality. Fram (talk) 17:41, 27 March 2019 (UTC)
  • Oppose 1) Let's not create precedents where we hand single admins editorial control, admins may well be great editors (some better than others), but let's keep editorial control as much as possible only with all editors. 2) The formulation of this supposed CSD criteria seems to be a WP:PUNISH against a single user. (As an aside, different perspective: there are perhaps millions of pages in article space that are "poor", so portal space is bound to have them, too - just work through it -- and if we come-up with new forward looking policies and guidelines for all portals (or mass creations) consistent as possible with the 5 P, all the better). Alanscottwalker (talk) 17:42, 25 March 2019 (UTC)
  • Support - per Fish & Karate. Ealdgyth - Talk 16:08, 27 March 2019 (UTC)
  • Oppose. I feel there are much better ways of handling the situation, including but not limited to: expanding P2, Portal PROD, and even MFD. This is too broad of a sword that doesn't even cut in the right places since it's only limited to one user in a given time frame. -- Tavix (talk) 16:15, 27 March 2019 (UTC)
  • Thought I had voted here but I guess I hadn’t. Regardless, my thinking on this has changed because of Certes’ in-depth analysis of TTH’s portal creations. Anyway: Oppose. The mass creation of portals is something that should be dealt with preferably quickly, but this proposal as written is not the right way to do it. Sure, there are a lot of crappy portals that could be deleted fairly uncontroversially, but there are also a lot of good portals as well as edge cases that deserve more community discussion on whether they should be deleted, or at least a longer waiting period so users may object. — pythoncoder  (talk | contribs) 12:40, 29 March 2019 (UTC)
  • Oppose for now. I still hope that the proposal might become limited to portals looked at and determined to be poor by some objective criteria, which I could support, but that hasn't yet happened. Speedy ad hominem deletion regardless of subsequent tuning, current quality or even potential for future improvement is likely to throw too many babies out with the bathwater. Certes (talk) 12:46, 29 March 2019 (UTC) Duplicate !vote stricken. GoldenRing (talk) 10:14, 4 April 2019 (UTC)
  • Regretfully support: as an editor I dislike the idea of creations made by certain users being deleted en masse but, quite frankly, MfD cannot cope with the influx at the moment. Hell, I've got a decent laptop and MfD is getting so big scrolling down causes a bit of lag. SITH (talk) 20:57, 30 March 2019 (UTC)
  • Strong support of something to this effect, per WP:MASSCREATION and WP:TNT (i.e., the babies thrown out with the bathwater can be recovered later). However, opponents raise good points of localizing control to a few members, and while I do argue that portals are not content, they are a navigational tool, so community control of them can be a bit "stricter" than mainspace articles, perhaps something like PROD would be better. Regardless of how this pans out, for future portals going forward I proposed Portals for Creation at RfC, and created a mockup here if anyone wants a look. — Preceding unsigned comment added by John M Wolfson (talkcontribs)
    Why is requiring administrators to comb through deleted portals to find those that should not have been deleted in order to restore them, having inconvenienced those people who use the portals in the mean time, in any way better for the project than deleting only those that need to be deleted? Thryduulf (talk) 07:34, 4 April 2019 (UTC)
  • Support. Worthless pages which take 12 seconds to create shouldn't take more than 50000 times that for multiple users to delete. If a subject WikiProject or person interested in the portal's subject is willing to "adopt" that portal, or even assert that the portal is not useless, a more nuanced consideration may apply. And, I should point out, some of the individual deletions are incomplete, as user-facing pages (mostly categories and navigation templates, but some actual article pages) still point to the deleted portals. — Arthur Rubin (talk) 10:25, 4 April 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Clarification on G8Edit

There are a whole host of unused documentation templates (1,111 to be exact). The vast majority are the result of the base page being redirected. For example, you have Template:Bible/doc. Well Template:Bible now redirects to Template:Bibleverse. Since the base page has been redirected, there is really no reason to keep the documentation. Technically you COULD redirect the old doc as well, but why? Again I want to emphasize this is ONLY regarding documentation subtemplates (I.E. Template:<sometemplate>/doc) that are UNUSED. It seems to me this is a clear WP:G8. Anyone have any strong feelings? --Zackmann (Talk to me/What I been doing) 20:13, 13 March 2019 (UTC)

This is not a G8, as the parent page does exist. What is wrong with redirecting the doc of the old template to the doc of the new template? {{3x|p}}ery (talk) 20:21, 13 March 2019 (UTC)
To clarify, does G8 then apply to documentation pages for deleted or otherwise nonexistent templates? I would assume so, as documentation pages are technically subpages, though it is not entirely clear. ComplexRational (talk) 02:35, 14 March 2019 (UTC)
Yes, I would say so. If Template;X doesn't exist and wasn't speedy deleted out of process, then Template:X/doc is a proper G8 deletion. {{3x|p}}ery (talk) 02:49, 14 March 2019 (UTC)
If you really want to pursue the claim that doc pages of redirects should be deleted, then take it to the proper venue (RfD) rather than misusing speedy deletion criteria that do not apply. {{3x|p}}ery (talk) 20:23, 13 March 2019 (UTC)
For goodness sake Pppery AGF. I'm discussing it at templates for deletion because they are TEMPLATES. You are of the opinion that G8 is not valid, but so far that is just your opinion. --Zackmann (Talk to me/What I been doing) 20:29, 13 March 2019 (UTC)

Transcluded to Wikipedia talk:Criteria for speedy deletion. {{3x|p}}ery (talk) 20:32, 13 March 2019 (UTC)

  • Simply redirecting them or deleting them per WP:CSD#G8 are both perfectly fine and functionally equivalent options. -- Ed (Edgar181)
  • Support only for non-subst templates. like CSD C1. It should await 7 days after tagging CSD before actually deletion. For any subst templates, should always be posted to TfD Hhkohh (talk) 23:01, 13 March 2019 (UTC)
  • Zack, some of these could be the result of cut-and-paste moves, if the template at the base page was moved. Some could also be the result of a merge, for which the page should be preserved for attribution, and might not be properly labeled as such. I'd worry that expanding a speedy deletion criterion to this therefore could be problematic. --Bsherr (talk) 01:16, 14 March 2019 (UTC)
  • In my opinion these /doc pages leftovers should be deleted. A redirect has a function (or purpose if you will), in that it serves to lead users reaching it to the correct end-point. How exactly would a user reach an unused and unlinked sub-page of a page that itself was redirected? The only way is by manually searching for that exact title, and that should not be a valid result for a page that serves no purpose. --Gonnym (talk) 21:22, 14 March 2019 (UTC)
    (edit conflict) In reply to Gonnym, who I edit-conflicted with: I'm not necessarily saying we need to keep these unused or otherwise "orphaned" /doc subpages. I'm just saying that CSD is completely inappropriate to use in this case. I don't think you need to go about putting in a TFD for every one (hell, I don't really think we need to worry about these pages), but at the very least there needs to be a discussion to determine their fate. Primefac (talk) 21:24, 14 March 2019 (UTC)
    As seems to be case with all the latest discussions making the system more efficient, more bureaucratic proceedings which serve absolutely no editors. The result of this will be that they will just get put up on TfD slowly, make the discussion list longer for no reason, and end up with the same exact arguments - "unused and should be deleted" and "redirect to new /doc page" - as there can't be any other argument (for valid unused /doc pages of redirect). --Gonnym (talk) 21:33, 14 March 2019 (UTC)
    Or Zach could go through and BOLDly redirect all of the /doc subpages and call it good. It's a heck of a lot easier to undo the creation of a redirect than it is to deal with an undeletion, should it prove necessary. Primefac (talk) 21:38, 14 March 2019 (UTC)
    Exactly, if we're striving for efficiency and we absolutely must do something about these doc subpages, then redirecting them is the one action that's the least time for everyone. And yes, a proposal for extending some CSD criterion to cover them is unlikely to pass: they don't do any harm that I can think of and there all sorts of problems that can arise if they get deleted: attribution could get broken (as pointed out by Primefac), or it might be difficult to fix errors resulting from template merges if you don't have access to the merged template's documentation. – Uanfala (talk) 02:29, 15 March 2019 (UTC)
  • No. The /doc subpages do not meet the criteria of G8, and WP:G6 is not a deletion criteria that means "well I don't really like it so it should be deleted". In the Black Metal example above, the /doc actually precedes the newer doc, and there could have been an attribution issue if the newer /doc had been copied from the old one. There is nothing in G8 or G6 that allows for deletion of these templates, barring IAR from admins who don't really care and just click "delete" when they see a CSD tag. Primefac (talk) 21:24, 14 March 2019 (UTC) Reasonable argument made below... still not overly thrilled but w/e. Primefac (talk) 00:12, 16 March 2019 (UTC)
  • Support CSD If the base template was made into a redirect, then G6 should apply: the doc template was "orphaned as the result of a consensus at WP:TfD". In other cases, I note that the list at G8 says "Examples include", not "these are the only possible cases" as some above seem to want to interpret it. An unused doc subpage would be "a page dependent on a nonexistent page": doc subpages exist only to document a template, and if there's no template to be documented then it's dependent on something that doesn't exist. If someone really did do a cut-and-paste move of the doc page (but not the template? why?), WP:REFUND exists. Anomie 23:51, 15 March 2019 (UTC)
    Eh... fair point. I suppose my main concern is that some admins don't care why a template/page has been nominated, just that it's not an "obviously wrong" tag. I know REFUND exists, but I would just strongly caution anyone wanting to deal with this "issue" to take care and not just batch-nominate 1k+ pages, because that's when mistakes get made. Primefac (talk) 00:12, 16 March 2019 (UTC)

Proposal: Apply a 7-day hold to G13Edit

There are currently 1508 drafts eligible for G13 listed at Wikipedia:Database reports/Stale drafts, and the number continues to rise. With the current workflow, clearing this backlog requires going through each of the drafts, checking them for notability/potential usefulness, and tagging them for speedy deletion. Then a closing admin will need to go through each of them again, verify it meets the G13 criteria, and delete.

This may happen quickly enough that the author of the draft, any reviewers who thought the draft might have potential, or other interested editors who may have the draft watchlisted, may not receive any warning or notification until the draft is already deleted. Admins can view and restore the deleted version, the original creator should hopefully remember what the draft was about and request a REFUND, but others have no ability to save the draft or even remember if it was useful.

I believe there is simpler and better way. Tag each stale draft as G13, with an appropriate notification for the creator of the draft. After 7 days, if no one has contested the deletion, an admin will delete it. If someone has contested it but does not improve the draft, the process repeats in six months. By applying a 7-day hold, the entire community could review the existing stale drafts and act to save them. Compare that to the current system, where no action results in the draft being saved, and editors need to act to delete them.

If we make this change we should be able to do a better job of clearing out old drafts, while working together to save the good ones. – bradv🍁 03:54, 7 May 2019 (UTC)

  • Oppose. Unless you have people who keep constant eyes on G13's category that aren't bots and who actually give a damn enough to find sources (as that's generally the main issue with drafts that languish that long) then this is just kicking the can down the road indefinitely, since to stall the process out an editor could either challenge the G13 or make a null edit to the draft (thus negating the G13 entirely). Another thing worth bearing in mind is that for many of these drafts, sources just might not exist at present (a problem for biographies in particular). —A little blue Bori v^_^v Bori! 04:06, 7 May 2019 (UTC)
    Jéské Couriano, but the current system is that the draft languishes indefinitely until someone chooses to nominate it. And then no one chips in to fix it, it just gets deleted without a second look. This proposal provides a more collaborative approach. – bradv🍁 04:10, 7 May 2019 (UTC)
    A more collaborative approach doesn't mean much if the only sources available are ones that we don't consider useful, and this is, again, doubly so for biopgrapbies. A big reason many of these drafts languish is because the sourcing is not up to scratch. Indeed, a decent amount of the drafts we see in -en-help have serious issues with both the sources that are used and the sources that are even available in the first place, with the editor in question defaulting to "what-about-this-article" arguments as opposed to putting in the work to look for more useful sources, online or off. (Most of these editors are also mercenaries but that is largely irrelevant here except to explain their behaviour.) —A little blue Bori v^_^v Bori! 09:52, 7 May 2019 (UTC)
I don't see a scenario where someone is astute enough to make a null editor but not request a refund. By putting a hold someone could verify that deletion is in the interests of promoting encyclopedic knowledge. Best, Barkeep49 (talk) 04:12, 7 May 2019 (UTC)
  • Don't have much of an opinion here, but It's amusing to me to note that the first sentence seems to imply that we need a faster G13 process, not a slower one. ansh666 05:20, 7 May 2019 (UTC)
    Ansh666, the idea is to tag stale drafts somewhat indiscriminately and then review them, rather than check each item on the list for notability before they are tagged. Then if anyone thinks they might be notable, the tag can be removed. So yes, this should actually speed up the process, while hopefully getting more eyes on the drafts before deleting them. – bradv🍁 05:31, 7 May 2019 (UTC)
  • To clarify, the idea here if this is implemented is to then indiscriminately nominate all G13 eligible pages at some sensible rate? Tazerdadog (talk) 06:05, 7 May 2019 (UTC)
  • I'm not sure what to think. On the one hand, a week-long hold akin to some C- and F-criteria to allow others time to rescue it from deletion seems like a good idea. On the other hand, changing the process so that taggers no longer have to think about the consequences of tagging something useful for deletion is imho a no-go because G13 is just a possibility, not a necessary step to take. Just a thought but can't the draft template be modified to list drafts that have not been edited for say 5 months in a category like Category:Drafts that are eligible for G13 in a month or something? A bot could also notify editors that their draft becomes eligible for G13 in a month if abandoned. That way, there is no need to add a hold to G13 while simultaneously speeding up the process by removing drafts that are still worked on before they become eligible for G13. NB, I oppose G13 altogether but if the community wants it, it should at least be done right. Regards SoWhy 07:22, 7 May 2019 (UTC)
    As it is, a bot notifies a user if a draft they worked on is at or approaching the six-month threshold. —A little blue Bori v^_^v Bori! 09:41, 7 May 2019 (UTC)
    Jéské Couriano, HasteurBot used to notify them and then automatically tag them for deletion, but it's been decommissioned. Stale drafts are now deleted manually without notification. – bradv🍁 14:01, 7 May 2019 (UTC)
    • AFC tagged drafts have this already (meaning the rest of draft-space does not): Category:AfC_G13_eligible_soon_submissions. --Izno (talk) 12:11, 7 May 2019 (UTC)
      Thanks for the info, I didn't know that. Then I'm definitely opposed to making such a change, seeing as that information about G13able drafts is already available and editors get notified that their draft is at risk. Further holding seems unnecessary then. Regards SoWhy 12:28, 7 May 2019 (UTC)
SoWhy I disagree with you that "further holding seems unnecessary" and this is a personal gripe as I've several times had the experience of having my draft deleted within minutes to an hour of it being tagged and my draft has never been submitted to AFC (and imo, should be ineligible for g13) or was wrongly submitted to AFC and moved from my userspace without my doing so (yeah yeah, I know WP:OWN.) I think the issue with G13 is a bit deeper than we're going to get into in this proposal but I disagree entirely with the deletion of something just because it's old and I find this to be a problem also with administrators not actually evaluating the merit of the draft when reviewing for deletion (and I wonder if some G13 mass deleters actually look at the suitability of the content before doing so.) Praxidicae (talk) 14:21, 7 May 2019 (UTC)
@Praxidicae: As I said, further holding seems unnecessary if editors are notified anyway. Bradv has afterwards clarified that the bot in question no longer works. Reinstating a bot to notify you and any other editors that a draft will soon be eligible for G13 seems like a better idea because it allows notice before deletion is requested. Regards SoWhy 15:20, 7 May 2019 (UTC)
SoWhy, the bot didn't notify any other editors though, it only notified the creator of the draft. In order to also notify other interested editors we would need to also put a tag on the draft so it shows up on watchlists. This would be a much more complicated solution than the one I am proposing, as the stale draft database report would have to somehow ignore the application of the tag in the edit history. – bradv🍁 15:25, 7 May 2019 (UTC)
  • Oppose per perennial opposition to G13. Also oppose in this case because speedy criteria are meant to be objective and uncontestable; adding a 7-day hold acknowledges that the criterion fails those two conditions. If we want to create a DRAFTPROD then let's just do that, and toss the six months requirement. Ivanvector (Talk/Edits) 12:33, 7 May 2019 (UTC)
    Ivanvector, I agree that stale drafts need more review before deleting, not less, which is why I proposed this. – bradv🍁 14:07, 7 May 2019 (UTC)
Yes I know, it's a more reasonable approach than what I've seen proposed on stale drafts in recent memory. I'm mostly only opposed to this being defined as a speedy criterion, and in general (my ongoing protest) I dislike that we have a class of pages that can be deleted just because they're old. If they're old, and they're unsuitable for mainspace and nobody wants to improve them, well then fine, clean them out, but I think that's a PROD more than a CSD. Speedy criteria should be for pages that can be deleted at the moment they are tagged, for unresolvable issues. Ivanvector (Talk/Edits) 14:13, 7 May 2019 (UTC)
Ivanvector, in principle I agree with you entirely, and I think this is a step in the right direction. I'm fine with calling this a PROD rather than a CSD. – bradv🍁 14:16, 7 May 2019 (UTC)
I like the idea of a draft-prod without a 6-month requirement, but under current prod rules, something can't be re-prodded if it's been prodded in the past. That would mean that rather than getting a 6-month extension when someone removes a G13, these drafts would languish around forever once someone removes one. Natureium (talk) 17:11, 7 May 2019 (UTC)
MfD would be the place to handle drafts where a prod has been removed so they would only languish until improved enough for mainspace or nominated at MfD. Another solution would be a draft-only rule that drafts may be re-prodded after a given time (eg: after six months of inactivity if G13 procedures are to be imported). -- Tavix (talk) 17:28, 7 May 2019 (UTC)
As I understand the proposal, it is PROD-like but is not actually using PROD. If deletion of an abandoned draft is contested, it would be eligible again for deletion through this process after 6 more months of inactivity. ~Kvng (talk) 21:02, 7 May 2019 (UTC)
Whether we end up calling this G13 or a PROD is up for discussion, but I agree that drafts should be eligible again after 6 months of inactivity, regardless of whether they've been tagged in the past. – bradv🍁 21:06, 7 May 2019 (UTC)
Correct, it would be PROD-like, in the way that WP:BLPPROD is "PROD-like" but is a separate process. I would think that the one-time PROD convention would not be a problem here: if something has been de-PRODded and is still not improved, run it to MfD. The idea is for there to have been a genuine opportunity for the creator to re-stake their claim or for someone else to take it over, not the current nominal "your stale draft is about to be dele ... oh never mind, an admin already got it" that we basically have now with this being a speedy criterion. Ivanvector (Talk/Edits) 16:09, 8 May 2019 (UTC)
  • Strong support In the absence of any other reasonable changes to removing stale drafts. I find mass g13 deletions to be one of the more disruptive aspects of Wikipedia. I'll clarify a bit more in detail later but I don't see any harm in keeping stale drafts provided they don't meet some other deletion criteria. Praxidicae (talk) 14:14, 7 May 2019 (UTC)
  • Support. Adding a seven-day review would effectively make G13 a draft PROD process with a couple extra rules, so let's call it what it is and move the process to PROD if/when something like this passes. -- Tavix (talk) 14:21, 7 May 2019 (UTC)
  • Support I am in agreement with those who note it's no longer a speedy deletion but becomes a new kind of PROD. To that I say GREAT (and have indeed left a message on that talk page). Most G13 are incredibly uncontroversial. These will be unaffected by this change - G13 could already be removed by anyone including article creator (unlike some other CSDs). But this adds time for any interested editor to ensure that, given our lack of deadline encyclopedic content can be created and developed - which is not the kind of content referred to in WP:WEBHOST and thus not applicable. Indeed this tag would allow any who are interested to look through possible deletions and find an article they wish to improve and get ready for mainspace. We're here to build an encyclopedia and drafts are one way we do this. Best, Barkeep49 (talk) 17:49, 7 May 2019 (UTC)
  • Support - Authors are currently receiving little or no notice before their drafts are deleted. I have watched WP:PROD closely and I think this process works well and would work when applied, in the modified form proposed, to our G13 candidates. ~Kvng (talk) 20:58, 7 May 2019 (UTC)
  • Support plenty of people go to WP:REFUND to request restoration of drafts which were deleted only days ago, which is rather pointless. If there is an active editor who cares about the draft enough to contest deletion then it isn't abandoned. I don't see any inconsistency with a speedy deletion criterion having a waiting period, lots of the file criteria have waiting periods (e.g. F4, F5, F6, F7). Hut 8.5 21:18, 7 May 2019 (UTC)
  • Isn't the more straightforward solution to pressgang someone into reviving the bot, so that users are notified at month 5 and then pages are auto-tagged at month 6? Seems like a good task for a bot, and a particularly pointless task for humans. ~ Amory (utc) 00:43, 8 May 2019 (UTC)
    I support this option. Natureium (talk) 00:46, 8 May 2019 (UTC)
    I'd be willing. — JJMC89(T·C) 03:49, 8 May 2019 (UTC)
    Without a doubt. —A little blue Bori v^_^v Bori! 05:25, 8 May 2019 (UTC)
    Amorymeltzer This is fine for the article creator but what about any watchers? Best, Barkeep49 (talk) 03:51, 8 May 2019 (UTC)
    The bot could do a dummy edit to the draft with a suitable edit summary to alert watchers. Johnuniq (talk) 03:57, 8 May 2019 (UTC)
    That would reset the clock on the G13. – bradv🍁 03:59, 8 May 2019 (UTC)
    Nah, bot edits don't count for G13. I think it's likely probably overkill, given how few watchers there are for most things, but you make a good point below about not being able to review. At any rate, such a "dummy edit" would be well suited to the talkpage; it'd be trivial for (insertBotName) to place a similarly-worded notification on the talkpage at the same time as notifying the creator, if desired, thus alerting anyone watching. That'd also make it trivial to categorize every draft into a G13 soon category, which should make review (or at least finding them) easier. ~ Amory (utc) 09:41, 8 May 2019 (UTC)
    I think the idea of the hypothetical bot posting on the talk page and alerting the creator is a great idea in lieu of this - where we can automate repetitive tasks like this, that's ideal. It sounds like JJMC89 might be willing to take this from hypothetical to actual bot? Best, Barkeep49 (talk) 14:13, 8 May 2019 (UTC)
    Sure, adding draft talk notices to go out with the user talk notices would be easy. — JJMC89(T·C) 05:25, 9 May 2019 (UTC)
    Amorymeltzer, HasteurBot indiscriminately tagged drafts for deletion once they had reached six months with no edits, and admins routinely mass-deleted entire categories of drafts. No one was actively reviewing these drafts, as the only ones who were notified were the original creators. It never was the best solution, as it led to thousands of potentially useful articles deleted without review. Every day there are several deleted drafts on my watchlist – I can't see them any more to see if any of them have potential, and I usually don't remember why I was watching them in the first place. Admins have the ability to view deleted drafts, but for most AfC reviewers and editors this is a big issue. How would bringing back HasteurBot help with this?
    Secondly, the current situation is that there are 1500 stale drafts that need to be either rescued or deleted. I propose we nominate them a handful at a time until the backlog is cleared, and allow 7 days for editors to review each of them. If you object to this proposal, what do you recommend we do with these drafts? – bradv🍁 05:42, 8 May 2019 (UTC)
    That sort of is the point though, no? You make a fair point about watchers and reviewers, not to mention there not being a complete category (that is, only AfC drafts have the "soon" category, not all drafts) for the community to peruse a la WP:ARS, but the difference between what you're proposing and a bot is 6 months + 7 day review versus 5 months + 1 month review. I'd feel much better with either process, truth be told — I'd be much happier deleting something knowing that folks have been explicitly given the chance to return to the content — but I don't see an appreciable difference in result aside from complexity, and I don't foresee an appreciable difference in behavior aside from easier cleanup. ~ Amory (utc) 09:48, 8 May 2019 (UTC)
    Amorymeltzer, the change we're proposing would only require a change to the {{db-g13}} template so it behaves like other timed deletion templates, like {{Di-no source}}. That's a fair bit simpler than bringing back HasteurBot with the changes we discussed here, isn't it? – bradv🍁 14:34, 8 May 2019 (UTC)
  • Support, however the real issue is that pages are being drafitied (usually without any attempt at improving the article beforehand) for reasons that would never get a page deleted at AFD, then they're abandoned as the creator gives up or leaves Wikipedia, and then the page is G13'd after 6 months without anyone checking to see if the page could have been saved. Hopefully this change limits those kind of deletions, but I'd prefer a change so that any pages that have been draftified should be mainspaced or AFD'd instead of being subject to G13. IffyChat -- 10:09, 8 May 2019 (UTC)
    Generally, I move a page into draftspace in responce to a helpee in -en-help asking how to submit their already-in-mainspace article, and the page itself is not ready for mainspace yet. When I explain why I am moving it back (in IRC, of course), I get castigated by them. It's as if they only care that it shows up on Google.A little blue Bori v^_^v Bori! 20:24, 8 May 2019 (UTC)
  • Oppose - This defeats the purpose of CSD. It's called speedy deletion for a reason. If you would like to allow the draft author to have some time before the draft is deleted, you can just use PROD as an alternative, with something like {{subst:proposed deletion|concern=Stale draft, remove this if you plan to work on it}} InvalidOS (talk) 11:38, 8 May 2019 (UTC)
No, you can't because PROD cannot be used in draftspace. Praxidicae (talk) 15:33, 8 May 2019 (UTC)
  • Oppose G13 is a bad idea anyway and indiscriminate deletions would A: delete tons of useful content and B: create even more backlog than before. PrussianOwl (talk) 17:53, 9 May 2019 (UTC)
    PrussianOwl How would this proposal cause more deletions? I think by instituting a waiting time it would cause for less deletions since people could decline deletion more feasibly. Best, Barkeep49 (talk) 14:25, 10 May 2019 (UTC)
  • Comment I agree that G13 needs a fundamental reform as it's not currently working in a way that is compatible with the best interests o the encyclopaedia (deletion without review, biting new users, etc), but I'm torn about whether to support this as a first step on the way to that goal or oppose it as it as delaying that reform. Thryduulf (talk) 14:12, 10 May 2019 (UTC)
  • I always tag G13 drafts with Twinkle which notifies the creator. But I don't know if this is common practice. I think some of the "deleting admins" (that's my term) might delete G13s straight away without notifying the original editor. Whether they examine the drafts for their potential, I'm unsure. But the rate at which some admins delete pages, I kind of doubt that they could spend more than a minute looking at the draft. But that's just my impression from looking at deletion logs. Liz Read! Talk! 00:59, 17 May 2019 (UTC)
  • Weak Support - More or less agree with Ivanvector and some others -- G13 should just turn into DRAFT PROD. This sort of kind of does that. It shouldn't be under CSD, but while it is ... meh. — Rhododendrites talk \\ 02:26, 22 May 2019 (UTC)
  • Oppose per WP:CREEP. The stale drafts are now empty; the entire basis for this proposal was flawed, because the large number of stale drafts at the time of the proposal was due solely to a TfD six months prior that led to a large number of bot edits all on the same date. We can expect this to recur, on a six-month delay, whenever a TfD or CfD affects the draftspace, but it is only a temporary issue that resolves as soon as editors work throught the resulting blip in stale drafts. UnitedStatesian (talk) 14:22, 25 May 2019 (UTC)
    How many of those stale drafts were contested or improved and moved to mainspace? Do we have any idea? Or were they all deleted without a second look? – bradv🍁 16:54, 25 May 2019 (UTC)
  • Oppose per above and per WP:CREEP. Reeks of solution in search of a problem -FASTILY 23:12, 25 May 2019 (UTC)
  • Oppose, even if a draft is deleted under G13, they're restored just for the asking. And there is already, after all, a full six month delay. If you think the draft ought to be retained, just make an edit to it any time during that. Seraphimblade Talk to me 23:30, 25 May 2019 (UTC)

NOTWEBHOST should apply to all namespacesEdit

pages that violate NOTWEBHOST do not only exist in userspace, there are many in draftspace too. I see no reason to limit this speedy deletion criterion to only userpace. Roger (Dodger67) (talk) 07:46, 10 May 2019 (UTC)

  • Can you give some examples of pages that violate NOTWEBHOST that are not in userspace, do not meet an existing speedy deletion criterion, need to be deleted quicker than can be done at XfD and for which no alternative to deletion applies? Thryduulf (talk) 14:04, 10 May 2019 (UTC)
    • I had one "Draft:Timothy payne", where the user posted his date of birth (under 16), the name of his school, and other personal details. I thought we had a deletion tag for children posting all there personal contact information. I tried to have it deleted faster by moving it to userspace and tagging it. my deletion tag was removed, and it was moved back to draft space. but, eventually it was deleted as "housekeeping" which seems like a very general criteria. Frietjes (talk) 21:45, 10 May 2019 (UTC)
      I have come across many drafts like the one mentioned above. There needs to be a speedy criterion for stuff like that. CoolSkittle (talk) 01:51, 11 May 2019 (UTC)
      If you see anything like that (apparent minor self-disclosing) remove the information with a neutral edit summary and alert the oversight team (WP:OVERSIGHT) as it needs redacting. Moving a page to a different namespace just so it can be speedily deleted is never an appropriate action. Thryduulf (talk) 10:47, 11 May 2019 (UTC)
      Any specific speedy deletion criteria for this sort of stuff would be a big red flag, telling those looking for this information (for good or bad purposes) where to find it, which is exactly the opposite of what we want - see Streisand effect. Thryduulf (talk) 10:50, 11 May 2019 (UTC)
      Frietjes, as a side note, in future it's probably better not to tag anything with suppressible information with CSD or any other deletion tag. Those are being automatically archived on Wayback by someone (no idea who). The using !oversight ping and waiting for PM on #wikipedia-en-revdel (freenode IRC) or the email form are the fastest ways to get personal information of children redacted. If it clearly doesn't meet WP:OSPOL but does meet WP:CRD just posting the page to the IRC channel or emailing a willing administrator is what's suggested by WP:REVDELREQUEST. Alpha3031 (tc) 15:54, 14 May 2019 (UTC)
    • FYI, see this recent RfC. Frietjes (talk) 21:46, 10 May 2019 (UTC)
      • Isn't there a list of frequently proposed CSD criteria somewhere? Thryduulf (talk) 11:04, 11 May 2019 (UTC)

Suggestion: Don't delete draft pages after 6 months due to historical reasons.Edit


I suggest to keep draft pages beyond 6 Months because of historical reasons and also because someone in future might find it and work on it.

Keeping those articles does not harm or disrupt Wikipedia at all, therefore I suggest draft articles to be kept indefinitely, or be put into a draft archive after 6 months instead of full deletion. Someone might find the article in the draft archive and work on it.

--Chanc20190325 (talk) 09:21, 18 May 2019 (UTC)

@Chanc20190325: What about the spam, web hosting, vandalism, hoaxes, testing, CoI/paid work, attacks, copyright violations, personal information, nonsense etc hidden among the abandoned pages in draft space? Anyone can resurrected an abandoned draft article by going to WP:REFUND. Also see the G13-related proposal above before making a new one. CoolSkittle (talk) 18:23, 20 May 2019 (UTC)
@CoolSkittle: Good point. And thanks for the response. --Chanc20190325 (talk) 22:29, 21 May 2019 (UTC)

Clarification of R3 seems neededEdit

Given some of the comments at Wikipedia:Deletion review/Log/2019 May 16#Badnam Song it seems there is misunderstanding of what R3 is for. I think the best way to solve this is to add a short note that simply being incorrect is not the same thing as being implausible (in a similar manner to how the difference between significance and notability is stressed at A7). I'm not sure how best to word this though. Thryduulf (talk) 10:49, 18 May 2019 (UTC)

I saw that discussion and I don't think any clarification is needed. Everyone knows just what the criterion says and means but they just don't like things like that. In my experience for other widely misused criteria such as WP:G13 (survived its most recent deletion discussion) and WP:G4 (not substantially identical) people just deny what the words say even when the exact wording is pointed out and explained. Thincat (talk) 13:28, 18 May 2019 (UTC)
@Thincat: so what can be done to stop this abuse of CSD? Thryduulf (talk) 15:55, 20 May 2019 (UTC)
Consequent reporting of admins who do so to ANI? Regards SoWhy 17:08, 20 May 2019 (UTC)
  • I also think R3 needs clarifying, but not in the way I believe Thryduulf means. I would add something saying that it applies to any redirect which is strictly a mechanical alteration of the title based on punctuation, word order, or upper/lower case, since all of those are already handled by any reasonable search engine (including our own). The "recently created" clause should still apply in these cases, to avoid breaking external links. -- RoySmith (talk) 20:02, 20 May 2019 (UTC)
  • I agree with Roy. I'd be happy to have someone justify why such newly created redirects are helpful, but I don't see a need right now. I can see an argument that getting the wording correct may not be as clear-cut as we generally like for CSD. But I'm not seeing a use for these at this point of search-engine prowess Hobit (talk) 20:41, 20 May 2019 (UTC)
    • Because going via the search engine is always going to be a significantly inferior experience for the reader to a direct link. Unless the search term is ambiguous or unintelligible to the point we don't know what the searcher is looking for or we don't have any relevant content to take them to, we should always take people directly to the content they are looking for as quickly as possible. Thryduulf (talk) 22:08, 20 May 2019 (UTC)
      • The people who write the big search engines put a mind-boggling amount of effort/money/brainpower into figuring out what page a person is looking for when they enter a search term. The idea that you or I can do a better job of that by guessing which redirects to create is just absurd.

        Let's for the moment assume that this redirect makes sense. Then, the logical extension of that would be to create the similar redirect for every other "...(song)" title. Which, by my count is just shy of 30,000. Are you suggesting we do that? Because, if we don't, then we'll have inconsistent results for different titles. badnam song will get you directly to that page, but gorilla song will get you to a search results page. Inconsistent behavior is confusing for the user. -- RoySmith (talk) 22:57, 20 May 2019 (UTC)

        • That's a fair argument for RfD but because not every redirect of the type "foo thing" → "foo (thing)" and vice versa should be deleted it is not a reason for speedy deletion - see WP:NEWCSD point 2. Thryduulf (talk) 23:24, 20 May 2019 (UTC)
  • R3 has two criteria: "recently created" and "implausible". Both must be satisfied: it is not enough that it be recently created, it also needs to be implausible. If I were to create two redirects: Donnald Trump and That guy with the hair, both going to the same article, the second one would be implausible but the first would not. So only the second one would be speedy-R3-able.
    Now to a real example (BTW: Maproom, Ritchie333: this is the case that I mentioned on Sunday 19 May). About a year ago, I wanted to find the page about an MP who had spoken on some or other political TV prog. I heard her name on the audio, but didn't see an on-screen caption. So I tried typing in her name as I had heard it ("Annalise Dodds"), with no joy; similarly when I tried about four spelling variations on that before giving up. But her constituency was mentioned in the broadcast, so I went in that way: typing in "Oxford Eas" was sufficient to yield exactly one suggestion, Oxford East (UK Parliament constituency). From that I followed the link to Anneliese Dodds, which is not (to me) an obvious spelling. In order to prevent other people having the same problems as myself, I created these redirs. They are all plausible, to my mind. The result of this is that you can now type in "Annalise D", get Annalise Dodds suggested, and that will take you to the properly-spelled page. --Redrose64 🌹 (talk) 16:55, 21 May 2019 (UTC)
    • That's a good example from Redrose64, although I suspect my suggestion of "the one in Oxford who's not Layla Moran" is probably a step too far. In general, the only time I would consider R3 if it contained formatting errors (eg: "Lore Ipsum (singer") completely nonsensical typos (eg: "Thereeeeeeesa May"), or blatantly offensive (use your imagination). As with all CSD criteria, it must be so obvious to any reasonable editor that you should be confident there will be no objections. Ritchie333 (talk) (cont) 17:05, 21 May 2019 (UTC)
    • I apologize for introducing a tangent, but R3 and A10 specify "recently created", and I was wondering if there's any clear agreement on what that means. A day? A week? A month? Three months? WhatamIdoing (talk) 21:48, 21 May 2019 (UTC)
      • In the case of R3, less than two weeks is uncontroversially recent, more than a month will almost never get consensus that it's recent. In between the two it varies - if it's extremely implausible (e.g. "Cahrles Dickens" → "Boeing") then people are more forgiving on the recency than if it's not (e.g. "Cahrles Dickens" → "Charles Dickens"). Thryduulf (talk) 23:29, 21 May 2019 (UTC)
        • The point of the "recent" restriction is to make it unlikely that external sites have already linked to the URL. It would be more useful to turn this into a search for such links (which the various search engines support with their own syntaxes). Our own web servers can also tell if a page has been linked to by looking at the HTTP Referrer headers, but I don't know if that information is available to users. If a redirect has existed for 5 minutes and external sites have already picked it up, then we should keep it. If it's existed for a year and nobody's linked to it, then there's no need. -- RoySmith (talk) 13:26, 22 May 2019 (UTC)
          • That information is not available to anyone (except possibly developers, and if they do I have no idea if they have the tools to easily analyse it). It also cannot tell whether a page has been linked, only whether links from sites that choose pass on correct refer information have been followed. It also cannot tell whether search engines have indexed it, nor whether it has been bookmarked or added to a hard copy document or other offline resource. The recency of creation is a crude method of determining the likelihood of such links, but it's the only one we have. I know getting access to the http refer information has been discussed before, I only have a vague memory of that but I think it was deemed that making such information public would violate the Foundation's privacy policy. I also vaguely recall some concerns about manipulation, spamming, or something like that. One final point is that even some redirects that seem implausible to a random editor can turn out to actually be very useful when someone with relevant subject knowledge fills in context. The longer ago a redirect was created, the less likely such a person will be around to spot the nomination and the more likely that the context will be discoverable by non-experts. Not the best example of this, but Wikipedia:Redirects for discussion/Log/2019 May 16#Gut bath is one of the most recent cases. Thryduulf (talk) 23:22, 22 May 2019 (UTC)
          • It has just occurred to me that if there is a privacy concern then aggregated and anonymised statistics might not (e.g. 20 hits today, 8 were from the English Wikipedia, 8 were from other websites, 4 were from other or unknown sources) but (a) I don't know if it would be allowed, and (b) I don't know who/where to ask to get the answer, but MusikAnimal maintains the pageviews analys tool and so might be able to help. Thryduulf (talk) 23:29, 22 May 2019 (UTC)
  • The extended lengthy discussion at DRV over a particularly unimportant redirect and the exact definition of scope of R3 is a monumental waste of time for the importance of the question. There is no information being deleted, it is just a cheap redirect. I think a better option than a tighter wording for R3, is explicit wording that in the case of an good-faith objection to a speedy deletion by any editor in good standing, and the lack of a good reason not to (generically G10 and G12 cases), the deletion should be listed at XfD. Discussion of the merits of a particular case belongs at XfD, not DRV. In this case, RHaworth has again being quick to accept a CSD request for an unimportant page(redirect). Just send it to RfD. --SmokeyJoe (talk) 01:01, 23 May 2019 (UTC)
    • Whether a page (redirect or otherwise) is "important" is something that can only be determined at XfD. I agree that any reasonable objection to a speedy deletion should result in the deleting admin speedily listing it at XfD (with evidence that it might not be a copyvio in the case of G12, for G10 I'd probably want a couple more opinions if it was borderline). That does not mean though that getting CSDs right first time is somehow unimportant or that it doesn't really matter if someone makes a lot of mistakes if they're happy to correct them afterwards when challenged. Incorrect speedy deletions are one of the most harmful things an administrator can do. Thryduulf (talk) 01:15, 23 May 2019 (UTC)
      • I think that admins should be allowed a reasonable error rate in accepting others' CSD taggings. In this case, did User:RHaworth unilaterally delete, or did someone else tag it? I think that is an important distinction, if someone wants to criticize the admin. This case is pretty trivial. Taking it to DRV without talking to deleting admin is poor protocol. DRV seems to need WP:CSD to say something to encouraging speedy listing at XfD disputed trivial deletions. --SmokeyJoe (talk) 01:43, 23 May 2019 (UTC)
        • Badnam Song was tagged by user:CptViraj. A deleting admin should be personally verifying that every CSD tag they encounter is correct, and it is the admin that carries the responsibility for the deletion. An error rate is inevitable as we're dealing with humans, but that does not mean that the errors themselves are anything other than significant, and the absolute number of errors is equally important to the error rate (10 incorrect speedy deletions out of 100 are equally important as 10 incorrect deletions out of 1000; and both rates are unacceptably high). No speedy deletions are trivial. Some G6 deletions (specifically: obvious errors that were quickly corrected, empty maintenance categories, redirects with trivial history in the way of page moves) and some G7 and U1 deletions (specifically: those with a trivial history and no significant current content) have a low potential for harm but even they are not trivial. Thryduulf (talk) 10:13, 23 May 2019 (UTC)
  • I found it totally incredible that the deletion review should grow to such length. A redirect such as Badnam Song would only come to my attention because it had a speedy tag on it (or was closely connected to another speedy candidate). In this case the relevant edits for Badnam Song are:
  • 2019-05-16T07:04:49 . . CptViraj 80 bytes ({{Db|Wrong Redirect! Not Useful!}})
  • 2019-05-16T01:44:05 . . Meatsgains 44 bytes (Meatsgains moved page Badnam Song to Badnam (song))
The ones for Badnaam Song are effectively identical: same mover and same speedy tagger.
But in this case, I totally deny doing anything "wrong": it was simply a normal editorial dispute. Instead of starting the discussion, the person who objected to my deletion could have simply re-instated either or both redirects with an edit summary of "RHaworth, I think this should be kept". I would have taken no further action. — RHaworth (talk · contribs) 10:21, 23 May 2019 (UTC)
Yes, well, like it or not people are gunning for you now so it might be wise to be super pedantic about crossing every t and dotting every i for a while. Reyk YO! 10:55, 23 May 2019 (UTC)

A10 in user spaceEdit

Is A10 valid in the user space? I've seen this happen a lot, e.g. User:AsumConnect is a substantial copy of Dave (rapper). Or would U5 be applicable, or simply blanking it per WP:FAKEARTICLE? --Drm310 🍁 (talk) 19:12, 23 May 2019 (UTC)

@Drm310: A10 only applies to articles. U5 does not apply to stuff that would look like an article. I asked the user on their talk page. Feel free to blank or MfD it. CoolSkittle (talk) 19:20, 23 May 2019 (UTC)
A10 is meant for cases when someone accidentally creates an article on a topic that already exists, not if someone copies an article and gives it a different name. Such cases are often either 1) people using a previous article as a template for their draft, 2) test edits or 3) cases of U5. The best approach is probably simply asking the user why they did so and explaining to them how drafts are supposed to work. Regards SoWhy 19:20, 23 May 2019 (UTC)
(edit conflict) Absolutely not. User space may only be tagged with G and U criteria; the A criteria apply only to article (main) space. --Redrose64 🌹 (talk) 19:22, 23 May 2019 (UTC)

Edits welcome to new post-CSD noticesEdit

As mentioned last month at AN, I'm (slowly) working on adding to Twinkle the ability for sysops to automatically notify users upon CSD deletion. I've created the corresponding templates, and wanted to make folks aware of them so it's not just me writing them. They were all created based on their corresponding "db-criterion-notice"(with minimal tweaks) and are named similarly, as "db-criterion-deleted." You can find them all at Template:Speedy deletion deleted, but I've included a table below for convenience, which includes each new template alongside its corresponding original notice (and any related templates). Also included are diff links to compare the two, so you can see what I changed.

Template table
Criterion New "Deleted" template Notice and related templates
G1 {{db-nonsense-deleted}} - diff Template:Db-nonsense-notice(edit talk links history) Template:Nonsense-warn-deletion(edit talk links history)
G2 {{db-test-deleted}} - diff Template:Db-test-notice(edit talk links history) Template:Test-warn-deletion(edit talk links history)
G3 {{db-vandalism-deleted}} - diff Template:Db-vandalism-notice(edit talk links history) Template:Db-hoax-notice(edit talk links history)
G4 {{db-repost-deleted}} - diff Template:Db-repost-notice(edit talk links history)
G6 {{db-copypaste-deleted}} - diff Template:Db-copypaste-notice(edit talk links history)
G10 {{db-attack-deleted}} - diff Template:Db-attack-notice(edit talk links history)
{{db-negublp-deleted}} - diff Template:Db-negublp-notice(edit talk links history)
G11 {{db-spam-deleted}} - diff Template:Db-spam-notice(edit talk links history) Template:Spam-warn(edit talk links history) Template:Spam-warn-deletion(edit talk links history)
{{db-spamuser-deleted}} - diff Template:Db-spamuser-notice(edit talk links history) Template:Spam-warn-userpage(edit talk links history)
G12 {{db-copyvio-deleted}} - diff Template:Db-copyvio-notice(edit talk links history) Template:Nothanks-warn-deletion(edit talk links history)
G13 {{db-draft-deleted}} - diff Template:Db-draft-notice(edit talk links history)
G14 {{db-disambig-deleted}} - diff Template:Db-disambig-notice(edit talk links history)
A1 {{db-nocontext-deleted}} - diff Template:Db-nocontext-notice(edit talk links history) Template:Empty-warn-deletion(edit talk links history)
A2 {{db-foreign-deleted}} - diff Template:Db-foreign-notice(edit talk links history)
A3 {{db-nocontent-deleted}} - diff Template:Db-nocontent-notice(edit talk links history)
A5 {{db-transwiki-deleted}} - diff Template:Db-transwiki-notice(edit talk links history)
A7 {{db-notability-deleted}} - diff Template:Db-notability-notice(edit talk links history) Template:Nn-warn-deletion(edit talk links history)
{{db-bio-deleted}} - diff Template:Db-bio-notice(edit talk links history) Template:Bio-warn-deletion(edit talk links history)
{{db-band-deleted}} - diff Template:Db-band-notice(edit talk links history)
{{db-club-deleted}} - diff Template:Db-club-notice(edit talk links history)
{{db-inc-deleted}} - diff Template:Db-inc-notice(edit talk links history)
{{db-web-deleted}} - diff Template:Db-web-notice(edit talk links history)
{{db-animal-deleted}} - diff Template:Db-animal-notice(edit talk links history)
{{db-event-deleted}} - diff Template:Db-event-notice(edit talk links history)
A9 {{db-a9-deleted}} - diff Template:Db-a9-notice(edit talk links history) Template:Db-song-notice(edit talk links history)
A10 {{db-a10-deleted}} - diff Template:Db-a10-notice(edit talk links history)
A11 {{db-invented-deleted}} - diff Template:Db-invented-notice(edit talk links history)
R2 {{db-rediruser-deleted}} - diff Template:Db-rediruser-notice(edit talk links history)
R3 {{db-redirtypo-deleted}} - diff Template:Db-redirtypo-notice(edit talk links history)
R4 {{db-redircom-deleted}} - diff Template:Db-redircom-notice(edit talk links history)
F1 {{db-redundantimage-deleted}} - diff Template:Db-redundantimage-notice(edit talk links history)
F2 {{db-noimage-deleted}} - diff Template:Db-noimage-notice(edit talk links history)
F3 {{db-noncom-deleted}} - diff Template:Db-noncom-notice(edit talk links history)
F7 {{db-badfairuse-deleted}} - diff Template:Db-badfairuse-notice(edit talk links history) Template:Di-replaceable fair use-notice(edit talk links history) Template:Di-disputed fair use rationale-notice(edit talk links history)
F9 {{db-imgcopyvio-deleted}} - diff Template:Db-imgcopyvio-notice(edit talk links history)
F10 {{db-badfiletype-deleted}} - diff Template:Db-badfiletype-notice(edit talk links history)
C1 {{db-catempty-deleted}} - diff Template:Db-catempty-notice(edit talk links history)
U3 {{db-gallery-deleted}} - diff Template:Db-gallery-notice(edit talk links history)
U5 {{db-notwebhost-deleted}} - diff Template:Db-notwebhost-notice(edit talk links history)
T2 {{db-policy-deleted}} - diff Template:Db-policy-notice(edit talk links history)
T3 {{db-t3-deleted}} - diff Template:Db-t3-notice(edit talk links history)
P1 {{db-p1-deleted}} - diff Template:Db-p1-notice(edit talk links history)
P2 {{db-emptyportal-deleted}} - diff Template:Db-emptyportal-notice(edit talk links history)
Other {{db-reason-deleted}} - diff Template:Db-reason-notice(edit talk links history)
{{db-deleted-multiple}} - diff Template:Db-notice-multiple(edit talk links history)
{{Db-csd-deleted-custom}} - diff Template:Db-csd-notice-custom(edit talk links history)
{{CSD-deleted}} - diff Template:CSD-warn(edit talk links history)

A good portion of the language is handled by {{db-deleted}} and {{db-deleted-multiple}}, a la {{db-notice}} and {{db-notice-multiple}}, respectively, so those should certainly be edited to your heart's content. One particular area I was unsure of was the language around contacting the deleting administrator. I've written it to be neutral, to match the language in the notice templates, as well as since in the future these needn't necessarily be placed by the individual deleting the page in question, but would welcome feedback on that front. The notice for G6 copypaste merely redirects to Template:Db-copypaste-notice, which is itself mostly a wrapper for {{uw-c&pmove}}.

Additionally, Twinkle tagging and notification for F4, F5, F6, and F11 is handled by the di module, not the csd. As such, my intent is not to provide deletion notices for those criteria. F4, F6, and F11 specifically state that deletion may be seven days after notification, so there seems no need for duplicate notifications. F5 does have an "immediate" option, but {{db-f5}} was only recently created and there is no corresponding -notice template (i.e. {{db-f5-notice}} redirects to {{Di-orphaned fair use-notice}}). I did create versions of these templates, though, in case reviewing language would help decide (F4, F5, F6, F11). ~ Amory (utc) 19:49, 25 May 2019 (UTC)

Draft testsEdit

Can junk drafts be speedied? These were created by (talk · contribs).

What about {{db-test}}, or should they just be left for six months? Johnuniq (talk) 08:05, 26 May 2019 (UTC)

WP:CSD#G2 (test pages) doesn't exclude draft space, but before applying it there you need to determine why deleting it sooner than G13 allows will benefit the encyclopaedia. In this case, the pages seem harmless so I don't see any reason why they shouldn't be left for G13. Thryduulf (talk) 11:48, 26 May 2019 (UTC)
OK although my feeling about junk is that it accumulates and it would better to remove it on sight. However, I agree that arguments about whether a particular draft is or is not junk would probably be unproductive. No doubt some other reason to delete a draft could be found if someone kept adding meaningless stuff to the above. Johnuniq (talk) 05:16, 27 May 2019 (UTC)
If you think there is a reason and benefit to deleting any page in draft space sooner than G13 allows then nominate it at MfD. Thryduulf (talk) 07:40, 29 May 2019 (UTC)

Deletion of redundant (disambiguation) redirectsEdit

I have been tagging as G8 a number of "Foo (disambiguation)" redirects where they target a page that is not a disambiguation page. They exist, for instance, where the second entry at a two-entry disambiguation page at the base name has been deleted, and the other use is moved to the base name, but without the (disambiguation) redirect having been deleted. It's really a housekeeping exercise: these pages are orphans, useless, and not controversial (I would not nominate a "controversial" redirect from, for instance "Foo (disambiguation)" to "Foo (name)").

Some admins are happy to delete these redirects (@Anthony Bradbury:, @Nabla:, @RHaworth:, @Michael Greiner: thank you, by the way), although sometimes they're actually deleted as G6 or G14. One @Smjg: has suggested G6 is a better classification. One (@Jo-Jo Eumerus:) has removed the speedy tag and suggested RfD. Whether they're deleted as G6, G8, or G14 is a diversion: what's important is that they're deleted. The redirects are, using the language of G8, "redirects to invalid targets".

Can I please suggest an additional explanatory bullet at G8 "Examples include":

  • Orphan "Foo (disambiguation)" redirects that target pages that are not disambiguation pages or pages that perform a disambiguation-like function (such as name SIAs or lists).

Shhhnotsoloud (talk) 09:31, 9 June 2019 (UTC)

After looking after some of these deletions, perhaps it should be deleted under WP:CSD#G6; that's the normal route for maintenance deletions. Jo-Jo Eumerus (talk, contributions) 09:40, 9 June 2019 (UTC)
  • Agree Holsworthy (disambiguation) was declined with R3 (which I though included such redirects that point to non-DAB pages). Crouch, Swale (talk) 19:13, 9 June 2019 (UTC)
  • I agree (has my 2 deletions say :-). It should be clear that if and only if the target is not a disambiguation in any (broad) away then it is a good speedy delete candidate. I think the proposed tet makes it clear. I think G8 is more logic, but G6 is not bad either. - Nabla (talk) 21:21, 9 June 2019 (UTC)
  • If a redirect targets a page that exists then it is not a G8 candidate under any circumstances. The only speedy deletion criterion that applies to unnecessary disambiguation pages is G14 - if it isn't covered by that criterion then it should not be speedy deleted. Thryduulf (talk) 18:05, 10 June 2019 (UTC)
  • I would support that bullet point added under G6 because it's a housekeeping deletion and I think it would nicely fit with the other bullet points currently there. I'd also support G14 if we want to keep all disambiguation-related deletions together. R5 would even work. G8 is more of a stretch because the target page does exist (G8's redirects to invalid targets might need tightening if that's the argument). -- Tavix (talk) 20:01, 10 June 2019 (UTC)
    I think it falls under G6 (and indeed per Thryduulf not G8) but I suppose it could indeed be bundled with G14 (or R3). Crouch, Swale (talk) 20:09, 10 June 2019 (UTC)
    It definitely would not fall under R3 because (disambiugation) redirects are almost always not recently created, so that would be either too much of a restriction or too different from the criterion definition to fit. -- Tavix (talk) 20:17, 10 June 2019 (UTC)
    R3 could specifically have (disambiugation) redirects that target non dab pages regardless of age but I'd agree that G6 would be better. Crouch, Swale (talk) 20:20, 10 June 2019 (UTC)
    G6 is already overloaded so we really shouldn't be adding more stuff to it (it's part of why G14 and R4 were split off recently). Adding it to R3 wouldn't make sense as "recently created" is the fundamental part of that. If we need to speedy delete any of these redirects that don't already fall under G14 then we should be either expanding G14 slightly or adding a new criterion for them, but either way we need to exclude cases where there is a (different) target that is a dab page or something similar (e.g. set index). As for tightening the invalid targets section of G8, yes I'm all for that. Thryduulf (talk) 20:39, 10 June 2019 (UTC)

Modified proposalEdit

Given the comments above that G6 is overloaded and G8 may not be appropriate, but no objections so far to the principle, may I suggest an addition to G14: "G14 also applies to orphan "Foo (disambiguation)" redirects that target pages that are not disambiguation pages or pages that perform a disambiguation-like function (such as name SIAs or lists)." Shhhnotsoloud (talk) 13:38, 14 June 2019 (UTC)

  • Support per the above. -- Tavix (talk) 14:11, 14 June 2019 (UTC)
  • Support. Note that I have deleted hundreds if not thousands of these historically using G6, though I stopped when I noticed some objection to deleting them via an RfD, I forget which. As I said then, the vast majority of these redirects are created by bots, and will never be used by a human. —Xezbeth (talk) 14:38, 14 June 2019 (UTC)
  • Support, although I'd prefer "set index articles" or "set indexes" to "SIAs" and I don't get why it's restricted to just name set indexes? Thryduulf (talk) 15:02, 14 June 2019 (UTC)
  • Question: Is this a proposal to allow speedy deletion of pages that end with the word "disambiguation" and are not acting as disambiguation pages? If that's the case, then I would support the proposal, but the verbiage needs to be cleaned up, because I personally do not understand the meaning of the proposed verbiage (hence I began this comment with the word "question", as opposed to either the word "support" or "oppose"). Banana Republic (talk) 15:48, 15 June 2019 (UTC)
    • @Banana Republic: G14 as it currently exists allows for the speedy deletion of pages are not disambiguating anything in two circumstances. It does not currently apply to redirects at all. This proposal is to allow speedy deletion of redirects with titles ending "(disambiguation)" that redirect to pages that are not disambiguation pages or similar to disambiguation pages, e.g. if Foo (disambiguation) redirected to Association Football then it could be deleted under the proposal. If Foo (disambiguation) redirected to List of ships named HMS Victory it could not be speedily deleted under this criterion as set indexes perform a disambiguation-like function. Thryduulf (talk) 18:31, 15 June 2019 (UTC)
Sounds to me like this proposal should be listed as an R5, rather than a G14, as it is specific to redirects. Banana Republic (talk) 19:13, 15 June 2019 (UTC)
It could fit as R5 but as it's entirely complimentary to G14 (disambiguation pages that don't disambiguate) it also fits as part of G14. I have no preference between the two. Thryduulf (talk) 20:53, 15 June 2019 (UTC)

Tightening G8 with respect to redirectsEdit

The bullet point for G8 regarding redirects currently reads: "redirects to invalid targets, such as non-existent targets, redirect loops, and bad titles". I propose changing that to just "redirects to non-existent targets" as the others are not needed. The section above also shows that these are currently causing confusion.

Redirect loops can mean either:

  • A page redirecting to itself - these will almost always be pages created in error (G6), test pages (G2) or vandalism (revert or G3). In the few remaining cases it is probably someone trying to create a valid redirect and RfD is the place to determine where it should point if the correct target is not obvious.
  • A page redirecting to a page that redirects back to it (A → B → A) - these are usually going to be the result of a page move and the correct solution is almost always not deletion but retargetting to where the content now is (i.e. retargetting A and B to point to C). If this is not obvious then again RfD is the place to discuss them. It's also possible that some could be the result of errors (if they can't be fixed then they can be deleted under G6 already).

"Bad title" is very ambiguous:

  • Many, perhaps most, titles that are "bad" (i.e. are incorrect or do not conform to naming conventions) are actually good redirects and so should not be deleted.
  • Redirects to titles that don't or can't exist are already covered by "redirects to non-existent targets".
  • Some redirects do not work (e.g. to special pages, see User:Thryduulf/R to special) and function as soft redirects, the consensus regarding these is that they should be either left as is or changed to be explicit soft redirects not deleted.
  • A proposed as a CSD criterion for redirects to foreign language projects was rejected so these should not be speedily deleted. T
  • Anything else should be discussed at RfD (e.g. there was a redirect discussed not too long ago with a title that worked only in some circumstances - I can't immediately remember the details but I believe it was kept).

"Invalid targets" is also ambiguous so if there are any instances not covered by "non-existent targets", G2, G3 or G6 where deletion is always required they should be explicitly added to an existing criteria or a new criteria created that meets the WP:NEWCSD requirements. Thryduulf (talk) 21:21, 10 June 2019 (UTC)

  • Seems to jive well with Wikipedia talk:Criteria for speedy deletion/Header, so it has my support. Paine Ellsworthed. put'r there  15:30, 11 June 2019 (UTC)
  • Support proposed reduction in scope. As well reasoned by Thryduulf, redirect loops are most likely fixable.
    To be honest, I don't think I even understand what does it mean to redirect to a "bad title". A page can be redirected to either an appropriate existing page, an inappropriate exiting page, or to a non-existing page. If a page is redirected to an existing page, and other speedy deletion criteria specific to redirects are not met, then it should be discussed whether the redirect is appropriate. I do want to note that this discussion is mostly academic. Since redirects are easy to create, if a redirect is erroneously speedily deleted, it's not very difficult to re-create the redirect. Creating a redirect takes less than a minute. Banana Republic (talk) 15:31, 15 June 2019 (UTC)

Ambiguity in G11Edit

Current version of the page has this sentence in criteria G11 If a subject is notable and the content could plausibly be replaced with text written from a neutral point of view, this is preferable to deletion.

Seems to me that the word "this" is ambiguous, and it would be better to replace the fragment this is preferable to deletion with rewriting would be preferable to deletion. Banana Republic (talk) 15:36, 14 June 2019 (UTC)

I'm neutral about "this" vs "rewriting" but "is" is significantly better than "would be". Thryduulf (talk) 15:38, 14 June 2019 (UTC)
It's just grammar. Because this phrase is inside a conditional statement (the sentence begins with "if"), "would be" is more appropriate than "is". Additionally, the word "preferable" already implies that the action is not mandatory, so it is not compatible with the word "is", which does make it sound mandatory. Banana Republic (talk) 15:45, 14 June 2019 (UTC)
It's not about mandatory/not mandatory (although it is very strongly preferable) it's about tense. It is preferable in the present tense, not would be preferable in the future tense. Thryduulf (talk) 17:37, 14 June 2019 (UTC)
The verb "be" is present tense. Therefore "would be" is present tense. See this reference, for additional details. Banana Republic (talk) 23:33, 14 June 2019 (UTC)
Agree "this" is ambiguous, and conditionals are usually "If..., then..." types. "This" should be changed to "that", as in "If a subject is notable and the content could plausibly be replaced with text written from a neutral point of view, then that is preferable to deletion." Paine Ellsworthed. put'r there  08:42, 15 June 2019 (UTC)
Return to the project page "Criteria for speedy deletion".