Wikipedia talk:WikiProject Portals

WikiProject Portals Talk Pages
Tasks and Administration New Post | Watch Page To discuss work on the portals, and project administration, including policy issues.	Portal Design and Ideas New Post | Watch Page Existing and potential portal design features and support tools. Technical stuff.	General Discussion New Post | Watch Page General portal topics and announcements that don't fit elsewhere
Shortcut: WT:WPPORT/T	Shortcut: WT:WPPORT/D	Shortcut: WT:WPPORT
Main Discussion Page Shortcut: WT:WPPORT All Discussion Sections Shortcut: WT:WPPORT/ALL

General discussion threads

Guideline discussions announcement

• Wikipedia talk:Portal guidelines#Second sentence contradicts WP:NOTCOMPULSORY policy, and should be removed
• Wikipedia talk:Portal guidelines#Concerning the inclusion of "Related portals" section
• Wikipedia talk:Portal guidelines#Concerning the inclusion of "Selected article(s)" section
• Wikipedia talk:Portal guidelines#Concerning section: Recommended
• Wikipedia talk:Portal guidelines#Concerning section: Article selection
• Wikipedia talk:Portal guidelines#Concerning section: Required

Proposal to shut down or reform this WikiProject

The discussion has been closed and archived to Wikipedia:Administrators' noticeboard/Archive307

I know, me proposing shutting down a WikiProject I'm in? What am I thinking? Well, I mainly joined to make sure things would go smoothly after that RfC to delete all portals - clearly it has not. As thus, I think a solution (among the others) would be to shut down the WikiProject responsible for many of the bad portal creations. Right now it appears all its doing is creating new portals, not maintaining or improving them - which is what a WikiProject is supposed to do. However, a less extreme solution would be to reform the project to actually maintain and improve the portals it creates, and creates portals sparingly. I'm fairly certain a task force making sure portals meet standards would be beneficial to the issue, and also making it clear that not everything needs a portal. I'm going for the latter option to reform - however, I'm going to leave the shutdown option up in the air in case people find good reason for it to be considered. Addendum 13:48, 15 March 2019 (UTC) - Since I forgot to clarify ( Self-trout) here's two examples of reforms I could see being useful: A quality scale for portals, like we use for articles - this could help with knowing which portals are good and which ones need improvement Dividing the Project into task forces to make sure necessary tasks for the maintenance of portals are completed, as right now they clearly are not Sub-reform for this would be to make a task force that deletes bad portals that don't meet quality standards and are not needed Hopefully this can help clarify this proposal somewhat - if none of these can be done reasonably (which I doubt they can't) the shutdown option should be considered. Kirbanzo (userpage - talk - contribs) 23:01, 14 March 2019 (UTC) Survey on sub-proposal to shut down WikiProject Portals SNOW No The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion. Neutral as per above. Kirbanzo (userpage - talk - contribs) 23:01, 14 March 2019 (UTC) Strong oppose firstly this is the wrong forum, secondly there is nothing in the nomination that explains why this is needed, or how it will result in an improvement to the encyclopaedia. Thryduulf (talk) 01:04, 15 March 2019 (UTC) Oppose. Abyssal (talk) 01:35, 15 March 2019 (UTC) Support: might as well. --K.e.coffman (talk) 02:23, 15 March 2019 (UTC) Oppose. There is consensus to keep the portal system but it has many faults, so a focus for improving it seems sensible. Certes (talk) 14:36, 15 March 2019 (UTC) Strong oppose. Not necessary and not the best way to fix Wikipedia’s portals. — pythoncoder  (talk | contribs) 19:49, 15 March 2019 (UTC) Oppose – Would amount to throwing the baby out with the bathwater. North America1000 01:19, 16 March 2019 (UTC) Oppose For the same reasons. — AfroThundr (u · t · c) 19:48, 16 March 2019 (UTC) Oppose For the same reasons. Bermicourt (talk) 22:37, 16 March 2019 (UTC) Support Incompetent project that doesn't want to deal with the crud their members create. CoolSkittle (talk) 18:07, 17 March 2019 (UTC) Invalid rationale. See Wikipedia:Arguments to avoid in deletion discussions#Surmountable problems.  — SMcCandlish ☏ ¢ 😼  20:58, 17 March 2019 (UTC) Oppose as ad hominem vindictiveness. The only rationale for deleting such a project would be a proper community-wide decision to eliminate all portals. This is not the venue for that; WP:VPPOL is. And this is not the venue for deletion of a wikiproject; WP:MFD is. WP:Process is important, most especially in deletion discussions and related matters, because damned near zero people are going to look for such discussions in an admins' "house organ" page like this. Hardly any non-admins watchlist this page or pay any attention at all to what is said here. It is not intended to be a venue for community-wide concerns in the first place, and even with belated addition to WP:CENT, discussing such matters here is a special kind of forum shopping, namely an attempt to appeal to a small cadre of specialist editors whose concerns about maintenance (and cop-like role of "going after" people for alleged behavioral flaws, often with little oversight, especially compared to WP:ANI process) will colour everything they do and say about the matter.  — SMcCandlish ☏ ¢ 😼  20:58, 17 March 2019 (UTC) Widely misleading arguments. This is a widely advertised and widely participated discussion. It came from a VPR discussion, linked from the very beginning. There are far more non-Admins than Admins involved here. Try to stick to facts. Legacypac (talk) 23:23, 17 March 2019 (UTC) Support [non-admin comment :] opposed to portals, they harvest legitimate contributions yet the creators expect them to be automatically protected as legitimate contributions and outside of normal guidance on creation. There are cadres of users who think this is what wikipedia is about, or at least it is a way of making a big splash without knowing anything but how to tweak code (and then wikilawyer when challenged). cygnis insignis 06:10, 18 March 2019 (UTC) Oppose Punishing a whole community for the actions of one person is not reasonable. WaggersTALK 16:49, 18 March 2019 (UTC) Oppose per above. It's getting cold out... SemiHypercube 16:52, 18 March 2019 (UTC) Oppose In the grand scheme of things I'd like to see portals deprecated, but doing so is not where the community is at right now. If there is consensus to keep portals, having a wikiproject to maintain them seems like a good idea. I also feel cold... Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 06:47, 19 March 2019 (UTC) The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion. Survey on sub-proposal to reform WikiProject Portals Support as proposer and per above. Kirbanzo (userpage - talk - contribs) 23:01, 14 March 2019 (UTC) Oppose as the proposal is in the wrong forum and contains no details of what reform is being suggested, let alone how these reforms would solve the issues identified. Thryduulf (talk) 01:05, 15 March 2019 (UTC) This is related to the discussion as the WikiProject is headed by the user being discussed here. Kirbanzo (userpage - talk - contribs) 13:48, 15 March 2019 (UTC) Wikprojects are a collection of editors, not just one person. There is no evidence presented that there is any admin action required regarding the WikiProject as a whole collectively (not that I can immediately think of what that action could look like if it were), and there isn't even consensus that admin action regarding the single editor is required. Thryduulf (talk) 13:57, 15 March 2019 (UTC) Fair point, but considering the discussion below it should still be considered. Kirbanzo (userpage - talk - contribs) 14:00, 15 March 2019 (UTC) Support. I’ve been doing some reform work of this type by creating a page to clean up some of the damage done to the older portals. WikiProject Portals has an assessment page but I’m not sure how much it gets used. — pythoncoder  (talk | contribs) 19:49, 15 March 2019 (UTC) It took quite a lot of discussion to form a consensus for those assessment criteria. Any portals would need to be evaluated against them to ensure they meet at least minimal quality standards (not including the other criteria in the portal guidelines). It will take a while to go through all of the portals and rate them on the quality scale, and that is one of our backlog tasks. — AfroThundr (u · t · c) 19:48, 16 March 2019 (UTC) Support in theory. It makes more sense than the above "I disagree with you so I will try to just erase you" bullshit. However, it's not at all clear that the wikiproject, as such, needs any "reform"; rather, some specific decisions and actions taken by its participants have turned out to be controversial, and the community will discuss that (hopefully in a more sensible venue like WP:VPPOL), and the wikiprojects should abide by the result of that process. We don't have any indication this would not happen, so there isn't actually a "reform" to perform, nor is there yet any consensus of what form that should take anyway. Some people here seem to be under the impression that WP is going to come out against portals; others that it'll be against automated portals; others that it'll be against portals on minor topics (and sub-sub-sub-topics) that people aren't likely to seek a portal for; others that nothing is actual broken; others that .... There isn't a single direction of "reform" being proposed.  — SMcCandlish ☏ ¢ 😼  21:03, 17 March 2019 (UTC) Oppose The way to reform a project is to get involved with it. We've already had multiple discussions about how the project should be structured and how it should operate on the project pages themselves, and further suggestions there are always welcome. But proposing "reform" without specifying what particular changes are being suggested isn't exactly helpful. WaggersTALK 16:53, 18 March 2019 (UTC) Exactly right, Waggers, exactly right. You've hit the nail on the head. ~Swarm~ {talk} 18:22, 20 March 2019 (UTC) But is you see little need for portals why get involved? Legacypac (talk) 23:18, 21 March 2019 (UTC) Nominating hundreds of portals for deletion is getting involved. If you see little need for them then fine, live and let live, they're not doing you any harm. The community has decided to keep portals, so either you respect that consensus and ignore them, or you respect that consensus and get involved with resolving whatever problem you have with them. WaggersTALK 12:58, 3 April 2019 (UTC) Qualified support. The current project is far from perfect but it's hard to give unqualified support without a statement of specific reforms. We don't want thousands more portals, but last year's RfC shows that it would be equally inappropriate to "reform" into WikiProject Nuke All Portals From Orbit. I removed my name from the project's roster when portal creation grew rapidly. Since then I have done some maintenance but I see little point in improving pages that other editors are working so hard to delete. I could rejoin a project that combined improved existing portals with the right blend of identifying poor, narrow portals for deletion and creating portals in small numbers where clear gaps exist. Certes (talk) 13:32, 29 March 2019 (UTC) Qualified support per @Certes:. As a participant in the Portal project, I would encourage them to adopt a more rigorous process for creating new portals, including qualifying criteria, and also for the maintenance of portals by the relevant project members. I'm disappointed that, while this discussion is going on, at least one portal that I help with has been nominated for deletion (it's not one of the automated portals created by TTH which is subject of a deletion nom that I support). Bermicourt (talk) 11:45, 13 April 2019 (UTC) Discussion on proposal to reform WikiProject Portals Query @Kirbanzo: - do you have any early thoughts about what some good reforms would be to shift the primary focus of the project towards maintenance/improvement over creation? Nosebagbear (talk) 23:11, 14 March 2019 (UTC) See addendum. Kirbanzo (userpage - talk - contribs) 13:50, 15 March 2019 (UTC) Transcluded to Wikipedia talk:WikiProject Portals. {{3x|p}}ery (talk) 23:36, 14 March 2019 (UTC) No, do not transclude important discussions from AN to the relevant talkpage. Hold the discussion on the relevant talk page. Transclude to here is there is good reason, which there is not. Holding hte discussion here means watchlisting it doesn't work, and it wont be archived in the right place. Shutting down a WikiProject is not in scope for WP:AN. --SmokeyJoe (talk) 02:20, 15 March 2019 (UTC) The Portals Wikiproject members can't even come up with a proper new guideline for what topics get a portal even when faced with a village pump imposed moratorium. The discussion is all over the place with no focus. Heck they did not even follow their old guideline about picking subjects broud enough to gain reader and editor interest. The only thing they appear to agree on is MORE MORE MORE and using WP:VITAL as a to do list. Their newsletter said they are pushing to 10,000 portals (off a base of 1500 old line portals). Now the number of portals will shrink until and unless they get new guidelines passed by an RFC. Legacypac (talk) 09:57, 15 March 2019 (UTC) That old guideline wasn't generally followed, ever. That's because portals (except those on the main page) get about 1 to 3 percent of the amount of traffic that their corresponding root articles get. In other words, "not a lot". That's because almost all their traffic comes via WP internal links. Almost nobody googles "Portal". So, for the vast majority of topics, large numbers of readers and editors will never be forthcoming, and never were. Out of the 1500 portals, about 100 had maintainers (maintained by around 60 editors), and maybe 20% of them regularly edited the portals they maintained. The WikiProject, and the community, need feedback in the form of hard numbers, in order to get a sense of what will even get used. How hard would it be to make a chart listing all the portals in one column, and their page views for the past month in the second column, and then sort the chart by the second column? That might provide some insight.    — The Transhumanist   11:05, 15 March 2019 (UTC) Sigh. :TTH, you had this data already. You know that portal pageviews are miniscule. At the RFC on deleting the portal namespace, stats were posted on pageviews, and not even all the portals linked from the front page had decent viewing rates. Yet despite knowing all that, you personally created thousands of new portals, despite having all the evidence in front of you that they are useless. And when I presented the evidence to you again, and asked you to desist, you were furious. Instead of assessing the issues, you posted multi-screenfull unfocused ramblings replete with shouts of "bias", "personal attack" etc. The problem is not any shortage of information. The problem is that as @Legacypac notes above, the discussions in the WikiProject have no focus, no regard for available evidence, and no respect for community consensus. Legacypac and usually disagree, but in this case we see exactly the same problem: a WikiProject which has a long and sustained track record of being utterly incapable of acting responsibly wrt the page within its purview. This is not solely TTH's doing. TTH bears by far the highest responsibility because TTH has been both the most prolific creator and the most angry objector to calls for restraint, but several other regulars at WikiProject Portals have been equally unfocused and equally bonkers. For example: Only 15 days ago, WT:Portal/Guidelines#Portal_creation_and_deletion_criteria_proposal_5: a proposal to create portals up to VA Lelevl 5, when even VA level 4 would be about 10,000 portals. 17 days ago, WT:Portal/Guidelines#Portal_creation_and_deletion_criteria_proposal_1: a proposal for portals to have minimum of only 20 articles. Precisely the sort of microportal of which the community has had enough. So the community simply cannot rely on this group to set and uphold resposnsible guidelines. --BrownHairedGirl (talk) • (contribs) 11:53, 15 March 2019 (UTC) @BrownHairedGirl: I make the proposal 5. And it was a proposal. I Support a reform in WikiProject Portals. My idea is the existence of approximately 1000(level 3) single page portals layout, directly linked in tree model with the main page. The role of the wikiproject should be to organize this tree and develop tools to transform all portals into single-page layout portals.Guilherme Burn (talk) 12:11, 15 March 2019 (UTC) @Guilherme Burn, no technical diversions. My point is not about how the portals operate; it's about their scope. And 20 pages is insanely narrow. A 20-page portal is just an bloated navbox. --BrownHairedGirl (talk) • (contribs) 12:36, 15 March 2019 (UTC) @BrownHairedGirl: I'm trying to figure out how you've come to the conclusion that WPPORT completely ignores evidence and consensus. The project discussions I've participated in have been rational and reasonable, and far from unfocused. Also, please try not to conflate individual editors' behavior with the project as a whole. I've seen no evidence that the WikiProject has acted irresponsibly regarding the Portal system. If you're referring to the several thousand new portals created by TTH, you should keep in mind that WikiProjects don't have any actual authority to dictate who can and can't create something (even if we were opposed to creating new portals). That's what guidelines are for. We've been working to develop updated criteria for the Portal guidelines since November (rebooted from even earlier discussions in April) - which you already know, since you've participated as well. We're still working on the guidelines so that we have better, more concrete criteria to judge new and existing portals against (and which would make MfD easier for those that fail). Once we've developed consensus on these, they can be applied to the namespace to fix the portals that can be fixed, and remove the ones that can't (new or old). (Side note: Anyone with input or ideas is welcome to participate at WT:PORTG.) Actions in the Portal namespace itself (for most of us, it seems) has mostly been technical fixes and tweaks to our tools. Also, your not agreeing with particular proposals does not make those proposing them irresponsible or incompetent. Talk pages are a place to discuss new ideas so that we can find the benefits and drawbacks of each. If we constantly had to worry about being labeled as irresponsible or incompetent for suggesting something, we'd never have any new ideas or get anything done. I've made plenty of suggestions that didn't pan out later, as I'm sure you have, and everyone else here. That's how we learn what works and what doesn't and build a better encyclopedia. In the end, that's what we're all here for right? — AfroThundr (u · t · c) 19:48, 16 March 2019 (UTC) @AfroThundr3007730: that's not at all how it looks from outside. Last year, the project began developing automated portals, whose advocates claimed need little or no curation. No attempt was made to hold an RFC to determine whether the community found these automated portals to be a worthwhile addition. (I think I see an emerging consensus that they are not useful, or maybe useful only in some curcumstances) Following the WP:ENDPORTALS RFC which decided not to actually delete the whole portal namespace, the project decided to massively expand the number of portals, despite the clear evidence at RFC that many editors wanted fewer portals. At no point did the project initiate an RFC to establish whether there was a community consensus for the project's enthusiasm to bizarrely interpret "don't TNT the lot" as "create thousands more". You are right that a WikiProject has no powers of restraint on an individual editor. However, the project does have an ability to watch what is done, and to act a venue to monitor inappropriate creations, and to initiate cleanup as needed. I see no sign at all that the project has done any of that ... and on the contrary, when outsiders have challenged TTH's sprees of portalspam, other project members have rallied to TTH's defence. Even now, as a cleanup is underway, I see next to no assistance from project members. V few even comment in the MFDs. For example, take the most extreme case so far: MFD Portal:University of Fort Hare, an utterly absurd creation for which there exists precisely zero relevant selected articles ... yet none of the project regulars is visible. In my view, a WikiProject which shows zero interest in removing inappropriate pages within its scope is dysfunctionally irresponsible. The project's efforts to develop guidelines have been exceptionally poor. The discussions have been rambling and unfocused, with a persistent failure to distinguish between factors such as technical ability to create, availability of editors to maintain and monitor, actual usage data, etc. Above all, none of the proposals has been put to an RFC to gauge community consensus, so the guideline discussion have effectively been the work of a small group of editors who are united by a common desire to massively increase the number of automated portals. The result of this failure has been a walled garden of thousands of micro-portals, sustained only by the enthusiasm of the portal project ... and the absolutely inevitable massive shitstorm at the village pump. What this needs now is a structured RFC, which brings together some or all of the proposals made at the project, adds proposals from outside the project, and seeks a community consensus. --BrownHairedGirl (talk) • (contribs) 20:18, 16 March 2019 (UTC)

Discussion update

The Proposal 4: Provide for CSD criterion X3 proposal at the Administrators' noticeboard to create a speedy deletion criteria X3 for the deletion of automated portals created by User:The Transhumanist between April 2018 and March 2019 was closed as no consensus (permanent link). As such, the criteria was not added to Wikipedia's Criteria for speedy deletion page. North America¹⁰⁰⁰ 11:55, 6 April 2019 (UTC)

Nomination of 1,426 portals for deletion

A discussion is taking place as to whether 1,426 portal 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/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. North America¹⁰⁰⁰ 21:11, 7 April 2019 (UTC)

• Note. A further batch of portals has been added to this nomination. The total number of portals now included in this nomination is 2,698. --BrownHairedGirl (talk) • (contribs) 12:57, 8 April 2019 (UTC)
  • I have withdrawn the additional portals from the nomination. --BrownHairedGirl (talk) • (contribs) 14:04, 8 April 2019 (UTC)

A new newsletter directory is out!

A new Newsletter directory has been created to replace the old, out-of-date one. If your WikiProject and its taskforces have newsletters (even inactive ones), or if you know of a missing newsletter (including from sister projects like WikiSpecies), please include it in the directory! The template can be a bit tricky, so if you need help, just post the newsletter on the template's talk page and someone will add it for you.

– Sent on behalf of Headbomb. 03:11, 11 April 2019 (UTC)

Identifying old-style portals

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)

Dreamy Jazz's lists

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:

A quick and dirty way of finding some, using AWB

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: Deleted portal subpages where the base page exists

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)

Portal restoration to pre-automated versions

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=}}

Red links to deleted portals need to be removed

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)

An easier question to discuss

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)

Revert to manual: what's the plan?

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)

Supposed Mass deletion of manually-maintained portals

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)

Nomination of 1,165 portals for deletion

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)

Nomination of 83 portals for deletion

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)

Multiple hand-curated portals up for deletion

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)

Automated portals: not bugs or random errors

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)

Manually maintained portals: some design failures

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)

Portal:Shia Islam

Would anyone please resolve the problem in the 'Chosen holy figures' box? Husayn ibn Ali is not shown correctly in the box. Regards. --Mhhossein ^talk 09:27, 21 April 2019 (UTC)

Hey The Transhumanist. Can you give it a try please? --Mhhossein ^talk 13:17, 26 April 2019 (UTC)

I've fixed it.--Auric talk 01:10, 27 April 2019 (UTC)

Auric: Thanks so much. --Mhhossein ^talk 06:23, 3 May 2019 (UTC)

Wide-ranging discussion on portals ongoing

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

WP:REDUNDANTFORK portals

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)

Automated portals based on outlines

There is currently an ongoing discussion as to whether portals based on outlines, with no manual version worth saving, should be deleted on sight. As I said above, while I see consensus for navbox(es), and hoovering links from the head article is just a terrible idea, I'm not convinced that there's clear consensus at present regarding outlines.

There is some discussion of this at Wikipedia:Miscellany for deletion/Portal:Jordan (2nd nomination) and I'm also aware of Wikipedia:Miscellany for deletion/Portal:Classical architecture. Espresso Addict (talk) 03:51, 27 April 2019 (UTC)

@Espresso Addict, that's an outrageous act of WP:CANVASSing.

It is blatantly partisan, and misrepresents the nomination: there is no proposal to delete on sight. (That would be speedy deletion, which is not proposed).

The community consensus on forking is very clear: see WP:Content forking#Acceptable_types_of_forking, which provides no exceptions for portals for Outlines. --BrownHairedGirl (talk) • (contribs) 15:35, 27 April 2019 (UTC)

Calm down guys. BrownHairedGirl is right but sounding a bit like RedHairedGirl lol. :) Bermicourt (talk) 18:51, 27 April 2019 (UTC)

Sorry. I was very angry last night. Espresso Addict (talk) 05:09, 28 April 2019 (UTC)

Suggested deletion of portals purely because they are a subset of other portals

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)

Project status update?

As The Transhumanist, for understandable reasons, appears to be no longer updating the newsletter, I think the project could do with taking stock.

Based on links provided by BrownHairedGirl there seem to be 1303 portals not currently tagged with a deletion request plus 228 portals currently at MfD. (The query seems to return in order of creation with oldest at the top, and I don't know how to sort.) So the project is roughly back where it started a year ago, at least in terms of number of portals.

Can anyone provide anything more useful? eg

• Which portals, apart from the eight linked off the main page, get decent hits? Is there a way of getting a bot listing?
• Which portals are maintained/unmaintained? Not just the maintainer parameter being filled in, but actually being updated
• Which portals are in a decent state? And what does that even mean at the moment?
• &c&c&c

WP Portals has got to start moving towards a realistic assessment of what type of portals are useful & to whom, how to maintain them, and what forms of portal & topics for portals are accepted by the community, if any, if it's not to be led by the editors at Miscellany for Deletion. Espresso Addict (talk) 03:26, 28 April 2019 (UTC)

Quick reply

1. Glad the Petscan links were useful, but AFAIK Petscan won't sort. When I need to sort, I use its wiki output mode, save to a text file and load it into AWB.
2. I'd also like a listing. I will write a bot request.
3. Portals in a decent state? Probably no surprise that my answer is "very very few". I'm working on the bottom rung. i.e those which are just bloated rewraps of navboxes/lists or plain broken, but as I view nearly all of them along the way, it's v rare to find one to which I can actually say "yes, that's good". But if this portal wants to do more than triage the portals in big trouble, then it needs some actual criteria for what makes a good portal. And to avoid a rerun of 2018, those criteria need broad, RFC-based community support.

Observation: this project looks to me to be directionless. Most of what energies it has seem to e to be going into either resisting deletion of portals of at best marginal utility, and/or in restoring to an old multi-subpage manual format portals which had rotted so badly when in that shape that they were automated without protest. That;s too much energy focused on the least important pages, which is a sure path to decline.

Both seem to me to be backward-looking strategies. The community voted not to delete all portals, but has made no broad decisions on which topics it wants portals for. There is no broad consensus on what portals are actually for or how they should do it, and at least radically 3 difft models have support.

If those two big questions are answered with clear community support, then portals may have a future. Otherwise, sooner or later somebody will do an ENDPORTALS2 which may succeed. --BrownHairedGirl (talk) • (contribs) 03:55, 28 April 2019 (UTC)

Thanks for offering to write a bot request, BrownHairedGirl; I have no idea how one goes about that.

I come at this from the other end of the quality scale, having mainly interacted with portal peer review and the featured portal process. When the latter was active, there were a handful of really good portals, plus perhaps 50–100 that were decent/mediocre and a substantial minority that should have been de-featured. But the process was last fully active back in ~March 2016, and all the former featured portals were of the static lead extract form. That was what Transhumanist was trying to fix, but the community has rejected most, if not all, of those methods. From the perspective of a portal-phile, I think we need to be more proactive in presenting the community with at least some good-quality, attractive, updated portals, plus a process to move a higher proportion of portals towards this state, and say, hey, look how great they are!

I don't think another portals RfC of any description will be of benefit to this Wikiproject at this time, and in particular I don't think asking the Usual Suspects (mainly long-term editors & admins) at an RfC is going to shed any light on what a reader might want from a portal. None of us here are (primarily) Wikipedia readers. I asked my social media network earlier this year about the main page, and not one person ever visited it, and more than one person expressed surprise that it so much as existed.

The project looks directionless to me, too, hence the unsubtle attempt to push it along, but I don't think I've ever been a member. Espresso Addict (talk) 05:02, 28 April 2019 (UTC)

PetScan's "Output" tab has limited sorting ability: by title, size, date or incoming link count. For example, here is the list of non-MfD portals sorted by title.

PetScan's "Page Properties" tab can filter by last edit before or after a given time. However, it can't filter out non-content edits such adding a tag.

Two open questions are whether every portal which was generated automatically is necessarily a bad portal which must be deleted, and whether whether every portal which is not maintained manually is necessarily a bad portal which must be deleted. Perhaps they are valid reasons for considering a portal for MfD but not valid rationales for deletion.

Automated portals could benefit from some semi-automated one-off improvements, such as customising the DYK and ITN lists. For example, I edited Portal:Bears to filter out people who "bear arms" etc. It may be worth resuming those tasks once it becomes clear which portals are likely to survive. Certes (talk) 11:24, 28 April 2019 (UTC)

@Certes, I agree that non all automated portals should be deleted. If I did think they should all go, I'd have saved the community a lot of time by 4 weeks just MFDing in one batch all of the ~4,500 portal which then transcluded Module:Excerpt slideshow. Instead I have been MFDing only those which a) replicate the set of links on one single page, and have no viable pre-automated version; or b) portals with too narrow a scope. That has emeant several hundred extra MFDs.

Thanks for the comments on Petscan. I have used it squillions of times, but had never found the handy output-sorting, even tho I use that tab lots to set wiki output. Duk.

I tried Petscan's "filter by last edit" functionality, but never got it work. The results on my test set were junk. --BrownHairedGirl (talk) • (contribs) 14:19, 28 April 2019 (UTC)

@BrownHairedGirl: From experimenting, I'm convinced that PetScan has an unhelpful and undocumented feature. After (or exactly) does what it says. In particular, it modifies its behaviour correctly if you tick Only pages created during the above time window (overrides "last revision"). However, Before (or exactly) always seems to select by creation date, i.e. it acts as if the box were ticked even when it's not, and checks the earliest edit rather than the last. I don't think we can work around it – hacking the URL to add &only_new=off doesn't help – but it sounds like a fairly easy code fix. I'll report it if you agree. Certes (talk) 15:28, 28 April 2019 (UTC)

Thanks, @Certes, but I'm a bit too busy now to set up my own tests again. However, if you can show me some testcases on small sets to illustrate the behaviour, then I can see whether I agree. Alternatively, just file a bug report yourself if you are happy to stand over your findings. You've done the spadework, so you should get the credit! --BrownHairedGirl (talk) • (contribs) 15:40, 28 April 2019 (UTC)

Reported. Certes (talk) 16:11, 28 April 2019 (UTC)

Thanks, @Certes. --BrownHairedGirl (talk) • (contribs) 17:03, 28 April 2019 (UTC)

Portal pageviews

In a discussion above, @Espresso Addict wisely suggested that it would be helpful to have a list of pageview counts of portals.

I agreed, and offered to make a bot request. In preparing the bot the request, I did a little homework, and found that the bot request is un-needed, because there is already an interface to do what's needed: https://tools.wmflabs.org/massviews/

I fed it with Category:All portals, and and set the date range as 01/01/2019 - 28/02/2019, i.e the first two months of 2019, before pageviews began to be distorted by intensive scrutiny from editors.

Here's the direct link to the list of pageviews for each portal in the first 2 months of 2019. Sorry! Initial link was wrong. Now corrected to show Jan–Feb. --BHG (talk) • (contribs) 12:32, 29 April 2019 (UTC)

Note that of the 1504 portals which it successfully checked, the median daily average pageview for the is 11 views/day ... i.e. the midpoint in the series is 11 views day, or phrased differently half got more than that, half got less. I will now work on some breakdowns. --BrownHairedGirl (talk) • (contribs) 13:49, 28 April 2019 (UTC)

• Adding portal links to various pages tends to improve page views. I've noticed main article pages at times that have a direct corresponding portal lacking any links to the portal at all. Sometimes links are only present in a buried, collapsed nav box. More links = more page views. More visible links = even more page views. North America¹⁰⁰⁰ 14:11, 28 April 2019 (UTC)

• @Northamerica1000, in some cases, linking may help marginally. But in 2017/18 I used Template:YearInCountryPortalBox to automatically add links to multiple portals from over 70,000 category pages, and the result was no detectable change in views.

In this comment[4] at another discussion, I compared the hit-per-link for portals to some articles. My conclusion there was that it seems to me that on a pageviews-per-link ratio, the portal is underperforming by a factor of about ten.

So far as I can see from a lot of checking and comparisons, the reason that almost no readers visit portals is that almost no readers want to visit portals. Even the portals linked from Wikipedia's absolute prime advertising pace (i.e. top right of the front age) massively underperform. --BrownHairedGirl (talk) • (contribs)

• Those portals atop Main page sure get a lot of views. Quite a lot. The Arts portal gets more page views than the article itself! It's all about visibility; and the more the better. North America¹⁰⁰⁰ 14:43, 28 April 2019 (UTC)

• Also, I thought this page was about improving portals, rather than focusing upon ways to further their mass deletion. Moreover, portals should be considered on a case-by-case basis, rather than upon simplified averages and bean counting. Just saying. North America¹⁰⁰⁰ 14:51, 28 April 2019 (UTC)

• @Northamerica1000, I have created over 100 discussions to examine portals on a case-by-case basis, and you repeatedly complain about that.

Now when I post some statistics to inform those discussions, you complain about that too ... and make the thoroughly bad faith assumption that it was motivated by focusing upon ways to further their mass deletion. You know that is untrue, because in the first line of this section I noted that I offered the data in response to a request by Espresso Addict. It was not my idea -- it was EA's idea, and you knew that when you tried to smear my motives.

There is a 4-letter word for people like you who smear others on the basis of assumptions which you know to be false. Clean up your act.

Now to your comment about the portals linked from the front page. The rest of this is excepted from a reply I made to @Bermicourt on their talk:

Portal	Daily avg
Arts	1,237
Biography	2,407
Geography	983
History	1,946
Mathematics	1,230
Science	1,118
Society	665
Technology	1,098
Average (mean)	1,335

That point you make about portal promotion is interesting. Luckily, we have some data to test it: the 8 broad-topic portals linked from the top right of the front page.

Remember, that's the absolute prime spot for reader attention. If (God forbid!) Wikipedia ever took to selling space for banner ads, that slot would command the highest price. So links there should be getting a high hit rate.

But see right the daily average hit rate for those 8 portals for Jan–Mar 2019: 1,335

Compare that with a median range of 30,000 to 50,000 for recent TFAs. OK, TFA is a bigger, more eye-catching block. But still, that's about a 25:1 ratio. I looked at a recent TFA, Albert Pierrepoint: 83,227 hits on the TFA day (30 March 2019), but a Jan–Feb 2019 daily average of 847; that 63% of the big-8 portal average without being anywhere near the front page.

The DYKs are below the fold, and each is individually less much prominent than the DYK. But your description of individual DYK hits (which matches my experience) is that they each got more way more daily hits than the avg portal, despite being there for only half the day. (Or is it 6 hours?)

Or compare those 8 portals with the much less prominent link to the Featured content near the top of the left-side menu: 6,591. (Yes, it's a portal, but it's not advertised as such)

So it seems to me to be fairly clear that when offered a clear choice of portals or other types of content on the front page, portals are a relatively slow seller.

We could do similar analysis of portals linked from navboxes vs articles linked from navboxes, and I'm pretty sure that we'd see similar results: the portals get v low hit rates.

In the discussion at MFD:15 automated portals built on a single list, I wrote two long posts about why this is so. Basically, it's because an ordinary en.wp head article is so very good for navigation that a portal has to be truly exceptional to do better. And most portals, even on broad topics high on the vital article list, are not exceptional.

For example, I just made my first ever visit to Portal:Europe. That's a level-2 VA, chock full of highly-developed nations, where en.wp does a pretty good job of documenting two millennia of history. It's a much better maintained and developed portal than most, but it's still kinda rubbish as a portal. About 5 over-long snippet of articles, but no navigational pathways to follow. Instead of being a gateway to explore the huge collection of articles non Europe, it's a slim single-issue glossy mag.

So little wonder that Portal:Europe averaged 61 pageviews/day in Jan–Mar 2019, while the head article Europe averaged 8,788. That a 144:1 ratio, just like much smaller topics.

The data is the same wherever I look. For any given level of promotion, portal links are much followed than other links. --BrownHairedGirl (talk) • (contribs) 17:31, 28 April 2019 (UTC)

• So, the point is, BrownHairedGirl just wants all portals deleted, vis-a-vis WP:ENDPORTALS? I'm not sure what your overall stance is. North America¹⁰⁰⁰ 17:36, 28 April 2019 (UTC)
  • NAIK, it's disgraceful that you seem unable and/or unwilling stop putting words in my mouth, and actually discuss the matter in hand. It's highly uncivil, and it is disruptive conduct.

The two points I was making here are very simple:

• The statistics show that the overwhelming majority of portals have very low viewing rates
• That the research I have done shows that links to portals are much less likely to be followed than links to articles

That's it.

So please do me the very basic courtesy of actually looking at the figures if you are interested in them ... and if you're not interested, do something else rather than sniping. --BrownHairedGirl (talk) • (contribs) 18:29, 28 April 2019 (UTC)

I made a point in a specific MFD discussion which may be relevant here. I'd been looking at how German Wikipedia uses portals and noticed that e.g. Portal:Bahn (=Portal:Railway) gets twice as many views as our Portal:Trains even though German Wiki has a smaller audience. On checking their links from mainspace, I noticed that Portal:Bahn has relatively few article links (only 4 main topics plus some random articles which are clearly not following the conventions), but appears to be linked from all the category pages. In other words, it is being used in a different way - more as a tool to complement (and sit above) the categories (as well as being used to aid WikiProjects). I've only had a quick look, so more research required, but that may be a better way to go as far as the reader-facing usage is concerned. So I don't see why portals, which are not in mainspace anyway, are being expected to compete for hits against reader-facing articles in mainspace. Any thoughts? Bermicourt (talk) 19:05, 28 April 2019 (UTC)

• Very quick comment: Not read the above discussion carefully yet, but the list is absolutely fascinating! Thanks to BrownHairedGirl for coaxing it out of the software. Some off-the-cuff thoughts...

On a quick scan, I think Portal:Companies is top of the hits for those not linked off the mainpage – which is interesting, given how sparse & eclectic its contents are (my comment on the 23rd in Wikipedia:Miscellany for deletion/Mixed bag of group portals "Those advocating for deleting all individual company portals in favour of the top-level one might care to assess Portal:Companies, with its sparse & in some cases peculiar selection of articles, dull design and run of missing reference errors at the bottom.").

BrownHairedGirl: does the median change significantly if one excludes all the portals linked from the main page? ie 1–11 in the list I got.

On main-page hits generally: These have been declining overall for a long time, which is usually put down to a greater proportion of mobile views. Afaik, mobile removes some elements, which might include the boilerplate including all the portal links (I never use mobile). The DYKs have mainly been on a 24-hour cycle recently, except for 1 April. In my experience, average DYK hits have gone down greatly over the years; one used to be able to get >5000 in 6–8 hours by a reasonably snappy hook, especially in the top pictured slot; now even on the current 24-hour rotation, they can be numbered in the low hundreds. DYKs are not below the fold on my laptop. They're all visible. I even get all of today's featured list if I maximise. Even my other low-res screen usually gets the top half of the DYKs.

I wonder if main-page portal hits could be enhanced by adding an image? Or individual graphics? I agree they are prominent but they're very bland in appearance, and the other sections all usually have images.

@Bermicourt: Portals are, for some reason, much more successful in several non-English wikis, not just the German one. How many hits do the category pages get? I didn't think average readers often clicked on categories, but I've never seen that data.

On the other discussion, can I just say: Please can we try here on this page to focus on how we might make portals more attractive/more useful, how we might drive traffic towards them, and which portals need attention most urgently given the hits data? If we're always discussing the Imminent Demise of All Portals, OMG!!! then we're never going to make any progress. Espresso Addict (talk) 04:53, 29 April 2019 (UTC)

@Espresso Addict: I am sorry, I screwed up in posting the link. It was for recent hits, which are wildly distorted by all the recent views by editors at MFD etc. I have corrected the link above, and here it is again: Jan–Feb 2019 portal pageviews. Grovelling apologies for my stupid error.

A few other points:

• I referred to the median being 9 views/day. That's the mid-point of the ordered dataset, and it's v different to the arithmetic mean. The mean. Quick extreme example to illustrate: data set has 5 values: 1, 2, 2, 3, 1000. The median (midpoint) is 2; but the mean is 201.6. The median doesn't get distorted by outliers, so provides a better guide to the most common value.
• So the 11 most viewed at the start barely move the median. With them included, the median is #754 Portal:Luxembourg, with 677 totals view, i.e. 11/day ... but without them, the median is #760: Portal:Pervasive developmental disorders with total 672 views, 11/day
• Main page portal views might be enhanced by adding a wee graphic. I would oppose that unless there was a broad consensus that the portals concerned were of sufficient navigational benefit to justify such promotion. Looking at the leftmost 3 of the set, I'd say that Portal:Arts and Portal:Biography are competent examples of the magazine-style portal, but that Portal:Geography is mediocre. I don't think that any of them is a good enough navigational tool to deserve more promotion; I think that all are currently much too highly-promoted. I know that you do like the magazine-style, so we're going to disagree on that; but any further promotion should be based on a broad consensus that those portals do actually offer very high value to the readers.
• Overall, the dataset is damning. Only the top 56 portals (i.e. 3.7%) exceeds 100 pageviews/day. The top quartile begins at 23 pageviews/day. The gargantuan Portal:San Francisco Bay Area, with over 1100 subpages get only 83 views/day.
• Category viewing figures are a poor comparator, because the category system is highly-distributed with multiple entry-points, whereas portal pages concentrate topics on as= single entry-point. There are literally millions of categories, but only ~1500 portals.

Hope that helps. --BrownHairedGirl (talk) • (contribs) 13:37, 29 April 2019 (UTC)

I don't think any of my above comments were affected by the error. I was working on a long comment here which will have to go back to the drawing board; some of the observations did seem a little peculiar. (I've self-reverted the comments I made based on them to MfD, if anyone's confused.)

On the three main-page-linked ones you mention: The births and deaths in On This Day in Biography are great; however it only excerpts 12 bios, one per month. It doesn't look as if anyone is updating it annually, unfortunately; I'd suggest that's one priority. I like the audio clips in Arts, but otherwise it's bland. Geography looks weird; that enormous image at the top certainly wasn't in the featured version, not sure when that crept in! Geographical portals overall seem to do rather more poorly than I had envisaged. Also, Society gets surprisingly few hits given the plum placement. One thing we were talking about when the Featured Portal process was running, as I recall, was rotating in one of them in with set at the top, as Portal of the Day. I don't recall now whether the plan was to put it in place of Society or All portals.

On categories, I wasn't trying to use them as a comparator to portals, which I agree they are not, but to respond to Bermincourt's comment above about the German Wikipedia placing portal links predominantly on category pages.

I am wondering what's happened over time with the page views. My former featured portal used to get nearly 100 hits per day before the process was terminated, so it is possible to drive traffic towards a minority topic. Espresso Addict (talk) 14:43, 29 April 2019 (UTC)

Category:Portal with subpages tracking

Earlier today I created Category:Portal with subpages tracking, plus a set of subcats. This is an aid to identifying manual portals by the number of subpages they have. (Similar to Category:Automated portal pages tracking, which is for automated portals)

The tracking categories are automatically-populated by the Lua modules from which the portals are built. Please note the disclaimer on each those tracking categories. Software limitations mean that they should be used only as a starting point for careful scrutiny of the portal's wikitext and its list of subpages.

Limitations

Most such portals have more than one list of "selected foo", but the software handles each set separately and knows only about the set which it is currently processing. So if a portal has 4 selected biogs and 9 selected general articles, it will be categorised in both Category:Random portal component with 2–5 available subpages and Category:Random portal component with 6–10 available subpages. However, if the same portal had 6 selected biogs and 7 selected general articles, it would be categorised twice in Category:Random portal component with 6–10 available subpages ... but since the category system ignores duplicates, it would just appear once in Category:Random portal component with 6–10 available subpages. Caveat lector

Bonus

The number of subpages in each section is set by editors using the "max=" parameter in {{subst:Random portal component}}, {{Transclude random subpage}}. If I had simply used that parameter to build the tracking categories, then the code would have been simpler, but I soon realised that would create an unhelpful vector for miscreants to game the system by setting a "max=" higher or lower than than the actual number of available subpages, to make the portal look much more complete or less complete than it really is.

So I rejigged it actually check for the existence of subpages. The handy bonus from this approach is that the module can compare the number of subpages found with the value of "max=", and categorise the portal in Category:Random portal component with fewer available subpages than specified max or Category:Random portal component with more available subpages than specified max, as appropriate. If everything is properly maintained, both those categories should be empty ... and as of now they contain a combined total of 113 pages. ()

The downside is that has required reducing the level of detail given about on very big portals.

Huge portals

Note that I had initially built the system to provide more finely-grained breakdown of portals with over 50 subpages, grouping them 50–100, 101–200, 201–500, 501–1000, and over 1000. However, this caused Lua overload on portals with large numbers of subpages, e.g. Portal:San Francisco Bay Area with its 1,159 subpages. So I tweaked it to stop checking once it finds over 50 subpages.

So it now helps positively identify large portals, but it doesn't separate out the huge or humungous portals. Large is the biggest grading.

Uses

1. This will help portal editors to identify portals which already have good coverage, and also to spot on broad topics which should have more sub-pages.
2. This also helps to identify never-really-started portals, which are possible candidates for deletion. See e.g. Portal:Kandahar, now being discussed at WP:Miscellany for deletion/Portal:Kandahar; that was the portal which prompted me to build this tracking system.

Hope this helps. --BrownHairedGirl (talk) • (contribs) 17:32, 29 April 2019 (UTC)

• Question It looks like certain portal subpages are themselves also being categorized, rather than just the top portal; any way to limit this just to the top portal page? UnitedStatesian (talk) 17:37, 29 April 2019 (UTC)
  • @UnitedStatesian, that would be a very simple piece of code to add. When I saw some subpages being categorised, I had considered adding it ... but I decided to wait and then check whether all of the subpages were in fact subpages, or just misnamed portals. The categories may yet not be completely purged, but here's the list of pages so far:

1. Portal:Beer/Sandbox
2. Portal:Human body/Cardiovascular System
3. Portal:Human body/Integumentary System
4. Portal:North America/Geography
5. Portal:Human body/Reproductive System
6. Portal:AC/DC
7. Portal:Canada/Wikiprojects
8. Portal:Speculative fiction/Horror
9. Portal:Speculative fiction/Publications
10. Portal:Speculative fiction/Fantasy
11. Portal:Speculative fiction/Science fiction
12. Portal:Heraldry/Selected article
13. Portal:Japan/Geography
14. Portal:Africa/Countries
15. Portal:Speculative fiction/People

My plan to look check for pages with a slash in their titles would obviously generate a false positive on Portal:AC/DC, but I'm not sure about the others. Please would you be kind enough to check? --BrownHairedGirl (talk) • (contribs) 18:21, 29 April 2019 (UTC)

After checking, Portal:AC/DC is the only one that is an actual portal (and it is up for deletion). I think you can safely add your code. UnitedStatesian (talk) 18:30, 29 April 2019 (UTC)

Many thanks for the prompt check, @UnitedStatesian.

I will implement it now, with Portal:AC/DC hardcoded as an exception, 'cos I don't want to prejudge the outcome of the MFD. --BrownHairedGirl (talk) • (contribs) 18:50, 29 April 2019 (UTC)

Sub-pages now excluded. I screwed up a few times along the way, so the categories will be a bit unstable for the next few hour while pages get purged. --BrownHairedGirl (talk) • (contribs) 20:24, 29 April 2019 (UTC)

• Comment. As noted above by BrownHairedGirl all sections are categorised separately. In terms of identifying good/bad coverage, this works rather counterintuitively where the portals have a lot more than one selected item, as larger portals IMO should. One of mine has ~9, depending on exactly what it is counting, and most old-style ones should have at least 4: articles, bios, images, DYK. Or is it not counting images/DYKs? What I'm trying to underline here is that there will be a mix of both well-developed and poor portals in both high and low categories, while the poor-to-mediocre ones with only one subbox will tend to sit in the middle. Espresso Addict (talk) 03:11, 30 April 2019 (UTC)
  • @Espresso Addict, sorry, I should have noted that it's not counting DYKs. I had to exclude them, because a significant dose of portals had high numbers of DYK pages which broke the Lua module. In any case, the number of entries on each DYK sub-page is variable, so it was a bit of an apples-and-oranges comparison.

So what the module is now doing is tracking sets of subpages whose title begins with "Selected". That will pick up "Selected articles", "Selected biographies", "Selected pictures", "Selected stripey things which go bump in the night" etc.

My interpretation of the data is that any set of subpages with less than 10 pages is weak, those with over 50 are strong, and that those with under 5 are poor. Obviously that may be offset to some extent by having multiple sets of subpages, but I don't see any way of checking that short of a bot trawling all the portal pages and doing a more comprehensive analysis. So the module is just collecting what data is available to it, and reporting that with big red caveats.

Actually, it has just occurred to me that I think there is a way that a different module could do a somewhat broader analysis. It might be a bit of a stretch for my hacker levels of Lua coding, but if this project settles on a few stable models of portals, it would probably be worth developing it to all a wee "portal info" link somewhere on the bottom of the page which could generate a quick report on the claimed number of subpages in each section.

(Personally, I think that the current many-subpages model of portal is a very bad idea which should be phased out, but that's another discussion). --BrownHairedGirl (talk) • (contribs) 12:31, 30 April 2019 (UTC)

@BrownHairedGirl: I don't know whether everyone is using "Selected"; some might be "Featured" or "...of the Month/Week/Day". (Some of those would have 365, obviously.)

My personal categories would be roughly <8 poor, 8–12 low, 12–15 moderate, 15–20 fair, 20–45 ideal, >45 too many, should be split. The featured portal process used to broadly require 20 in all boxes; and a minimum of 2 textboxes plus images, as I recall, though there were exceptions where there were more than the minimum number of boxes. OhanaUnited was the arbiter.

DYKs are problematic; I hand-assemble sets of 4 or 5 with an image, but others put individual DYKs into subpages and let the randomisation pick a set. And they do tend to accumulate in a large numbers, especially if someone's gone round specifically searching them out from the archives. A proper DYK display is a lot of work, believe me; much easier to add textboxes and especially images.

A detailed bot report would be interesting. Sometimes it's hard to see how many pages there are, especially where there's no see-all-on-one-page feature. The max= figure is not always correct (and can go either way). Espresso Addict (talk) 13:10, 30 April 2019 (UTC)

@Espresso Addict, your assessment of counts makes sense. Your groupings don't quite align with the thresholds I used, but are not wildly divergent, so I hope the current set is some help. If there is consensus for any particular grouping, I'd be happy to change the categories (it would take me about 20 minutes work to implement it, so not a big deal).

Yes, the max= figure can be wrong, which is why I didn't rely on it, and created the two tracking categories for anomalies (fewer pages than max and more pages than max). It looks like someone has already been doing some cleanup there, which is great.

I can see that DYKs take a lot of research. I am not persuaded that it's worthwhile; a more sophisticated search system than TTH's current implementation would probably have much better return on effort.

BTW, I just noticed that the tracking wasn't picking up portals which use {{Random portal component with nominate}}. So I fixed that[5], nad have purged the 116 portal pages involved. Sorry for the oversight. --BrownHairedGirl (talk) • (contribs) 13:38, 30 April 2019 (UTC)

Re DYKs, I don't see the point in throwing them away once done – that was one of the worst feature of The Transhumanist's reboots, IMO – but if anyone could write a really sophisticated finding tool it would be a lot easier than paging through the DYK archives by month one by one with a moderate number of search terms... But if someone can find something that gets all viruses/virals/virologists that aren't computer viruses or viral memes, and doesn't just lose all those including the word computer, deals with the fact that the viruses project actively won't tag virologists, antivirals & is ambivalent towards vaccines, and then persuade the Lua not to time out... Espresso Addict (talk) 13:51, 30 April 2019 (UTC)

@Espresso Addict, I certainly wouldn't support anything remotely resembling a blind cull. But even the good ones are maintenance headache, so in cases where search results come close to replicating the manual version, I'd support replacement. That would obviously require checking in each case and some override system to exclude false positives, but conceptually I think that is achievable in some cases. Viruses is probably example that wouldn't work because of the word's multiple primary meanings, but other topics such as some country names don't have many other major uses. e.g. Uganda overwhelmingly refers to the country, and sadly we don't have an extensive collection of DYKs relating to the ever-important encyclopedic topic of Ugandan discussions.

Now that I have moved on to more scrutiny of manual portals, I am horrified by the proliferation of sub-pages. It's a big maintenance nightmare, as well as an huge attack vulnerability, and a breach of WP:REDUNDANTFORK. I don't intend to do any sort of cull, but some ways needs to be found to massively reduce the number of subpages. It's another example of an area where TTH rightly identified a problem, but implemented a change without enough analysis and no broad consensus that it was actually a good solution. So, no change without lots of discussion and testing ... but e.g. Special:PrefixIndex/Portal:San Francisco Bay Area is a problem to resloved. --BrownHairedGirl (talk) • (contribs) 16:45, 30 April 2019 (UTC)

That's a euphemism I'd never encountered, thanks!

I'd be interested in what the community thought of proactive semi-protection. I don't think I've ever seen a positive IP edit to a portal subpage. One might also fully protect BLPs. To be honest, though, even when my former featured portal was getting 100 hits/day, there wasn't a great deal of vandalism.

I also would like to suggest the idea of using the head subpage – where all the 1–n are listed – as the source. That would greatly reduce the number of necessary subpages. Espresso Addict (talk) 16:57, 30 April 2019 (UTC)

Regarding pre-emptive page protection, current English Wikipedia consensus doesn't favour it, and exceptional cases are those that are vandalized a lot, so portal pages probably won't make the cut.

I do not understand how the older subpage system works, so forgive me for mixing up apples and oranges, but your first sentence triggered an idea, which may or may not be what you're thinking of. Could the helper templates be used to create a one-page portal that draws from a subpage for its source data? This would simplify maintenance by having one subpage to update (e.g. links to relevant articles and a photo gallery for the helper templates to get its info), but not tightly couple the portal page to the specific formatting and layout of mainspace articles. isaacl (talk) 17:32, 30 April 2019 (UTC)

@isaacl, I think that a much better solution would be to stop forking content, and instead adapt some of the modules which TTH wrote to just grab the lede from the article. So manually create a list of selected articles, but let software do the rest.

Better still, dump the magazine-style format, and just list a cluster of selected pages, possibly accompanied by some metadata like the short description data in the article. --BrownHairedGirl (talk) • (contribs) 21:16, 30 April 2019 (UTC)

You mean create a one-page portal that doesn't use any subpages? Sure, that's also feasible. If it were desirable to keep some of the functionality to rotate different content on the portal, then having a separate page to list the content might be helpful, but it probably doesn't make too much difference versus just listing the content on the portal page directly as template arguments. isaacl (talk) 21:29, 30 April 2019 (UTC)

Sorry for being late to the party (been dealing with matters related to floods in central and Eastern Canada at work). I didn't have time to read through all the comments above so I'll just reply to the portion where I was pinged by User:Espresso Addict. Featured portals should have at least 20 items. I want to emphasis on should. Under 15 means there's probably not enough depth in that area to merit its own section. But I'm not chasing numbers either. I would rather have 18 FAs/GAs as selected articles instead of 25 selected articles but the number is padded by 10 stubs and start-class. And it's very rare to have too many items lol. I echo what Espresso Addict said regarding DYK. It's very tricky to deal with and add contents. You want to avoid overlapping with the selected articles or images' topics. But you also don't want to pick a topic that the hook is too obscure or not interesting. Often times, it's impossible to find 20 DYK items and I will let it slide. OhanaUnited^{Talk page} 01:23, 3 May 2019 (UTC)

Thanks, OhanaUnited. I think we always differed on how much weight to put on quality as opposed to importance. The advantage of FA/GA/FL is that someone else has reviewed the article in detail; if one includes B-class/below one has to do that oneself, which is time-consuming but probably good for the project, as the article will tend to improve during the review. I'd not advocate adding Starts unless one could first upgrade them to at least C-class.

I had not thought of DYKs duplicating selected articles as a problem, except where the header image is duplicated. In the ideal world, sets with a range of DYKs that are actually interesting would be great, but that isn't what the main-page project is generally generating these days. Espresso Addict (talk) 09:42, 3 May 2019 (UTC)

Counting redirects

• Question: does the categorization exclude redirects in the count? I do not think these should be included. UnitedStatesian (talk) 14:40, 30 April 2019 (UTC)

• @UnitedStatesian, no it doesn't check whether a page is a redirect. So unfortunately, redirects are included.

I would like to exclude them, and the coding to do so would be very easy: just three lines of code using the Title objects property "isRedirect". Unfortunately, that's listed as one of the Expensive_properties, so if I call that too many times the Lua module is halted, leaving a redlinked error instead of output.

This overuse of one of the Expensive_properties is what caused the module to break on large sets of subpages, sadly causing you to get yelled at in MFD:State-level road portals. If I enabled redirect checking, I would double the number of calls to expensive properties, so I'd have to further reduce the number of subpages checked, which I think would severely degrade the utility of the tracking.

So I think that the remedy is to delete the redirects, after checking whether they are needed. --BrownHairedGirl (talk) • (contribs) 15:24, 30 April 2019 (UTC)

Suggest change

As mentioned by another editor above, I know of many portals that use "Featured . . ." rather than "Selected. . ." in their subpages. Any way to add that second word in generating the count? UnitedStatesian (talk) 17:25, 1 May 2019 (UTC)

@UnitedStatesian, it's not even a SMOP.

Please can you point me to some examples, just so I can check that I understand the usage correctly? --BrownHairedGirl (talk) • (contribs) 02:51, 2 May 2019 (UTC)

@BrownHairedGirl: here's one and here's another UnitedStatesian (talk) 12:30, 2 May 2019 (UTC)

Thanks, @UnitedStatesian. Now implemented in these 2 edits: [6], [7]. --BrownHairedGirl (talk) • (contribs) 18:00, 2 May 2019 (UTC)

Redirected portals

Portal: namespace has many redirects for good reasons. However, a few portals were discussed at MfD, found no consensus or a consensus to keep, but were subsequently replaced by a redirect to a broader portal. As this may have been accidental, I would like to respect the MfD outcomes by restoring these portals. The topics are narrow and the portals could be improved, so I see no objection to their immediately going to another (possibly bundled) MfD.

• Portal:Kent (previous version) redirected to Portal:South East England following no consensus at MfD
• Portal:Quidditch (previous version) redirected to Portal:Harry Potter following no consensus at MfD1 and keep at MfD2
• Portal:Years (previous version) redirected to Portal:History following keep at MfD

Any objections? Certes (talk) 19:00, 29 April 2019 (UTC)

I have no objection even though I am one of the 3 redirectors. UnitedStatesian (talk) 19:01, 29 April 2019 (UTC)

No objection to restoration. North America¹⁰⁰⁰ 19:10, 29 April 2019 (UTC)

I strongly object to restoring Portal:Years. The last version[8] before redirection[9] by @Fram was just an empty shell, similar to mountains of similar junk which we have deleted in recent weeks. If it's restored, I will immediately MFD it, but please @Certes will you spare us that discussion?

The Feb 2017 MFD was all about "potential", but we have far too many of these abandoned portals with "potential" which never be realised because there simply aren't enough editors interested in maintaining them. That MFD included a boast of the staggering popularity which meant it actually received 286 page views in the last thirty days. That's just under 10 views per day, which is abysmal.

It's also a spectacularly pointless portal, for reasons I hope should be obvious, but just in case anyone misses it: I don't need a pseudo-portal to serve a random year, cos I can just type in a random number <=2019 in the search box and go directly to an article.

Some redirects may be worth restoring, but that one?

Similarly, Portal:Quidditch. For goodness sake, it's a fictional sport from one novel series. That's a classic example of a narrow topic. --BrownHairedGirl (talk) • (contribs) 19:22, 29 April 2019 (UTC)

Fair enough: I'll abandon the idea. I agree that quidditch is too narrow a topic to justify a portal. I just felt that being seen to respect the community's views as expressed in two MfDs might show this project in a better light than effectively deleting the page in the face of repeated consensus not to do so. Certes (talk) 19:28, 29 April 2019 (UTC)

@Certes: Two discussions, both poorly attended. Consenus can change, in respect of portals there clearly has been a big shift in the last 10 weeks.

If this project wants to recover from its well-deserved leper-status, unredirecting a narrow-scope portal on a niche topic is not the way to go. --BrownHairedGirl (talk) • (contribs) 19:43, 29 April 2019 (UTC)

• Comment. I wouldn't bundle these three together as they seem rather different.

• Quidditch is a classic example of a narrow topic not suitable for a portal. The 2nd MfD (2018) closed with keep but the closer noted "Discussions about upmerging to the Harry Potter portal can be done on the talk page", so redirection is clearly possible if such a discussion was held, and possibly even if it was just done and no one objected.
• Kent might be suitable for a portal, depending on how much coverage the encyclopedia has, but was MfD'd back in 2013 as no consensus and remained a sea of redlinks until Transhumanist et al. started working on it last year.
• Years is covered above, and on a brief look I agree with BrownHairedGirl's assessment. Perhaps Portal:History could link to those of the individual decade portals that are worth promoting, which it does not seem to at the moment? Espresso Addict (talk) 05:08, 30 April 2019 (UTC)

• There's a lot of coverage of Kent, so if we are merely counting the number of available non-stub articles, it's a clear yes. However, I am less persuaded that a 3rd-level national subdivision is conceptually a broad enough topic for a portal, given the low interest from both readers and maintainers. Two weeks ago I began drafting a batched MFD of English county portals, but decided not to pursue it for now because I think it's probably more of an issue for wider discussions about suitable topics for portals. But my sandbox draft shows a severe lack of reader interest in the existing county portals. --BrownHairedGirl (talk) • (contribs) 12:43, 30 April 2019 (UTC)

• @BrownHairedGirl: I guess you realise that you are not going to win me as a friend by suggesting deleting English county portals. I don't think, given the clear bias towards English-language topics here and the long history of some of them, that they are not broad enough – but then I wouldn't, as I've spent years of my life working on one. I will say that the portals are very far from all being the same; some were backed by very active Wikiprojects, others never had a functional project. Espresso Addict (talk) 13:19, 30 April 2019 (UTC)

• @Espresso Addict, I have no desire to alienate anyone, but I also won't shy away from pointing out facts just because some editors find them uncomfortable.

English counties are only Level-5 Vital Articles. It's clear that readers don't want these portals. So at some point we need that wider discussion about how much to retain the vast numbers of unread portals on low-priority topics. But as noted above, I think that discussion needs to start somewhere other than MFD, and probably requires prior broad discussion of the higher-level principles around portals. --BrownHairedGirl (talk) • (contribs) 14:37, 30 April 2019 (UTC)

With respect, we keep quoting Wikipedia Vital Article levels, but frankly that system is just unbalanced as the portal system and not AFAIK part of the criteria for portal guidelines. And counties are only level 5 because England has been inserted below United Kingdom, so English counties are automatically one level below than e.g. oblasts in the Ukraine or tiny cantons in Switzerland. The concept is good and I could see us using it intelligently in future to assess portal relevance, but in its present state it's not a pretty poor guide. Bermicourt (talk) 15:42, 30 April 2019 (UTC)

Sure, @Bermicourt, VA is flawed, but at least it's an actual attempt to define some sort of hierarchy of priorities, whereas portals have mostly been created just on an I-feel-like-making-this basis. I don't take VA as anything approaching gospel, but it's a good initial guide.

As to the the UK, it does have 4 primary divisions: England, Scotland, Wales and Norniron. England is then subdivided into regions, with counties below that, and the average population of a non-metropolitan county is ~500,000, so they aren't big units.

The question I have in the back of my mind all the time is "how many portals can be be sustained overall?" ... and if the set of portals is going to be anything other than haphazard, I don't see much chance of sustaining a set which extends down to such small units unless portals are radially simplified. (Back to the excellent example of Portal:Harz Mountains again!) --BrownHairedGirl (talk) • (contribs) 16:58, 30 April 2019 (UTC)

I respectfully disagree, BrownHairedGirl. By far the best way of getting maintenance work is to allow people to create & work on the portal topics they are passionate about. If my portals were deleted, I would not take up working on some other assigned Big Important Topic Portal. And there's no reason why we should attempt portals for all x where our coverage can differ radically. Espresso Addict (talk) 18:18, 30 April 2019 (UTC)

ETA: @BrownHairedGirl: the average population of a non-metropolitan county is ~500,000, so they aren't big units. Which average is this, by the way? If you look at the 2017 estimated population figures then only five "real" (ie excluding the tiny outliers of Isle of Wight, Rutland & City of London) counties have a population of less than 500k. Espresso Addict (talk) 06:14, 1 May 2019 (UTC)

I've just shoved the table into Excel, and the average population of all counties is mean 1.2 million, median 906k, which changes to mean 974k, median 902k if one excludes the three urban ones at the top (Greater London, West Midlands & Greater Manchester) and the three outliers previously mentioned from the bottom. Espresso Addict (talk) 06:52, 1 May 2019 (UTC)

BrownHairedGirl I agree that portals need sustainability, although well designed / mature ones need little maintenance, so that should be a factor in what is acceptable. Re populations, just look at some of the Swiss cantons - I think I saw one with a population of c. 30,000! So again, it's a factor not to be scorned, but not to be the sole criterion. But I think you and I could agree on a lot of that, at least in principle, if not on the actual levels in every case. BTW I'm glad that Portal:Crawley got deleted; that never merited a portal, especially a half-finished one. Bermicourt (talk) 18:51, 30 April 2019 (UTC)

@Espresso Addict, there are several problem with niche portals, e.g.

• they rely on the continued attentions of the one editor whose passions drove the creation. When that editor stops, it's less likely that someone else will fill the gap
• they set a precedent for the creation of other niche portals by less experienced and/or committed editors. (see e.g. [10])
• they are more likely to draw on less closely-monitored content

@Bermicourt, yes it is possible to design portals which don't need much maintenance, and you have created some good examples thereof. But once you get into the dozens of sub-pages with content forked from the main article, you're in high-maintenance territory.

I agree that any rigid formula will lead to absurd creations as well as absurd omissions. But AFAICS, there needs to be some combination of:

1. importance of topic
2. breadth of topic
3. quality of article set
4. some cluster of editors who will at least monitor it, and preferably maintain it
5. some review or pre-approval mechanism with a checklist to assess whether it genuinely offers value beyond that of other pages pages on the topic.

--BrownHairedGirl (talk) • (contribs) 21:07, 30 April 2019 (UTC)

• User:Bermicourt, do you have any evidence to support your statement above that "counties are only level 5 because England has been inserted below United Kingdom, so English counties are automatically one level below"?  Geographic areas are not always assessed as being (at least) one VA level below the area that they are part of - e.g. (perhaps taking an extreme case) Paris (VA3) is part of Île-de-France (VA5). If your statement is just an (incorrect) assumption please strike it. DexDor ^(talk) 19:04, 30 April 2019 (UTC)
• @Espresso Addict: to your statement above that you would "not take up working on some other assigned Big Important Topic Portal": not sure what the county closest to your heart is, but say that instead of being located at Portal:Favourite County and subpages, as is presently the case, all of the portal content was at Portal:United Kingdom/English Counties/Favourite County and subpages? Is there really a difference, in your view? Just trying to find some win-win middle ground here. UnitedStatesian (talk) 23:12, 30 April 2019 (UTC)

Er, yes, there really is a difference. I can't imagine how one would subsume a fully developed county portal into Portal:United Kingdom – which btw is on the list of those trashed, I notice – or why on earth one would want to. Espresso Addict (talk) 23:31, 30 April 2019 (UTC)

I'm not saying the current version of Portal:United Kingdom, but imagine a true, very broad country portal for the UK. Look at Portal:Human body: each other tab across the top leads to what is effectively a separate portal, except . . . each isn't: each was made up of (and will be again, once my WP:REFUND requests are complete) subpages of Portal:Human body, so: doesn't count in how many portals exist, not subject to discussion of "is it a broad enough subject?", doesn't have its pageviews counted, unlikely ever to be separately brought to MfD, etc. You see where I'm going here? UnitedStatesian (talk) 00:12, 1 May 2019 (UTC)

@UnitedStatesian: That's an interesting model of a portal, or it was before someone deleted it all! If there's no other solution to sub-regions that kind of fadge might be an avenue to explore. If one wanted to retain the portal colours, then the frame portal would probably have to be white, not a distinctive colour scheme such as pink/orange. Also what would you do with 48 tabs? If you were not careful you'd just reduce the hits by making the existence of a subportal less obvious.

Would you, by the way, also be suggesting doing that for US states? Seven of which have lower populations than the County of my Heart?

I'm not really seeing how it benefits the project though, other than reducing #PORTALS, as it would require just as many subpages. Espresso Addict (talk) 06:06, 1 May 2019 (UTC)

Yes, I would suggest doing it for all subnational divisions other than cities: U.S. states, German states, all of them. And I think reducing #PORTALS (to several hundred or so) is a huge benefit to the project: makes WP:ENDPORT2 less likely, significantly drives up per-portal pageviews, increases editor collaboration, etc. Number of subpages dedicated to high-quality portals does not matter at all. UnitedStatesian (talk) 14:29, 1 May 2019 (UTC)

Noted. If it was agreed to put all sub-national portals in a structure so that they were technically within the national portal, in such a way that all the portal's features (including colour scheme) could be accommodated, that might be less offensive. I worry it would still further reduce these portals' hits, though. And I don't know how much traction you'd get from US editors for the suggestion when it related to US states. Espresso Addict (talk) 15:16, 1 May 2019 (UTC)

• I object to a sweep of reverts to redirected portal. Over many years, before this year, the vast majority of MfD-ed Portals should have simply been redirected, they were over-specific and completely redundant to another Portal. In some cases, this can be done recursively three times over. Reverting a redirect to make live again a redundant Portal is not an improvement and so don't do it. --SmokeyJoe (talk) 03:36, 1 May 2019 (UTC)

• I agree with @SmokeyJoe. Unredirecting junk is spectacularly unhelpful, unless it is followed by some other action. We now have two currently open MFDs on @UnitedStatesian's unredirected portals: WP:Miscellany for deletion/Portal:Narendra Modi and WP:Miscellany for deletion/Portal:University of the Philippines.

UnitedStatesian, if you really have to unredirect junk like those two pages, please will you at least MFD it yourself, rather than leaving others to find it and nominate it? --BrownHairedGirl (talk) • (contribs) 13:08, 1 May 2019 (UTC)

Of course, @BrownHairedGirl:, that was always my plan, as you will see from upcoming noms.; apologize that I got pulled away unexpectedly and was not able to complete the MfDs before you got to them. I do think there is some value to un-redirection followed by MfD discussion, as, for example, we currently we have all the subpages for Portal:Quidditch and others hanging out in limbo. UnitedStatesian (talk) 13:17, 1 May 2019 (UTC)

I think that is even more stupid than ignoring portals. Do you enjoy busywork? Or do you enjoy putting others to busywork? The point has been made with MfDing portals. What more do you hope to achieve at mfd? —SmokeyJoe (talk) 13:26, 1 May 2019 (UTC)

• All redirected portals should stay redirected until they become eligible for WP:CSD#G8, when the target gets deleted. Portal subpages can be redirected to their main portal page. A dispute about a redirection of a portal, cases of Wikipedia:Pseudo-deletion by redirection, can be formally discussed at WP:MfD and reviewed at WP:DRV, but only if there are at least two people in disagreement. --SmokeyJoe (talk) 01:46, 3 May 2019 (UTC)

I hope those fears are unfounded. I'm assuming good faith, rather than seeing the redirects as preparation for stealthy deletion via G8. Certes (talk) 02:10, 3 May 2019 (UTC)

Ill considered portals, ill-considered because they are too thin and completely redundant to another portal, should be redirected to the portal that covers the topic. There is no deletion concerns with that.

If, later, the community decides to delete portals wholesale, that will be the deletion decision that covers the history of the redirected ill-considered portals. I don't see anything much to worry about. A community decision to delete many, most, or all portals will not be stealthy. Ill considered portal histories behind redirects will not be missed because G8 bots will sweep them up. There is no need to revert their redirection to get them deleted.

My preference is to archive all of Portalspace, not delete it, there is no history in it that needs hiding. For anyone particularly enthused to continue with Portals, let them fork it offsite, anytime they want. I think portals have not been fo rthe benfit of the prject for at least 15 years, if ever. I think there is only one portal that needs keeping, Main Page, and it is in mainspace. Something needs to be done with the confusing Wikipedia:Community portal. --SmokeyJoe (talk) 06:56, 3 May 2019 (UTC)

To be brutally honest, SmokeyJoe (and I realise you were pointed here from an MfD by, I think, BrownHairedGirl), I don't think repeating these views here is pointful. You're entitled to hold them, and this project is of course bound by well-conducted site-wide RfCs, but in the meantime it only inflames matters to rehearse them in front of those who are bound to disagree vehemently with you. Espresso Addict (talk) 10:40, 3 May 2019 (UTC)

(ec) @SmokeyJoe, you make my heart sink.

WP:ENDPORTALS was a year ago. It closed as don't delete all portals. It's fine for you to wish it was otherwise, and hope to overturn it ... but unless and until that is overturned at a new RFC, that's established WP:consensus. And we all have to work within that consensus.

So proposing options now on the basis that everything is going to be deleted anyway is a WP:IDHT approach, and musings about overturning the consensus are disruptive to a discussion on the immediate issues which are undecided. --BrownHairedGirl (talk) • (contribs) 10:47, 3 May 2019 (UTC)

I think I am being misunderstood. There is no decision to delete all portals. Unless that decision is made, an unlikely hypothetical, redirected portals will not be deleted. Redirected portals are not being backdoor deleted. —SmokeyJoe (talk) 10:57, 3 May 2019 (UTC). Portals that are too thin should be redirected, not MfD-ed. Deletion is for things that should have never been. —SmokeyJoe (talk) 10:59, 3 May 2019 (UTC)

@SmokeyJoe, redirected portals will be bot-deleted per G8 if their target is deleted. So it's better to have a discussion, because otherwise redirection becomes a path to stealthy deletion.

And in the case that led us here, we were dealing with what was basically an abandoned test page. There's no need to get finnicky about preserving that for posterity. --BrownHairedGirl (talk) • (contribs) 11:05, 3 May 2019 (UTC)

I am not emotionally involved with any of this, and I seemed to have been sidetracked, with different thoughts crossing. I thought I was here from talking about Portal:Narendra Modi. If that is redirected to Portal:India, it is not deleted. I think that would be a good outcome, because Modi belongs in Portal:India. I am indifferent to whether Portal:India continues. —SmokeyJoe (talk) 11:12, 3 May 2019 (UTC)

Alert bot is running again

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)

Proposing two-stage process for deletion of portals

I've mentioned this in several places, but I'd like to propose formally that this project institutes a two-stage process for the deletion of portals. This would apply to old portals (pre-dating the "End Portals" RfC of last year), whether or not they had been converted to the automated format. I don't envisage it applying to any brand-new portal without history, nor to the remaining navbox-, list- or outline-based automated portals, which are generally easy to assess and difficult to improve without essentially starting from scratch. Portals that urgently need deleting for any reason (I'm thinking of BLP violations in particular) would also be excluded. It might also exclude portals on a truly miniscule article base. The process would be optional, but a reasonable argument for retention at Miscellany for Deletion would become that the nominator should have taken it to Portals for Discussion (or whatever) first.

I envisage this working a little like the now-defunct portal peer review, and it could form a sub-part of a revival of that process. The nominator would identify a substandard portal, and would bring it to the forum. They would notify all interested parties, including creator, maintainer and relevant Wikiprojects. The focus of the nomination would be on the ways in which the portal needed to be improved in order to be more useful to readers. Nominations would not usually be batched. Everyone would be encouraged to critique, bluntly if necessary, but also to help out in improving the portal. The process would last longer than the MfD cycle, perhaps a month, or even longer if the portal was still being improved. At the end of this time, either the original nominator, or perhaps a co-ordinator, or another uninvolved project member, would either (1) declare the portal adequately improved; or (2) move to a MfD deletion request, which would proceed in the usual fashion.

The advantages I see for this process include:

• it would be less confrontational and more collaborative
• plenty of time would be allowed to find maintainers and improvers, and to get collaborations going, and there would be no artificial time cut-off imposed
• novel solutions such as merging or radical changes to the format could be discussed
• some portals would be sufficiently improved that readers would benefit
• if the portal did go on to MfD, it would be likely to have a smoother ride to deletion

Some obvious disadvantages:

• it would take longer and it's not really suitable for batching, so it would slow down the reduction in number of portals
• it's harder to see how scope/topic breadth could be brought into the critique, as that's difficult to improve in what's still a relatively short timescale
• there isn't consensus on what "a truly miniscule article base" means in practice
• those outside the project would no doubt continue to bring portals straight to MfD
• admins closing MfD discussions would need to buy in to the keep argument that the portal should have been brought to the process first

Thoughts, anyone? Espresso Addict (talk) 17:49, 1 May 2019 (UTC)

First, thanks for the good thoughts on portal improvement, here, and of course elsewhere. Second, I think this is a solution to a problem that is pretty temporary: I think we have only a couple weeks more, at most, of significant MfD nominations. But I do think all would benefit if we can get back to running this WikiProject more like other projects, focused on collaborating around the quality (n.b.: not quantity!) of their content. Even without bringing back featured portals, there are things we could do. Other projects have article-improvement-of-the-month; let's have a portal-improvement-of-the-month for May: have the project nominate one portal that a large subset agrees should stay but that needs help, slap a {{construction}} tag on it, rope in the related subject-area WikiProject(s), and see what happens in a month. Other projects have missing article drives; let's have a single missing portal drive: have a process to nominate one missing broad-subject portal each month, create the shell, and again, rope in the related subject-area WikiProject(s) and build the high-quality portal. Thoughts welcome. UnitedStatesian (talk) 18:12, 1 May 2019 (UTC)

@UnitedStatesian: I fear that we all have such different ideas as to what constitutes an adequate portal, and how many portals is a good number, that we are going to be continuing to have a stream of deletion requests, hopefully at a reduced rate, for months, with escalating howls of anguish from maintainers who find their portal is next up. I don't know if we can resurrect portal peer review to review portals that the nominator did not create, especially when one possible outcome of drawing a portal to the attention of the community is a request for deletion.

These are all good ideas. I'm 100% behind trying to focus on quality not quantity. There's also some thinking harder to be done about what these automated methods can do to improve quality, rather than erode it. We've all spent a lot of time talking round in circles on this project, without doing an awful lot to improve the portals in our care. I think we should probably focus at present on what we have, rather than creating new – at least unless there are really obvious gaps that someone cares to bring up.

If you want to suggest a portal for collaboration, how about Portal:Companies? Very high hits (relatively speaking!), very limited content. Espresso Addict (talk) 20:02, 1 May 2019 (UTC)

@Espresso Addict: Funny you write that since I am proud member of Wikipedia:WikiProject Companies; you must have checked my contributions! I'm not ready to tackle Portal:Companies since it is not yet clear to me how/if it will interact with Portal:Business. How about Portal:Nautical? UnitedStatesian (talk) 17:11, 2 May 2019 (UTC)

Long reply and ALT proposal from BHG: the incubator

I really appreciate all the deep thought and good intent in Espresso Addict's proposal. Huge thanks, EA for the time and care you put into it.

Like @UnitedStatesian, I think that the current phase of MFDs is slowing down. We've mostly finished the automated spam, and are motoring fast through the set of long-term abandoned portals. I am not seeing a problem there.

But there is a problem with the much larger set of portals which are poor but not obviously-kill-it-now abysmal. So I think EA is asking the right question about what to do with them, even if that wasn't EA's primary focus.

However, I have two fundamental objections to EA's proposal as formulated:

1. It puts a process barrier between editors and XFD. I am not aware of any other such barrier, and creating one would requite a broad community consensus at RFC. I would oppose such a barrier for three reasons:
   • As a matter of basic principle, XFD should be drectly accessible to all editors. It's kinda the ultimate safeguard against cliques: let everyone pile in.
   • Technically, MFD is easy to access because Twinkle will auto-build the nomination. That may sound trivial, but it's actually really important, because Twinkle makes MFD accessible in practice as well as in theory. (Without Twinkle, most editors find XFD about as accessible as a wheelchair user finds a wide-open door at the stop of a flight of steps). An alternative process would not be as accessible.
2. EA's proposal puts this project in pivotal position, and bluntly I don't trust this project with such a role. I don't trust it to try to work within broad community consensus. There are some fine editors here such as EA and Bermicourt for whom I have huge respect, but too many others whose judgements seem to me to be a long way removed from the outcomes of broad community discussions ... and the project's record is not encouraging.

So, I'm sorry, but I object long and hard to EA's proposal as currently formulated.

However, my suggested alternative isn't a million miles away, but avoids the pitfalls above. It's simply this: create a pseudo-draft space for portals, with no link from reader-facing pages, i.e. not from articles, categories, navboxes, sidebars or other portals. Much like the existing "Draft:" namespace. Forget the "how" for now, just consider the way it could be used:

• If desired, new portals could be moved straight to draft space (if they haven't already been created there), pending review
• any internal project review process of existing portals could move them to draft
• MFDs would have a third option, just as AFD does. Consider some of the recent MFDs where there has been an editor pledging to fix it all up after a decade of neglect, and in no time make a magical wonderful portals that everyone will love. I'm one of skeptics who and say delete; EA and others are more inclined to say let-em-try. Both views have merits, but if we had a draftify option then I think we could both agree to compromise on "take it offline and let the would-be maintainer develop it"

I think that would radically defuse a lot of the existing tensions. Those like me who want less reader-facing junk in portalspace would achieve what we want, while I hope that those of a more eventualist approach who hate seeing anything deleted would be satisfied too. I think this would take most of the heat out of MFD, because actual direct deletion would be the preferred option of those like me only when the scope was clearly too small. No need to toss a coin on the marginal cases; just draftify and see if anyone turns up to get stuck in.

I came here to start a new discussion because I had encountered some portals which I thought were too poor to leave as reader-facing pages, but which didn't seem to me to be clean deletes, e.g. Portal:New Orleans. See Special:PrefixIndex/Portal:New Orleans: lots of quite well-selected pictures, but pitiful article content. I don't think a picture-gallery should be a live portal, but OTOH if someone were to re-build the portal, it'd be a shame to have to rebuild that gallery.

So I thought up a way in which I think I can make draftify work for portals. And having read EA's proposal, I think it would allay a lot of EA's concerns. (EA, obviously please critique mine hard if you see any failings).

It's quite simple: don't use the "Draft:" namespace, just move it to a new name with a special prefix in front of it. My initial suggestion is "Incubator — ", I.e. Incubator — or Incubator — ... but obviously there are other possibilities. (Just not "Draft", to avoid confusion)

So take Portal:Jimbo Megacity, about the Jimbo Megacity meagalopolis in Wikitania. It has a population of 20 million, the world's highest GNP per capita and en.wp has copious coverage of its illustrious people and their stupendous achievements. GA-class head article, >800 non-stub articles within scope including lots more GAs and some FAs.

However, the current Portal:Jimbo Megacity is dire. Five rubbish photos, 1 selected biog (a stub on some minor lawyer of at best marginal notability), and a selected article about some minor bank robbery 15 years ago.

• Eventualist insists: c'mon, it'll be easy for somebody to make this good! Don't just kill it! There's no deadline.
• Deletionist replies: yeah, but when will it get good? There are 500 other crap portals, and this one has been rotting since we got the new steam-driven server in 1802[diff].

Both sides are right, just have different priorities.

So I reckon the win-win solution is: move it to Portal:Incubator — Jimbo Megacity, along with all its subpages, leaving no redirect. A one-click move, just like any other.

Hey presto! It's all intact. It will still work as before, and can still be developed with none of the glitches that arise in the "Draft:" namespace.

Can anyone see a downside to this? --BrownHairedGirl (talk) • (contribs) 02:27, 2 May 2019 (UTC)

@BrownHairedGirl: There has not been a better idea in the history of ideas for portal creations!!!
Suggestions:
(1) Call it Portal:Ω and make everything a subpage of that. Therefore, in your example the move would be to Portal:Ω/Jimbo Megacity and its section on topics to Portal:Ω/Jimbo Megacity/Topics. Portal:Ω is what I suggest because this way it alphabetizes/categorizes the portals to the bottom of any list (per WP:SORTKEY). I know it'd make things difficult to type out, but it can save us a lot of backend work where things like Special:PrefixIndex/Wikipedia:Miscellany_for_deletion/Portal: isn't cut in half by a huge list of pseudo-portals.
(2) We have the option of undeleting thus far deleted portals per WP:SNOW if a user in good standing pledges to maintain them (limited the amount of requests they could make of course). *cough*Portal:Webcomics*cough*
(3) This gets implemented as soon as feasible please. This would really save us a LOT of time. –MJL ‐Talk‐^☖ 03:12, 2 May 2019 (UTC)

Thanks for that endorsement!

Sorry, @MJL, but I am pretty sure it can't have a slash in it. Some of the modules interpret slash in a special way, so adding one will cause malfunctions. And I think it probably should include plain English, for clarity. --BrownHairedGirl (talk) • (contribs) 03:23, 2 May 2019 (UTC)

Perhaps Portal:Ω Jimbo Megacity? I like the idea of having a non-latin character. Would [[Portal:& Omega Jimbo Megacity]] work? — Arthur Rubin (talk) 04:42, 2 May 2019 (UTC)

@Arthur Rubin, as afar as I know, only a slash would cause trouble with the Lua module, though I have not examined the code for other possible issues. But ampersand is best avoided, because it has a special meaning in URLs, and it I'm not sure what issues arise where from the need to encode it in titles.

If the consensus is do it and to use a non-latin character, then so long as there aren't technical issues, I'll go with that. But I think it would be a very big mistake to use some form of code which is non-obvious to the casual reader or the non-portal-specialist editor. Anyone looking at Portal:& Omega Jimbo Megacity will ask "zOMG! WTF?!?!?" and either waste time trying to find out, or move it to some non-WTF title, which would defeat the whole point of the exercise. The less explanation needed the better. --BrownHairedGirl (talk) • (contribs) 05:19, 2 May 2019 (UTC)

• Comment. I fear the major reason that portal deletion requests have slowed this past week is that one of the major instigators is blocked. Otherwise they seem to be ongoing at a faster rate than I can readily keep up with. (I know this is a crowd-sourced project, but MfD does not usually attract many participants (unless the discussions are listed at CEN!)).

First off, I don't think BrownHairedGirl's and my proposals are incompatible. My process is explicitly optional. If implemented, some editors would continue to go straight for MfD; some closing admins would wholly discount "should have gone to the review process first" arguments. Because it would be optional, I don't personally think it would need a community-wide RfC to implement, though I note BHG's disagreement on this point. I don't know how pointful it would be, though, if those who wish to delete low-quality portals were not prepared to give it a whirl. In most implementations I wouldn't see the result as binding, either. If someone closed a review discussion as "sufficiently improved", the original nominator would be completely at liberty to say "no it ain't, -->MfD!!!".

What both BHG and I are proposing, I think, relates to what to do with portals that are (1) clearly substandard; but (2) have what I'd call "legs", ie are not obviously a waste of everyone's time. I don't want to link to specific MfD discussions here but at least some of the recent batch of mainly US university portals might be an example. My process would allow project members to find such portals and to try to rally others to work on them in the immediate short-term (month), without the overt threat of deletion hanging over everything.

Some first thoughts on BHG's idea, which I genuinely think might have legs (to use the above terminology):

I've never used either Twinkle or AWB (I edit entirely by hand, and always have) so I don't know how easy it is to make XfD deletion discussions for newbies. (Can new editors even get Twinkle/AWB??) In my experience, ~95% of XfDs come from a relatively small band of regulars, and XfDs brought even by good-faith newbies are usually speedy kept. What I would be suggesting would be slimline, informal, and hopefully relatively easy to do -- eg adding a comment to a page. If lots of portals were being considered in detail, we'd need to develop subpages, but the DYK nomination system seems to manage to get newbies to do that without too much hand-holding. If there was a moderator (and I'd offer to moderate if that were helpful), the newbie could comment on the top page, and the moderator could create the subpage for them.

Is it really trivial to move multi-page portals? How does that work exactly?

How would we deal with someone creating a new portal to fill the perceived hole?

As I've mentioned in a recent MfD, portals used to be categorised into "live" vs "under construction". The latter weren't linked from mainspace and did not appear in either the category or the list of portals. This seems to have got lost in the wash of moving to the new portal maintenance template. One of the consequences of that appears to have been that a number of portals that had long been abandoned in the under-construction state suddenly went live. I wonder if we could implement Incubator/"Draft" (I'd oppose the use of the omega character for a bunch of reasons) without needing to move portals at all, merely by putting a box at the top of the page that reads "This portal is under construction/redevelopment..." and moving mention of it out of all reader-facing places?

I've had some experience of draftification for new stub articles and basically once an article is draftified, it is very unlikely ever to get any further edits. It's removed from mainspace and all the tracking/content categories & project tagging that enable editors to find it, and usually lingers around until the six months is up and then is deleted G13. If this proposal were genuinely going to work as an incubator, rather than effectively deletion, then that would need to be addressed. (On a side note, Articles for Creation was, I thought, intended as an incubator process, to hand-hold newbies through developing a basic acceptable stub that isn't speediable. What actually exists is anything but – articles need to be super-notable & approaching C class to escape, IMO, and at least some of those who work there object vehemently to the notion that they should help the newbie to improve the article. I'd rather not duplicate that here.)

What I strongly object to – and for clarity, this is not at all what BHG is proposing, but I can see almost any system being used to negative ends – is any process that takes a large number of extant, hand-curated, non-broken portals based on some relatively arbitrary threshold (eg number of [textbox]subpages, number of non-stub articles in head category, date of last update, hit counts, date in the template, maintainer listed &c&c) and removes them to a limbo where they are unlikely ever to be worked on. To be honest, swift deletion would probably be more sensible. Espresso Addict (talk) 09:25, 2 May 2019 (UTC)

@Espresso Addict: It's removed from mainspace and all the tracking/content categories & project tagging that enable editors to find it This is why I suggested a non-latin character like Portal:Ω (which btw, Portal:Ω/Webcomics, Portal:Ω:Webcomics, or Portal:Ω Webcomics or whatevs makes no difference to me. I suggested subpages just because I figured the technical limitations were less of a problem, but I guess that wasn't true lol). Having a non-latin character means we can keep them in all the hidden/tracking categories without getting in the way of the regular portal-space portals. The alternative to that solution is Portal:Zzz-Incubator which is fine, I guess (just prone to miscapitalization).
A separate reason I preferred Portal:Ω is because it isn't supposed to reader-facing anymore once it is moved to that title. –MJL ‐Talk‐^☖ 16:40, 2 May 2019 (UTC)

I have no idea whatsoever how to move pages to a title including any non-Latin character reliably. Outside Wikipedia I've worked on database-driven websites where one of the major problems was titles with en rules in them; they sort differently according to where exactly one sourced the en rule from,and they display differently on different browsers. Espresso Addict (talk) 16:51, 2 May 2019 (UTC)

@Espresso Addict, I am going to create a silly sample portal to play with and test this idea. {{subst:Box portal skeleton}} here I come! --BrownHairedGirl (talk) • (contribs)

@BrownHairedGirl:Good luck – be warned this portal creation process is addictive :) I don't see in principle why we can't use all of your incubator, my idea of a negative side to peer review that leans towards deletion, and a portals for creation process to filter this stuff before someone goes to the bother of creating it. Espresso Addict (talk) 21:23, 2 May 2019 (UTC)

A milestone: less than 1500 portals

Σ Portals
~ 542
As of 06 Jul 2024 17:49

A few hours ago, the total number of pages in Category:All portals dropped below 1,500 for the first time since the tide of automated portals began to surge in mid-2018.

The current count displayed on Category:All portals is "approximately 1,463". However, the category software has a long-standing bug in its counting mechanism; the actual figure can be got by using AWB: 1432.

I have placed a live counter on the right, but note that it is displaying the "approximate value".

I think this is good news. The spammed automated portals are nearly all gone, and cleanup is now focusing on long-abandoned portals which are woefully underdeveloped, and on the few remaining narrow-topic portals.

There are currently 166 portals tagged for MFD, with 1,264 not currently under discussion. That figure of 166 is well own on the 250+ of a week or two back, and I think that the 166 includes some "zombie tags" from old discussions. Also a significant number of current discussions seem unlikely to close as "delete". So, allowing for some more nominations, I expect that the total will begin to stabilise around the 1200–1300 mark.

Before long, the drama will be reduced to a trickle, and this project can get back to improving portals and working towards new broad-consensus portal guidelines. --BrownHairedGirl (talk) • (contribs) 03:48, 2 May 2019 (UTC)

@BrownHairedGirl: What are your views on those remaining automated portals which are not currently at MfD? I have started improving them, but if you plan to MfD them or revert them to non-automated old versions then I'll stop editing pages which are about to disappear and do something else. Certes (talk) 10:18, 2 May 2019 (UTC)

Me too. I'm hesitant to do much more improvement on portals until the smoke clears and there appears to be a working consensus in favour of the sort of improvements to the project and its portals that we've discussed before. Bermicourt (talk) 10:50, 2 May 2019 (UTC)

Here's a radical idea: transparency. Which ones are you thinking of working on, and we can have a pre-discussion here. At the same time, here's my transparency about what I'm thinking has yet to come to MfD (and which I am starting to think about preparing):

• there are still a few performers/politicians/companies/products that, because of narrowness of topic, would not, I think, survive MfD based on previous discussions.
• Other User:Abyssal portals, besides the ones already at MfD, that do not meet the breadth-of-subject-area requirement
• We still have a bunch on individual cities under 500,000 population
• Religious denominations outside the major subgroups of the worlds major religions
• Ethnic groups. This is a new one, but my first look is that most of these are in a sorry state and have breadth-of-subject-area issues.
• At the same time, I think there is little value at this time bringing to MfD any portals on smaller countries, or on subnational political divisions other than smaller cities (i.e., states of US/Germany/Australia/Philippines/India, UK counties, etc.), so don't hold off working on those because you fear an MfD from me.
• And is anyone thinking about any new portals? I think some of the TTH ones on broad subjects could support a recreated portal.

I of course welcome comments on the above in advance of any MfD discussion that may or may not ever happen. What are other folks thinking? UnitedStatesian (talk) 12:16, 2 May 2019 (UTC)

My current portal task has been working through this search improving DYK and ITN search patterns, but I have paused awaiting news on their prospects for survival. Certes (talk) 12:27, 2 May 2019 (UTC)

@Certes, Bermicourt, and UnitedStatesian: I have set out below how I select portals for MFD. Basically, I am triaging to look for clearly bad. Beyond that, I think we need broad discussions about what portals are for, how they should do it (see MFD:Portal:Ireland#4bigquestions) and then which topics should have them.

I personally would like to see the consensus settling on: a) hybrid of the outline model of e.g. P:Harz Mountains and a little of the magazine model, but no pure magazines; b) deprecating the content-forked-subpage model; c) much fewer, better portals, probably numbering in the low hundreds. (I'd prefer 30–100, but think that's probably unachievable)

However, any such big changes require a broad community consensus. Those are not matters for MFD, so I do not propose such things at MFD, and I oppose them if others try using MFD for that purpose.

But I do think that creating new portals right now would be a great folly. That broad consensus is needed first. --BrownHairedGirl (talk) • (contribs) 15:16, 2 May 2019 (UTC)

PS Sorry, I didn't answer Bermicourt's question What are your views on those remaining automated portals which are not currently at MfD?

My take on them is that:

1. some automated portals are so-called "restarted" manual portals. In those cases, it may be worth restoring the manual version, if the manual version is not junk (which it often was, hence the conversions)
2. Automated portals which are just a fork of a single navbox are a clear delete, per consensus of the mass nominations one and two
3. Automated portals which grab links from a non-list article should be killed with fire (see e.g. MFD:Portal:Lusaka)
4. Automated portals which are just a fork of any other single page also are a clear delete in my view, tho some editors have contested some of that
5. Automated portals which build their list by aggregating multiple pages may be redundant if e.g. all those pages are transcluded in one place (e.g. if Portal:MyNiceTown builds its list on Template:MyNiceTown districts + Template:MyNiceTown history and both are transcluded in the article MyNiceTown, we have redundancy.)
6. An automated portal which uses a curated list of topics that would make a good navbox should be deleted and replaced by a new navbox
7. An automated portal which uses a well-curated list of topics that represents a subset of the best-quality and most significant articles in a wide topic is by far the vest way of creating a magazine-style portal. I am not a fan of the whole magazine model, but it has many fans, so unless and until there is a consensus to deprecate that model, this is a vastly better way to implement it than the hideous, abominable, bloated, sprawling subpage model. It a) avoids content forking; b) it is massively easier to build and maintain; c) it is better for readers, because it doesn't require a refresh.

Hope that helps. --BrownHairedGirl (talk) • (contribs) 16:32, 2 May 2019 (UTC)

OK, here's how I am working at the moment. I am looking for portals which fit one or all of these criteria:

1. Broken
2. Abandoned
3. Narrow scope
4. Automated, but redundant 'cos it draws its article list from a single source (making it a fork); usually a single page, but sometimes multiple pages which are transcluded in one place
5. Manual, but with a too small a selection to be useful to readers

The more of those attributes that are present, the more likely I am to MFD. e.g. my most recent nomination is MFD:Portal:Daman and Diu, which matches criteria 1, 2, 3 and 5.

Where scope is narrow and/or Wikipedia coverage maintenance is poor, I advocate outright deletion. In the other cases, I advocate WP:TNT: delete this, but don't necessarily preclude creation of a better portal on the topic.

Right now I am working through Category:Random portal component with less than 2 available subpages. This takes some scrutiny, because many of the portals there have more than one set of subpages, so the total count isn't too dire.

I also have list of random city portals which look to me to be in possibly poor shape, so I will do some more analysis. Where possible, I look for tightly-bound sets with multiple shared attributes, to allow for coherent bundling ... but I'm not finding so many bundles right now.

My main starting points for research have been the tracking categories I created: +subcats, and Category:Portal with subpages tracking+subcats. However, 294 of the portals in Category:All portals are in neither of those category trees, and that needs investigation.

Hope that helps. --BrownHairedGirl (talk) • (contribs) 14:26, 2 May 2019 (UTC)

That's helpful; thanks. It sounds as if most of the pages I intended to repair or improve will be deleted anyway, so I can be more helpful in other areas of Wikipedia for the time being. I'll look back when the dust settles and see if I can improve any portals which remain. Certes (talk) 15:38, 2 May 2019 (UTC)

@Certes, BrownHairedGirl, and UnitedStatesian: thank you for those helpful comments. Let me try and answer US's question about being transparent. I don't have any plans at the moment to create new portals, but hoping those I do manage are spared from the cull. I want to focus on steadily working through the existing ones I manage, fix any glaring problems, reduce red links (takes time as it involves creating new articles, but that's part of the benefit of a decent portal - having c. 5-10% red links to entice editors to "get creating") and automate those sections like "image of the month" which currently rely on manual intervention (and thus get out of date). I've not investigated the automated tools generated during the portal frenzy to see if any are useful, so that's something else I'd like to check out. I know we still have a range of views on total numbers of portals (~30 to ~2000) but I feel that if we focus on what portals are for and what makes a good portal we will converge to a range that we can all live with. But at least it won't be 4,500 and rising! Bermicourt (talk) 17:10, 2 May 2019 (UTC)

In order to get back to improving portals and working towards new broad-consensus portal guidelines it will be necessary to repudiate some of the arguments and tactics we have seen at MfD over recent weeks. For who will now want to make efforts in this direction if their product appears at risk of being clobbered over again?

Arguments: from forking – a concept that in Wikipedia applies to articles. From pageviews – readers searching for a broad topic are offered the article, not the portal: they haven't looked at a portal and decided to reject it as a presentation of that topic. From the absence of a named "maintainer" – not a requirement for any other type of page. It isn't just me. A chorus of editors have been making these points, to no avail.

Tactics: we have seen quite general discussions over portals initiated under MfDs of a particular portal, not stating on its face that a wider community debate was intended. At times there has been something approaching tag-teaming, with a handful of editors !voting delete on every one of a whole sequence of MfDs.

I'm wholly in support of the goal of a limited number of high-quality portals, acting as a "main page for a broad topic" as an introduction to Wikipedia for new readers. Time now for the deletion campaign to end and open debate to proceed: Bhunacat10 (talk), 19:58, 2 May 2019 (UTC)

• Sorry, no dice. There are still plenty of portals that clearly do not meet the current guideline, and which I will continue to bring to MfD. You are welcome to help with that effort. UnitedStatesian (talk) 20:12, 2 May 2019 (UTC)

• No dice from me either. I will also continue to MFD portals which meet the criteria I outlined above.

Yes, of course, some MFDs trigger generalised discussion, which is healthy: individual pages can throw up wider issues. XFD can't make a decision on those wider issues, but discussion at XFD can inform other decision-making processes.

Anyway, I'm delighted to hear that @Bhunacat10 is going to repudiate some of the tactics they have been using in recent weeks, like their assume-bad-faith rant and wild accusations[11] at MFD:Portal:Ireland; see my reply[12].

I wish Bhunacat10 well in getting their head around the idea that forking can applying many different contexts. Maybe then they can move on to next stage of recognising the overwhelming consensus against it mass deletions one, and two, and avoid follies like [13] comment.

Best wishes, --BrownHairedGirl (talk) • (contribs) 20:52, 2 May 2019 (UTC)

Portal maintenance status notes field

I was using this to record the actual maintenance status in the notes field, as a handy summary onwiki of the spreadsheets on my hard-drive. The visible talkpage note seems to have disappeared since I last looked. (It's still there in the portal code.) I don't see an edit in the portal maintenance template history that would make the notes field disappear. Can anyone elucidate? And if that's not an allowable use of the field, can I request a field for which it is allowable, because it was, as I wrote, handy. Espresso Addict (talk) 10:54, 2 May 2019 (UTC)

What template are you referring to, @Espresso Addict? --BrownHairedGirl (talk) • (contribs) 13:56, 4 May 2019 (UTC)

@BrownHairedGirl: Template:Portal maintenance status. Espresso Addict (talk) 14:24, 4 May 2019 (UTC)

Sorry, I couldn't quite figure it out in a quick check of the template and Module:Portal maintenance status.

However, the maintainer seems to have been @Evad37. Maybe they can help. --BrownHairedGirl (talk) • (contribs) 16:13, 4 May 2019 (UTC)

The code for showing Portal maintenance status on the talkpage is in Template:WikiProject Portals, which has recently been edited by MJL - Evad37 [talk] 02:21, 5 May 2019 (UTC)

@Evad:  Reverted I should have tested the changes I made more. My apologies :( –MJL ‐Talk‐^☖ 02:34, 5 May 2019 (UTC)

Project newsletter

I was going to propose we wrote one, given the large number of issues that would merit wider discussion, but I see The Transhumanist has done so. As that editor has not been participating in recent MfDs (as far as I can tell) nor in any of the ongoing discussions on this talkpage (also afaik), this is ... not the newsletter I might have co-written. ETA: As the newsltter repeatedly links the sub-talkpage, I have put a note there indicating that there are ongoing discussions here. Espresso Addict (talk) 11:04, 2 May 2019 (UTC)

For now, I think anyone interested in the progress of portals will get more timely updates by watchlisting relevant pages. There's a case for a newsletter to promote portals to editors who don't actively follow them, but this month's message of "Yay! We deleted another thousand!" is unlikely to boost recruitment. Certes (talk) 11:15, 2 May 2019 (UTC)

It had become a battleground and mudslinging fest. Not the collaborative atmosphere that the previous portal project participants had become accustomed to. Now that the dust has mostly settled, perhaps we can recapture that team spirit, and attract the members back. ;)    — The Transhumanist   11:57, 2 May 2019 (UTC)

The Transhumanist, that would be lovely, although there's still plenty of mudslinging going on I'm afraid. But there's plenty of work to do so hopefully we can get back to that collaborative atmosphere now and start making progress again. Other than the newsletter, I think we should work on:

• Some definitive creation/deletion criteria for portals, based on the scope of the topic they cover
• Some clarifications at WP:POG so it's clear which bits are best practice and which bits are minimum criteria for a portal to exist, and an update to reflect the lower maintenance overhead of transclusion based portals
• A bit of a spruce up of the project talk pages - at the moment they're full of angst-ridden rants and it's hard to find useful, constructive discussions to contribute to or take notice of.WaggersTALK 12:22, 2 May 2019 (UTC)

Given the enormous shitstorm created by @The Transhumanist's spectacularly destructive portalspamming antics over the past year, his current topic ban and his failure to assist in the cleanup ... it seems to me to be an utterly outrageous act for TTH to issue a purported newsletter in the name of the project, esp since it appears to have been done unilaterally.

I am appalled. This is precisely the sort of Napoleonic, anti-consensus antics which led to the massive shitstorm in the last few months. Have you absolutely no shame at all, man?

In recent weeks, this project has been starting to have some good, fundamental discussions. TTH has chosen to take no part in those, but instead makes unilateral pronouncements in the name of everyone else.

If this project is going to allow TTH to Waltz back in and resume speaking for it without any consensus-building, then it's time to reopen discussion on shutting down the project and/or making TTH's topic-ban complete and permanent. --BrownHairedGirl (talk) • (contribs) 15:31, 2 May 2019 (UTC)

@Espresso Addict: I'm sure The Transhumanist could use some help with newsletter building (as far as I know The Transhumanist has always put together the newsletter solo, and it looks like a lot of work). While I found the last one informative and remarkably measured (and have said so "on the record"[14]), there's a whole lot going on that it doesn't get into, as you (Espresso Addict) touch upon.

While I've only participated in this project as an MoS advisor and an occasional commenter on open questions (and first arrived here as a skeptic, half-convinced that portals should just go away, only to have my mind changed by this renewed project), I think the witch-hunt against the project and its work, and especially the WP:BATTLEGROUNDing incivility against project participants as a class, cannot be permitted to continue. I attempted to get ArbCom (at a WP:RFARB opened by @Robert McClenon:, as I recall) to accept a case about this "portalwar" and the WP:ASPERSIONS, WP:AGF, WP:NPA, and related problems, as well as WP:TE and WP:POINT antics, about a month ago, and they declined. The situation has eroded sufficiently – despite the warning of being RfArb'd, and one of the instigators getting indeffed for directly related reasons, after the instigators turned on each other – that I think ArbCom would accept another case request. But I don't really consider myself a directly aggrieved party, just a shocked observer. Someone clearly needs a topic ban, but someone else from this project with a more direct grievance and better-collected evidence may have to ask for it.
 — SMcCandlish ☏ ¢ 😼  07:03, 5 May 2019 (UTC)

Purpose of portals?

The portal purge has pretty much established, by limiting subject scope, that portals will not be allowed to become a comprehensive navigation system. (So, if you are studying oranges, you will need to go elsewhere, as the most specific relevant portal is on plants).

The reason for that is actually strategically sound, and goes something like this: most (if not all) portals get dismal traffic compared to the corresponding articles, and the lack of traffic is especially pronounced for narrow subjects. Therefore, the effort spent on them would be better applied to articles.

This doesn't make much sense until you consider articles as navigation pages, with the potential to be developed further as such. Far more people see the navigation features on root articles than those who look at all other types of navigation pages combined.

Not to take advantage of this fact is to ignore the profound benefit provided to Wikipedia by Google and other search engines. They bring the traffic to the doorstep of each subject: to its root article. That's what users type in as their search terms, and those are the pages they arrive at.

So, attempting to build a comprehensive navigation system in the portal namespace, which gets a tiny fraction of traffic by comparison, is misguided effort.

However, developing new or enhanced navigation features on articles directly could lead to another debacle like the infobox war, or the portal purge and reversion we just went through.

A better option might be to not touch the articles at all (that is, take an indirect approach), and develop the navigation elements as software features. Pop-ups are a prime example, as is the slideshow feature of Mediawiki.

This can be done through Phabricator (working with the developers of Mediawiki), or by developing userscripts/gadgets. The latter is probably easier than the former, and more hands-on accessible to editors.

As userscripts, new features would unlikely be the focus of deletion efforts, because all they would be changing is the view (not the saved articles themselves), and because their use would be optional. Only users who wanted to apply them would install them. If a userscript became popular enough, it may inspire the development of a Mediawiki feature.

Lesson learned: if you want comprehensive, to make it worthwhile: think "traffic".

Where does that leave portals?

As samplers (providing "topic tasters") for broad subject areas. Each similar to a Readers' Digest on a particular (wide) topic.

So, the community needs to decide how broad they want portals to be, and what any other selection criteria should be. And the place for such discussions is the portal guidelines discussion page (WT:POG). See you there.    — The Transhumanist   11:57, 2 May 2019 (UTC)

TTH, the place for such discussions is in broad RFCs at the village pump. Your practice of having project-space discussions with your cronies while shouting down objectors and not seeking broad community support, so that you could then stealthily rewrite guidelines according to your own personal preferences, is precisely what led to the almighty shitstorm which began in February.

If you are going to try to resume the destructive practices of before, then it's back to the drama boards time. --BrownHairedGirl (talk) • (contribs) 15:36, 2 May 2019 (UTC)

I disagree. Wikipedia talk:WikiProject Portals is the best place to talk about the Portals project. Also, please refrain from the use of profanity in discussions as it does not add any value.--Paul McDonald (talk) 15:57, 2 May 2019 (UTC)

@Paul McDonald, the practice of making broad decisions among a small clique in a sub-page of projectspace is precisely what led to the project getting so wildly out of step with community consensus that whole thing exploded as a storm on the drama boards, and led to the deletion in recent weeks of 75% of all portals. Big decisions belong at WP:RFC, and if that principle is any way controversial amongst fans of the portalspammer, then it's time for community intervention via the drama boards.

If you really, seriously, have any lingering doubt that there was something very radically wrong with a project which saw 75% of its pages deleted in two months, including 45% of them deleted by overwhelming consensus in in a pair of record-breaking WP:CENT-advertised mass nominations, then the community needs to intervene now before the cycle is re-started.

And, no I will not refrain from calling it a shitstorm. That's actually a severe understatement for a long-term project failure which exploded over WP:AN, WP:ANI, WP:VPP, WP:RFAR and WP:MFD. If you actually want to be constructive, stop trying to be a language cop and start upholding the core en.wp principle of WP:CONSENSUS-building. --BrownHairedGirl (talk) • (contribs) 16:44, 2 May 2019 (UTC)

Then why even have a page for Wikipedia talk:WikiProject Portals? If it's not for discussing the project, what would it be for? As for the other issues, I'm not opposed to the deletion of the recent large volume of portal creation. I am opposed to uncivil language.--Paul McDonald (talk) 19:14, 2 May 2019 (UTC)

@Paul McDonald, This is not complicated. Project space should be for discussing how to implement the community's consensus, or for identifying areas where consensus is unclear ... not for making big decisions without community support, and certainly not for steamrollering through huge changes to a whole namespace which were known from the outset to both controversial and unresolved.

Like Arbcom, I am massively less concerned about the profanity checks than about uncivil conduct. Steamrollering through huge changes, creating a huge storm, leaving others to clear it the mess, then wandering back and without any apology or regret, arrogantly presuming to speak for a whole bunch people and proposing to restart the conduct which led to the crisis in the first place .... that's a squillion times more uncivil than a whole pageful of plain words. --BrownHairedGirl (talk) • (contribs) 19:28, 2 May 2019 (UTC)

I'm with BHG on this one: TTH certainly has a lot of balls (is that profanity?) to waltz (Her word. Perfect.) back in after doing nothing to help with the cleanup (which is ongoing and will be for some time) and suggest proceeding without broad community consensus that is not possible to achieve in a WikiProject discussion. UnitedStatesian (talk) 20:09, 2 May 2019 (UTC)

Let's presume that is 100% correct at this point: that still is not a reason for uncivil behavior. See the essay Wikipedia:All Five Pillars are the same height and also A weak personal attack is still wrong. As is said above, the editor's actions indeed may be "a squillion times more uncivil than a whole pageful of plain words" -- simply being less severe doesn't bring the bad behavior into the category of good behavior. Nor should uncivil behavior be returned with more uncivil behavior. We have five pillars. They all matter.--Paul McDonald (talk) 21:08, 2 May 2019 (UTC)

Sadly, Paul, the only aspect of them that I have seen you expressing any concern about is your offence-taking that the portalspammer is called a portalspmmer, and a shitstorm is called a shitstorm. If you showed a fraction of the same concern for consensus, rather than describing it as "kool-aid" and objecting to calls for RFC, then I would be more inclined to take your complaints seriously. --BrownHairedGirl (talk) • (contribs) 00:49, 3 May 2019 (UTC)

I'm confused. Again. It seems like you mean you'll only listen to me on topic A if I first agree with you on topic B.--Paul McDonald (talk) 01:43, 3 May 2019 (UTC)

For once, we agree! You are indeed confused. Very much so.

Nothing in what I wrote there was about you agreeing with me. It was about your failure to embrace the core policy of consensus. --BrownHairedGirl (talk) • (contribs) 09:53, 3 May 2019 (UTC)

Where or how have I failed to embrace the core policy of consensus?--Paul McDonald (talk) 13:22, 3 May 2019 (UTC)

Above, where you objected to the big decisions being made at RFC.

And at [15], where you wrote I've never been one to drink the consensus WP:KOOLAID. --BrownHairedGirl (talk) • (contribs) 23:41, 3 May 2019 (UTC)

I'm going to ignore the ranty-pants stuff above my post and just address the OP: I think this is clearly the way forward. While well-developed portals on sufficiently broad topics will still have a place (at least judging from the strong consensus to retain them in the RfC last year), they're clearly not viable as a generalized navigation system, and arguments are frequently made that our mainspace articles already have too many navigation features injected into them (excessive infoboxes, piles of navboxes at page bottom, distracting sidebars, redundant "See also" links, redundant categories, etc., etc.). So having the software, or some optional "gadget" adjunct to it, provide unobtrusive but better-engineered and more helpful navigation would surely be a boon, if done properly. I also agree with the gadget approach; the MW devs accept little input, even to fix crucial bugs. It seems unlikely to me that they'll implement something complicated, if it wasn't mandated by WMF, unless it is pre-developed and well-tested – handed to them on a silver platter, as it were. Many of the things we now take for granted on MW wikis, like the Lua-based Scribunto modules back-end that gives us a far more functional template system than we had in the 2000s, were third-party projects.  — SMcCandlish ☏ ¢ 😼  07:14, 5 May 2019 (UTC)

Two groups of editors with differing aims are trying to share one WikiProject. On the one side we have the portal enthusiasts, though the most prolific creator now concentrates on other areas. On the other side we have the substantial minority who !voted to ENDPORTALS. Even BHG, one of the more moderate deletionists who actually improves portals, feels that portals are by and large a waste of time. That's an awkward environment for anyone to work in. Certes (talk) 11:18, 5 May 2019 (UTC)

For what it is worth . . .

I found it interesting that despite some talk of a "war on portals," at this writing all of the recent MfDs have not yet led to a single deletion of a portal that was a Wikipedia:Featured Portal while that process was running. Not one. A few are at MfD currently, and I am sure this perfect record will not stand forever, but the community does not yet show any appetite to delete, let alone massdelete, portal content that was once formally recognized as being of high quality. UnitedStatesian (talk) 16:52, 2 May 2019 (UTC)

Which are up at present, do you know? I thought they'd nearly all closed as keep. Portal:Halo is the only one I can think of at present. Espresso Addict (talk) 16:58, 2 May 2019 (UTC)

Off the top of my head, the 3 state roads portals are up too; that MfD is looking like a keep also. Expect an MfD that includes the 2 small cities too. UnitedStatesian (talk) 17:07, 2 May 2019 (UTC)

"War on portals" is just alarmist, scare-mongering propaganda by a few editors who have chosen not to look at what's actually happening, and prefer to allege bad faith than to stop and watch.

The wave of deletions has been been firstly about removing the portalspam, and secondly about deferred housekeeping: removing portals of v low quality and/or excessively narrow topics. The MFDing of portals which have were still-born a decade ago should not be needed. It is happening now only because a) it was a not done much sooner, and b) outsiders have started peering inside the cupboards where the project chose not to look. --BrownHairedGirl (talk) • (contribs) 17:08, 2 May 2019 (UTC)

Oh, I'd forgotten those. Thanks, UnitedStatesian. They have very active projects backing them, as I recall. It was I think Legacypac who nominated Portal:Architecture, which was one that really made me cross. Espresso Addict (talk) 17:14, 2 May 2019 (UTC)

Me too: I !voted keep on that one without any hesitation. Though to his credit he did more good work than bad when he was able to keep his temper in check. UnitedStatesian (talk) 17:17, 2 May 2019 (UTC)

Indeed. The problem was not just the temper, but the failure to recognise and repair screw-ups. So while he was right most of the time, the times he wasn't became a huge timesink. --BrownHairedGirl (talk) • (contribs) 17:30, 2 May 2019 (UTC)

I think that passing featured portals is an indication that there is a level of formal review done to assess the depth and breadth of the portal. So I am not surprised that none of the featured portals were deleted. OhanaUnited^{Talk page} 01:03, 4 May 2019 (UTC)

It's only a matter of time. There are new ones nominated every few days. Espresso Addict (talk) 01:58, 5 May 2019 (UTC)

@UnitedStatesian: I hope you know that you personally just nominated a former featured portal lol –MJL ‐Talk‐^☖ 02:22, 5 May 2019 (UTC)

Yes. I did write "I am sure this perfect record will not stand forever", after all. And 170 out of 171 is still a pretty good record. UnitedStatesian (talk)

Reverting portals to the manual version

I've done this a couple of times eg Portal:Amusement parks, but the format seems to come out one column, which is not what's intended. Can anyone tell me what I've done wrong? My manual two-column portals, which never got converted, have not shown any signs of morphing into one column behind my back. Espresso Addict (talk) 11:25, 3 May 2019 (UTC)

I've just been reverting them to a state prior to conversion, but drew both positive and negative responses for doing so. In the case of this portal, the version prior to any edits by TTH is actually the one column version. Here's a version of this portal prior to conversion that has the two column approach. Looking at the code it appears there is a float left and float right parameter in the fourth and eighth paragraphs respectively. One could simply copy the code area and try it out. That's how I learned this stuff. BusterD (talk) 13:33, 3 May 2019 (UTC)

Thanks, BusterD. I'll see if I can fix it by using the column code that my working two-column portals use. I pootle around with css in my personal websites, but I don't want to screw things up in mobile view, of which I am supremely ignorant. Espresso Addict (talk) 13:55, 3 May 2019 (UTC)

¯\_(ツ)_/¯ –MJL ‐Talk‐^☖ 13:47, 3 May 2019 (UTC)

• Well, I've tried everything I can think of, and it's resolutely single column. I've posted a note on John of Reading's talk page, as it was his bot that did the conversions to the mobile-compatible columns, to see if he can help. Espresso Addict (talk) 14:34, 3 May 2019 (UTC)

The style definitions needed by the bot edit have been moved from global CSS into Template:Portal styles, so any portal that tries to use them nowadays needs to transclude that template. -- John of Reading (talk) 14:50, 3 May 2019 (UTC)

(More) I see that most portals pick up that template via Template:Portal maintenance status. -- John of Reading (talk) 15:01, 3 May 2019 (UTC)

That's very useful. Thanks! BusterD (talk) 15:02, 3 May 2019 (UTC)

Thanks, John of Reading! If all else fails, ask someone who knows what they are talking about :) Espresso Addict (talk) 15:23, 3 May 2019 (UTC)

Portals as vulnerability

See Wikipedia:Miscellany for deletion/Portal:Donald Trump, where the issue of possible POV-pushing is raised. --BrownHairedGirl (talk) • (contribs) 10:09, 4 May 2019 (UTC)

I agree this is an issue with portals related to any living person. UnitedStatesian (talk) 12:54, 4 May 2019 (UTC)

Thanks, BrownHairedGirl. I was coming here to advertise this as meriting wider discussion. @UnitedStatesian: I don't think it necessarily relates to all living people; only a handful of political figures at present are as polarising as Mr Trump. Espresso Addict (talk) 13:04, 4 May 2019 (UTC)