Wikipedia talk:Portal/Guidelines/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

Portal deletion criteria proposal 3

Proposal: Every portal should be watched for breakage and vandalism by at least one monitor who is an active editor.

1. The monitor(s) will formally indicate that they are taking on the responsibilty by inserting their username(s) in the template {{Portal maintenance status}} of the portal. (Currently there is space for four |maintainer=s, but this can be adjusted if needed to reflect the changed use).
2. Activity may be determined by getting a reply to a user talk page within a week if there is no notice that the user is on a wikibreak of specified length.
3. The default person responsible for overwatch is the article creator, but this responsibility may be taken on by any editor in good standing.
4. More than one person may simultaneously take on this responsibility, and as long as at least one is active, the criterion is fulfilled.
5. The monitor should ensure that defects are fixed or problems with templates reported within a reasonable period (1 week?) but is not expected to be immediately responsive every time there is a problem, is not required to log these actions, and is not required to do anything about problems already fixed or under investigation by someone else, or which may reasonably be expected to be fixed by a regular bot run.
6. Nothing in this requirement prevents any other editor from making improvements to or fixing problems in a portal.
7. This criterion is independent of any other creation or deletion criteria.
8. A portal with no active monitors and visible non-compliance with the creation criteria may be proposed for deletion as Unmonitored. Any active editor may overturn this proposal by taking on the task of monitoring the portal, and by fixing the problem. The deletion proposer is responsible for checking the activity of any listed monitors, but the monitors are responsible for showing that they actually watch the portal. A portal with a notice proposing deletion under this requirement that is unchallenged for a week can be deleted without further discussion, as it is evidence that the portal is not actively monitored.
9. Deletion following this criterion does not prevent recreating the portal under the current creation criteria by another user.

• Support as proposer. Open to good suggestions for improvement. Not overly attached to 1 week if anyone thinks a longer period would be more fair. · · · Peter Southwood ^(talk): 08:27, 28 February 2019 (UTC)
  • Seems quite complicated. Perhaps a Portal version of WP:PROD might suffice, so that if no-one is interested in a portal, and it seems horribly broken, vandalised, or just not on a suitable topic, it can just be deleted after several days of being tagged. - Evad37 [talk] 14:49, 28 February 2019 (UTC)
    • It may look complicated, but it should be very simple to use. Everyone knows where they and the portals stand at any time and much time is saved which can be better used not arguing. Mainly it removes the concern that portals are being created and abandoned, and very little needs to be done to make it work. Basically what it does is require portal creators to be seen to take responsibility for their creations and not burden the rest of the community with what is perceived to be a major maintenance load. If the portals function as intended, the burden will be tiny, and no big deal to the creator. If not, then they alone are stuck with the problem of their own making, no-one else needs to be concerned, and chronically broken portals can be deleted quite easily.· · · Peter Southwood ^(talk): 15:06, 28 February 2019 (UTC)
    • In a way it is a portal version of PROD, but with the procedures codified for less hassle. · · · Peter Southwood ^(talk): 15:12, 28 February 2019 (UTC)
      • I think some of the point I raised has been missed. I don't think a major maintenance load is perceived, but nor do I think it is reasonable for one person to maintain hundreds of portals across the full range of topics in Wikipedia. If portals are truly going to evolve towards being a significant "guided tour" path through English Wikipedia, then I think their support needs to be distributed out to the community at large, just as it supports articles. I think portal creation needs to be better linked with the interested subgroups of the community at inception. In that way, they can keep portals in mind when adding new articles or restructuring articles and integrate any helpful changes to the portal system as well. isaacl (talk) 15:38, 28 February 2019 (UTC)
        • If there is not a perception of a large maintenance load, why are there objections based on other people ending up having to do the maintenance? Also don't understand why one person should not take on as many portals as they feel able to manage. The crux of the matter is whether they actually do maintain them acceptably, and that is where we should measure compliance. If it turns out that the automated maintenance does not work, then it will show up and either be fixed or the portals that no-one cares about maintaining will have to go. As long as portals are easy to create and contain a trivial amount of unique content, the removal of an ill-formed portal is not a big loss.
          I agree that a portal can be an inspiration to improve the coverage of a topic, if you use it that way. I have created several articles on underwater diving related topics that I realised were not here because I was working on the related portals.This is most likely to work through a WikiProject, where there are people who are focused on the broader topic, but we all do what we choose to do, not what others here would like us to do, so the growth of the encyclopaedia tends to be less structurally organised than it might be. Is it desirable and possible to try to force portal creation to follow a different route? Do we accept that we are volunteers and will do what we want, and accept that as long as it builds the encyclopaedia? Not everyone has a preplanned route for the big tour, and I dont even know if that would work. The planning might take too long to keep up with the changes. What we do here is contingent on what is already here, we do what is possible at the time. It is an evolutionary process, but with a little bit of intelligent design guiding it in directions that look like a good idea at the time. It has worked so far because of selection pressures weeding out garbage and allowing the development of new things that contribute towards the perceived effectiveness as a source of free knowledge. Sometimes it is hard to distinguish between what will make the encyclopaedia more useful and what will not until enough time has passed to see whether it works, and sometimes a thing that was made for a specific purpose turns out to have a secondary useful function. · · · Peter Southwood ^(talk): 05:34, 1 March 2019 (UTC)
          • We're all in this together; I don't want to measure someone's compliance, which can only lead to hard feelings. I want portals to be supported by the same editors who support the navigation boxes (used by the new helper templates) and the pages in the boxes, particularly since changes to these affect the portals. Portal support should be part and parcel of the topic area. I think it makes the most long-term sense to spread out the maintenance load to those most interested in the covered topics. isaacl (talk) 06:12, 1 March 2019 (UTC)
• To me this seems overly complex. Some of the issues with portals are structural automatic selection of content. This seems like it creates a game of whack a mole between those that wish to see no or fewer portals and those that love them. Wait till the maintaner goes on vacation and whack the thousands of portals they claim to be maintaining. Yes TTH told me one person can maintain thousands of portals. Legacypac (talk)

  You would only be able to cull the ones that are broken at the time and if all the monitors went on holiday for longer than a week without saying how long they would be away. Those who do not like portals are free to ignore the ones without defects, like thy are free to ignore topics they find uninteresting or any other thing they choose not to do. There is usually someone else who is interested, and as far as I am aware, there is no obvious way to make new model portals that go against the 5 pillars, as they use existing content which should already be compliant. The worst that can happen with a new model portal is that it looks bad and does not provide very useful information because the articles it uses have those problems, or has a technical defect and displays a bunch of error messages. The same can be said for a bunch of articles. Technical defects can often be fixed, making the system better. Crappy content happens all the time and gets fixed at source.· · · Peter Southwood ^(talk): 05:55, 1 March 2019 (UTC)

• Comment Parts of this sound like they would be better off in WP:PCSD, perhaps as a new WP:P3. I do like how it leaves little open for interpretation, but it may be a bit verbose. We could put it in a new section though, or rather, it should be the meat of a new creation/deletion criteria section, along with several of the other proposals posted here. I might also mention in there somewhere that WT:WPPORT would be good venue to find a willing maintainer before the portal goes to the chopping block, even if it's as a courtesy notice prior to posting to see if anyone jumps in to claim it. — AfroThundr ^{(u · t · c)} 03:14, 1 March 2019 (UTC)

We have been told one person can maintain thousands of Portals, which has been proven false by the number of crappy and broken ones found. Listing portals for adoption is just going to lead to the same small group claiming them everytime. Legacypac (talk) 12:56, 5 March 2019 (UTC)

Portal creation and deletion criteria proposal 6

I'd propose the following:

Every portal should offer the reader functionality that goes significantly beyond the information of its corresponding mainspace article and the navigation features (navboxes, categories etc.) offered there. If a portal displays selected content, that content selection should be based on some criterion of feature-worthiness over and above mere relatedness of topics. Thus, just like on Wikipedia's Main Page, portals should point to content of particularly high quality (e.g. Featured Articles), or content that is topically relevant because of current events, or newly created content, or content that stands out according to some other similar criterion over and above those used in mainspace navigation aids. A portal should only be created if its topic area can be expected to offer a sufficient amount of such material, and if a process for intelligent selection of such material is in place.

Fut.Perf. ☼ 08:52, 1 March 2019 (UTC)

Future Perfect at Sunrise, How would you measure this?
Can you link to an illustrative example? · · · Peter Southwood ^(talk): 19:35, 1 March 2019 (UTC)

What do you mean by "measure"? A rule about what counts as "sufficent amount" of featurable material? I don't have a yardstick for that, personally. Or a rule for what counts as an intelligent selection process? I can certainly give you examples of what is not an intelligent selection process: selecting randomly from a list of images merely because they are contained in a certain article. Or selecting randomly from a list of articles merely because they are listed in some navbox. Fut.Perf. ☼ 19:58, 1 March 2019 (UTC)

A measurement is a comparison between an expected value (such as a standard or theoretical value, with its type or unit) and an actual value ('actual' depends on the situation: what actually happened). The Portal guidelines are bumping up against an actual situation, which was a response to a proposal to delete the Portals completely, not just manage them. 'Random' selection, in the case of the Portals, is from a curated list, which are of the same type. --Ancheta Wis   (talk | contribs) 01:13, 2 March 2019 (UTC)

Pretty much what Ancheta Wis says above. Something that can be used in an objective method for determining whether a portal meets the expected standard or not, with a minimum of personal interpretation and prejudice involved. Something allowing agreement between someone who likes portals and someone who does not.· · · Peter Southwood ^(talk): 06:48, 4 March 2019 (UTC)

What's not objective and not clear about the criterion? If you want to defend a portal, just point to the selection criteria for its material and show how they are more than just re-jumbling the same links that are already in the main article. Easy enough. Fut.Perf. ☼ 07:48, 4 March 2019 (UTC)

Vocabulary

In this search for suitable criteria for the creation of portals, we need more vocabulary. Consider a musical analogy: Some cultures create music that is unique (say a performance with a new type of instrument, such as the electric guitar), or surprising (something unexpected), or representative (in which case the music serves to identify or remind its audience of its use case, such as transmission of the commander's intent in a battle: a bugle call a drumbeat, signifying an order that the army advance a gong strike, signifying an order that the army retreat—in the Warring States period in China), or iconic (what comes to mind is Eugene Aynsley Goossens's WWII contest to create fanfares to begin a concert. Eighteen candidate fanfares were submitted; and Aaron Copland's Fanfare for the Common Man emerged.). So considering the 4th case, a musical hit appeared, but it took 18 candidates, an initiator, a venue, and musical training. Now jumping to portals, it appears that we seek hits. Additionally, it emerges (as of 07:48, 4 March 2019 (UTC)) that User:Future Perfect at Sunrise seeks 'viable and useful' ones. --Ancheta Wis   (talk | contribs) 09:35, 4 March 2019 (UTC) I have no idea what you are rambling on about. Please try to be concise and to the point. You are not making any sense. Fut.Perf. ☼ 09:42, 4 March 2019 (UTC)

OK, You appear to seek hits (as in Your Hit Parade or perhaps ☼). --Ancheta Wis   (talk | contribs) 11:42, 4 March 2019 (UTC)

This is the best idea yet. It would deliver something useful to the readers and a standard against which MfD can judge pages. I'd strike "newly created content" as that is not usually all that great unless it goes to DYK or something unusual. I'd add (from some of the other options) that an active Wikiproject other than Wikiproject Portals must be willing to support Portal, assisted by the Portal project. Legacypac (talk) 19:50, 1 March 2019 (UTC)

I would caution using 'hard-coded' standards which are unproven. The Portals are clearly blazing new ground. For example 'Featured Articles' are completely dependent on known sources (usually secondary sources), but unusually broad articles are dependent on tertiary sources, such as the Science article or portal. That is a real limitation on Featured Articles, which are observably small in scope (think a certain species of bird or plant). But Portals can also be cross-cutting, which are currently not enjoined. Cross-cutting portals can span a large scope, by their nature. What I mean is that a cross-cut could compare some situation at some time or place with a comparable situation. For example hypersonic flight; the hypersonic regime was crossed during the era of spaceflight 50 years ago, with a specific technology to survive it. But today hypersonic systems are under active development for a different application, an array of candidate technologies which could serve hypersonics. In this case, the choices for inclusion might appear random, but are in fact open questions to the reader, whose solutions are likely to be surprises to the reader. For that reason, a Portal would serve a useful (educational or summary) purpose not yet available to the reader. --Ancheta Wis   (talk | contribs) 01:13, 2 March 2019 (UTC)

Additionally, 'deletion criteria' might also be termed 'deletion or inclusion criteria'. That might serve as a criterion for creation of Portals. --Ancheta Wis   (talk | contribs) 01:13, 2 March 2019 (UTC)

Spare us the "blazing new ground" story. Portals were such a failed endeavour in July 2018 there was a big move to delete them all. The new "improved" portals are so unimpressive random ones nominated for deletion are going snow delete. The community is imposing a creation ban now. Portals as they were and as they are don't attract readers and in fact really annoy many of our most engaged users. In the end these are just low quality webpages previously poorly designed and poorly maintained and now now being poorly automatically mass generated and poorly maintained. Mass created autogenerated content is an idea that time and again across the internet has proven to result in dissatisfied human readers. Legacypac (talk) 01:27, 2 March 2019 (UTC)

But observe that the July 2018 movement was countered. Witness the enlivenment of the Portal effort. I appreciate that you have knowledge of the holes in the dike. The content is for the readers and the implementation exposed holes. The portals were prototyped against the Main Page list of portals. That was the good faith effort. The scale-up exposed a limitation, which I acknowledge. But the Main Page itself is a portal; the Contents are portals; the Categories are not portals, but presaged portals when they were first implemented; the Portals were an improvement on the Category page concept. I caution you against a mischaracterization about the portal concept. A single aspect, namely the effort of deletion does not grant a subgroup license to speak for the entire community, whether readers or editors.

I caution labelling the current templates as autogeneration. Compared to the effort of customizing a Category page, a Portal remains a large improvement from my efforts of 10 years ago. The decade-old effort was large but the result was an improvement, but still an effort, until @User:The Transhumanist analyzed what needed to be done. The bots partially mechanized the effort (as you have noted). That meant the innards of WikiText were manipulable at a higher level (I am reminded of the time when User:Mav was able to create a way to display Selected Anniversaries, now called On This Day, in WikiText). If there are missing pieces, then the current mechanisms can be used to advantage for improvement rather than shutting down editors completely. The current effort of intercommunication might be used to better effect for Portals.

The word 'autogeneration' connotes a mindless automated process; might I suggest that is an inappropriate characterization ; the selection of topics, and their display, instead requires discretion, at a higher level. The selection of categories within the portals did not scale up, as compared to the Main Page. But that is an item for improvement, not deletion. The bots are not the issue. Hiatus is appropriate, but examination of the Portal cases merits more than deletion, but further definition of the holes in implementation. --Ancheta Wis   (talk | contribs) 02:46, 2 March 2019 (UTC)

@Legacypac and Ancheta Wis: I agree that we could improve our selection process for what warrants a portal. That's what most of the discussion on this page is trying to accomplish, by fleshing out notability and creation/deletion criteria that work well with the new model of portals. If you guys have some ideas to this effect, we welcome you to include them here so that we can discuss their merits. — AfroThundr ^{(u · t · c)} 07:21, 3 March 2019 (UTC)

I certainly don't agree that it should be the purpose of this discussion to create criteria "that work well with the new model of portals". To my mind, the new model of portals don't work with anything, full stop. I want criteria that will lead to good portals, and that pretty much excludes anything along the lines of the recently created (or "updated") ones. Fut.Perf. ☼ 20:38, 3 March 2019 (UTC)

I submit Portal:English language as the poster child for the new system vs Portal:English which the new team destroyed (just put back together). The automated creation of portals for 23 neighborhoods of Portland Oregon that don't have enough content to justify a portal is mindless. The over reliance on Navboxes that were never designed and are not edited with portals in mind is mindless. Pulling random math images withiut context from articles to display is mindless. Legacypac (talk) 02:57, 2 March 2019 (UTC)

Those are valid observations. What you are saying is that a process for validating the topics for inclusion in the lists of a portal is in order. You are specifying a better way to curate the Navboxes (or the successor concept to Navboxes for feeding a portal. Those are holes to learn from. For example, your responses are exemplifying a design process. --Ancheta Wis   (talk | contribs) 03:03, 2 March 2019 (UTC)

Legacypac, Thank you for noting Lua errors (the bolded red text) on the English language portal. There is some interaction which needs to be pinned down. The 31 October 2018 version does not duplicate the symptom of red text messages. Neither does the 22:44, 10 January 2019 version. But neither does the 22:51, 24 February 2019 version. There must be another factor operating behind the scene which is causing the symptom from appearing right now. You found it, I saw it as well, but the causal factor must not be operating right now (it points to an infrastructure process that is kicking in). I am not able to duplicate the red text messades right now, so that this data (the timestamp) can be reported to WP:VPT. --Ancheta Wis   (talk | contribs) 12:04, 2 March 2019 (UTC)

Portal:English language didn't show red messages for me but did take 10.268 seconds to purge. Timings over 10 s usually cause errors. 85% of this is random slideshows; I've reduced the article limit to fix it. To see timings, view HTML source (Ctrl+U in most browsers) and search for NewPP. Certes (talk) 13:32, 2 March 2019 (UTC)

Right, we are only part way there. In mid-journey, we could decide to keep moving forward, or just return home. If we return home, we won't reach the desired destination: we want automated portals that work right. Without the type of feedback you are providing, Legacypac, that would be impossible. Pointing out the problems allows those problems to be fixed. Feedback is an essential need of this team effort.    — The Transhumanist   10:03, 2 March 2019 (UTC)

I don't think "automated portals that work right" is a good goal. "The best portals we can create and maintain" is a good goal. If we have human maintainers, they tend to be create superior results. Portal:Germany/Did you know is such an example. Anniversaries sections like those on Portal:Belgium may also be better hand-curated than automatic (if that is even possible). Speaking of Belgium, why you replaced all of the content at Portal:Belgium by an automatic skeleton is a mystery to me. Drawing in contributors (one of the purposes of portals) is difficult if there is no specific editing-related content on a portal page. —Kusma (t·c) 11:38, 2 March 2019 (UTC)

Portals themselves are one of Wikipedia's navigation systems. The navigation systems are all redundant (see WP:CLN). If complete, none could go beyond the others, because they would all be comprehensive. The above proposal would simply allow portals only when the other systems were incomplete, and that would defeat the purposes of portals: to provide an alternative format for surveying information about a subject on Wikipedia, and gather all the navigation information together conveniently in one place.    — The Transhumanist   10:03, 2 March 2019 (UTC)

They are not a navigation system they are way to present content. Automated Portals do not gather all the nav info in one place they pick up and magnify whatever errors and failures there are in existing navigation systems. Legacypac (talk) 19:50, 2 March 2019 (UTC)

What they are is what you do with them. If you use them to navigate they are a navigation system. They present existing content (they are not supposed to be a content fork) in a way that allows those that update automatically based on the navbox to work better as a navigation system than those which rely on regular/frequent manual updates by editors, who may lose interest, of no longer be available. · · · Peter Southwood ^(talk): 06:27, 4 March 2019 (UTC)

• Oppose, based on no clear way to identify eligibility, massive requirement for editor input on a continued basis, and high probability based on historical evidence that most will become outdated and be nominated for deletion for failing to continue to comply with the few measurable aspects of the proposed criterion, possibly leading to a repeat of the RfC for closing Portal space by the same people who did it last time. Is this the ultimate intention of this proposal? · · · Peter Southwood ^(talk): 06:40, 4 March 2019 (UTC)
  • No, it's not the intention to remove portals completely. But, yes, this criterion would certainly lead to a much smaller number of portals. Not just smaller than the scale envisaged by the recent creation program, but radically smaller than the number we had previously. I'm convinced the large majority of portals is not viable. My personal guess (but it's really just that) is that the number of viable and useful ones is somewhere in the dozens rather than in the hundreds. Fut.Perf. ☼ 07:48, 4 March 2019 (UTC)
    • Why is it that you envision the viable number to be in the dozens? I'm just trying to find some reasoning behind the two camps (the <100 group and the 5k+ group) that I've seen discussing the total portal population. Very few seem to take a more middle ground stance. I myself would see that number somewhere close to the original 1500 give or take a few hundred. This mainly being due to the older portals not having micro scope problems that some of the new ones do. This will obviously be dependent on how the guidelines evolve, but notability-wise, the older generation seemed to hit the sweet spot. I'm not sure a few dozen super portals is the answer we need for the namespace. Perhaps instead accounting for a couple tiers below them, in a pyramid fashion would be better. — AfroThundr ^{(u · t · c)} 23:29, 4 March 2019 (UTC)
    • Count me in the middle ground. Category:Active WikiProjects has 691 pages (though not all are subject-matter). Each subject-matter WikiProject could "sponsor" a portal, and that would get us to the "few hundred" high quality portals that I think are best for the encyclopedia. That is the objective of the Proposal 2 I made above. UnitedStatesian (talk) 04:16, 5 March 2019 (UTC)
      • Well, if there are a couple hundred teams willing and able to set up an intelligent selection process for the stuff they want featured on their portals, sure, why not. I'm just skeptical if there are that many people interested in that kind of work. Even some of the top-level portals linked from the main page had hardly any activity for years. And as much as it would be nice if that kind of work could be automated somehow, the recent experiments just go to show that it can't. I'm not convinced good portals can be maintained without manual maintenance. Fut.Perf. ☼ 07:39, 5 March 2019 (UTC)
    • I've not been chiming in here as we have enough voices already, but I'm also in the middle ground. Based on feelings rather than arithmetic, 1000 sounds about right but I wouldn't argue with 500 or 2000. One way forward would be to assess what we had before, keep the good actively maintained portals and delete bad portals which are unimportant. That leaves a few hundred bad but important portals. Give relevant Wikiprojects a chance to adopt these; otherwise overwrite them with semi-automated replacements. Next, identify important topics without portals: these do not correspond 1:1 with vital articles but that list is a start. Again, notify Wikiprojects and semi-automate if there's no positive response. Finally, newly created semi-automated portals on narrow and unimportant topics can be deleted once we have rescued anything covered by the previous categories. Certes (talk) 13:25, 5 March 2019 (UTC)

The middle ground is also where I fall, with an order of magnitude of approx 1000 portals – roughly corresponding to vital articles which are broad enough to have a substantial content base, and aren't on substantially the same topic. You can also count me in the middle ground for (semi-)automation: the ideal would be automation that makes manual maintenance very easy, so it takes like 10 minutes or less, once a week (after some initial effort to set up the portal) – i.e.

• Manual selection of articles, but semi-automated transclusion of each in a way that is manually-customised for each article (number of paragraphs, which images, adjust captions if necessary). Some automated/bot suggestions on a separate page (maybe the talk page) of articles in the topic area that have recently been promoted (B-class or higher, or maybe GA or higher) which the maintainer can choose to add to the portal if relevant.
  • Manual selection would include grouping related articles in their own section, e.g. "Biographies", rather than lumping everything together
• Manually selected DYKs and ITNs, but with automated suggestions on that separate page, so it is easy to copy over the relevant ones and maybe add an image
• Manually selected images, with automated suggestions on the separate page
• Automated checks that Lua usage is still working, with errors automatically reported to wikiproject portals for technical assistance

The automation part isn't too difficult, but to get high-quality portals there has to be some human assistance, especially given the technical restrictions like the limited amount of Lua processing time. - Evad37 [talk] 00:25, 6 March 2019 (UTC)

A more balanced approach like this makes a lot of sense actually. Instead of pushing for fully automated portals that make expensive Lua modules do all the heavy lifting, we just use the automated components to make the construction easier. A human would still be there to put everything together and add the finishing touches. This type of attention to detail doesn't work very well when scaled to thousands of portals, and would act as an artificial limiter on the portal population, preventing the "mass-produced" feel that many are condemning the new generation portals for. This would allow for a significant reduction to the maintenance burden of the portal system, while maintaining a high level of quality content. Kind of like how we were overhauling the existing neglected portals by upgrading various sections with the new equivalents. We could go back to focusing on portal upgrades instead of concentrating on pushing out lots of new portals. — AfroThundr ^{(u · t · c)} 03:36, 6 March 2019 (UTC)

Question unrelated to this discussion, but just for my own edification, can someone point me to a page discussing how Lua processing time is "expensive," or tak a shoet at an explanation here? Thanks in advance. UnitedStatesian (talk) 14:18, 8 March 2019 (UTC)

Basically, there are three limitations as to how much Lua a Wikipedia page can use. One is time based – after 10 seconds total, execution will be halted, and any further attempts to use Lua (like in templates further down the page) will just result in error messages. The second is Wikipedia:Template limits#Expensive parser function calls. Certain Lua functions count towards this limit; they are marked as expensive on mw:LUAREF. A third limit is the amount of memory that Lua can use (but I haven't personally encountered this as a problem). You can see these and other limits in a HTML comment in the source code (search for NewPP limit report), or by editing and previewing the page, and clicking on "Parser profiling data". - Evad37 [talk] 14:53, 8 March 2019 (UTC)

Thanks so much, very helpful! UnitedStatesian (talk) 14:57, 8 March 2019 (UTC)

I think something like what Evad37 suggested (bot/automation assisted, but manually curated portals) would work best. The ITN and DYK templates are great to find candidates, for example, but manual curation improves them. If portal maintenance could be done in 20 minutes per week per portal we might find enough people to do it, unless we have too many micro-portals. Updating Portal:Germany/Germany news took just a few minutes after Pppery helped me by making the ITN automation subst'able. Another thing that is bad about fully automated portals is that they do not have obvious edit buttons, and their complicated code is a high barrier to participation. If you can't figure out how to fix a typo, it doesn't feel like a wiki page. —Kusma (t·c) 09:54, 6 March 2019 (UTC)

"...semi-automated transclusion of each in a way that is manually-customised for each article (number of paragraphs, which images, adjust captions if necessary)." Yes, please! The current automated transclusion mechanism, no matter how much care is put into content selection, just results in an ugly mess. Espresso Addict (talk) 02:34, 8 March 2019 (UTC)

I've started {{Portal suggestions}} as a first step towards the semi-automation I described above. Anyone fancy trying it out on a couple of portal talk pages? (or perhaps wikiproject pages, or some other place that isn't reader-facing) - Evad37 [talk] 09:42, 9 March 2019 (UTC)

@Evad37:What does one have to do to try it out? Espresso Addict (talk) 00:18, 11 March 2019 (UTC)

@Espresso Addict: Just place it on the portal talk page with appropriate parameters (e.g. [1]), and see if it helps you with portal maintenance. The content will auto-update to always show relatively recent content, so you can check back once a week or fortnight or month or whenever, and see if there's anything new (the page might just need a purge, so the template includes a purge link). Let me know if you have any suggestions or other feedback. - Evad37 [talk] 00:37, 11 March 2019 (UTC)

Portal creation and deletion criteria proposal 2

I propose that each portal created must have the sponsorship of a related active subject-matter WikiProject. They are the most knowledgeable about how to structure and organize Wikipedia's subject-matter information. This connection to subject-matter WikiProjects is consistent with how the Portals operated (quite well) for a long time.

• Support As proposer. UnitedStatesian (talk) 19:16, 26 February 2019 (UTC)

This would ensure that there are a group of editors who feel a portwl wouod be useful not just one edotor that thinks hundreds or thousands of portals are fun to create. Legacypac (talk) 19:24, 26 February 2019 (UTC)

• Oppose new semi automatic portals have a set design, so WikiProjects don't have to edit the portal to be the way they want to unless they want too. Having a WikiProject to support it isn't also necessary as they don't need much at all in terms of maintenance. Also new portals are completely different to old portals. Sure the page structure is similar, but everything is automated and a connection (bar a link to the project from the portal) isn't necessary needed unless the portal is customised to what they want. Dreamy Jazz 🎷 ^{talk to me | my contributions} 22:01, 26 February 2019 (UTC)
• I agree that a portal page should have support from some group, and the natural ones would be related active WikiProjects. It's not scaleable for one editor to watch hundreds of portal pages to check on vandalism and make any fixes as needed. The work should be distributed to the editing community. isaacl (talk) 22:55, 27 February 2019 (UTC)
  • @Isaacl: Not that it exempts them from the requirement of periodic review by a human, but most of the new generation of portals have a significantly reduced maintenance burden - in some cases, by an order of magnitude - which would allow for significantly more portals to be handled by the same editor pool, without a significant increase in workload. That said, the need for periodic review doesn't disappear entirely, and I agree that a set of editor eyeballs should be on hand for that, not just technical checks by bots. — AfroThundr ^{(u · t · c)} 02:01, 28 February 2019 (UTC)
• Reviewing these automated portals shows to me they need attention from humans that know something about the tooic. Legacypac (talk) 23:17, 27 February 2019 (UTC)
  • @Legacypac: Not that I disagree that a person thoroughly familiar with the topic would be an asset for creating (and reviewing) portal content, but in most cases, it seems that someone with a decent interest in the topic can do an adequate job of creating a portal on said topic. Have you found some specific cases where the portal was botched completely due to the creator not understanding the topic? Most of the portal issues I've come across were just technical ones. Granted, some portals may sport a less than ideal content selection at times, but those are going to happen sometimes, and I think the best method to deal with them would be tagging them for review by someone more familiar with the subject matter, like we do with articles. — AfroThundr ^{(u · t · c)} 02:01, 28 February 2019 (UTC)
  • To expand on AfroThundr3007730s explanation: The major input by editors who are thoroughly familiar with the topic is generally at the Navbox. Articles that are in the navbox will be in the portal, otherwise not. Obviously this only applies to portals using a navbox for structure, but that covers most of them at present. · · · Peter Southwood ^(talk): 15:23, 28 February 2019 (UTC)
    • Maybe not "botched completely", but see Wikipedia:Miscellany_for_deletion/Portal:Fruits where the creator didn't understand the topic. And no, you can't assume a Navbox is any good. Army and Air Force Exchange Service has been in {{Burger King}} since 2008 and doesn't belong there at all (if it does belong there, Massachusetts Turnpike should be there too, as turnpike service areas are home to several Burger Kings). {{Allen Park, Michigan}} arguably shouldn't exist at all, but was used to build a portal. Editig Navboxes is not something a lot of editors engage in and many are quire out of date are include questionable entries. Plantdrew (talk) 20:33, 28 February 2019 (UTC)
      • @Plantdrew: While I agree that portals using these navboxes also inherit their issues, and that creators should be cognizant of these potential issues when selecting source material for a new portal, I still belive these issues remain squarely with the navbox itself, and should be fixed when encountered. If I were building a portal on Burger King and selected that navbox for the portal, I'd be inclined to investigate why that exchange article was even in there, and either remove it or open a discussion on the navbox talk page. When building a particular piece of content, it is sometimes necessary to update or improve the existing related content, so that the collection as a whole benefits. — AfroThundr ^{(u · t · c)} 02:40, 1 March 2019 (UTC)

It is unfair to impose on editors of NavBoxes the unintended unknown consequences of changing the pages in a Portal by adding or deleting a link from a nav box. Complex Navboxes give context for the link's inclusion. Portals do not.

The ledes of articles are also not really expected to be scraped as content on another page. Many ledes are too long or too short or otherwise have issues. If we knew the first X lines would be dosplayed alone we might write them differently. Legacypac (talk) 05:54, 1 March 2019 (UTC)

On the face of it, these are reasonable concerns. On the other hand, how much does it really matter if a portal contains a few articles that are more tangentially related? The editors of navboxes are generally expected to have some competence in assessing what is appropriate for the navbox based on the navbox title. They need not concern themselves with the effects on a portal: if the article really is relevant to the navbox title topic, then it is relevant enough for the portal.
Quality of leads is a wiki-wide problem. On average they probably do not comply with the recommendations, and some are simply appalling. There have been a number of articles where I could not work out what the article was supposed to be about by reading the whole lead several times (while trying to add short descriptions to random articles). If articles with such poor quality leads are kept out of the portals it will be a net gain for portals, but not necessarily for the articles as the portal display may get someone to improve the lead. I am not particularly concerned which way this goes as I see benefits both ways. I would not oppose a restriction to C-class or better if there is a way to do this automatically. I have been told there is not. With automated portals if an automated way becomes available, it can be added to the system and will become part of it without personal intervention at each portal. Maybe a target to aim for.
Perhaps a maintenance tag for bad leads could be used to prevent display in portals?
Most automated portals already limit the number of paragraphs displayed, but obviously they cannot display what does not exist, and do not check for paragraph length or quality. · · · Peter Southwood ^(talk): 07:53, 1 March 2019 (UTC)

• Support as a minimum requirement. Would accept the slightly relaxed version that any portal which should be under an active WikiProject must have the sponsorship of a related WikiProject. This would allow portals that are under an inactive WikiProject to exist as potentially better than nothing unless an active project reports it is inappropriate. — Arthur Rubin (talk) 11:28, 13 March 2019 (UTC)
• This should be a required portion of the overall guideline. It's not enough on it's own. Legacypac (talk) 12:07, 15 March 2019 (UTC)

Clarify goals

Is the goal to create a portal for all 723 districts of India? Is it to create a portal for every navbox as seems to be the arguement that this replaces Navboxes which are not shown on mobile? What is the plan here? If we understand the objectives we can craft a guideline that meets the objectives. Legacypac (talk) 19:24, 26 February 2019 (UTC)

Legacypac, as long as a navbox has enough articles a portal should be allowed to exist based on it, is what I think is the best idea. It depends on what the minimum for the number of selected articles is what can and can't be created. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:46, 26 February 2019 (UTC)

So yes? Legacypac (talk) 23:15, 27 February 2019 (UTC)

Legacypac, I would say "Yes, but see my proposal for taking responsibility below." · · · Peter Southwood ^(talk): 08:39, 28 February 2019 (UTC)

I've been trying to reconcile this view with the statement on this guideline page that "portals should be about broad subject areas", and it struck me, particularly in the light of Wikipedia:WikiProject Quantum portals: these pages using templates to generate content from navboxes are more akin to a second screen experience than a topic portal. They provide an x-ray view into the pages referenced by a navbox. The helper templates/modules are certainly very good work under the hood, and have admirably increased the benefit/cost ratio of the resulting page. However the results don't always fit well under the term "portal", as used historically on Wikipedia. I think there is an expectation that portals will, as stated, cover broader topics, not just every topic for which someone has created a navbox, and been curated to the best entry points to the overall topic area, rather than anything meeting some numerical standard. isaacl (talk) 19:41, 5 March 2019 (UTC)

I think the active editors interested in maintaining all of these portals should be identified first, and then they can decide how they want to organize them. Editors with skin in the game should decide on how they want to allocate their efforts. isaacl (talk) 23:00, 27 February 2019 (UTC)

I will shortly propose an altenative that fits in with Isaacl's suggestions, as they seem to be reasonable, relevant and enforceable.· · · Peter Southwood ^(talk): 06:11, 28 February 2019 (UTC)

For the record all the Districts of India as well as US Counties, a group of small US Cities and all the Portland OR neighbourhoods were deleted at MFD. There is clearly no support for this projects plans for 723 Indian District portals or anything along those lines. Legacypac (talk) 12:11, 15 March 2019 (UTC)

Portal creation and deletion criteria proposal 5

I propose:Guilherme Burn (talk) 13:54, 28 February 2019 (UTC)

All portals should be to X level under the Main Page.

My reasoning for this initial proposal is:

• The portals should be a navigation system from the Main Page.
• Portals should work with a hierarchy like as the categories.

Example: Wikipedia:WikiProject Portals/Portals tree

Guilherme Burn, This proposal needs to be clarified quite a bit as at present I don't know what you mean. What is "5 level under the Main Page"? · · · Peter Southwood ^(talk): 14:51, 28 February 2019 (UTC)

Pbsouthwood I imagine that:

• Level 0 - Main Page
• Level 1 - Main Page Portals - 8 portals - Portal:Arts,Portal:Biography,Portal:Geography,Portal:History,Portal:Mathematics,Science, Portal:Society and Portal:Technology
• Level 2 - Forks of Level 1 portals - about 100 portals - based on WP:VA2
• Level 3 - Forks of Level 2 portals - about 1000 portals - based on WP:VA3
• Level 4 - Forks of Level 3 portals - about 10000 portals - based on WP:VA4

Guilherme Burn (talk) 16:46, 28 February 2019 (UTC)

Having some sort of hierarchy, and not going too deep into that heir achy, seems like a good way of ensuring important topics get portals, rather than overly narrow topics. I think having criteria like

1. The portal's main article is a level-4 or higher WP:VITAL article; and
2. The portal has at least 20 selected articles

might be a good system. Or perhaps level-3, if we want to be stricter. - Evad37 [talk] 14:58, 28 February 2019 (UTC)

Yes Evad37 level 5 seems too wide, 3 or 4 will be better.Guilherme Burn (talk) 16:51, 28 February 2019 (UTC)

• Comment I like the idea of limiting the portal tree to WP:VA4, as that would give a decent structure to the namespace, and help with creating the hierarchy. I think the existing portals should be grandfathered in though, barring serious issues with individual ones. — AfroThundr ^{(u · t · c)} 03:05, 1 March 2019 (UTC)

If this is accepted we need to axe all existing portals that fail the criteria. TTH says they take 3 minutes to create so it's no big loss of work to remove the overly specific ones. There are way too many listed at List of Portals already and I know at least the Indian Districts ones are not on that list. Legacypac (talk) 04:12, 1 March 2019 (UTC)

• If I understand correctly, this is following the vital article levels listings.
  • The vital article lists can change, and frequently do, so binding portals too strongly may be problematic if a previously vital article gets the boot. Mostly an article will move one step up or down so not much of a problem on the higher lists.
  • A vital topic may consist of a single article or a tree of a thousand articles. This does not map well to whether a portal would be appropriate. At one extreme there is no point in a portal for a single article, at the other, several sub-portals could be required to give suitable coverage, as there is a technical limit to automated portal size. The VA lists are useful guidance, but cannot be effectively used as strict criteria.
  • I suggest that no matter what VA level the topic may currently occupy, if the portal is so large that it exceeds technical limits, it may be split into a main portal and as many subportals as necessary that meet the general criteria, whatever they finally turn out to be, even if the topic of the subportal does not make it to a VA list. This can be done by splitting the navbox.
  • As a currently topical example, if the districts of India are subortals of the relevant states of India, which should be subportals of India, they would be more useful and fit into a logical structure. My suggestion would be to start at the top and work your way down following a logical pattern. Each subportal would be linked from the immediately inclusive super-portal, but not necessarily from the next level up, in the same way the categories are supposed to work.
  • There may be topics which are not on any of the vital lists, but still have large numbers of articles. Would these be blanket banned? Would they be allowed if included in a portal tree structure as subportals of a vital topic portal? How many levels of separation from a vital list would be acceptable? It looks complicated, but may be amenable to a simple rule.
  • Another way of dealing with it may be to simply require a linear descent from a high level vital article portal. A portal would need to be a subportal of a portal which is descended from a vital artical portal, applied recursively. · · · Peter Southwood ^(talk): 08:27, 1 March 2019 (UTC)
    1. We could have some sort of grandfathering clause for portals with vital articles that get demoted, e.g. like has a main article that is currently or was previously listed a vital article
    2. Yep, that's why you still need some sort of criterion for has enough stuff to warrant a portal, like the at least 20 selected articles I suggested above.
    3. If the portal is so large that it exceeds technical limits, it probably either needs some manual curation (e.g. manual selection of mainly good/featured articles, with some B/C-class ones for diversity), or stricter limitations on how much stuff the automation looks through (i.e. smaller values in |limit= and similar parameters), or perhaps a few subpages with a tabbed heading (subpages aren't evil, we just want to avoid them where possible).
    4. Perhaps, as long as there's a breadcrumb navigation or something to make it obvious, but how far down do you go from a parent portal? And if you do have a set limit like 5, what happens if an intermediate portals gets created? i.e. (Main page)→Geography→Continent→Country→State→City is five levels deep, but adding something like (Main page)→Geography→Continent→Country→State→District→City makes it six levels deeps.
    5. I would say keep it simple, and if allowing subportals of vitals, then only allow one level of it. Perhaps some other existing groupings would make for good portals, like a sufficiently large good/featured topic.
    6. If its recursive without limit, then that's not too far off 'anything can have a portal', since any topic could eventually find a path up to one of the main page portals (assuming any missing parents/grandparents are just created on the way)
  • It might be better to discuss with examples of actual portals that would be affected, rather than hypotheticals. The 10,000 level-4 or higher Vital Articles are a pretty big base, even discounting ones that won't have enough related content for a portal. - Evad37 [talk] 01:08, 2 March 2019 (UTC)
    • @Evad37 and Pbsouthwood: I agree with pretty much everything y'all have said above. Perhaps the Vital Article tree wouldn't be a hard requirement, but could be a decent pool to pull new topics from for new portals. I think as long as we can clearly link them all together in the breadcrumb hierarchy they should be fine. I also agree that there has to be a lower limit, and that's kind of what the other criteria discussions are for (e.g. >20 articles). — AfroThundr ^{(u · t · c)} 07:09, 3 March 2019 (UTC)
    • Having looked through the level 4 vital articles, most of them wouldn't be suitable for portals, though they are useful as groupings of related articles that could be included in a section of a broader topic. The main exceptions would be Geography § Countries. So the number would be closer to 1000 than 10,000 - Evad37 [talk] 23:45, 5 March 2019 (UTC)
      • Portal:Cheshire, a former featured portal which has been maintained by me & others since 2007, pends from a level 5 article. It has 77 linked articles, mostly GA/FA, 39 images, and 60 sets of 4 DYKs, as well as much hand-curated content (In this month, quotations, topics &c). Espresso Addict (talk) 02:24, 8 March 2019 (UTC)
        • @Espresso Addict: Topics for places seem to be the main exception to level 4 (and below) VAs not being broad enough for portals. Every country, and most top-level administrative districts (state, territory, province, etc) would have enough content to be suitable for a portal. The issue then becomes how far down do you go – this might vary from country to country, but should definitely be bigger than suburb or town, and perhaps bigger than city. Maybe limiting to just one-level down from the top-level admin district would work, e.g.

Country – Portal:Australia

→ State – Portal:Western Australia

→ Region – each of the Regions of Western Australia could have a portal (the main RDCA ones, plus Portal:Perth which is geographically covers the Perth metropolitan region)

→ (no further sub-portals)

Or another way would be to limit to only the top-level admin districts, which should then be more substantial portals with sections for "Selected Foo region article" etc. - Evad37 [talk] 01:39, 9 March 2019 (UTC)

Geographical portals seem to me somewhat different from others, as there genuinely are going to be lots of relevant articles on any area with plenty of English-speaking, computer-connected people, particularly when you consider buildings, people & history, as well as just settlements. In the UK, before the current initiative, there were successful portals for the bigger cities eg London, Greater Manchester, as well as a few for counties. It really depends on how many high-quality articles there are to gather together in a portal, which will depend more on whether the Wikiproject is/was active than any other factor. Espresso Addict (talk) 00:16, 11 March 2019 (UTC)

This is a criterion that needs a complementary criterion to guarantee the quality. As discussed could be created infinite portals respecting this limit. For example:

Portal:Geography→Portal:Countries→ Portal for all Countries. Y

Portal:Geography→Portal:Cities→ Portals for every city in the world. N

But I still believe that this criterion should be approved in association with others, as I said. It would be a way of ensuring a logical relationship between the portals.Guilherme Burn (talk) 12:36, 15 March 2019 (UTC)

Proposed new section Automation

Per the comments re automation in proposal 6 above:

- Evad37 [talk] 23:46, 13 March 2019 (UTC)

Inserted more examples and additional bullet point added at 10:02, 14 March 2019 (UTC) - Evad37 [talk]

I'd suggest broadening the inappropriate section; amusing though examples of spider monkeys appearing in Spider portals are, that's relatively easy to trouble shoot. The real problem with those so-called "improved" portals I've reviewed is dull articles/images, very short or very long blurbs, heavily tagged articles (that was a problem with the old system too) links to lists where the content was along the lines of "this is a list of x", and content of peripheral interest. In the old system (at its best) there was a positive choice to have this article, coupled with a burden of work to add it, that made a virtue of selectivity.

The other thing to note is that portals should generally be developed by people who know (and love) the subject area. I note that the revised medical portal (formerly featured, now garbage), was recently marked as "checked and ok", when a five-second glance found some dire content inclusion choices. Espresso Addict (talk) 06:20, 14 March 2019 (UTC)

I've added more examples from what you've pointed out, and added a bullet point about reader interest. Your other point – should generally be developed by people who know (and love) the subject area – is a valid concern, but not really limited to automation – inappropriate content selections can still be made without automation. - Evad37 [talk] 10:02, 14 March 2019 (UTC)

I agree with you, Espresso Addict. Back in "the old days" a decent portal was meant to showcase the best that Wikipedia had to offer on the subject. Now the automated ones are simply glorified navboxes. In the case of Portal:Medicine which is now indiscriminately populated with the contents of Template:Medicine and the images in Medicine, the results are obvious. Having said that, I assume WikiProject Medicine was notified of the impending "improvements" and no one seemed to care one way or another. A real pity! As a member of WikiProject Opera, I nipped over here straight away and made sure they left Portal:Opera, a Featured Portal, strictly alone.

I never understood why using carefully curated sub-pages was seen as something to be eliminated. Once properly set up, a portal like ours maintains itself, and only requires the creation of new sub-pages for new featured content and updating the "max" for the rotation on the portal page. If a subject is worth a portal, it will have a number of FAs and GAs to populate it. If it doesn't, in my view that calls into question the need for that portal, as opposed to a navbox. For our Featured Picture section we use only FPs to ensure they are interesting and high quality. We require all DYKs to have actually appeared on the Main page (e.g. Portal:Opera/DYK/1), and all selected quotes to have a source (e.g. Portal:Opera/Selected quote/15). I also never understood why having specially curated blurbs for the Selected articles and the main article is considered a "bad thing" by this project with the blurbs characterised as "forks". When an FA appears on the main page, special blurbs are created to highlight the salient points and pique the reader's interest. No one considers those "forks". Ah well, enough blithering from me . Voceditenore (talk) 14:24, 14 March 2019 (UTC)

Indeed! You put it very eloquently, Voceditenore! I think one of the points is that the frozen blurbs on portals go out of date, if say, an actor appears in a new film. This is less of a problem for, say, 19th-century operas or 18th-century listed buildings! One of the obvious problems with the new medicine portal is that it has ignored the enormous number of featured and good articles on the topic, as well as many featured pictures, in favour of high-level summary articles from a navbox. Espresso Addict (talk) 18:56, 14 March 2019 (UTC)

Update: UnitedStatesian has rolled the medicine portal back to an older version & I've restored its header, but something has broken in the coding and I can't see what... could someone fix this, please? Espresso Addict (talk) 19:24, 14 March 2019 (UTC)

Any guideline needs to specify that the Portal must present a better introduction to the associated topic than the article does. Just showing random images from article without context is useless. Showing random article excerpts help no one. Legacypac (talk) 20:54, 14 March 2019 (UTC)

I can support restricting how the automation templates are used in a portal. We don't need to be completely free from random content transclusion, but there should be an editor vetting the list of articles that shows up in the featured sections. If you actually wanted to show any random article in a particular subject, we could have a separate section for that. So a "Featured content" and a "Random content" section, if the goal is to draw attention to the articles not necessarily optimal for portal display. — AfroThundr ^{(u · t · c)} 20:52, 16 March 2019 (UTC)

amusing though examples of spider monkeys appearing in Spider portals are... as well as the Richmond Spiders. — pythoncoder  (talk | contribs) 20:12, 25 March 2019 (UTC)

Portal creation and deletion criteria proposal 1

• We need these criteria written soon. I propose (but this is subject to change and improvement):

Every portal must have at least 20 selected articles which are unique to the portal.

My reasoning for this initial proposal is:

• It is generally excepted that a portal won't survive MfD if it does not have 20 selected articles
• There has been significant concern from other editors about how some portals are pretty much duplicating another parent or related portals content, without adding much. This would ensure that this is catered to. This will also help the portal namespace, in that readers are not split into different portals when the portal contains very similar or the same information.

I don't mind changing the number of selected articles or whether the selected articles need to be unique (and what defines unique). This is meant to be a conversation starter and so improvements are going to be needed. It is important as several editors have raised this at Wikipedia:Village_pump_(proposals)#Hiatus_on_mass_creation_of_Portals in only around 6 hours, so we need to do something soon about this issue. Thanks and all input is welcome, Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:40, 26 February 2019 (UTC)

@Peter Southwood: pinging the regulars. Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:42, 26 February 2019 (UTC)

@The Transhumanist, Certes, AfroThundr3007730, and Evad37: Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:43, 26 February 2019 (UTC)

Where is the concensus at MfD that 20 is the right number? I've not seen that and I'm very active at MfD. 20 is far too low because darn near any topic can loosely have 20 related topics. A guideline needs to ensure we don't get portals on every one of the 723 districts in India for example. Legacypac (talk) 18:51, 26 February 2019 (UTC)

Legacypac, it has been discussed in the wikiproject that this number is a good estimate. This would catch out your example that you posted on the VP. It wouldn't delete burger king. Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:53, 26 February 2019 (UTC)

Confimring: By "unique to the portal", that means if an article was related to more than one Portal, it would not count toward the 20 required by in either one. So Albert Einstein does not count in Portal:Albert Einstein's 20, and does not count in Portal:Physics's 20, since the article is not unique to either one. Correct? UnitedStatesian (talk) 19:00, 26 February 2019 (UTC)

UnitedStatesian, yes. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:44, 26 February 2019 (UTC)

@Dreamy Jazz: thanks! UnitedStatesian (talk) 21:47, 26 February 2019 (UTC)

See my comments below on why this may not be workable. · · · Peter Southwood ^(talk): 05:32, 28 February 2019 (UTC)

I think it's too difficult to try to set a standard on what topic can serve as a entry point to a swatch of related knowledge based on how much it wouldn't overlap with other topics. I would prefer that there should be one or more active associated WikiProjects, and that they should decide which topics are best to act as a main page to that area. isaacl (talk) 22:53, 27 February 2019 (UTC)

Please explain why Portal:Burger King has an article about a military exchange and a racecsr driver in int he article list. Neither have anything but a very distent connection to the fast food chain. Legacypac (talk) 23:20, 27 February 2019 (UTC)

Legacypac. Most of the new model portals are based on a navbox to select content. The articles in the navbox are added by editors who thought that they were relevant. The creator of the portal probably just accepted the judgement of the editors who added those articles to the navbox, as their continued presence suggests tha no-one has objected or there is consensus for their presence. If anyone later objects and removes those articles fom the navbox, they will simultaneously disappear from the portal without further human intervention. If this does not sufficiently answer your question, feel welcome to clarify your point. · · · Peter Southwood ^(talk): 05:42, 28 February 2019 (UTC)

@Dreamy Jazz: I would support adding a lower limit to help address community concerns of spamming (even though that's not what's really going on here). Perhaps something like any new portals must have 20 unique articles would set the bar for newer ones, and we can revisit any that somehow don't meet that bar while we get better guidelines in place. @The Transhumanist: I believe there was a suggestion before of redirecting portal creation to target the Vital Articles list first, and work our way down the levels. Most of the pages on that list should have a fairly healthy ecosystem of related pages and shouldn't run afoul of a lower bar as proposed above. Any that do fail that criteria could then be skipped for now and revisited at a later date to decide what to do about them.

@Isaacl: While portals are a bridge to their related WikiProjects, and the projects should be aware of and interact with them, I would hesitate to levy a requirement that the projects have sole discretion to dictate what topics under their purview rate a portal. Much as any editor can create an article that can belong to multiple projects, portals should remain open for any interested editor to jump in and create one. Our guidelines should remain the mechanism for determining if the portal can stand on its own, not just one (or more) projects. That said, a WikiProject's opinion should obviously be given due weight when reviewing a portal's suitability.

This feeds back around to the idea of a Portal Review Board. Not necessarily a preemptive one, where approval is required before creation, but there should be a venue for discussing the validity of a portal before it ends up on MfD (and no, I don't mean WT:WPPORT). If our guidelines are in order, there should be no need to fear their abuse or misapplication as a tool to purge portals. Once the remaining problems with them are ironed out, we should have faith in the community to apply the guidelines rationally. We're all trying to build an encyclopedia here guys. Also pinging @Pbsouthwood: what do you think on the above? — AfroThundr ^{(u · t · c)} 01:48, 28 February 2019 (UTC)

It can be any group of interested persons, but the most natural approach would be for the interested persons to co-ordinate their activities on the appropriate WikiProject discussion page, so they can more easily attract additional interested persons. What it comes down to is if someone is willing to commit to provide necessary support, including finding other people to support the portal should they wish to step away, then as Wikipedia is a volunteer environment, they can feel free to create a portal.

I don't quite understand your reluctance to centre discussion about a portal within WikiProjects if you are thinking of having a portal review board. I don't think a common discussion point across English Wikipedia is needed. To take one of the examples that has triggered this conversation, personally I wouldn't create a portal for the mathematical constant e. (In my opinion, the area of transcendental numbers would make a better entry point.) But since the whole portal system is pretty much orthogonal to the article creation process, having a portal for e won't really impose any additional work on anyone except for the one supporting it. (I feel confident saying this because today, most editors completely ignore the portal pages, and I don't think the articles suffer for it.) So even though I think it's way too narrow, if someone is committed to supporting it, I don't feel like I should deny them. So I think we should try to make sure all portals have a good home at the time they're created (I don't like having them created with the hope that someone else will take care of it; you're handing someone else a bill to pay without their agreement). I also think we have to be aware, however, that most WikiProjects are dormant, and many are close to it. Thus we shouldn't overextend a WikiProject's ability to support its associated portals, and account for the possibility that it will be a little less active over time. isaacl (talk) 02:46, 28 February 2019 (UTC)

@Isaacl: I understand your reasoning for wanting a responsible editor for every portal, and it makes sense, but I also think that portal abandonment is becoming less of a problem than it was before. If editors come across a portal that is being neglected, and for some reason don't want to deal with it themselves, they can always post it on WT:WPPORT and one of our regulars will look into it. We realize that since a significant portion of the community has written portals off entirely, it means that if we want portals to be a thing, we have to be willing to pony up the time to keep them working. Should this WikiProject ever fall dormant like others have, we could no longer make the claim of supporting and maintaining the Portal namespace, and the community would be free to deal with them as other abandoned or outdated pages.

We've continued to stick around because we find value in a curated network of portals to provide new avenues into any particular topic area, a namespace where anyone with sufficient interest can (within the guidelines) expand that network with new portals. I want to find balance between the need for at least a minimalist review mechanism and the concern of too much red tape stifling new creations. This is is why I was pushing in the direction of a post-creation review process, rather than a pre-creation approval process, which would allow the problematic ones to be addressed without hampering future portals.

This comes back to making sure our guidelines are up to snuff so that the problems can actually be addressed when they arise, rather than leaving too much open for (mis)interpretation, while also providing a solid framework so that creators know where their portal will stand without a lot of guesswork over the subjectivity of the current guidelines. — AfroThundr ^{(u · t · c)} 03:25, 28 February 2019 (UTC)

As I said elsewhere, minimally someone should be watching the pages for vandalism, and I think it's unreasonable to expect the portals wikiproject to watch thousands of portal pages. I also think the related subject matter experts should be involved in deciding what topics would make the best entry points into a subject area, since it's their area of expertise. I think it is better to integrate support for portals into the same support network for articles. isaacl (talk) 04:08, 28 February 2019 (UTC)

I agree that there should be a vandalwatch. As a first approximation, the creator of an article generally watches the article, so this would be a reasonable expectation for the creator of a portal. If a specific portal is a frequent target for vandals it can be protected in the usual ways, and if a portal is found to be vandalised and no-one is watching, that might be a reasonable criterion for deletion. I would put the onus for vandalwatching on the person who wanted the portal in the first place, usually the creator, but sometimes a person who requests a specific portal. This seems a reasonable allocation of responsibility to me – if you want it, you look after it. If or when no-one cares any more, the portal is open for deletion, and can be re-created any time someone is willing to watch it and revert vandalism again. Willingness to do this could be specified in the portal maintenance template, so it would be easily confirmable. Thanks for this idea Isaacl. · · · Peter Southwood ^(talk): 06:06, 28 February 2019 (UTC)

• Technical query: How would one know if an article is unique to a portal? · · · Peter Southwood ^(talk): 05:30, 28 February 2019 (UTC)
• Some articles, by their generalised nature, would be appropriate as content in more than one portal, just like they may be relevant to more than one project. This is particularly relevant when one portal is a subportal of another, which can occur quite easily in huge or even just large topics, and as the encyclopaedia expands and more finely granular topics are added, this will become more prevalent. In the same way that no project can claim exclusive rights to any article, I don't see how it could be decided which portal has rights to any given article. This rule could allow gaming the system by creating a new portal with overlap and then using it in an attempt to delete the other or both portals. I don't see this as workable, but maybe I am missing something. · · · Peter Southwood ^(talk): 05:30, 28 February 2019 (UTC)

Question #2 The current guideline says "articles above a Start-class." Under your proposal, this qualitative guideline would be replaced by a purely quantitative article count? UnitedStatesian (talk) 14:35, 28 February 2019 (UTC)

@UnitedStatesian: I believe this proposal would be in addition to the current requirement of "articles above Start-class", considering there was a strong consensus built here to add that requirement, and there's no good reason to revert back. All of our automated templates already exclude Start-class articles from the selection filters anyway. — AfroThundr ^{(u · t · c)} 02:25, 1 March 2019 (UTC)

Do the templates really exclude start-class? I thought it was stub-class because I asked whether specific classes could be excluded and if I remember correctly was informed that it was not easily possible for start-, C-, and B-classes. However this may have changed since my query. · · · Peter Southwood ^(talk): 06:58, 4 March 2019 (UTC)

Stubs can be identified through the presence of one of the {{stub}} templates on the article. The default setting for the slideshow excerpt templates is to exclude stubs, unless every article is a stub (since otherwise a Lua error would be shown). Identifying other classes would theoretically be possible (grab the wikitext of the talkpage, check the value of |class= parameters), but would likely take up too much Lua time since you're doubling the number of pages to be loaded. - Evad37 [talk] 10:17, 4 March 2019 (UTC)

I don't think the "unique to the portal" would be easily workable, per Peter Southwood. Perhaps something more along the lines of "doesn't substantially duplicate a parent portal" would be more workable, and would allow Foos in Bar type articles to be count for both Portal:Foos and Portal:Bar. - Evad37 [talk] 14:45, 28 February 2019 (UTC)

Yeah, my mistake. I was thinking of the stub filtering, not start-class. That would be a strain on page generation time to accomplish automatically. That's not to say that start-class pages are inherently bad portal material. I've come across many that were a few edits away from C-class, and if displaying them in a portal entices a reader to improve the article, so much the better. Stubs should definitely stay out though. — AfroThundr ^{(u · t · c)} 23:23, 4 March 2019 (UTC)

• Support. There is strong MfD precedent for this, and practice is policy. — pythoncoder  (talk | contribs) 18:48, 25 March 2019 (UTC)
• Support 100 or so as a minimum threshold. I'd support 20, as it's better than nothing, but it's too low. If a reader wants just the links, there's a navbox. If a reader wants the context, there's an article. Portals should be for those topics that have so many links they cannot fit into one navbox or article. Topics like "Earth." Leviv ich 02:18, 28 March 2019 (UTC)

Automatically harvested DYK pattern matching problems

A number of the MfD discussions have brought up embarrassing errors in the DYK pattern matching. The default code inserted by The Transhumanist's creation script appears to be, for the example of Portal:Beer:

{{Transclude selected recent additions | Beer | months=36 | header={{Box-header colour|Did you know... }}|max=6}}

which generates DYKs matching spurious entries such as 'Frank Beermann' & 'Beerbohm'.

This needs to be changed to insert something more appropriate. Lowercasing usually gets better results where the portal topic is generally used in the lower case. Extending using exclusions:

{{Transclude selected recent additions | beer | months=36 |not=%abeer |not2=beer%a | header={{Box-header colour|Did you know... }}|max=6}}

seems to work, but will also exclude the legitimate hit 'beers'. I don't know whether or not adding 'beers' to the inclusion criteria helps.

Perhaps someone more knowledgeable can help out here? Espresso Addict (talk) 00:36, 29 March 2019 (UTC)

{{Transclude selected recent additions|%f[%a]beers?%f[%A] |%f[%a][Bb]rewery%f[%A] |%f[%a][Bb]rewing%f[%A] }}

is one option. %f[...] here is a "frontier" which only matches if the following character is in the set but the preceding character was not, so %f[%a] means "start of word" and %f[%A] means "end of word". We could use this sort of technique to improve many newer portals. Certes (talk) 00:52, 29 March 2019 (UTC)

Edited to remove a capital B from Beer(s) because we don't want to feature Alan Beer or Adrian Beers. We may still get the occasional "storm brewing" but false positives should be minimal. Certes (talk) 01:06, 29 March 2019 (UTC)

Further options on an increasingly drastic scale include:

1. editing the portal creation templates to include this sort of thing by default for future portals only
2. bulk-editing existing portals which look as if they were created by the templates (perhaps pointlessly, given the pressure to delete them)
3. editing the module behind this to look only for whole words (e.g. to read "beer" as "%f[%a]beer%f[%A]")

– Certes (talk) 01:53, 29 March 2019 (UTC)

Thanks, Certes. I would be against editing the module just to look for whole words, as you can easily do things like:

{{Transclude selected recent additions | wich |latest=yes|max=20|months=36|not=Norwich |not2=Ipswich |not3=sandwich |not4=Greenwich}}

to pick up all the -wich towns of Cheshire, but not the obvious other usages. As to editing existing portals, I think we need to concentrate on those that are likely to survive a deletion request. Rolling back to a multi-page version with hand-selected DYKs might well be easier in some cases. Espresso Addict (talk) 02:33, 29 March 2019 (UTC)

...Harwich, Droitwich, West Bromwich... I'd go for the positives: Nantwich, Middlewich and Northwich should cover most of that news. Certes (talk) 09:24, 29 March 2019 (UTC)

It looks as if Portal:Beer has been unilaterally binned anyway despite having been fixed. There's a ArbCom case here if anyone has the stomach for standing up to these determined editors. I'm afraid I have less stressful things to do. Certes (talk) 09:31, 29 March 2019 (UTC)

Au contraire, mon frere: not binned, reverted (the middle step of WP:BRD, so now we can discuss. And if we do, let's involve the relevant WikiProject this time.). Am I determined? Yes. But only to improve the encyclopedia, as I am sure you are too. Don't think that needs standing up to. UnitedStatesian (talk) 11:20, 29 March 2019 (UTC)

Reverted to tue non-automated version makes the most sense. Code all you want but no amount of complex automated DYK selection is going to keep a hook about a theatre cat out of the Beer portal or a hook that included a pipped link to a politician with the 5 letter string of "horse" in his middle name out of a portal about horses. There is no substitute for human editing content. If readers want to read bot collected content without human intervention there are crappy bot created websites out there to use. Legacypac (talk) 18:02, 29 March 2019 (UTC)

• Did You Know that following his retirement from football, Alan Beer worked in a car dealership ? I don't see why some angry people are trying to hide such an important fact from the eyes of the chivalrous beer explorers. And, to be more inclusive, Did You Know that Bishop Wine died before 672 ? Pldx1 (talk) 08:16, 3 April 2019 (UTC)

• DYK that these DYKs at Portal:T.I. have nothing to do with the singer?

1. ... that Jimmy Wales wants WikiTRIBUNE to counter fake news?
2. ... that Michael Frenzel, the former CEO of European tourism group TUI, escaped from East Germany with his father when he was nine years old?
3. ... that the Ferrari 330 TRI/LM, the last front engined racecar to win the 24 Hours of Le Mans, was driven regularly in New York City after the end of its racing career?
4. ... that the species description for the mite Afropolonia tgifi was likely only approved because the journal's editors were unfamiliar with the expression "TGIF" ("Thank God It's Friday")?

Legacypac (talk) 18:33, 3 April 2019 (UTC)

DYK that your constant barrage of ridicule and sarcasm have already driven highly valued editors to leave Wikipedia, and that no one is going to waste their time fixing pages you are trying to delete? Certes (talk) 18:53, 3 April 2019 (UTC)

Which editors are those? UnitedStatesian (talk) 18:58, 3 April 2019 (UTC)

DreamyJazz for one. I will probably go too once I have tidied up a few (non-portal) loose ends. I've enjoyed a good ten years here with pleasant and co-operative editors, but in the last few months the environment has become so toxic that I no longer feel comfortable contributing. Certes (talk) 22:19, 3 April 2019 (UTC)

Will be sorry to see you go and hope you come back when you are ready. Dreamy Jazz repeatedly said real life issues were the reason for leaving. Never mentioned portals that I saw. Legacypac (talk) 22:31, 3 April 2019 (UTC)

I'm pointing out recurring problems that need fixing. Since Portals project members claim that one person can maintain thousands of automated portals, it should not be so easy to find problems like this. These issues start at the page creation date which suggests the creators are not even reading the pages they make. Maybe stop harvesting DYKs automatically? I don't know. Legacypac (talk) 18:57, 3 April 2019 (UTC)

Portal:Roses has 2/2 unrelated DYKs to the topic of the flowers. Legacypac (talk) 22:31, 3 April 2019 (UTC)

One edit at a time

Any strong objections to removing "Portals do not work in Draft or Userspace so they must be built in Portal space."? I believe that sentence is demonstrably false, and I think allowing users to use those two namespaces would help gain consensus. Also, there is now a proposal to require autoconfimration before any pagecreation in the portal space. UnitedStatesian (talk) 14:51, 8 April 2019 (UTC)

A more correct version is "multi-page portals are often difficult or impossible to easily move between namespaces, so they are usually built in portal space". Single page portals can be built anywhere (unless they invoke {{PAGENAME}} or similar). —Kusma (t·c) 14:59, 8 April 2019 (UTC)

I disagree: with pagemover permissions, one can in a single step move all the subpages at the same time the parent portal page is moved. UnitedStatesian (talk) 15:25, 8 April 2019 (UTC)

Whether that works or not depends on how the transclusions are set up -- with {{/Related portals}} or something it would work most of the time. But returning links from subpages to the portal don't necessarily work correctly after a move. Anything involving {{PAGENAME}} will possibly return strange results after a page move. It is a lot easier to build a portal if you don't have to anticipate all the link targets changing. —Kusma (t·c) 15:48, 8 April 2019 (UTC)

(Ec) One page portals work in other spaces. Multipage do not, unless you move/create all the subpages in the same mainspace. This needs correcting.  :WP:ACREQ as a bare bare minimum should be required. I've not seen any non-AC creations though and I've looked at lots of portals. Ok 4 from one user. He likely saw the big debate and decided to be a troll and add to the pile. Legacypac (talk) 15:00, 8 April 2019 (UTC)

• The notion of portals not being workable in the Draft or User namespaces is not true. Moving to portal namespace from user or draft space simply requires performing page renames in the wikicode on various pages and then moving the pages. Therefore, the statement should be removed from the guideline page. North America¹⁰⁰⁰ 16:44, 23 April 2019 (UTC)

• I think the above confirms the sentence is false, so I am removing it. Any editor who feels something should be added in its stead can propose that add as a separate thread on this talk page. UnitedStatesian (talk) 02:26, 28 April 2019 (UTC)

Project newsletter

As the project newsletter has just gone out linking here, I am writing to indicate that several major discussions are currently ongoing on the project's main talk page. Espresso Addict (talk) 11:08, 2 May 2019 (UTC)

Removal of portal links

I've noticed this a couple of times for articles that are selected items in one of my portals (which is entirely hand-curated), where the link had been in the article for years without opposition but has been quietly removed within the past 12 months or so. Has anyone else had a problem with this? Espresso Addict (talk) 13:25, 28 March 2019 (UTC)

Can you give a specific example? UnitedStatesian (talk) 03:08, 31 March 2019 (UTC)

[2] & (not as recently as I'd thought) [3] are the two I noticed recently. Espresso Addict (talk) 05:50, 31 March 2019 (UTC)

I think those two, and others, may be reflection of our lack of success at convincing the broader community of the value of having those portal links in an article's see also section (as opposed to in the WikiProject boxes on the talk page). UnitedStatesian (talk) 17:25, 7 May 2019 (UTC)

WP:BRD revert of recent additions

I removed some content that was added to this page without any apparent consensus existent for doing so (diff). Note that I have this page watchlisted, which is how I noticed the changes. The changes made are controversial and contestable, and were performed by a user who is typically for the deletion of portals. As such, this user should not be unilaterally dictating portal policy on this page. Rather, policy should be decided upon WP:CONSENSUS. Feel free to discuss here. North America¹⁰⁰⁰ 01:02, 31 March 2019 (UTC)

There is a fundamental clash of cultures here. In one corner we have prolific creators of pages, many (but not all) of which are unnecessary and contain errors. In the other we have editors whose contributions to Wikipedia consist mainly of deletions and XfD advocacy. Unfortunately, both groups have turned their attentions to portals simultaneously, resulting in a battleground. Either side could easily rewrite the guidelines as "why we need a portal on everything under the sun (and then some)" or "why we should nuke all portals from orbit (and salt them)". Rather than presenting one personal opinion as canon, let's wait and see if a consensus emerges as to what portals should exist and what form they should take before editing the guidelines. Certes (talk) 13:54, 31 March 2019 (UTC)

I don't think we should stop editing the guidelines, but there should be a two-way interaction between this page and portal MfDs. While this page is commonly cited at MfD, we should make sure it also reflects typical MfD outcomes, at least roughly. —Kusma (t·c) 14:40, 31 March 2019 (UTC)

Yes, let's update it, but only to reflect consensus. It would be unfortunate if anyone were to take a portal to MfD citing a guideline which they just added without consultation. Certes (talk) 14:58, 31 March 2019 (UTC)

Yes, changes to the guideline page should be performed based upon consensus at this talk page, and potentially from other discussions. A single user moving the goalposts by unilaterally making the guidelines stricter, and then potentially nominating portals for deletion thereafter based upon their own stricter changes would be a highly inappropriate conflict of interest. North America¹⁰⁰⁰ 09:27, 1 April 2019 (UTC)

Reversion of my minor changes and then assuming I did them so I could cite little changes like "we use MFD for portals" is hardly WP:AGF but rather battleground behavior. Telling me I can't edit guidelines because you don't like my other edits is just wrong. Legacypac (talk) 15:11, 8 April 2019 (UTC)

WP:NOTCOMPULSORY

I performed a minor reversion of some content (diff), back to "The portal should be maintained and serve a useful purpose", which has been in place for some time. Not seeing any consensus on this talk page for the recent change of this to "The portal must be maintained and serve a useful purpose.". The notion of a required maintainer goes against WP:NOTCOMPULSORY, part of Wikipedia policy. I also performed a minor rewrite to "DYK selections harvested automatically should be regularly curated to remove false positives and inappropriate selections" The recently-added notion stating that this action must be performed also goes against the grain of WP:NOTCOMPULSORY. Furthermore, I feel that a consensus should first be formed regarding these potential new changes, particularly with all of the discussions occurring regarding portals all over the place. It's also common for changes to guideline pages to be discussed first in the form of proposals. North America¹⁰⁰⁰ 16:39, 23 April 2019 (UTC)

This is nonsense. It inverts the meaning of WP:NOTCOMPULSORY, which says in full "Wikipedia is a volunteer community and does not require the Wikipedians to give any more time and effort than they wish. Focus on improving the encyclopedia itself, rather than demanding more from other Wikipedians. Editors are free to take a break or leave Wikipedia at any time.".

Any editor is free to volunteer as a maintainer if they want, and to quit that role whenever they want.

The word "must" is used here to impose a condition on the portal, not on any editor. --BrownHairedGirl (talk) • (contribs) 20:51, 7 May 2019 (UTC)

What reasons should a portal be deleted?

Right now we have an editor trying to delete Portal:Friends with his stated reason "Individual TV shows should not have portals". [4] A lot of portals are up for deletion now at Wikipedia:Miscellany_for_deletion mostly with similar rational of someone not liking them. Some strict guidelines on legitimate and illegitimate arguments to make in a deletion discussion for this sort of thing, would eliminate some needless arguments. Dozens of portal articles are up for deletion, new ones keep getting added, and many more aren't sent there at all just replaced with a redirect. Dream Focus 03:22, 26 March 2019 (UTC)

Individual people, TV shows, companies etc don't need portals. Generally there is just not enough content within the topic to justify a portal. Legacypac (talk) 07:49, 26 March 2019 (UTC)

So, is everyone alright with this one editor going around each day nominating dozens of portals for deletion one right after the other? Some people disagree with him in the discussions they notice and bother to participate in. Just so many though, no one is going to bother with them all. I really think specific strict guidelines need to be in place, not just a flood of deletion discussions all at once. Dream Focus 23:28, 26 March 2019 (UTC)

I don't know about everyone, but I am 100% ok with any editor (whether one, five, or a thousand; though in this case it is more than one) nominating for deletion any Portal that is not consistent with the WP:POG guideline (particularly that guideline's requirement that the subjects of portals be broad), just as I am fine with any editor nominating for deletion any article that is not consistent with the WP:N guideline. Can you identify any of the 5,000+ portals that are not consistent with the guideline? UnitedStatesian (talk) 23:27, 27 March 2019 (UTC)

The problem is defining 'broad'; there really is no consensus on whether a show such as Friends forms a sufficiently broad topic to support a portal. Espresso Addict (talk) 01:36, 28 March 2019 (UTC)

Which is why the MfD discussions are currently so valuable: they are critical to defining the consensus around topic breadth (which I think is currently uncertain for only a small subset of the 5,000 portals: no one is bringing Portal:India or Portal:Opera to MfD). And for Portals brought to MfD, I do not expect every one to end as "delete". UnitedStatesian (talk) 01:46, 28 March 2019 (UTC)

Indeed, but someone has recently brought Portal:Jane Austen, Portal:English language & Portal:Horses, to pick just three examples of portals that seem to be entirely appropriate in their scope, and there has been limited or no notification of interested topic-specific Wikiprojects by the nominators, coupled with some pushback against using the existing deletion-sorting mechanism on Miscellany for Deletion. Espresso Addict (talk) 01:57, 28 March 2019 (UTC)

Portal:English language was a fork of the pre-existing Portal:English, which has now been un-forked following the MfD. Nobody has suggested deleting Portal:English, which was created back in 2006. "English language" is a broad topic; few individual authors will be broad enough to justify a portal. Shakespeare: yes. Austin: no. "Animals" is a broad topic; few individual animals will be broad enough to justify a portal. Humans: yes. Horses: maybe. Horseback riding and all that goes with it, from saddles to cavalry, might make horses a sufficiently-broad-topic animal to justify a portal. I suspect there's a lot to say about animal husbandry and the animals we husband. The MfD process is what's allowing us to figure these distinctions out. Leviv ich 02:10, 28 March 2019 (UTC)

(ec) Agreed, I don't see any problem in what User:Espresso Addict notes. Portal:Jane Austen may be grey in breadth (I could go either way: seems a notch below the topic breadth of Portal:Shakespeare), for Portal:English language the issue was not topic breadth but a titling issue in that it was duplicative of Portal:English, and Portal:Horses is almost certainly going to close as keep (see how the nominator did us a favor in helping to define the consensus?) UnitedStatesian (talk) 02:16, 28 March 2019 (UTC)

[Edit-conflicted response to Levivich] In fact, the portal with the entire history for Portal:English was recently brought to MfD; you participated in the discussion. And let's not get into whether ABC topic is sufficiently notable here; it's wearying enough dealing with it at MfD every day. Espresso Addict (talk) 02:23, 28 March 2019 (UTC)

As I mentioned in previous threads, I think the subject matter experts for the related areas should be consulted to determine the most suitable entry points for the topic areas. If the members of this wiki project would pause their portal creation efforts and start consultations, perhaps some of the deletion discussions can be paused, too. isaacl (talk) 03:38, 28 March 2019 (UTC)

I nominated the automated messed up version of Portal:English language but it was such a muddled situation it took two MfDs to get back to one non-automated non-duplicated portal. I have no problem with a correctly built portal on English (so long as portals exist, it is a valid topic). The community will decide if Portal:Friends is broad enough. Several editors said no TV show deserves a portal, and I put up some edge cases to assist us in drafting guidelines. Jane Austin is a pretty broad topic, broader than some of the other authors with portals. As a principle, very few individuals have enough material on them to justify a portal. Recent US President's, Shakespeare, Jesus, maybe a handful of other people who are the subject of many books and academic interest. Legacypac (talk) 03:47, 28 March 2019 (UTC)

@Legacypac: I don't know how many editors ever look at MfD in the normal course of events -- for MfDs to work as a means of building consensus, they must be sufficiently widely advertised and only occur at a rate that an ordinary editor can respond in a thoughtful fashion. Mass deletion requests tend to stimulate knee-jerk keep responses and a sense of hostility.

@Isaacl: I'd agree that everyone should pause portal creation until some consensus arises as to what is viable and what is not. Espresso Addict (talk)

MfDs are happening a glacial speed compared to how fast this junk was created. The creators refuse to help with cleanup too. Legacypac (talk) 12:08, 28 March 2019 (UTC)

@Isaacl: Mass portal creation paused long ago. Ten portals have been created in the past month, by eight different editors, suggesting that they are motivated by their respective subject interests rather than an enthusiasm for portals. There are currently 96 open MfDs listing one or more portals, and at least four concurrent forums currently devising new policies and criteria for deleting portals. Certes (talk) 12:02, 28 March 2019 (UTC)

How did you find that list? I'd like to look into any new creations. Legacypac (talk) 12:08, 28 March 2019 (UTC)

Although I feel a responsibility to protect the eight editors, I shall reply in the spirit of AGF. I listed NewPages in Portal: namespace, and filtered out the subpages containing "/" using an offline text editor. Certes (talk) 13:44, 28 March 2019 (UTC)

@Certes: I think your count is off: I found a single user (not TTH, obv.) who has created six non-deleted portals in the last month (and 45 since Jan. 29, fwiw), all using the single-page-portal automated tool. UnitedStatesian (talk) 02:29, 29 March 2019 (UTC)

New portals are easier to find on my screen now, as pages nominated for deletion show up pink. I won't be repeating the exercise. Certes (talk) 09:14, 29 March 2019 (UTC)

"and start consultations" is what I suggested to occur in order to defer deletion discussions. If there is already engagement with subject matter experts to figure out what are the desirable entry points, then it would render any deletion discussions in that area moot (they could just be redirected to the corresponding subject matter expert discussion). isaacl (talk) 14:39, 28 March 2019 (UTC)

My thoughts on this, for what it' worth...

1. The type of subject is irrelevant to whether a portal should exist. Portals on multi-series TV shows, individual people, etc. are perfectly fine if they have sufficient scope. It seems pretty obvious that we should have portals for prolific individuals like William Shakespeare, Jane Austen, and the like. Should Winston Churchill have a portal? I'm not sure. Should Gordon Brown? Almost certainly not. It's about scope. It's all about scope.
2. Forgive me for stating the obvious but a deletion discussion concerns whether or not a thing should exist. Deletion policy is quite clear that if a page (of any type) can be improved by editing, then that is preferable to deletion. So if a subject has sufficient scope for a portal but the portal itself doesn't meat the best practice standards laid out in WP:POG, that is not a reason for deletion. In the same way, we don't delete stub articles because they're unfinished or articles with MOS issues. So it's not about the content or quality of a portal, or whether it's sourced from a navbox, subpages, or whatever else. It's only about scope.
3. Scope not just about how many articles there are on a topic. Wikipedia is a work in progress; we don't have articles on everything we perhaps should have yet. Systemic bias is a well documented and much discussed issue on Wikipedia, and is only made worse by deleting portals on a topic that doesn't yet have many articles associated with it, but is sufficiently broad in scope for such articles to exist.
4. Scope is not about how many articles have been selected for inclusion in the portal, because - again - it's a work in progress. There might be thousands of suitable articles, with only a handful selected for the portal at a particular time.

I've talked about what scope is not; the problem now is identifying a way we can agree on figuring out how to assess the scope of a topic and, crucially, how to ascertain what is sufficient for a portal to exist. But scope is not a number or something that can be measured empirically - there's always going to be some subjectivity around it. Also, given that one of the advantages of portals is the ability to highlight content of interest to the viewer that they might not think of looking at ordinarily, there's a question of how rigidly "in" scope something has to be to be included on the portal. So our Winston Churchill example would almost certainly include articles on World War II and Blenheim Palace; it could conceivably also include articles on cigar smoking and alcoholism - they're clearly related to the topic, but might not ordinarily be seen as within scope. So the scope of potential articles for inclusion in a portal is often much wider than it might first appear - because portals are not mere navigation tools for single topics. WaggersTALK 15:17, 3 May 2019 (UTC)

• • A few comments on the last post: (1) you make a lot of statements that I'm not sure are correct; links to relevant p&g/examples would help a lot. (2) With your WC example, if the portal included (links to?), for example, Blenheim Palace then isn't the portal just duplicating the WC article? DexDor ^(talk) 18:24, 3 May 2019 (UTC)

    DexDor, No; if the portal used Blenheim Palace as a selected article, it would contain the first few paragraphs of that article, not just a link to it. As such it's a richer source of information on topics related to the subject than the article itself. WaggersTALK 07:36, 8 May 2019 (UTC)

• I want to pick up Waggers's extraordinary comment above if a subject has sufficient scope for a portal but the portal itself doesn't meat the best practice standards laid out in WP:POG, that is not a reason for deletion. In the same way, we don't delete stub articles because they're unfinished or articles with MOS issues. So it's not about the content or quality of a portal, or whether it's sourced from a navbox, subpages, or whatever else. It's only about scope.

This goes to the very heart of why the topic portals became such an almighty storm over the last very months, so I want to unpick it.

@Waggers, articles are content, so deleting them removes content.

1. Portals are not content, so they are not covered by content-based aspects of deletion policy. They are a navigational device and/or a showcase for existing content, so the case for their existence depends on whether they do that well enough to add value per WP:PORTAL: "Portals serve as enhanced 'Main Pages' for specific broad subjects". If they don't do that, they should be deleted, just like we routinely delete redundant or non-defining categories.
2. In several cases today, Waggers has cast "keep" votes for abysmal pseudo-portals which have rotted for up to 13 years. This isn't a content issue; it is a rotten, almost non-existent junk issue.
3. Why does Waggers want to continue these decade-long scams of advertising to our readers that we have a "portal" on a topic, even tho you know that when they visit it they will discover this junk? That's like advertising a car, and taking the buyer to pile of rusted pieces in the scrapyard.
4. Similarly, Waggers has been strenuously resisting the deletion of some of the last of the drive-by portalspam created by @The Transhumanist, on the grounds that if the topic is suitable, then the page must stay no matter how useless or misleading it is to readers.

What on earth is the point of wasting the time of readers by trying to keep this rotten junk and drive-by spam?

If Waggers's aim was to discredit the whole portals project by retaining even the most useless and and most long-abandoned pages, then they would be doing a brilliant job ... but if Wagers has any other objective, then this determination to retain portalspam and abandoned relics is self-defeating. It seems to be a continuation of the never-mind-the-quality-just-count-the-numbers ethos of TTH's newsletters. That didn't end well.

For goodness's sake, folks, support the clear-out of the spam and the abandoned junk, and concentrate on building portals which actually add value for readers. --BrownHairedGirl (talk) • (contribs) 16:48, 7 May 2019 (UTC)

BrownHairedGirl, You're mixing up quite a few things here. I'll try to deal with them in turn.

1. Of course portals are content. WP:POG is a content guideline. We don't have content guidelines for things that aren't content.
2. Specific recent interactions at MfD are not pertinent to this discussion, but BHG's attempts to suggest portals are exempt from the general principles laid out in WP:DP have been laughable.
3. As I've stated above, we don't delete articles or other content because they don't meet the gold standard quality guidelines. There's no reason to treat portals differently in that regard.
4. Deletion policy is clear that adequate tagging is preferable to deletion. If portals requiring maintenance or updates are visibly tagged as such, there's nothing to mislead readers. In fact, such tags are a call to action that often turn readers into editors. WaggersTALK 07:43, 8 May 2019 (UTC)

More nonsense.

1. No, portals are not content. You can label the portals guidelines however you like, but they remain devices for showcasing and/or navigating content which is located elsewhere.
2. Recent MFDs are highly pertinent. Waggers has been systematically trying to impede the removal of junk portals abandoned a decade ago by cherrypicking parts of deletion policy out of context
3. Portals are not content
4. Tagging is good practice for articles. Portals are nor articles.

So I'll ask the key point again. What on earth is the point of wasting the time of readers and editors by trying to keep this rotten junk and drive-by spam? --BrownHairedGirl (talk) • (contribs) 12:31, 8 May 2019 (UTC)

This section headed "What reasons should a portal be deleted?" was started six weeks ago and we're no closer to a resolution.

Setting deletion policy on portals by case law based on dozens of MfDs isn't working. It's degenerated to the point of large chunks of general arguments being copied from one MfD to the next.

Agreed, the portal creation drive launched after WP:ENDPORTALS ran too far. But it has now been more than reversed. Seeing recent nominations of portals for such major topics as Electricity, Anthropology, Museums, Nursing and whole countries induces a feeling that the pendulum is swinging too far the other way, and that's probably why people are digging their heels in.

It's time to start that big RfC to lay the ground rules for portals: their purpose, nature of topic, structure, functioning, content selection, quality standards, maintenance requirements. But it must not misfire: it needs editors with know-how and clout to get it off the ground, preferably those who haven't been involved in shouting matches over the deletion campaign. We know where to request closure of RfCs, but how to seek openers?: Bhunacat10 (talk), 09:45, 9 May 2019 (UTC)

In my opinion, as previously expressed, the ground rules should set broad direction, but allow for the editors on the ground who are committing to keeping a portal updated to use their discretion to decide what works best for them. By editors on the ground, I mean those interested in the topic area and who will actively participate in ongoing maintenance. It doesn't make sense to have portal creation driven by one person and maintenance driven by others, just like it wouldn't make sense for navigation boxes to be managed that way. If interested parties can work out what navigation boxes are most sensible to exist, they should be able to do the same for portals. isaacl (talk) 19:08, 18 May 2019 (UTC)

For example, some people believe that a portal can be used by interested editors to examine the breadth of coverage of a subject and see where additional expansion may be helpful. Personally, I don't think a main page-like portal page is the best way to achieve this, but if some group of editors is committed to building and updating a portal for this purpose, and it doesn't impose additional work on those uninterested in using the portal, why shouldn't they be able to use the tool of their choice? isaacl (talk) 19:18, 18 May 2019 (UTC)

How often to update?

This section needs to be based in reality and not the wishes of a few editors . As of now 90 percent of our portals do not meet this criteria and the other 10 percent that are automated are being deleted for that reason. So what is really happening to updating portals...definitely not being updated weekly or monthly. So what can we say here that is truthful? --Moxy 🍁 13:53, 18 May 2019 (UTC)

• Yeah, the reality is that many portals are typically not going to be updated weekly or even monthly. They also don't necessarily need to be updated all the time. Much of other Wikipedia content is not updated all the time. The guideline is out of touch with reality regarding this matter. This out-of-date part of the guideline is also being used in part as a rationale for the mass deletion of portals that is occurring at MfD. Furthermore, some of the automation provides automatic updating, such as for dyk content, which negates the need for manual updating. North America¹⁰⁰⁰ 00:02, 30 May 2019 (UTC)

I think specific time period should be avoided. It depends on the portal. Portals should be updated as often as necessary to stay relevant. It could also be a few times a year or even less. Still better than no updates for years. Pelmeen10 (talk) 17:17, 30 May 2019 (UTC)

I agree that a specific time period should be avoided; it creates a standard that is unnecessary in many situations. North America¹⁰⁰⁰ 02:45, 31 May 2019 (UTC)

I disagree. This is long-standing guidance which is facing objections only now that abandoned and outdated portals are being deleted. The preview-a-topic style of portal is based on presenting a sample article from a wide set, and if that sample doesn't change regularly, the portal becomes stale. Most portals have a range of topics on rotation, so the requirement for frequent updates doesn't apply ... but for those without a rotation, updates are needed.

And please, NA1K, drop this nonsense other Wikipedia content. Portals are not content; they are a tool for navigating content and/or a showcase for content. Any showcase needs to be refreshed regularly; the closest parallel in the Main page, which is updated daily. --BrownHairedGirl (talk) • (contribs) 00:51, 3 June 2019 (UTC)

Dame there is a fundamental misunderstanding here of what a portal was intended for.... though I agree they are a failure overall. Not sure the deletion notice board that content editors avoid should be driving this effort. Navigation tools are static in nature because our featured content and name of Articles frequently don't change..... we don't rotate hundreds of articles in navigational template as we link the major articles that lead to sub articles. Would be best if we get them all deleted over deletion with a rationale that is fundamentally wrong. Should those not interested in portals be guiding what should be done with them.... logically the answer would be no.--Moxy 🍁 05:33, 3 June 2019 (UTC)

@Moxy: if portals are not a tool for navigating content and/or a showcase for content, then what are they for?

Navboxes are not rotated for the simple reason that they provide a comprehensive list at a given level of a given topic, and they don't make a selection. However, portals do make a selection (usually on an apparently arbitrary basis), which is why rotation is needed.

The reason that deletion is being driven by editors not otherwise involved is very simple: since the portals project was created March 2006‎, it has never done any systematic monitoring of the quality of portals, let alone done the sort of routine cleanup which other projects do. On the contrary, it unleashed last year a tsunami of automated spam portals, ignored objections, never sought broad community consensus for what it was doing, and reacted with outraged indignation when the community called a halt. So the inevitable result has been that the vacuum has been filled ... and others are doing the cleanup which the portals project has shied away from for 13 years. --BrownHairedGirl (talk) • (contribs) 20:03, 3 June 2019 (UTC)

I can't say this enough. ......we don't delete things that can be improved on ... is a fundamental principle of operating here and as been principle guiding force that eliminates a lot of animosity. ..... all these things should be given time to be improve perhaps by way of tag.. as is done with any other namespace.. Unless the community decide if they're no good overall as a whole. Portals should follow the rules as outlined at Wikipedia:Miscellany for deletion and WP:PRJDEL. We are having to explain over and over to projects why there portals are being deleted with them having no knowledge of the process....and have to explain that the moratorium on recreating one is null in void and feel free to do so and we'll deal with deletion board after. Can you explain why portals are exempt from our normal processes of content improvement as we have with content and templates and images Etc? Keeping in mind this is the point of view of someone who thinks they should all be deleted..... but as a Wiki project council member is having to deal with it. the driving force behind portals was not Wiki project portals but individual Wiki projects that made portals..... that have no clue there's a problem just see their portal deleted.--Moxy 🍁 22:33, 3 June 2019 (UTC)

@Moxy: This very very very very very very very very very simple.

Portals are not content. They are tools to help readers navigate a topic and to showcase some of its best and/or most significant articles in its scope.

So they are not subject to the eventualist principles which apply to actual content, i.e. articles. Like other navigational devices such as categories or navboxes, portals can be deleted if they are not fulfilling their purpose.

It's sad to see that after several months of deletions, some editors remain in denial about this extraordinarily simple point. --BrownHairedGirl (talk) • (contribs) 21:19, 4 June 2019 (UTC)

What?..are you even reading the guidelines provided. ....not one is about article content.. Good luck in your deletion Adventure.... it's exactly happened to the last guy.....out of the loop in what is being seen by others.--Moxy 🍁 01:13, 5 June 2019 (UTC)

@Moxy: Portals are not in the project namespace, so WP:PRJDEL doesn't apply. As to being given time to improve, nearly all the portals coming to MFD have been rotting for 5 to 14 years. And there are no tags for portals, because the portals project has never paid any attention to maintenance. --BrownHairedGirl (talk) • (contribs) 12:20, 5 June 2019 (UTC)

OMG all namespaces work the same Wikipedia:Miscellany for deletion ....give people time to fix things ....tag them...and for the tenth time Wikiproject Portals does not maintain portals....just as Wikiproject Council does not maintain projects. --Moxy 🍁 13:04, 5 June 2019 (UTC)

@Moxy: Can you point me to the recent issues that WikiProjects had with portal deletion, to which you refer? In the one case with which I am familiar, WP:WikiProject Nigeria mobilized during the MfD, which resulted in it being closed as keep, and its members continue to improve on it. Obviously we want to make sure that any affected WikiProject is aware of an MfD discussion and want to afford them the same opportunity that WP:WikiProject Nigeria had. UnitedStatesian (talk) 21:38, 4 June 2019 (UTC)

WikiProjects get automatically notified through the article alerts system. If a WikiProject is unsufficiently interested in the portal to even tag with their project banner, or to respond to the alert if it is tagged, then that speaks volumes about the lack of interst most projects have the portals related to their topic area.

For example, I started WP:Miscellany for deletion/Portal:Ireland, not as a deletion proposal but as a means to kickstart conversation about whether and how the portal could be made of some use. I left a notification at WT:WikiProject Ireland, but was very noticeable that all the enthusiasm for keeping it came from the usual crew of keep-any-old-crap portal fans rather than from the editors who actually build and maintain Ireland-related content. --BrownHairedGirl (talk) • (contribs) 23:08, 4 June 2019 (UTC)

No the norm is no notification...no notification to any project related to Wikipedia:Miscellany for deletion#Music Portals by Moxy thus email after email asking WTF is going on. Even the individual portals no notification given to anyone that may help Portal:Boston for example...Wikiproject Boston, Wikiproject USA, Wikiproject Massachusetts,.nothing. The deletion board works in isolation and content editors need to know there work is being deleted with zero effort at improvement. As stated 2 times not many projects use the article alert anymore. What we are looking for is editors to help improve and update portals BECAUSE the community decided they are valid...we are not looking for a wild deletion party...looking for helpfull editors!!!--Moxy 🍁 13:04, 5 June 2019 (UTC)

All the projects I work with use article alerts. If others chose not to, then that is their choice ... but if they choose to opt out of being informed, they have no right to complain that they are not informed.

The community never decided that all portals are valid. Please don't make stuff up. --BrownHairedGirl (talk) • (contribs) 13:27, 5 June 2019 (UTC)

I cant say much more..you wont address the concerns raised just that your always right....now your reverting me in the middle of trying to restore things. Credibility with me has reached zero.--Moxy 🍁 13:32, 5 June 2019 (UTC)

Moxy, you did an unexplained revert which broke categorisation and removed 6 months of formatting improvements. Surely you know how to use edit summaries to explain why you did that?

And I have addressed the concerns you raised. We disagree, but I have addressed them. --BrownHairedGirl (talk) • (contribs) 13:49, 5 June 2019 (UTC)

As said many many times I agree portal namespace is dead....but the community has been clear that they believe they have value and should be retained...that means effort to improve them...not mass deletion basses on when they were last updated. You are fully aware that once the page hits the deletion page those that hang-around there will vote yes..thus discouraging any attempt at fix-up. Again time is needed - wait and see what a long time editor is up to perhaps he was about to use all the sub pages again!. Yes you have replied to some concerns...told projects there are shit out of luck for notifications if they dont have article alerts...and have explained you dont belive the normal process for page improvement applies to this one namespace because others have not made a template for you. Simply does not look good....long time editors should be fighting to retain work by improving it...not deletion on mass...be a pillar not a wrecking ball. -Moxy 🍁 14:19, 5 June 2019 (UTC)

Cleaning up portalspace by removing abandoned junk is not wrecking.

The wrecking is being done by those who object to removing the abandoned stuff which wastes the time of readers. --BrownHairedGirl (talk) • (contribs) 14:27, 5 June 2019 (UTC)

The community may not know its abandoned we need to inform the community and give time for improvement.....just like every other namespace. Your intent is good but the effort is in the wrong direction as outlined by the huge RfC...as the intent was improvement of what was there....not mass deletion.--Moxy 🍁 14:41, 5 June 2019 (UTC)

Moxy, just read the RFC. It was consensus not to delete everything.

It was not a consensus to keep every piece of abandoned crap.

And now that the automated portalspam has been removed, there are no mass deletions. Just individual nominations and occasional small groups.

If you or anyone else wants to set up a process of identifying and improving abandoned portals, then nobody is standing in your way. But it is now over a year since WP:ENDPORTALS closed, and there is still no sign of even the first step of triaging them. --BrownHairedGirl (talk) • (contribs) 23:37, 5 June 2019 (UTC)