Archive 5

←

Archive 8

Archive 9

Archive 10

Archive 11

Archive 12

→

Archive 15

Further to yet another thread at WP:AN (permalink), I want to encourage others to help in identifying portals which are or used to be old-style — that is, portals which have at some point not been automated.

Pinging other participants there @Northamerica1000, Thryduulf, and Cryptic:, and also @Pldx1 who has shown tech savvy in this area. --BrownHairedGirl (talk) • (contribs) 14:38, 11 April 2019 (UTC)

BrownHairedGirl, I have a list generated from portals present in the archive of all portal pages before automated conversion began and now present in the single-page portals category. it is probably inferior to other methods, but may be of use. It is at User talk:Dreamy Jazz/Archive 3#Tags, but a copy is below for convenience (one marked first list) Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:50, 12 April 2019 (UTC)

For example Portal:Bangladesh Premier League is present on Wikipedia:WikiProject Portal/List of_all_portals/Archive/4-22-2018/Page_1. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:02, 12 April 2019 (UTC)

However, it was deleted at MfD back in 2018. There may be useful content in the previous version. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:05, 12 April 2019 (UTC)

BrownHairedGirl, just by random selection I have found some portals which are in the deletion discussion for Wikipedia:Miscellany for deletion/Mass-created portals based on a single navbox but are in the old list. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:01, 12 April 2019 (UTC)

@Dreamy Jazz, please identify those which you found, so that I and other editors can check them? --BrownHairedGirl (talk) • (contribs) 13:07, 12 April 2019 (UTC)

@BrownHairedGirl: In comparing portals for deletion on the page and portals in the list below using python, these portals are present in both lists. It does not mean that these portals currently have versions which could be reverted to, but it does say that they existed on the 22 of March 2018: Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:12, 12 April 2019 (UTC)

@BrownHairedGirl: Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:12, 12 April 2019 (UTC) (forgot to sign above)

Sorry, @Dreamy Jazz, but that python-generate list is v poor. The most of first few were deleted at MFD, which isn't relevant to the mass deletion discussion. The next 3 — Portal:Polynesia, Portal:Aquariums, and Portal:Exploration — have no history of deletion. --BrownHairedGirl (talk) • (contribs) 13:19, 12 April 2019 (UTC)

BrownHairedGirl, this list was supposed to be those which existed then and this might mean they were deleted and then recreated. The list is now smaller as there was a generation issue with the information from quarry, in that the script detected parts of lines. This should be fixed now. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:26, 12 April 2019 (UTC)

Thanks, @Dreamy Jazz, but I'm still not seeing any utility to this. AFAICS, you have identified some portals which were MFDed, then subsequently recreated as automate portals. I don't see how this affects any future decisions. --BrownHairedGirl (talk) • (contribs) 13:57, 12 April 2019 (UTC)

BrownHairedGirl, the second list wasn't necessarily meant too, but was meant incase there were any portals which are up for deletion as they were created by the Transhumainst, which may now have the topic base, but had a previous (now deleted or not deleted) non-automated design which may have been useful in creating the portal in a non-automated way.

The first list, I think, is more useful as it shows portals which existed on the 22 of March 2018, but are now single page portals. Several (probably most) portals in this list will have a non-automated version in their edit history (those that don't will have been deleted and then recreated). So if reverting the upgrading from non-automated versions is what is wanted through this discussion, then most portals on this list will need to be reverted back to their old design. Sorry if I have caused confusion. Dreamy Jazz 🎷 ^{talk to me | my contributions} 14:06, 12 April 2019 (UTC)

the issue fixed seems to have removed the three portals you mentioned above. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:29, 12 April 2019 (UTC)

sorry for confusion etc. Shows that quick and dirty python scripts don't always work! Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:31, 12 April 2019 (UTC)

First list:

One test which seems to be a possibility is to look for subpages of a portal. So far as I can see, any active non-automated portal will contain one or more of the following subpages:

• /Header
• /Intro
• /Topics
• /Categories
• /Selected article
• /In the news

So e.g. if Portal:Queen Victoria's ankles is non-automated, then one or more of the following pages should exist:

• Portal:Queen Victoria's ankles/Header
• Portal:Queen Victoria's ankles/Intro
• Portal:Queen Victoria's ankles/Topics
• Portal:Queen Victoria's ankles/Categories
• Portal:Queen Victoria's ankles/Selected article
• Portal:Queen Victoria's ankles/In the news

On that basis, I am about to do a WP:AWB list-making run to identify such pages. I will get a list of all currently extant portals, and use that to make a list of all the possible subpages. If any one of those 6 subpages exists, then the portal must at some stage have been non-automated.

It should pick up:

1. current non-automated portals
2. portals which were automated, but where subpages have not been deleted (or were deleted then restored)

--BrownHairedGirl (talk) • (contribs) 14:42, 11 April 2019 (UTC)

Great start, (thanks!) but there is one hole: I've found several cases where the Portal was moved, without its subpages, either before or after being automated. So the restored subpages are sitting under a different name than the actual portal. I'll try to come up with a couple examples. UnitedStatesian (talk) 14:49, 11 April 2019 (UTC)

No prob, UnitedStatesian. Thanks for the pointer. I'll just keep a note of any such orphaned supbages.

I have just set AWB off to ook for extant pages. I found 4913 portals, so it is checking the existence of 29,478 pages.

I expect that it will find very few unused subpages; they should mostly have been WP:G8ed, or (less appropriately) G6ed.

But it's an easy check, so I will see what it picks up. --BrownHairedGirl (talk) • (contribs) 15:17, 11 April 2019 (UTC)

quarry:query/35077 should be a complete list. (I suppose it could stand to have the deletion log entries, too, or maybe the page the base portal redirects to when it's a redirect, but those would involve a modicum of effort.) Note that this deliberately still lists subpages like Portal:Zelda/Intro that have both deleted and undeleted revisions. —Cryptic 15:11, 11 April 2019 (UTC)

Bless you, Cryptic. That is brilliant. I will play with that a bit. --BrownHairedGirl (talk) • (contribs) 15:18, 11 April 2019 (UTC)

quarry:query/35078 has the redirect targets and deletion log entries. —Cryptic 15:30, 11 April 2019 (UTC)

@Cryptic, if it's not too much trouble, would you kindly be able to make a quarry query like 35077, but which finds "Existing portal subpages where the base page exists"?

It should produce the same results as my AWB job, but more accurately. --BrownHairedGirl (talk) • (contribs) 15:29, 11 April 2019 (UTC)

quarry:query/35079 should be up momentarily. It's a fast query, but there's about 146000 such subpages, so - while it's almost instant at toolforge - the Quarry web interface will take a while to catch up. —Cryptic 15:36, 11 April 2019 (UTC)

• For what I understand, identifying portals which are or used to be old-style — that is, portals which have at some point not been automated amounts to identify portals that have/had any subpage, deleted or not. And then we have a question of policy. How to detect if there are any people or project who want to step forward as a maintainer of the portal, and organize the required editorial decisions ? Pldx1 (talk) 17:23, 11 April 2019 (UTC)

The red links on the Portal:Contents/Portals page resulting from portals that have been deleted should be removed. Red links in other areas (e.g. Related portals portal subpages, article templates, etc) should also be removed. I'm busy with other matters, and one person can only do so much, so posting here to notify others about the matter. North America¹⁰⁰⁰ 19:02, 12 April 2019 (UTC)

• I find the redlinks helpful to identify portals by subject that have already been deleted amd to see trends in various subjects.

Does anyone know the high point? Newsletter #29 I believe said 5700 portals and then #30 said the number dropped so it must have peaked north of 5700. We just hit 4700 and there are over 1850 under MfD right now. Further bulk nominations are in the works to. Legacypac (talk) 19:12, 12 April 2019 (UTC)

Hadn't thought of that. I'll revert my attempts to help. Maybe it's a maintenance we should do on a schedule, once a week, once a month BusterD (talk) 19:16, 12 April 2019 (UTC)

• The purpose of the Portal:Contents/Portals page is to direct WP:READERS to working portals. The red links still need to be removed from that and other pages as well. These pages are not meant or designed to be a directory for MfD. For more information, see WP:REDLINK. North America¹⁰⁰⁰ 19:28, 12 April 2019 (UTC)
• Agree with NA1000 on this one: that's a reader-facing page, and the redlinks should be removed expeditiously. Editors can use pages in this WikiProject, such as Wikipedia:WikiProject Portal/List of all portals (which was current as of Jan.), or the MfD archive to track deletions. UnitedStatesian (talk) 21:04, 12 April 2019 (UTC)

Well anyone that wants to spend time on this is going to be frustrated keeping up while Category:Miscellaneous pages for deletion has nearly 1900 portals under deletion discussion ending in the next week. Maybe wait till the dust settles. I also note this page is missing scores of portals so it is out of date coming and going. Maybe we shoud redirect it to Category:All portals or something similar that automatically updates. Legacypac (talk) 22:46, 12 April 2019 (UTC)

• A proposed redirect of the Portal:Contents/Portals page should be discussed at Portal talk:Contents/Portals, not here, because users of the page will not know about any discussion about it here. Also, the page has received 91,753 page views in the thirty-day period between 3/11/2019 to 4/10/2019. Clearly a well-used page in the state it is in. Redirection would likely significantly reduce portal page views. North America¹⁰⁰⁰ 23:26, 12 April 2019 (UTC)

While going through the war portals template, I came across the nine year-old Portal:Submarine which currently has a merge tag at the top. The requested merge target is Portal:Submarines, an automated portal created recently and currently up for deletion. I made my case for opposing in the appropriate place but thought "should the object class subject of a portal be plural or singular?" The browsebar in question includes portals for Battleships, Submarine, and Tank. Looking through the list of portals and MOS:Portal I didn't get any clear direction. Am I missing something? BusterD (talk) 23:44, 12 April 2019 (UTC)

I completed the merge. "Thing" portals almost always use the plural. UnitedStatesian (talk) 17:49, 13 April 2019 (UTC)

There was no merge to perform. The newer portal is up for deletion and should be deleted. Then we could move to the plural namespace. BusterD (talk) 19:30, 13 April 2019 (UTC)

A discussion is taking place as to whether 1,165 portals are suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether they should be deleted.

The pages will be discussed at Wikipedia:Miscellany for deletion/Second batch of mass-created portals based on a single navbox until a consensus is reached, and anyone is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the pages during the discussion, including to improve the pages to address concerns raised in the discussion. However, do not remove the deletion notices from the top of the pages. --BrownHairedGirl (talk) • (contribs) 02:18, 15 April 2019 (UTC)

• Thank you for not making 1,165 MfD nominations. --SmokeyJoe (talk) 03:40, 15 April 2019 (UTC)

A discussion is taking place as to whether 83 portals are suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether they should be deleted.

The pages will be discussed at Wikipedia:Miscellany for deletion/83 more navbox-based portals until a consensus is reached, and anyone is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the pages during the discussion, including to improve the pages to address concerns raised in the discussion. However, do not remove the deletion notices from the top of the pages. --BrownHairedGirl (talk) • (contribs) 13:24, 16 April 2019 (UTC)

In the last few days I have noticed a steady stream of automated portals being converted back to previous unautomated state. What's this all about?

This is big stuff, because it reverses a year of this project pushing full steam ahead for automation. But I see no discussion agreeing that this should be done, or which portals it should be done to.

I see no list of portals to which this has been done.

Most crucially, many portals which were converted because they were unmaintained. The were often broken, and/or wildly outdated. I see no sign of any plan to ensure that are now actually going to be maintained, no list of maintainers, no discussions with WikiProjects. Where are those maintainers and/or those WikiProject discussions?

I have seen one editor describe these reversions to outdated, broken formats as being close to vandalism. Given that many of these reverts are being performed by an editor who serially opposes deletion of even portals with long-term pageview averages of less than five day, I have to wonder whether they are some sort of attempt to game the system by taking these pages out of the frame of the growing mood to delete automated portals.

If this is not just some sort of effort to dodge deletion, please can someone point me to where the actual plan is, and where's the consensus behind it?

@Northamerica1000, you appear have been one of the most prolific performers of these reverts. Please can you explain where this high-speed reversal of the project's direction was discussed, and where the plan is? --BrownHairedGirl (talk) • (contribs) 19:58, 13 April 2019 (UTC)

Also pinging @BusterD and @Legacypac, who have discussed this issue with NA1K above. Have either you seen the consensus-based plan for this full-speed=in-reverse? --BrownHairedGirl (talk) • (contribs) 20:01, 13 April 2019 (UTC)

I think it is a deletion dodge. If the portal project found the page unmaintained and decided to automate it, and no one objected, then they were right it was unmaintained. That is a reason to deleet no lt a reason to revert to a state that was judged abandoned and worth replacing. I'm nominating these cases for deletion as I find them. It is one thing if an MfD finds that there is sufficent interest in maintaining a topic in a deautomated state. It is another case to revert hundreds of abandoned portals to non-automated state to game the system. Legacypac (talk) 20:09, 13 April 2019 (UTC)

@Legacypac, let's not rush to conclusions. I am AGFing that the appearances are misleading, and that this is part of an actual consensus-based WPPORT plan to establish some framework for maintaining and updating all those manual portals which are being restored to manual. --BrownHairedGirl (talk) • (contribs) 20:54, 13 April 2019 (UTC)

I watch all the project pages and the talkpages of involved users. If such a plan had been discussed I'd know it. Legacypac (talk) 21:08, 13 April 2019 (UTC)

First, I appreciate the ping to be involved in this valuable conversation. I have performed about 25-30 of these reversions myself, responding to this request for assistance from NA1000, an admin I admire yet frequently disagree with. I have had no hidden or private discussions with anyone. Note that I haven't performed any of these in the last 8 hours or so. I was waiting until the inevitable discussion provided an attaboy or otherwise. Thanks for providing a discussion for us to utilize. My starting position has been stated several places in the last two days: 1) IMHO the attempt to automate every portal was misguided and somewhat pointy, 2) community consensus has shut down new creation of these sorts of portals for the nonce and virtually every newly created one is up for deletion--and IMHO should be deleted 3) portals appearing in this template were of a regular quality and didn't for the most part need full automation though they did need maintainers 4) I am willing to put myself forward to recondition each of these MilHist portals and keep them maintained and 5) the techniques and technology developed by this project in the last year provide some useful tools to assist me in performing maintenance and keeping them maintained. BusterD (talk) 21:35, 13 April 2019 (UTC)

@BrownHairedGirl: I've never been a formal member of this Wikiproject, just a maintainer of portals, but from my perspective the project direction to change all portals where the maintainers didn't kick up a fuss to the automated format was never agreed, just promoted by a minority so loudly that those with other opinions fell silent or walked away. Reverting functional hand-curated portals to their previous state seems to me akin to reverting vandalism, though I agree it fails to fix underlying problems with lack of maintenance. In the current hostile climate, however, it's difficult to hold forward-looking discussions about the real problems of maintenance. Espresso Addict (talk) 23:53, 13 April 2019 (UTC)

I appreciated you classing some of the conversions as vandalism. There is not a one size fits all solution here. In many cases the automated version, with all it's failings, is an improvement on the old version. Since no topic needs a portal (unlike how many topics need an article), the solution is deletion. Legacypac (talk) 20:01, 14 April 2019 (UTC)

At this point in time, It is crystal clear that the community is against most (but not entirely all) of the automated portals that were created using automation, specifically, those that have no history of being hand-created using subpages. This is evidenced by present discussions at MfD (perm link). A further example exists at Wikipedia:Miscellany for deletion/Mass-created portals based on a single navbox, which resulted in 1,390 automated portals being deleted en masse. As such, it is common sense to restore old-style potals that were later automated back to their former state. It makes no sense to keep portals in a style and format that most people in the community don't want and are strongly against, and natural and normative to improve Wikipedia's portals by restoring hand-created ones to pre-automated versions. North America¹⁰⁰⁰ 04:14, 15 April 2019 (UTC)

I agree with your preceding statement and support your rollback efforts, for any portal that is not currently at MfD. I have done a number of rollbacks myself and made WP:REFUND requests of CSD G6 deleted subpages. UnitedStatesian (talk) 04:21, 15 April 2019 (UTC)

I have an incomplete list at WP:WikiProject Portals/Cleanup. For the time being, I have only targeted featured portals, because those are the portals that are most likely to have lost content in the conversion to automated. My goal was to readd removed content so it is more helpful to readers. I have intentionally avoided reverting smaller portals to as to not waste effort on portals that will become abandoned or deleted. —pythoncoder (talk | contribs) 19:42, 16 April 2019 (UTC)

While I fully agree with the recent proposal to delete the hundreds of 'auto-portals' mass created by TTH, AFAIK there is no consensus for the mass deletion of other, manually-maintained portals, especially while we're trying to reach agreement on how those portals should be created and maintained and what role Wikiprojects should have. I'm dismayed that certain editors are riding on the back of the TTH-deletion to embark on a campaign to delete other, manually-maintained portals, without a consensus existing on what standards portals should meet for creation or deletion and while discussion is still in progress. I'm involved with Portal:Rhön and Portal:Harz Mountains, but many others have been targeted. We're just swinging from one extreme to another. Happy to delete the TTH creations, but let's hold fire on the others until further agreement has been reached. Bermicourt (talk) 22:31, 13 April 2019 (UTC)

• What is happening is a portal by portal discussion of older portals as well, a review the portals project shoild have done before creating 3200 new portals and converting many more to a automated format. Some of the old portals may well be kept but many need to go per the results of WP:ENDPORTALS. Legacypac (talk) 22:38, 13 April 2019 (UTC)

The result of WP:ENDPORTALS was, and I quote, that "there exists a strong consensus against deleting or even deprecating portals at this time". So I don't understand how that gives carte blanche for a mass deletion exercise. Don't get me wrong; I never supported the mass creation either and I have always been an advocate for having an agreed approval process and for setting standards. But swinging the pendulum back the other way is a blunt weapon that risks throwing out perfectly good portals that have taken many man-hours to create. What criteria are we using to propose these deletions other than editors' personal views on whether they're good enough/broad enough? Do you see where I'm coming from? Bermicourt (talk) 22:53, 13 April 2019 (UTC)

Agree with User:Bermicourt. What seems to be happening here is that while hundreds of portals are being nominated for deletion in batches, (in what I'm sure is a coincidence) scores of deletion discussions (some overlapping) are going on simultaneously to eliminate portals whose creators, maintainers, and defenders are often retired from the pedia. It also seems a bit disingenuous to continually refer to ENDPORTALS as if the consensus were to END PORTALS when the actual outcome was otherwise. BusterD (talk) 23:05, 13 April 2019 (UTC)

I see more misstatements here. The consensus of WP:ENDPORTALS was that some portals were useful. If you see a consensus against deprecating portals there, you're seeing things that aren't there. — Arthur Rubin (talk) 21:58, 14 April 2019 (UTC)

First there is no mass deletion of manually maintained portals. However all portals have come under scrutiny. If you look at the ENDPORTALs discussion it is clear even many of the people against ending all portals supported a purge or cleanup. The sorry state of portals in general lead to the whole proposal. Legacypac (talk) 23:02, 13 April 2019 (UTC)

Most of the large bundled nominations at present are automated portals but Wikipedia:Miscellany for deletion/People Portals A-C, nominated by Legacypac, appears to include some/many hand-crafted portals. There is also such a large number of individual deletion discussions for hand-crafted portals (some, like Portal:Architecture, Portal:Hip hop & Portal:Jordan, rather odd choices) it is hard to keep up with them all -- not to mention dispiriting. Espresso Addict (talk) 23:34, 13 April 2019 (UTC)

The group of portals on individuals is looking for concensus on if an individual is a broad enough scope for a portal. Results so far, and even from 10 year old debates we have found, suggests otherwise. Portal:Jordan is a laugh. It's busted. Legacypac (talk) 00:38, 14 April 2019 (UTC)

Wikipedia is a collective enterprise and we are meant to get consensus before making contentious moves, especially deleting large numbers of entire articles (=mass deletion). You have taken WP:END (ACTUALLY KEEP) PORTALS as a mandate to bring all portals under your scrutiny and are now acting as if your personal WP:POV is the sole criterion for whether a portal should exist. What you are doing is as bad as TTH's mass creation, but in reverse and going much further - not just deleting his portals (which did have a consensus, including my vote) but, like the Baltic Sea, sweeping back like a storm surge taking everything else in its wake, good or bad. Please undo your deletion requests, except where they have a broad consensus, or this will have to go back to the community that voted to KEEP portals in principle. Bermicourt (talk) 07:21, 14 April 2019 (UTC)

Um... no one is acting without community consensus. The entire point of discussing a portal at MFD is to see what the community consensus on that portal actually is. Blueboar (talk) 15:09, 14 April 2019 (UTC)

Um... no it isn't. The wider community isn't visiting every single one of the mass of portal MFDs. What is happening is that a few anti-portal editors have decided they can pick off portals one-by-one precisely because the community won't go there to discuss generic portal standards and they won't meet much opposition from a portal maintained by a couple of editors from a Wikiproject. Bermicourt (talk) 19:51, 14 April 2019 (UTC)

But the portals aren't being maintained. (Or, at least, they weren't before the MfD.) — Arthur Rubin (talk) 21:54, 14 April 2019 (UTC)

And longstanding generic portal standards already exist, at WP:POG, from which I quote: "portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers" and "the subject of a portal should be broad so that it presents a diversified content."; That first sentence was put into the guideline in 2006. The portals being deleted do not meet these standards and never have. UnitedStatesian (talk) 03:03, 15 April 2019 (UTC)

The guideline is no longer valid - WP:ENDPORTALS made that clear. There was no consensus on what portal standards should be, but it was clear that many editors saw portals as having wider use e.g. as a tool to aid Wikiprojects improve and extend coverage of a topic. Meanwhile the guideline is being used as an licence by anti-portaleers to wipe out as many portals as possible and to do it by individual MFDs because they know the community won't visit each individual portal discussion. This mass deletion is exactly what TTH did but in reverse. Bermicourt (talk) 06:26, 15 April 2019 (UTC)

Bringing a page to XFD so editors can debate whether it should be kept/deleted is part of forming a consensus about what Wikipedia should consist of. If that consensus is to delete the page then it indicates that the page creator (e.g. TTH) was wrong/misguided to create it. Note also that more thought/care has gone into many of the MFD nominations than appears to have gone into the portals. DexDor ^(talk) 06:37, 15 April 2019 (UTC)

Precisely, and um, no, the MfD's are not "exactly what TTH did but in reverse." Please point me to where TTH first proposed any portal creation, waited seven days for other editors to comment, and then had an uninvolved administrator actually perform the action he proposed, but only if the discussion reached consensus to do so. The broader community has had plenty of notice (at the village pump, in the wikiprojects) that lots of portals are being brought to MfD. The lack of opposition to those deletions at MfD is proof the community sees no problem with the deletions that have been proposed, or the process. UnitedStatesian (talk) 03:49, 16 April 2019 (UTC)

• Saying because they know the community won't visit each individual portal discussion is perhaps fallacious, but surely a tactical error. The community is now visiting many portals for checking purpose. Some great moments:

Did You Know that males of the fossil ant Proceratium eocenicum have a hair fringe ? (at Portal:Men)

Did You Know that spiders in the genus Plato have cubical egg sacs? (at Portal:Plato -- the featherless biped, not the 8-pode)

Did You Know that in the Battle of Kharistan in 737, the Umayyads caught the Turgesh khagan off guard with only a fraction of his army, and secured a victory that saved Arab rule in Central Asia ? (at Portal:fraction)

Portal:Versailles, about Palace of Versailles, was in fact based upon the Versailles_(band) article

The Selected quotes page of Portal:Trump was created 26 September 2016‎, and has never been modified afterwards, except from (1) replacing {{/box-footer}} by {{Box-footer}}; (2) suggesting to include the grab them by the pussy quote, with no ensuing decision.

What could be the reason if the community is c-mused (=amused+bemused) by what is discovered ? Pldx1 (talk) 08:33, 15 April 2019 (UTC)

• Perhaps, we should start by a definition of what is a manually-maintained portal. In my opinion, this start by filling the maintainer1= item of the {{Portal maintenance status}}. If nobody can compulse herself to step forward and claim to be a maintainer, the portal is clearly unmaintained. The same goes when you look at a subpages based portal and only see, after 9 years of existence, a grand total of 3 articles in the Selected articles page, and a grand total of 3 pictures in the Selected pictures page (live example, not figures at random). Pldx1 (talk) 08:33, 15 April 2019 (UTC)

So many funny things to pick from but a recent favourite is the huge red Lua error on the images slot at Portal:Lua programming language. Perfectly illustrates the wisdom of using Lua for portals. Legacypac (talk) 08:46, 15 April 2019 (UTC)

I am sorry, but I disagree. When function makeTranscludedGalleryLinesTables (line 117 of Module:Random_slideshow) ends with error occurred at Module:Random_slideshow, line 170, error message=No images found, this is not an error of the Lua (programming language). There was no image in the file given as argument to this function, while line 170 is required to test the existence of images and otherwise send an error message. But there was at least 3 human errors:

1. Implementation error: using the cryptic message 'Lua error at' instead of the correct 'error in Lua:module..., message=...'
2. Implementation error: the listing of Lua modules is so poorly done that line numbers are not given.
3. Caller error: the main page containing the images is Lua (programming language), while the Lua programming language used in the {{Transclude files as random slideshow| Lua programming language||}} call... is only a redirect, and therefore contains no image.

Therefore, what this example perfectly illustrates is the lack of wisdom of not having deleted on sight all the template-generated portals as soon as the TTH-overflow has been detected. Pldx1 (talk) 09:40, 15 April 2019 (UTC)

• Of note is that per WP:NOTCOMPULSORY, the notion of a required maintainer for any Wikipedia content is against Wikipedia policy. As such, a lack of a maintainer, or immediate maintainer (per requests for maintainers at MfD discussions) for Portal content is not a valid rationale for deletion at MfD. North America¹⁰⁰⁰ 12:24, 15 April 2019 (UTC)

Portals are a copy of content. One of the problems with portals is that the portal is less well maintained than the corresponding article so any readers that do get to the portal (which is, of course, very few readers) are not seeing the best content that wp can offer to them. Not having a maintainer isn't itself a good reason for deletion, but it does add to the evidence that the portal is unlikely to be maintained. DexDor ^(talk) 12:44, 15 April 2019 (UTC)

You are assuming that articles continuously improve. This might be true for some, but certainly isn't in my experience for many. There's often a long slow decline or at best an accumulation of well-meaning but disorganised/poorly written content. Espresso Addict (talk) 05:45, 16 April 2019 (UTC)

I'm not assuming that articles continuously improve - although, of course, one hopes that the long term trend is for good edits to prevail (otherwise we should edit protect all articles). There are many examples where the portal is less well maintained than the corresponding article (e.g. Obama's article was updated from "is" to "was" president within a minute; his portal wasn't updated for months). DexDor ^(talk) 06:21, 16 April 2019 (UTC)

I found a TV show portal that was 6+ years out of date (at MfD now). Portal:Caribbean has news about Castro making a TV appearance last week which is a remarkable think for someone who died in 2016. Even Portal:Donald Trump is significantly out of date. Let's just admit no one but a few ideologues think portals have any use any more (if they ever did). Remember when people went to Yahoo as a web portal? Search killed the portal. Legacypac (talk) 06:34, 16 April 2019 (UTC)

@DexDor: In my experience, the higher-quality articles that aren't featured tend to deteriorate over time, unless someone wades in and takes them in hand, but perhaps I'm looking at a different set of articles from average. Espresso Addict (talk) 06:44, 16 April 2019 (UTC)

• I see another false statement about the "result" of WP:ENDPORTALS. It is not the case that many editors "saw portals as having wider use". In fact, I don't see a smidgen of support for expanding WP:POG, and considerable support for contracting WP:POG. WP:POG should remain, in general, as it was before TTH BOLDLY edited it, until more restrictive standards are agreed on. — Arthur Rubin (talk) 13:09, 15 April 2019 (UTC)
  • You may disagree, but please don't accuse other editors of lying. It was quite clear from the debate that raged back and forth, that there was a range of views on how many portals there should be from zero to thousands. That means that there is a range of views on where to set the bar for portals and, in addition, editors debated the utility of portals, for example, to enable Wikiprojects to improve and extend the coverage of topics. That's not so much expanding WP:POG but tightening up the guidelines around portals so that they make clear what we're aiming at and why. The current guidelines are now out of date and, in any case, were always too vague which is why editors can't agree on how many to have and we've reached the stage where editors at different places on the spectrum are all using WP:POG to support their particular WP:POV. Finally, let me make clear that, underlying this proposal, is not an intent to maximise the number of portal, but to call a halt to portal warring while we sort out a consensus on the standards and purposes of portals that allows the community to move forward. In doing so, and to show willing at some risk of being criticised, I am actually going along with proposals to delete the majority of mass-created automated portals which IMHO do a major disservice to other, decently created and maintained, portals. Bermicourt (talk) 14:38, 16 April 2019 (UTC)
    • Then why is the proposal one-way? Why not have it also call a halt to any creation of new portals? And why would it stop MfD's for automated portals created by users other than TTH? UnitedStatesian (talk) 14:53, 16 April 2019 (UTC)
      • I don't have a problem with that either of those amendments. Would you support a rewording along those lines? Bermicourt (talk) 15:13, 16 April 2019 (UTC)
        • I take it from your silence you wouldn't even support a proposal with your own suggested amendments? Bermicourt (talk) 11:42, 17 April 2019 (UTC)
• Dear User:Northamerica1000. Perhaps you should read again. The sentence if nobody can compulse herself to step forward and claim to be a maintainer doesn't intent to compulse anyone to do anything. This is simply a reminder of the fact that WP:NOTCOMPULSORY is a double edged sword. No one can compulse the Wikipedia to keep large amounts of unmaintained shit, mainly produced by a 14 characters incantation, and that result in butchering the content (articles, pictures, etc) created by other people. Did You Know that spiders in the genus Plato have cubical egg sacs (about Plato, the featherless biped) ? Pldx1 (talk) 13:34, 15 April 2019 (UTC)

... at Wikipedia:Miscellany for deletion/Portal:Ireland. Espresso Addict (talk) 08:12, 22 April 2019 (UTC)

As it appears that some editors are choosing to attempt to define portal guidelines at Wikipedia:Miscellany for deletion, just a heads up that multiple (formerly) hand-curated portals have recently been suggested for deletion under a range of rationales. These include:

• Wikipedia:Miscellany for deletion/Portal:Royal Australian Navy
• Wikipedia:Miscellany for deletion/Portal:Water sports
• Wikipedia:Miscellany for deletion/Portal:Chitral, Pakistan
• Wikipedia:Miscellany for deletion/Portal:Caribbean
• Wikipedia:Miscellany for deletion/Portal:Amsterdam
• Wikipedia:Miscellany for deletion/Portal:Tiruchirappalli
• Wikipedia:Miscellany for deletion/Portal:Robotics
• Portal:Marvel Cinematic Universe bundled in Wikipedia:Miscellany for deletion/Portal:DC Universe
• Wikipedia:Miscellany for deletion/Portal:Rock music
• Wikipedia:Miscellany for deletion/Portal:Korea
• Wikipedia:Miscellany for deletion/Portal:Bohol
• Wikipedia:Miscellany for deletion/Portal:Kilkenny
• Wikipedia:Miscellany for deletion/Portal:EastEnders
• Wikipedia:Miscellany for deletion/Portal:Grey's Anatomy
• Wikipedia:Miscellany for deletion/Portal:Dungeons & Dragons

among others mainly on bands/people. They are rather getting lost among the larger number of automated portal deletion requests. Espresso Addict (talk) 21:20, 16 April 2019 (UTC)

Not so much. Old portals are being tested against long standing WP:POG, a cleanup that should have happened a long time ago instead of a focus on mass automatic creation. Please join in on the cleanup. Legacypac (talk) 21:49, 16 April 2019 (UTC)

It would help if you & others followed BrownHairedGirl's example in advertising your MfDs here. Espresso Addict (talk) 22:00, 16 April 2019 (UTC)

Interested editors should watchlist MFD. I'm not seeing a benefit to selectively soliciting input from the portal proponents. Legacypac (talk) 22:15, 16 April 2019 (UTC)

Agree with Legacypac; even BHG is only "advertising" here her larger noms. Watch MfD please. UnitedStatesian (talk) 22:17, 16 April 2019 (UTC)

Anyway one off MfDs and bundled ones where there is a specific Portal in the title are automatically on this very project page [1] Legacypac (talk) 22:15, 16 April 2019 (UTC)

Ah, that's interesting. Unfortunately it seems to have got stuck at 14 April, for some reason, many hundreds or thousands of deletion requests back. Did the bot get overwhelmed, or is it not running for some other reason? Espresso Addict (talk) 22:46, 16 April 2019 (UTC)

That is two days ago so not hundred or thousands of MfDs but anyway, not my bot, no idea about how it works. Just know there is no reason to do what a bot does any anyway. Watchlist MfD and all the portal mfds will come up. I calculate about 55% of remaining portals are now up for deletion, so one of these days we will get to the bottom of the bin. You can see the numbers update on the Project Page associated with this talkpage. Legacypac (talk) 02:53, 17 April 2019 (UTC)

I make it 1,315 portals, but I might have missed some. Espresso Addict (talk) 06:41, 17 April 2019 (UTC)

We are still waiting for thousands of sub pages to be reinstated so reversal of the automated system can work. We literally have 10,000 pages to restore still.--Moxy 🍁 23:40, 16 April 2019 (UTC)

Moxy (and anyone else), I am willing to undelete moderate sized batches of portal subpages that were deleted per G6, G7 or G8 for editors in good standing who will take responsibility for ensuring that the requests are within scope. Make a list somewhere (a user subpage of your own is recommended) and ping me to it. One editor - one list. Cheers, · · · Peter Southwood ^(talk): 06:29, 18 April 2019 (UTC)

I will go slowly make sure I do this right lets start with Portal:Calgary pls Pbsouthwood ...--Moxy 🍁 11:42, 18 April 2019 (UTC)

Is there a list somewhere? I haven't seen any open requests at WP:REFUND. UnitedStatesian (talk) 23:44, 16 April 2019 (UTC)

It's not clear to me that restoring 10,000 subpages is a sensible direction when unmaintained hand-curated portals are the subject of multiple deletion discussions. Is there a way of triaging the list so as to prioritise those portals where an editor/project has shown interest in updating & maintaining? Also those that were in better shape to start with, such as former featured portals? Espresso Addict (talk) 02:49, 17 April 2019 (UTC)

No way of triaging that I am aware of. Only admins can look at the deleted pages, and only one at a time. The structure of the old portals using up to scores of subpages means that it is not possible to even look at the portal without first undeleting all or most of the subpages, so it is simply easiest and quickest to undelete everything so anyone can take a look. Most will probably be have to be redeleted, but that is just the way the old portal system works. One of the real advantages of the one-page portal concept is that deletion and undeletion are quick and easy. and it is actually possible to view a deleted portal to a useful extent, though as they use much transcluded content, the quality may be better or worse than when originally deleted, because the transcluded content may have changed in the interim.· · · Peter Southwood ^(talk): 07:59, 17 April 2019 (UTC)

One can easily see how many subpages a portal had without restoring them. Just go back to the version in the history before the portal deletion notice was posted in April 2018, and look for statements in the code of the form "{{Random portal component|max=37|seed=43|header=Selected article|subpage=Selected article}}". Espresso Addict (talk) 23:47, 17 April 2019 (UTC)

It is not clear why one would want to know how many subpages a portal used to have. They have to be undeleted to look at the whole portal anyway.· · · Peter Southwood ^(talk): 06:01, 18 April 2019 (UTC)

Well, if the portal only had a handful (there are some up at MfD with only one selection in each box!), it probably isn't worth the effort. If, otoh, there are 15–20 or more in each section, it's probably worth giving resusitation a try. Espresso Addict (talk) 04:50, 20 April 2019 (UTC)

The difficulty of working with Portals with 73 subpages (to use an example I found) is one of the reasons that portal space has failed. Very few editors want to mess with it, or can figure out how to do all the coding. Restoration of these busted pages is a fools errand. I can build a great webpage on Wordpress with drag and drop and widgets. Portal construction takes a lot of coding knowledge most people have no interest in. Legacypac (talk) 12:42, 17 April 2019 (UTC)

73 subpages is nowhere near the maximum. Portal:Pornography had 467 by my rough count - could be out by a few - The new modal portals have one page. They are trivially easy to create and delete.Not so trivially easy to make them good, and not perfect by far, but most of us were working on improving them all the time, mainly by developing the tools to do it easily and quickly, sort of like the widgets to build a webpage, and precisely so that the ordinary editor does not need to mess with the coding. It would have been more constructive to assist with creating good creation and deletion criteria than this late stage mess and cleanup, which is what I and a few others were trying to do, but that is water under the bridge, and we still dont have useful and objective creation and deletion criteria. I predict that on close inspection a large proportion of the refunded portal subpages will be found to be from portals not as good as the ones that replaced them, and will be deleted again, but that is what the community or parts thereof want to do, so that is what we are doing. In the long run the alleged mess that TTH created may turn out to be the lesser evil and smaller timesink, but time will tell. Cheers, · · · Peter Southwood ^(talk): 14:21, 17 April 2019 (UTC)

The new portals have one page, no content, and display random errors, even if done "correctly". It's possible they might be kept if any (extended confirmed) user can "hide" the portal if it's acting up. (By "hide", I mean hide all links from articles (even if in templates) and from categories.) I don't think this is technologically feasible, but it seems a minimum requirement for automated pages which can display errors due to reasonable edits of other pages. — Arthur Rubin (talk) 18:50, 17 April 2019 (UTC)

No unique content - they are not content forks. They display existing content. Is there a requirement for them to contain unique content? If so, where?

The errors are not random, they are the consequences of bugs that have not yet been solved or of misapplication of component templates. When a bug is fixed, all instances of the associated error disappear from portals using the debugged component.

The ability to hide portal links for a specific portal is an interesting and potentially useful concept. Does anyone have any ideas of how it might be done? · · · Peter Southwood ^(talk): 06:06, 18 April 2019 (UTC)

Perhaps the errors are not random, although my understanding is that they are often not detected unless someone carefully looks at the display of the portal. They often due to making reasonable changes to a template or article, which damages the additional use made of that page by the portal. It is irrational to expect template or article editors to understand that the portal is making use of the material. If portal links are appropriate in the used page, perhaps invisible comments that the page is used by the portal and to be careful on editing should also be on the page. (These should DEFINITELY be deleted when the portal is deleted.) This also explains why automatic portals need a maintainer who actually looks at the portal.

As for hiding, if portals are always called by {{portal}}, a quick solution which allows anyone allowed to create pages in portal-space to disable a portal, but requires an admin to re-enable it, would be to change the local function checkPortalExists in Module:Portal to check that the portal exists but that "SHUTDOWN "+portal does not exist. Then Portal:Foo could be disabled by creating Portal:SHUTDOWN Foo. (Is space 100 Portal:). I don't know Lua well enough to tell if it could check whether Portal:SHUTDOWN Foo exists and is non-empty. — Arthur Rubin (talk) 07:02, 18 April 2019 (UTC)

@Pbsouthwood and Arthur Rubin: Why not simply hide or blank the portal page then? Wrap the whole thing in an HTML comment, or put a tag on the page itself. The module could instead be modified to check for that special tag and not list the portal. In fact, we could just use {{Portal maintenance status}} for this, since that's what it's there for, after all. Modify {{portal}} to not display a page with |broken=1 or any other value. Something we should've done after implementing the broken flag in the first place.. No need to create more pages for this, I think. — AfroThundr ^{(u · t · c)} 15:47, 23 April 2019 (UTC)

@AfroThundr3007730:, Can that be done? If I understand you correctly, {{portal|Foo|Bar|Baz}} would only display links to Portal:Foo and Portal:Baz if Portal:Bar was flagged as broken? Cheers, · · · Peter Southwood ^(talk): 19:36, 23 April 2019 (UTC)

@Pbsouthwood: That's the general idea, kind of piggybacking off of the earlier conversation. I believe it would still require a modification to Module:Portal to make it detect the flag and trigger this behavior. Unless you know of a way to make Module:Portal maintenance status cause the portal to appear as a redlink to other templates. @Certes and Evad37: you guys have any ideas on this? I really need to get into Lua one of these days... — AfroThundr ^{(u · t · c)} 20:03, 23 April 2019 (UTC)

You would need to do that in {{Portal}}, perhaps by changing Module:Portal's function checkPortalExists either to read the portal page and check for a flag or to check whether the portal is in some category of unwanted portals. Certes (talk) 22:25, 23 April 2019 (UTC)

@Certes: Not that this will be as resource intensive as most portal templates, but do you think it would be less expensive to check for category membership or scan the page wikitext? If we make this modification, I wouldn't want people objecting on performance grounds. — AfroThundr ^{(u · t · c)} 00:46, 24 April 2019 (UTC)

Or now that I think about it, I wonder if it would be more future-proof to scan the wikitext and check if the |broken= flag has a value. That would remove the need to edit the module again later if we ever change the categories. — AfroThundr ^{(u · t · c)} 00:49, 24 April 2019 (UTC)

AfroThundr3007730, I don't know what's possible in Lua, but that seems a good solution -- PROVIDED that {{Portal maintenance status}} is displayed (which it isn't by default, at least according to the documentation), and that portals are more difficult to protect (under guidelines) than articles. How else is a user to know how to report the portal as broken. It would certainly be less costly (in run-time) to check categories, than to scan for |broken=, but — Arthur Rubin (talk) 04:02, 24 April 2019 (UTC)

The Lua feature to check category membership is still in development. We'd have to read the portal page text and check for either the flag or the category. Whilst [[Category:Foo]] might be a marginally faster pattern to parse, a flag would appear much earlier in the page, so it's unclear which would be faster. I suspect it's moot as either would be trivial compared to the expensive operation of retrieving the page text from the database. I would go for the flag because it is more flexible, and because a category check would overlook category inclusion via templates. In particular, you're never going to detect pages with Lua timeout errors. Please note that I am commenting on what is feasible rather than what is desirable. Certes (talk) 09:13, 24 April 2019 (UTC)

See my comments on Wikipedia:Miscellany for deletion/Portal:Kathmandu. I was able to break the automated portal by wikilinking newspaper in an associated article. Since my kids have never read a newspaper wikilinking that word is not unreasonable to assist the reader, but it makes a completely dumb feature artcle on the capital of Nepal. The new portal already had 4 inappropriate featured articles so it's not like I made the page much worse. Legacypac (talk) 19:10, 17 April 2019 (UTC)

Once a multi-page portal is set up & running it is very easy to maintain and update. The number of subpages is irrelevant except for watching for vandalism. The one-page template-based portals can't be edited at all, as far as I can tell, or at least require Lua knowledge, not wiki editing knowledge. Espresso Addict (talk) 23:38, 17 April 2019 (UTC)

• Regarding bundled nominations, I feel that automated and hand-created portals should not be intermingled in one bunch. Some users may not take the time to view each portal and assume that they're all automated as per the many "delete per nom" bandwagon !votes occurring at MfD regarding automated portals. It would be detrimental for portals that meet guidelines to be indiscriminately deleted per this type of potential oversight. Furthermore, non-automated portals should be denoted as such in MfD discussions, as should portals with a history of being hand-created that were later converted to automation. North America¹⁰⁰⁰ 22:09, 17 April 2019 (UTC)

  Might also be a good policy to not bundle portals created by different users. · · · Peter Southwood ^(talk): 06:09, 18 April 2019 (UTC)

  That's a terrible idea. If the portals on two trivial television shows happened to be created by two different editors, there is no reason to unbundle the deletion nominations at MfD. UnitedStatesian (talk) 06:23, 20 April 2019 (UTC)

  You're only saying that from a maxi-deletionist viewpoint and, even then, there's some merit in it. For example, three FAPs that I created as an experiment were MFD'd together. There were no other editors involved. I fully agreed their deletion, so there was no need for a debate and there were able to be deleted quickly. Try to see where others are coming from before diving in with a knee-jerk reaction. Not everyone else in the world is a dummy. Bermicourt (talk) 07:06, 20 April 2019 (UTC)

The automated portals don't have fixable bugs, they have unfixable core design failures. By calling on templates, links in lists and other articles, DYK's and images chosen for articles they are absolutely guaranteed to break. The theory that portals can maintain themselves is seductive but the reality is that relying on automatically selected content will never give results that match what a human can select.

If editors wanted to test some automation it should have been done in a proper test environment not linked from mainspace and not 4500 pages large. Rigorous testing would have included efforts to break the design in various ways. Instead of testing, a flood of crap was unleashed, many pages of which appear to not even have been checked by the creators for obvious errors. Instead of saving portal space this group may have killed it off. What a massive waste of time and effort.

And Peter, I read your ideas for automatically building nav boxes from categories so that you could build portals off them. The community has done the testing you should have done on automatic portals and has rejected them. An automated portal based on an automatically created nav box is an even worse idea. Legacypac (talk) 08:44, 18 April 2019 (UTC)

Having played with fully automated portals (FAPs), I've concluded that they fail to meet the 2 most important roles of a portal. Firstly they don't provide comprehensive and balanced signposting of a topic because they rely on a single navbox that often does not provide representative coverage of the topic; they blindly pull all pictures off the main article regardless of relevance or quality; and the formatting is very clunky. I know they can be manually enhanced, but the FAP structure is too limiting to overcome the problems. Secondly, they totally fail the other important role of portals which is to provide WikiProjects with a tool for improving and extending coverage of a topic with a structure that gives a balanced overview of topic articles, highlighting where gaps are, listing top articles and wanted articles, categories, etc. Those 2 things can only be provided by intelligent, human interaction.

That said, I have found some level of automation useful, usually at subpage level, to keep lists and categories up to date or to rotate key article summaries and images that I, not some robot, have created.

In sum, FAPs do a disservice to those portals that are manually created and properly maintained and used by WikiProjects, not just to signpost readers, but to extend the quality, coverage and balance of topics on Wikipedia in furtherance of its aim. Bermicourt (talk) 09:32, 18 April 2019 (UTC)

I agree with the core of @Bermicourt's summary and conclusion. I have examined hundreds of these FAPs, and studied the code used to make them, and I find that they are simply bloated WP:REDUNDANTFORKs of the navbox.

Note that there are also FAPs which use a single list article instead of a navbox, and they have almost the same set of failings.

However, I disagree with Bermicourt's comment about WikiProjects. Features should be added to portals only if they are a significant addition for readers. WikiPrject-focused content should be in project space. --BrownHairedGirl (talk) • (contribs) 13:18, 19 April 2019 (UTC)

@BrownHairedGirl:. Thanks, that's helpful. But I have a question: since neither portals nor Wikiprojects are in mainspace, why do the project aspects need to be in project space? They're already off the beaten track in portal space so from a reader's perspective it makes little difference (as your stats show). Bermicourt (talk) 18:33, 19 April 2019 (UTC)

Portals are (I believe) supposed to be user-facing, and Wikiprojects are not. If Portals were not user-facing, they shouldn't be linked from articles and categories, and most people wouldn't care if they were malformed. — Arthur Rubin (talk) 18:54, 19 April 2019 (UTC)

@Bermicourt, I think that @Arthur Rubin puts it v well.

If the assumption is that portals get leeway 'cos readers mostly ignore them, then why focus them at all on readers?

I think that this is quite fundamental to the whole question of where portals go from here, and it needs a lot more exploration. --BrownHairedGirl (talk) • (contribs) 19:34, 19 April 2019 (UTC)

I'm not sure what "portals get leeway" means, but Arthur Rubin's point is crucial. I'm discerning that one of the problems with portals is that editors are viewing them from different standpoints. So there are editors who a) don't use them but think they are intended to be articles and then slam them because they don't get many hits or b) create them with the intention that they are like signposts to mainspace articles and showcases of the best articles and images, overlooking the fact that they don't get many hits or c) create them in order to help Wikiprojects improve quality and coverage in a coherent way, and therefore don't care if they don't get many hits because that's not the intention. So we're all talking past each other depending on our use/non-use of portals and our differing perspectives on what they're for (and I'm sure I've missed other perspectives). Anyway, unravelling all that is certainly fundamental to the future direction of portals. Bermicourt (talk) 20:52, 19 April 2019 (UTC)

I don't see the abc analysis as sensible.

1. If Portals are user-facing, then they (1) should provide maps (or, at least, pointers into) broad topics, and (2) they shouldn't have errors. That they are not used much probably shouldn't have much significance. If they are well-designed, they should have links from mainspace and other indices into Wikipedia. If they are not well designed, they should go away.
2. If Portals are editor-facing (which I hadn't heard as an option before recently), they should be approved by the editors who would use them (WikiProjects, in option (c)), and should NOT have pointers from mainspace or category-space. Errors and missing sections aren't as important, if that is a (true) indication that we don't have any material that should be in the sections. "Random article" and "Random image" sections should be replaced by lists of relevant articles and lists of appropriate images.

Irregardless, there are probably 1 or 2 good portals. ("Current Events" may be in portal-space, but it doesn't act like any other portals.) — Arthur Rubin (talk) 23:06, 20 April 2019 (UTC)

@Arthur Rubin: I agree with Bermicourt's comment above, since depending on your perspective, portals have served several roles, often simultaneously. Many seem to use a hybrid approach, showcasing articles on the subject matter (serving as gateways to further explore the topic), and also showing project-facing material regarding the subject (serving as gateways for new potentially interested editors to get involved). The German Wikipedia has also used a similar model (and I'm not sure who came up with it first). It seems to work well, when implemented correctly. — AfroThundr ^{(u · t · c)} 16:01, 23 April 2019 (UTC)

@AfroThundr3007730: If portals have multiple uses, they must still be shut off from user-facing pages if they have errors, even if this makes them difficult for use by editors. This makes the necessary logic of hiding broken portals from users even more complicated. But I don't see how portals can be useful to both users and WikiProjects. — Arthur Rubin (talk) 03:52, 24 April 2019 (UTC)

@Arthur Rubin: I agree we don't want user-facing portals with errors although we need to be careful not to set a higher bar for portals than for mainspace articles. But I can see a well-designed portal facing both readers and editors. The readers see a good balance of links across the topic with top articles and images showcased, links to the topic categories and links to recently created or upgraded articles. Editors (especially WikiProject editors) get to see the degree of coverage, the top wanted articles and links to subpages where they can record their interests, discuss priorities for new articles or good article upgrades, list all wanted articles, articles in need of improvement, wanted images, all that kind of stuff. And the fact that those editor links are visible on the portal may attract others to get involved. Certainly German Wiki works that way and everyone seems to be happy. But they do have strict standards and no-one can create a portal willy-nilly - it has to go through a process and be 'ready to rock' before it's launched. HTH. Bermicourt (talk) 17:13, 24 April 2019 (UTC)

We should not forget that automation was proposed as a remedy to some design failures of the so called 'manually maintained portals'.

1. Lack of maintenance. When using subpages, a main subpage contains calls to (and transclusions from) subsubpages. The subsubpages themselves are more than often hand selected pieces of mainspace articles, that are cut once for ever and never maintained. A solution could be using automated subsubpages. E.g., using a page .../dongnamgangnu containing something like {{#section: Hwaseong Fortress |dongnamgangnu}} where "dongnamgangnu" refers to a pair of tags placed in the Hwaseong Fortress article. And now, the snippet is automatically maintained when the main article is changed.
2. Lack of useability of the templates. When using {{Transclude excerpts as random slideshow | .../paldalmun | .../namsumun| .../dongnamgangnu }} , the page .../dongnamgangnu isn't selected. On the contrary, .../paldalmun is selected because this subsubpage was created using {{subst:#section: etc . But obviously, this one is no more automatically updated.
3. Lack of useability of the templates. Let us create a page .../structure containing a list of links to, say, .../paldalmun and Joseon. Then {{Transclude list item excerpts as random slideshow|.../structure}} ignores the .../paldalmun page. Because of a titleObject.namespace == 0 clause in Module:Excerpt_slideshow.
4. Lack of useability of the templates. When a gallery is included in the snippet, the randomslideshow knows better than you, don't transclude the gallery... and don't use the images either.
5. Lack of maintainability of all this enchilada. When you try to construct a portal in some private space, using pages in this private space, in order to only launch a tested portal, part of the features are not available.

Therefore, reverting to manual doesn't appear to be a solution either. Pldx1 (talk) 11:14, 18 April 2019 (UTC)

Regarding "A solution could be..." in point 1 above: I don't think editing articles to make their code more complicated just to support portals (which readers don't use) is an improvement to wp. When newbies click on the "Edit" link every extra bit of markup etc could be confusing and offputting. There may also be issues such as what if several portals want to use the same article? DexDor ^(talk) 11:59, 18 April 2019 (UTC)

I agree that articles should not be made more complicated to make them easier to use in portals, but the transclude excerpt tools for portals have gone a long way towards making it easier to use a part of an article in a portal, without any direct affect on the article. Unfortunately, a badly written or badly formatted section remains badly written or badly formatted when transcluded, but it only has to be fixed at one place. The excerpt transclusion tools also work the same if several portals transclude the same or overlapping content. · · · Peter Southwood ^(talk): 12:26, 18 April 2019 (UTC)

But would such content sharing run counter to the WP:POG guideline's statement that portals ". . . should not be redundant to another portal. . . "? I would consider taking to MfD a portal that shared content in that way. UnitedStatesian (talk) 12:46, 18 April 2019 (UTC)

I was thinking of things like maybe Portal:France and Portal:Paris both taking material from the Paris article. Another example might be an article about a train disaster being used by Portal:Trains and Portal:Disasters. DexDor ^(talk) 17:44, 19 April 2019 (UTC)

Any plan that involves editing articles/Navboxes/etc to make the article/navbox/etc work better for a portal that is scraping the other page designed for another purpose is doomed to failure. Innocent editors will eventually undo or break whatever changes you make that are for the portal. Of course general article improvements are always welcome, but changes that only benefit the portal are unlikely to stick. Legacypac (talk) 18:21, 19 April 2019 (UTC)

I like the idea of hidden anchor points a lot, and don't think they'd necessarily cause editors much trouble. WikiProject Medicine articles often have a huge amount of hidden text explaining what goes where, for example, and yet inexperienced editors seem to have no trouble editing them.

I've suggested in a number of places that it would be useful if the extract paragraph function could take more parameters; much of the problem with using it is (1) some articles have a short lead with many very short paragraphs, while others have mega-paragraphs, so column balance is impossible; and (2) the image that's extracted is unusable (eg a flag blown up to monstrous proportions, a map, or an image that duplicates one used elsewhere in the portal): flexibility to choose the image, its legend & size would make this much more workable. Espresso Addict (talk) 05:27, 20 April 2019 (UTC)

Placing hidden code in articles (just to support portals) is unlikely to be popular. It would be another way that portals impact negatively on the rest of the encyclopedia (e.g. by causing watchlist noise on articles). Maybe an RfC would be a good idea before implementing such a scheme. Note: (afaik) the main page doesn't do this to articles so why should portals? DexDor ^(talk) 07:53, 20 April 2019 (UTC)

Wikipedia is made of articles. Portals are an adjunct to the articles and should never make articles more difficult to edit. If content is to be extracted from an article for use in a portal (a thing that I support in principle), this should happen without any requirement for change to the article, except possibly changes that fix bad formatting, and general inprovements to the article like better lead structure and content, but those are desirable whether a portal uses the content or not. The content extraction tools must deal with normal article structure, but if they can't deal with deprecated structure it is OK to fix that. Watchlist noise is the least of my concerns, though obviously others may consider it more iportant. On the other hand, it is normally accepted to put an anchor in when a section name is changed, but I somehow don't think this is what is being proposed here. An anchor at a section header has a reasonably obvious purpose, and even that can become wrong or confusing if a rewrite moved content between sections. Cheers, · · · Peter Southwood ^(talk): 13:45, 20 April 2019 (UTC)

@DexDor: The main-page TfA uses a hand-written blurb; it is not transcluded. As the blurb only shows for a day, it does not matter that it becomes outdated. Espresso Addict (talk) 06:14, 21 April 2019 (UTC)

Legacypac makes a good point that making changes that are mainly aimed at convenience for a portal are unlikely to stick, but changes that benefit both article and portal should be generally accepted, and in many cases that is the obvious thing to do. A lead section that is edited to summarise the article usefully and to comply with the recommendations for good article will inherently improve it for use as a summary in a portal. Using an image in the lead which represents the topic of the article well enough to be appropriate in an excerpt used by a portal is good practice in almost all cases. (we do have some apalling lead sections) Cheers, · · · Peter Southwood ^(talk): 14:03, 20 April 2019 (UTC)

Likewise changing the image in the lead of an article purely for portal convenience (eg to avoid repeating images) is only going to stick if the image is a clear improvement, which is why we need the auto-extract to allow the specification of an image. I assume this is reasonably trivial to implement, yet afaik no-one has yet done so, despite the many times/venues in which I have mentioned this very real problem. The only way around this of which I'm aware is to go back to the hundreds-of-subpages model. Espresso Addict (talk) 06:36, 21 April 2019 (UTC)

UnitedStatesian, There is a difference between two portals sharing some content that is relevant to both topics, and one portal being redundant to another. Disallowing all overlap is not practicable - which portal should get the exclusive rights to content which is fundamentally relevant to several topics? There is a frequently mentioned criterion that portals should be on broad topics, and the broader a topic is, the more likely it is that it will share some content with other broad topics. · · · Peter Southwood ^(talk): 14:19, 20 April 2019 (UTC)

• Dear fellows. Please, let us remain focused on "we should not forget that automation was proposed as a remedy to some design failures of the so called 'manually maintained portals'." The point is: what to do in order to have up-to-date snippets in the portals' windows, and not describe Ban Ki-moon as the actual Secretary-General of the United Nations now in 2019, when he was replaced in 2016.Pldx1 (talk) 19:56, 20 April 2019 (UTC)

Good point. And also that there are good automation features and bad ones, just as there is good and practice in using automation. The most glaring example of the latter is the use of automation to create an entire portal in seconds without any human intervention, a practice that led to the almost random creation of over 1000 new portals in less than a year and has resulted in an anti-portal backlash. Bermicourt (talk) 20:53, 20 April 2019 (UTC)

@Pldx1: In the hundreds-of-subpages model, in many cases there's no reason not to replace the old static extract in the subpage with a transcluded extract from the lead. It might not be ideal, but it is probably better than the Ban Ki-moon problem. Espresso Addict (talk) 06:45, 21 April 2019 (UTC)

there is no reason... Surely, there are no theoretical reasons! But there are practical ones, see §2-5 of the initial post atop this section. How to create a random slideshow with transcluded snippets ? I haven't seen how from documentation, and --at least now-- I haven't the motivation to study the code of the various templates and write another version if needed. Pldx1 (talk) 08:07, 21 April 2019 (UTC)

@Bermicourt, a wee correction to your comment that automation facilitated drive by-portals and led to the almost random creation of over 1000 new portals in less than a year. I estimate the total figure to be over 4,000 new portals, from a base of ~1,500.

TTH alone created over 3574 portals (including up 400 redirects) between 23 August 2018 and his cessation in February 2019. That was the count of currently extant pages which I gleaned from the portal-page creation sunset of TTH's contribs list on 14 April when I started making the lists for my two mass deletions of similar portals: one, and two. Dozens, possibly hundreds of TTH's creations had already been deleted or redirected. Plus several other editors were prolific creators of automated portals: at least one created over 100, one over 50, and many more created smaller numbers.

I agree that there are good automation features and bad ones. The problem was that there was insufficient evaluation, partly because TTH was so driven, and partly because none of this was set out at RFC.

RFCs can be slow, exasperating and perverse, but they are also a very good way of ensuring that issues get considered by people other than those who may too close to the workings to remember all the big picture issues and/or fallen prey to groupthink. Whatever happens in future, I hope that it will include testing ideas at RFCs, because they usually lead to better decisions in the long-term, even if they can be annoying in the short-term. --BrownHairedGirl (talk) • (contribs) 04:34, 25 April 2019 (UTC)

Pldx1, Have you tried asking for an explanation at the talk page of any of the templates you find difficult to understand? These templates were largely still in development - some may not yet be fully developed and debugged, so the documentation lag is not entirely surprising. Cheers, · · · Peter Southwood ^(talk): 04:44, 25 April 2019 (UTC)

@BrownHairedGirl: Sorry, yes, wow it was a lot more than 1,000! My contribution was just 4 of which I've agreed 3 can be deleted as they were really an experiment that just showed me how unhelpful they were. The fourth I hope to develop manually if it survives MFD as I think it lends itself to a portal... Bermicourt (talk) 06:28, 25 April 2019 (UTC)

@Pldx1:, you should be able to figure it out from looking at examples of existing uses. The templates themselves will tell you almost nothing; the processing is all done in Lua by Module:Excerpt slideshow. --BrownHairedGirl (talk) • (contribs) 06:37, 25 April 2019 (UTC)

Dear Pbsouthwood and BrownHairedGirl. You are right. The correct and 'state of the art' terms weren't template nor module, but procedures. My point was about these pieces of code that are supposed to implement some political decisions. Many people are involved: the political body, the writer of the code, the users of the code and the future maintainers of this code. The way a piece of code is documented says many things about a whole project. And what I perceive is as follows: code writers were not convinced of the perennial nature of Project Portal. By the way, reading and understanding Lua code is not that difficult. It suffices to import this code into some tool that numbers the lines. Pldx1 (talk) 08:20, 25 April 2019 (UTC)

Another novel deletion rationale: See eg Wikipedia:Miscellany for deletion/Portal:Andes and probably others. Espresso Addict (talk) 04:51, 27 April 2019 (UTC)

Since this is effectively a rephrasing of "subject area not sufficiently broad" (i.e., a violation of the WP:POG guideline), it is neither novel nor inappropriate to use as part of a good-faith nom.; the community will decide on each one if it is legitimate in each case. And of course, in the specific case of Wikipedia:Miscellany for deletion/Portal:Andes, the !voters seem to be rejecting the not-broad-enough argument. UnitedStatesian (talk) 11:25, 27 April 2019 (UTC)

I've been restoring older portals that have been automated back to their pre-automated versions. It is very time-consuming, laborious, can involve many steps, and requires a strong attention to detail. It also requires having a strong knowledge of how portals are designed, their layout, coding and wiki markup, portal templates, portal guidelines, etc., knowledge that many users may not necessarily possess. I'm not aware offhand of others who have taken up this task. It would be great if others who are competent in such matters would consider pitching-in. One person can only do so much. North America¹⁰⁰⁰ 18:08, 12 April 2019 (UTC)

I am knowledgeable but don't have the mop. What can I do to help? BusterD (talk) 18:12, 12 April 2019 (UTC)

• (ec) Hi BusterD: You can check for portals that have pre-automated versions available, such as from the hatted lists above on this page, and if there's functional content available, then perform the necessary reversions on the main portal pages and subpages. For pages that were deleted per WP:G6 uncontroversial deletion, you can simply recreate them anew from scratch, or request for them to be restored at WP:REFUND. These will typically appear as redlinks on the main portal page. North America¹⁰⁰⁰ 19:08, 12 April 2019 (UTC)

I've taken the liberty of restoring Portal:American Revolutionary War and its subpages. I can't imagine I missed much. Please look to see if I'm getting it right. I don't want to leave a mess behind myself. If there's a better way, please clue me in. BusterD (talk) 19:07, 12 April 2019 (UTC)

BusterD: Thanks for your prompt replies and actions. I spot checked a bunch of subpages of Portal:American Revolutionary War, and fortunately, it appears that none of them were G6 deleted or tagged with this notice, the latter of which makes the notice appear on the main portal pages because <noinclude> parameters were not used. The notice is also on some box-header and box-footer pages, and when so, also appears on the main portal pages. North America¹⁰⁰⁰ 19:15, 12 April 2019 (UTC)

When I see such a G6 tag, I'll simply delete it as unneeded. I'm starting with portals I know, then will work outwards. BusterD (talk) 19:19, 12 April 2019 (UTC)

That's what I've been doing when the G6 notices are there. I've spend a lot of time doing so. Pinging Dreamy Jazz to this thread, as they have been working to remove the tags per discussion at their talk page. North America¹⁰⁰⁰ 19:24, 12 April 2019 (UTC)

Northamerica1000, hello. I am still waiting for approval for AWB before I can do mass removal. I suspect it will be some time, but when I'm approved I will start removing notices. Dreamy Jazz 🎷 ^{talk to me | my contributions} 19:26, 12 April 2019 (UTC)

Dreamy Jazz: Hey, it's appreciated, and these things can take time. You can still perform portal reversions to non-automated versions and manually remove the tags when they're present, if you'd like. North America¹⁰⁰⁰ 19:37, 12 April 2019 (UTC)

User:BusterD to save yourself a lot of wasted effort please familiarize yourself with WP:POG and the very clear results of the MFDs. Working on restoring various classes of portals is an exercise in frustration when pages in these classes will be nominated for deletion. Large classes include individual people, bands, TV shows, media franchises, films, companies and organizations. Also expect to see all towns below some yet to be deturmined exactly size gone. Third level administrative divisions of countries, as well as some 2nd level divisions have been deleted across multiple MfDs. If it looks like a US county type political subdivision it will most likely be deleted. Any narrow focus general topic is likely to be chopped. Feel free to Twinkle anything you find in your sicting through portals that needs to go. This portal project went wild making new portals while not cleaning up the problems discussed at WP:ENDPORTALS and the end result will likely be less portals then they started with after ENDPORTALS. Legacypac (talk) 19:33, 12 April 2019 (UTC)

Wisdom in that. I thought I'd work through the WikiProject:Military History portals first because they were each around long before all this hubbub and have an active base of potential maintainers. Then I'll start picking out portals which have avoided deletion during process. For the record, I've always thought this automated portals stuff was way too much, but I believe I've learned some things about how automation could make a portal easier to maintain manually. BusterD (talk) 19:40, 12 April 2019 (UTC)

• @BusterD and Dreamy Jazz: Sure, I would start with portals that have a broad topical scope and meet WP:POG. North America¹⁰⁰⁰ 19:40, 12 April 2019 (UTC)

• Nb. Category:Formerly curated portals that are presently automated

• Lists portals that will likely require various subpages to be WP:REFUNDed at Requests for undeletion prior to being reverted to pre-automated versions.
• This is necessary to prevent red-linked pages from appearing on the main portal pages.

–North America¹⁰⁰⁰ 20:18, 12 April 2019 (UTC)

I'm finding the early going rather easy. It helps that the original MilHist portals were relatively sturdy before automation. It also helps that apparently there was considerable forbearance from admins not deleting G6 subpages immediately. So far this has been a simple matter of reverting to before TH's first edit on 11APR2018, then deleting the G6 tags, mostly from the intro and the box-footer. I've been through half of this template and I'm only needing 4 red linked pages restored so far, so it's not too bad yet. At my current rate, I'd estimate about 75 hours labor all told. That's just cutting the timber, not pulling the stumps (I must go back to Portal:USMC and completely rebuild because of some old fashioned selection structure on two subsections). BusterD (talk) 21:02, 12 April 2019 (UTC)

Can I ask why this is being done? TTH's mass creation of portals is a very different issue to this project's work on finding ways to reduce the maintenance burden of portals. It makes sense that the former should be undone but reverting automatically maintained portals to manually maintained ones, when there's nobody to actively maintain them, needs some justification. WaggersTALK 12:26, 17 April 2019 (UTC)

@Waggers: I think the consensus is that automation, while a very good thong in theory, has flaws in its current, rushed implementation, that are technical (e.g. possibility for Lua errors and presentation of unrelated content), philosophical (e.g. removal of the WikiProject to-do lists, adding of a link to the reference desks), and procedural (e.g. rammed through almost entirely without discussion of the specifics with the community and subject-matter WikiProjects and gaining of consensus, and without testing or documentation). UnitedStatesian (talk) 12:48, 17 April 2019 (UTC)

• I restored Portal:Middle East to its pre-automated version. It would benefit from expansion with more selected content, using WP:SUBPAGEs. North America¹⁰⁰⁰ 02:55, 28 April 2019 (UTC)

• It was recently brought to my attention that the {{Portal maintenance status}} template automatically populates Category:All portals, a matter I was not aware of. This was easy to not know about, because the template had no information about this in its documentation, which I have corrected by adding a notice atop the page (diff). So, when performing reversion of portals to pre-automated versions, please be sure to check that the Portal maintenance status template is in place. I inadvertenly erred in not doing so, but have gone through my edits, and it appears that everything is now properly in place. If unsure what to do, the following wiki markup listed below can be added, which will serve to populate the category. Thanks! North America¹⁰⁰⁰ 17:54, 29 April 2019 (UTC)

{{Portal maintenance status |<!-- {{subst:DATE}} --> |subpages= |nonstandard= |broken= |incomplete= |upgrade= |manual= |maintainer1= |maintainer2= |maintainer3= |maintainer4= |note=}}

In the last 6 weeks, over 3,000 automated portals have been deleted at MFD as WP:REDUNDANTFORKs of a single other page. In most cases, those other pages have been navboxes, but the same principle has been applied to delete portals which build their "selected articles" list off other types of single page: lists, head articles, etc.

So I was surprised today to see Auric (talk · contribs) has been editing some portals to change the source of their list from a single template to another single page, usually the head article or an outline page. In each case the edit summary used has been unhelpful, if not outright misleading: the single word "fix" or "update".

I have reverted the 7 such edits which I have found: see my 7 reverts[2].

I don't know why Auric has done this. However, I note that one of the effects of those edits was to remove each portal from the tracking category Category:Automated portals with article list built solely from one template. I hope that was not the intention.

Note that while redundant forks are always a bad idea, using the head article as the source of a "selected articles" list (as Auric did in this edit[3] to Portal:Yemen) is a spectacularly bad idea, beacause te articles are not written with the object of being mined in this way. For an illustration of what can happen, see Wikipedia:Miscellany for deletion/Portal:Lusaka.

Please can editors not do this? --BrownHairedGirl (talk) • (contribs) 14:33, 26 April 2019 (UTC)

My summary was not misleading, because before the edit, only two boxes were showing. Afterwards, the full range of boxes expected in a portal were visible. For some reason the portal remained fixed after the reversion. This happened in every portal I edited, with the exception of Portal:Jordan.

The intention of my edits were to remove portals from Category:Portals with errors in need of immediate attention. I used the outline page, because simply using the head article caused a Lua error.--Auric talk 15:04, 26 April 2019 (UTC)

Thanks for the expalnation, @Auric

It's still better to use the edit summary to explain what you have actually done, especially when it does something as major as change the source of the portals's content. Just about any edit to a portal is some sort of a "fix".

Anyway, there seem to be two issues here:

1. Why was "Template: Foo topics" as a page source causing these formatting glitches? It would be good to resolve that
2. Before and after Auric's edits, each of these these 7 portals remains a WP:REDUNDANTFORKs of a single page. They should be either reverted to a manual version (if a decent one exists), or just deleted. I will start researching them and MFDing them if appropriate.

--BrownHairedGirl (talk) • (contribs) 23:31, 26 April 2019 (UTC)

Thanks for understanding. I wonder if it is because their navboxes all seem to be named Template:[country] topics and not the usual Template:[Country]? --Auric talk 00:45, 27 April 2019 (UTC)

I agree 100% with BrownHairedGirl about informative edit summaries.

Consensus is clear for the deletion of portals that draw solely on a single navbox and have no other history. Legacypac has proved that drawing from the head article, even if it seems to work, is not robust to reasonable edits to improve the wikilinking of the head article.

However, I'm not convinced that there's clear consensus at present regarding outlines. I was going to look at Portal:Classical architecture, which I thought on a very quick look might be viable, or at least an interesting idea, but to be honest I'm drowning in more urgent things to do at the moment. It might be good to discuss here the ways in which portals drawing on outline articles work and fail to work, and perhaps could be improved. Pinging @Auric: Espresso Addict (talk) 00:49, 27 April 2019 (UTC)

@Espresso Addict, a fork is a fork. The long-established guideline WP:Content forking#Acceptable_types_of_forking provides no exceptions for portals.

If you want to make an exception for portals, that will need an RFC. I oppose any such proposal as a "license for more portal spam", but you are of course free to propose it. I reckon that any such proposal will be resoundingly rejected by a community which has clearly rejected spam portals. --BrownHairedGirl (talk) • (contribs) 15:25, 27 April 2019 (UTC)

A content fork is the creation of multiple separate articles (or passages within articles) all treating the same subject. I'd say that excludes portals and other non-article pages. There is also plenty of precedent with categories and navbox templates, many of which are essentially copies of each other or of lists in articles. Of course, many lists and outlines do not merit a portal for other reasons, but I don't think the WP:Content forking guideline is a valid argument against appropriate use. Certes (talk) 12:38, 29 April 2019 (UTC)

This comment is directed specifically toward Certes, as I find myself in agreement with your assessment. It's clear that the community is against most automated portals, with or without the use of WP:REDUNDANTFORK as a rationale. Redundant fork and the entire Wikipedia:Content forking page was written specifically in regards to articles, and states nothing about Portal namespace content. Fact is, there is nothing about portals on the page at all; even the word "portal" is not present. Conversely, the word "article" is used 100 times throughout the page (as of this post).

Ultimately, I view the use of Redundant fork toward Portal namespace content to be a slippery slope and overextension of the Content forking guideline page, as well as the intent of the page when it was written; it's about articles. That said, I can understand that others feel that RF it is applicable toward automated portals. However, per the slippery slope, Redundant fork could then potentially be used to rationalize the deletion of old-school, curated portal pages as well, since they present content from various articles.

I'm already aware that the OP and others disagree with some or all of my opinion, and this comment should not be misinterpreted as criticism toward anyone, because that's not the purpose or intent. In other words, please do not take it personally. I respect that people are entitled to their own opinions, and I also respect that I'm entitled to mine. Peace. North America¹⁰⁰⁰ 21:44, 29 April 2019 (UTC)

• My problem with the redundant fork wording is that it's so far divorced from what the guideline actually literally states (because the guideline relates to articles and not portals or other meta-content), that one can argue for the deletion of virtually anything based on it, from the main page downwards. I'm sure that BrownHairedGirl has no such intention. However, many less-thoughtful nominations at MfD have been made during the past few weeks.

One one hand we have hand-curated portals, which are being nominated for deletion on the basis of being limited and out of date.

On the other we have automated portals, which are being nominated for deletion on the basis of being a duplicate of mainspace and subject to mess-ups from pulling in dynamic content.

Both positions are to some extent true. But we are bound by the decision of last year's well-attended RfC that some portals, broadly the number we had last year, are at least tolerated by the community. We need to find a happy medium here, and avoid discussing good-faith creations of either type with rationales/comments along the lines of "nuke them from orbit". Espresso Addict (talk) 03:50, 30 April 2019 (UTC)

I was going to do a Today in MfD summary, but I notice the alerts bot is back up at last, so I don't need to. After a slowdown for a few days, there were 13 deletion requests yesterday, ranging from maintained former featured portals, to macro & micro hand-curated portals, to automated portals based on a single navbox. Espresso Addict (talk) 09:42, 30 April 2019 (UTC)

• What's with all these swipes at TTH in the xFD forums?--Paul McDonald (talk) 12:32, 30 April 2019 (UTC)

@Paulmcdonald: The Transhumanist created literally thousands of portals based on a number of fully automated methods that the community has largely or entirely rejected. He stated that they could be created in ~a minute each. Many of them were embarrassing in quality and on topics even I thought were too narrow. They also unilaterally and in some cases over objections from maintainers rebooted a large proportion of existing portals to these now-rejected methods, and got the subpages deleted, so that reconstruction is a long and fiddly process. If you want a longer history, try the admin noticeboards & ArbCom, passim. Espresso Addict (talk) 13:58, 30 April 2019 (UTC)

Then the issue is the content created, not the editor creating it. At least it should be.-Paul McDonald (talk) 14:27, 30 April 2019 (UTC)

In theory, yes, but when that editor was responsible for well >90% of the issue, created 100% of the tools that other editors used for the remaining <10% of the issue, and did nothing to cleanup the mess he made once it was discovered, it is difficult to maintain the distinction. UnitedStatesian (talk) 14:44, 30 April 2019 (UTC)

@Paul McDonald, you've evidently missed the many wider discussions. TTH personally spammed out over 3000 drive-by junk portals, and left others to clean up after him. He also converted hundreds of older portals to automated junk, and created portals on insanely narrow topics whch were conceptually broken

Many editors have put in hundreds of hours of work cleaning up after him, and despite all two months of MFDing we are still a long way from clearing up the mess. His rampage is a significant factor in many current discussions, which is why he is so often mentioned, either by name or as "the portalspammer". Note that the portalspammer has done almost nothing either to assist in the cleanup, or even to help triage the results of his rampage. --BrownHairedGirl (talk) • (contribs) 14:47, 30 April 2019 (UTC)

I think TTH may be topic-banned from assisting. — Arthur Rubin (talk) 18:39, 30 April 2019 (UTC)

No, there is no portal-space ban on TTH. For starters he could CSD G7 the remaining junk portals he created and save other editors the work of bringing them to MfD. UnitedStatesian (talk) 19:06, 30 April 2019 (UTC)

Where are these discussions?--Paul McDonald (talk) 19:48, 30 April 2019 (UTC)

@Paul McDonald, see e.g. the huge cluster of discussions at WP:Administrators' noticeboard/Archive307#Thousands_of_Portals. --BrownHairedGirl (talk) • (contribs) 20:25, 30 April 2019 (UTC)

A search now brings up 47 pages for "portalspammer". Perhaps it would be polite to cease using such terms, especially whilst discussing a block for name-calling elsewhere. Certes (talk) 15:48, 1 May 2019 (UTC)

I agree as that comment seems extraordinarily uncivil to me. What I see happened was there was an enthusiastic editor (a good thing) who had an idea (a good thing) and shared it with others in the Portal project (a good thing) and then rolled it out in high volume (with less than welcome results). Imagine having 3,000 or so unique pages you created suddenly get nominated for AFD in 6 weeks (or whatever the time frame is) and then people use comments like "3000 drive-by junk portals" and "portalspammer" to describe you and your work. There's no call for language like this. I understand that comments were made down the road and I have not reviewed those, I trust the final decisions of those who made it. Regardless, we should be above any personal attacks. We should be able to address this issue without calling anyone any names.--Paul McDonald (talk) 22:04, 1 May 2019 (UTC)

@Paul McDonald and @Certes see WP:SPADE.

This was spam, and it was pursued at high volume over objections, without attempts to seek a broad consensus. Many objectors were just shouted down; several formerly active members of this project quietly withdrew until TTH's eventual demise. Along the way, TTH repeatedly and stealthily rewrote the portal guidelines to justify his spam: by stealthily, I mean with no indication in the edit summaries of the nature of the change. He was then furious when I reverted the guidelines to the last stable version before his messing, and outraged that he should have to seek consensus.

This was not a good faith effort. It was organised steamrollering, and when challenged TTH complained that it was terribly hard work it took him between 60 and 120 seconds to create each of these portals (Have you tried creating 500 portals? It is rather repetitious/tedious/time-consuming (from 500 to 1000 minutes))

This was not the conduct of a good faith editor. A good-faith editor would not insist that an RFC decision not to delete all portals meant a consensus to create thousands more. A good-faith editor would treat sustained objections as a time to discuss and to draft RFC, not to shout people everyone down. A good-faith editor would not stealthily rewrite guidelines. A good-faith editor would not ignore calls to slow down. A good-faith editor would not stealthily convert hundreds of curated manual portals to his junk automated format without a consensus to do so, and would not ignore or override the objections of those portals' maintainers. A good-faith editor would accept that consensus had rejected his plan, and assist in the cleanup -- at least by helping identify which portals fitted various criteria. A good faith editor would not stealthily intervene in the debate on the portal-to-nowhere MFD:Portal:University of Fort Hare by trying to boost its numbers by enabling inclusion of stubs (as TTH did stealthily on 16 March 2019, at 03:05). A good faith editor would not have created dozens of pseudo-portals with less than 5 pages within their scope, and a good faith editor would not have created a redirect specifically to allow a portal to include content unrelated to the topic (see MFD:Portal:Palace of Versailles).

If I behaved like TTH did, I would expect a permanent topic-ban or, if not an actual siteban. TTH was very lucky to escape one.

I referred to TTH as "the portalspammer" in the nomination statement of each of the mass deletion MFDs (one and two). Those two MFDs were advertised at WP:CENT, and had a massive turnout. They have between them had over 6,000 pageviews in the last 3 weeks, which BTW is the same number of views as the median 21 portals got in the same period ... and I saw no objections in either discussion to my use of the term.

So no, I will not to stop using the term. It's an accurate description of what TTH did, not of his character, so it is not a personal attack: see WP:NPA#WHATIS. Calling the portalpsapmmer the portalpsammer is clearly not part of the definition. --BrownHairedGirl (talk) • (contribs) 23:57, 1 May 2019 (UTC)

I have no opinion at this time on the behavior of the editor that led to the topic ban, and this is not the place for it. I'm confident those involved got it right. My concern is what I am seeing here and what I observe here -- WP:NPA#WHATIS clearly states: "There is no rule that is objective and not open to interpretation on what constitutes a personal attack as opposed to constructive discussion." Calling someone a name like "portalspammer" is clearly not "constructive discussion" and I believe it is wrong to continue to do so. A weak personal attack is still wrong.--Paul McDonald (talk) 02:21, 2 May 2019 (UTC)

Then we will have disagree on both those counts, @Paul McDonald.

I find that it is very constructive to keep a clear focus on the difference between the output of the portalspammer and the good faith contributions of other editors, whose work should be treated with respect even tho it hindsight it was misjudged. Many other editors who created pointless-fork automated portals have responded to MFDs thereof with great grace, and quite a few have saved the community a lot of time by WP:G7ing them. --BrownHairedGirl (talk) • (contribs) 03:19, 2 May 2019 (UTC)

Then disagree we shall, for I will always find it destructive to refer to someone in a derogatory manner. No good can come from it.--Paul McDonald (talk) 12:36, 2 May 2019 (UTC)

• Could we just agree to refer to The Transhumanist by their user name or TTH for short? Anyone who's lived through the past year will append their own epithet of choice without needing to spell it out explicitly. Espresso Addict (talk) 09:44, 2 May 2019 (UTC)