Wikipedia talk:Portal/Guidelines

Notability Discussion: Revived

Moved from WT:WPPORT § Notability Discussion: Revived

 – — AfroThundr ^{(u · t · c)} 04:23, 6 November 2018 (UTC)

Much as we may wish it were so, this discussion isn't over yet. The conversation got a bit heated at times, and then it was basically just dropped with no resolution. Rather than truck out ~120kB of threads from the archives, I'll post them here, for convenience:

Original discussion of portal creation criteria

FYI

 – This conversation was also posted at the deletion discussions listed here. — AfroThundr ^{(u · t · c)} 16:49, 26 September 2018 (UTC)

This is mostly prompted by the recent MfD spree of a dozen newly created portals of varying scope and notability (most of which seem ok to me, but I digress). Our portal guidelines are still missing an important section: criteria for creation. We've talked before about drafting and codifying notability and other criteria to determine where the line is drawn for portal creation, and after the (mostly duplicate) discussions across those MfD's, I think it's time we finally sit down and hammer out something we can all live with, and build a set of criteria that might survive an RfC.

As a prompt, I'll take this back to the first thread I know of to discuss this matter: from WP:ENDPORTALS. I'm sure everyone here remembers that historical, semi-recent attempt to axe the entire portal namespace, which resulted in a no-consensus close and the reboot of this WikiProject. While creation criteria and notability were sprinkled all around that discussion, perhaps most relevant is the section WP:ENDPORTALS § Notability for Portal, which I have transcluded below for convenience:

Notability for Portal

An alternate solution to poorly maintained portal on narrow topics can be establishing “Notability” / Significance criteria for Portals which currently does not exist. Since WP strictly enforces notability criteria for articles, it only makes logical sense to have at least some minimum criteria for portals. There can be several approaches on how notability can be established, like:

1. . The core portal topic must be at least a Level-3 Vital Article.
2. . There must be minimum X number of Featured / Good articles that can be shown on the portal.
3. . The portal must be a level 3 or 4 sub-portal of the portals linked to the main page.

Please feel free to add why this may or may not be a good idea, or any alternative thought on how the “Notability” / Significance criteria can be established. Arman ^(Talk) 04:53, 25 April 2018 (UTC)

I agree to the idea in principle, but not in the specifics suggested above. Portals need to be understood as merely "Topic Overviews" or "Topic Tasters", and we should make them far more visible in Hatnotes, DAB pages, See Also and, especially, in Search results. As "Topic Tasters", they should exist only to introduce users to a broad subject area or theme at any level, and in a manner that single articles spectacularly fail to do. So, it's breadth and depth of subjects covered that is really important, not the current quality assessment of individual components. Have a minimum number of article linked from it, by all means, but do not require each to have a predetermined quality grading. This applies to Levels, too, I suspect. Portal:Mountain and Portal:Alps are at different levels, but they each serve as good, visual Topic Tasters to a very broad range of detailed content. Most importantly, they reach out and link sideways across other content at varying levels. So maybe judging Portals by that ability to link sideways is key here. As I'm not that familiar with the Wikipedia:Vital articles and their Levels, I can't offer more specific suggestions. But Portals are not Articles, so judging them by single article level doesn't seem appropriate. It's their function as a Topic Taster (and making them findable in the first place, and therefore functional) that should count towards an assessment of notability. If they don't give an overview across a wide range of subjects then they're probably not likely to be deemed noteworthy. Nick Moyes (talk) 08:24, 25 April 2018 (UTC)

Although it's tempting, I'm not sure notability is the right criterion as it's quite subjective and will result in energy-sapping discussions. What is more critical is the willingness of WikiProject teams to commit to supporting one or more portals. That's pretty easy to assess. If they do, the portal should be well maintained and high quality. If they don't, it could be a candidate for deletion if the quality is poor. Bermicourt (talk) 19:04, 25 April 2018 (UTC)

I very much like the suggestion to view portals as "topic taster" pages. I essentially agree with Bermicourt that quality should be enough as a measure whether we should keep or delete a portal -- for topics of fairly low notability (say, my local shopping mall) it will be really hard to make a halfway decent portal. But if somebody succeeds in creating an appealing and balanced portal, we don't gain by throwing it away. —Kusma (t·c) 19:19, 25 April 2018 (UTC)

German Wikipedia makes this easier by having guidelines on what definitely constitutes a valid portal (they call it 'relevance'), e.g. countries, major sports, capital cities, and saying that the rest should go through an approval process. I've translated (and slightly tweaked) their guidelines here. Maybe we could do something similar. Bermicourt (talk) 19:05, 30 April 2018 (UTC)

I am against notability guidelines. The Quality of a Portal is important. If the Quality is high enough, I do not care about notability.--Broter (talk) 16:09, 1 May 2018 (UTC)

I don't think that "notability" is the right measure either. I do think we need to have some kind of guideline or measure in place to make sure that portals do not get too granular.--Paul McDonald (talk) 16:19, 1 May 2018 (UTC)

These "relevance guidelines" are a good idea. In response to the concerns expressed by the last two users above, there's no requirement for us to make to guidelines rigid (per WP:IAR, if a rule prevents us from making a good, relevant page, well then ...). Actually, there is no reason to delete the portals whatsoever - we should use the same criteria as for Wikiproject pages - namely, if the pages are not well maintained or frequented but fall short of being "entirely undesirable", they can be tagged with {{WikiProject status|inactive}} or a (new?) variant thereof. 198.84.253.202 (talk) 18:04, 1 May 2018 (UTC)

Can we perhaps agree that at minimum a portal should:

1. be related to a notable topic (i.e., one with an article that is not likely to get deleted)
2. have a parent portal (so, no "orphaned portals") [edit: except for a small number of "top-most" portals — see discussion below]
3. have no missing/broken sections (like this)

Portals lacking these features could be tagged for refactoring (i.e., to be about a more general topic if #1 or #2 is the problem) or further improvement; in extreme cases, they could be deleted/archived. Obviously, plenty of opportunity would need to be given for interested editors to satisfy #3 before it could be used as justification for deletion/archiving. The details of "implementing" these principles could be worked out later, but I think "portals worth keeping" should satisfy these three conditions. Right? - dcljr (talk) 18:06, 1 May 2018 (UTC)

No. 3 seems good in principle, but in practice WP:NODEADLINE is a thing to consider and currently there is no policy which allows for deleting articles (or any other pages) because they are a "work in progress". No. 2 is good, but when pushed to its limit it becomes an infinite regress - of course, its possible to make "exceptions" to this "rule" for top level portals. Nevermind - No. 2 is good, too, assuming it can be linked reasonably (and without being an excessive split) to a parent portal (given that there is indeed a "parent of all portals", Portal:Contents/Portals). No. 1 is perfectly acceptable, though. 198.84.253.202 (talk) 18:12, 1 May 2018 (UTC)

Oh, yeah, for #2 I was implicitly exempting the "top-most" portals—say, those currently linked to from the Main Page, or, as you point out, those that are / could be listed as the most general portals on Portal:Contents/Portals. - dcljr (talk) 20:52, 1 May 2018 (UTC)

It seems silly to me to require that a portal be about a notable topic. If it's not about a notable topic, then the links in the portal will all be redlinks because any articles in the portal would be deleted at AFD... but then again... okay it still seems silly, but that doesn't mean it isn't a good idea too.--Paul McDonald (talk) 05:25, 2 May 2018 (UTC)

I much prefer Arman's criteria. 2 (once amended) seems absolutely critical. 3, while not vital, seems a fairly minimal standard to require. 1 actually might be a little under-strict: as noted, non-notable articles shouldn't be there, and if they aren't, it will just be redlinks. Should some qualitative requirement (not nearly as high as seen in the first mooted set) be needed for the primary article? E.g. a tested B standard? Nosebagbear (talk) 11:05, 2 May 2018 (UTC)

I agree with the minimal standards by dcljr. This should be required for every Portal!--Broter (talk) 13:25, 2 May 2018 (UTC)

I also agree with this. Under the above criteria, we could trim a significant amount of tiny, neglected, and unmaintained portals, and make our jobs of curating the rest easier. Having better guidance on when a portal should (or should not) exist is something we should work on. These criteria would be a good start on that. — AfroThundr ^(talk) 20:10, 7 May 2018 (UTC)

@Paulmcdonald: From what I see, no. 1 is indeed obvious, but it should still be stated clearly (something like "General guideline: there should already be at least a few (more than one) well-developed (not necessarily FA or GA, but more than start or stub class) articles about the topic") so as that it is clear in everyone's mind (even those who haven't discussed it here at the RfC). 198.84.253.202 (talk) 03:32, 4 May 2018 (UTC)

I mean it certainly wouldn't make sense to have a portal without at least 4 or 5 (at least!) articles to put into it. Having a "B" standard for the primary article and some general bit for a few more entries at least seems reasonable. (I don't think anything like "at least 3 more C or above articles" will help encourage portal upkeep!) — Preceding unsigned comment added by Nosebagbear (talk • contribs) 10:00, 10 May 2018 (UTC)

There were several other attempts I recall to get this discussion started shortly after the reboot, but they're buried in the archives somewhere. Let's see if this one sticks. So, what do you guys think on the matter? What criteria do you think a potential new portal should meet before it can be created?

Creation criteria discussion

@The Transhumanist, Evad37, Certes, Dreamy Jazz, Pbsouthwood, SMcCandlish, FR30799386, BrownHairedGirl, Godsy, Finnusertop, Cactus.man, and BrendonTheWizard: Pinging recent participants in the WikiProject and the MfD discussions. — AfroThundr ^{(u · t · c)} 16:54, 26 September 2018 (UTC)

So far, the main metric being cited is number of articles on the subject. The issue with that may be self-apparent to most: not all topics are created equal. Any number that would be sufficient for many topics may set the bar far too high (or too low) for others. I do, however, like the idea of linking them to vital articles, or the requirement for the main article to be rated a certain class or higher. If those aren't notable enough, I'm not sure what is. I also like the taxonomic suggestion that no portal can be standalone or orphaned. Ideally, all portals should have a parent and siblings that the reader can navigate like breadcrumbs to get to related topics. The rest of that section covered maintainability, which we've got in spades. — AfroThundr ^{(u · t · c)} 16:27, 26 September 2018 (UTC)

• I think that we should have a guideline, but, I feel that it shouldn't be too strict. I think that because portals act as a kind of navigation aid, a portal should not exist unless there are enough articles/pictures to make the portal seem finished. Also, I feel that we should ensure that the articles used are are of a certain quality rating or higher, because we are now so heavily reliant on transcluding leads from articles, having a portal based on stubs with small or no leads makes the portal also seem incomplete and empty.

I also think that having some kind of breadcrumbs link as AfroThundr3007730 mentioned is a good idea, but this could cut of having portals that do not necessarily have parents. Dreamy Jazz 🎷 ^{talk to me | my contributions} 17:01, 26 September 2018 (UTC)

Although "not topics are created equal", I still feel that if a topic does not have the articles on it, then those articles should be developed first, as I feel a portal acts as a way to find articles / similar topics, so not having the articles to link to is like having an empty or small contents page, which is inadvisable. Dreamy Jazz 🎷 ^{talk to me | my contributions} 17:06, 26 September 2018 (UTC)

Some ideas to consider:

1. I like the idea of a link to a higher level portal. Not sure if it should be a requirement, but am open to debate. There is almost always a possibility for a parent portal. If there are counterexamples, I would like to see a few. Siblings may or may not exist. A breadcrumb trail could be a nice touch. Breadcrumb trail upwards, box(es) of sub-portal, sister portal and related portal links downwards and sideways.
   • How do we do breadcrumb trails for portals with multiple parents? Several in parallel?
2. If there is a reasonable navbox, that may serve as the criterion for having a portal on the same topic, as the current system relies on the navbox for structure, but there is room for improvement.
3. A portal made up of mainly stubs and few substantial articles should be discouraged. First get the articles, then make the portal. If there are enough substantial articles, the number of additional stubs should not matter.
4. Images are nice but cannot be a qualifier as some topics have very few useful images. Same with news, quotes, did you knows etc, which are mainly decorative.
5. There should be a category of similar name and overlapping content. There may be cases where it does not exist, but then either the portal is frivolous or the category should be created. Navbox and category will usually have a large intersection.
6. Special cases should be considered on their merits.
7. Portals that are large and cumbersome will usually be suitable for splitting into sub-portals, based on rationalising the navboxes. I am experimenting on these lines with Portal:Underwater diving, which is in a state of flux, but demonstrates sub-portals/sister portals based on navboxes. Underwater diving is also one of those topics which does not have an obvious unique parent, as it could be a child portal of several, and the sub-portals could be sub-portals of various other parent portals. The network could get quite complex. · · · Peter (Southwood) ^(talk): 20:34, 26 September 2018 (UTC)
8. New single page portals are cheap to make, we can lose a few if they are not good enough yet and no-one is available to fix them quickly, but they can be recreated as soon as the topic is ready. That which is deleted now can be undeleted when the time is ripe. · · · Peter (Southwood) ^(talk): 20:57, 26 September 2018 (UTC)

You mentioned stubs. Keep in mind that our lua gurus have built-into the transclusion modules a stub filter, so that articles tagged as stubs are not displayed in portal slideshows. So stubs shouldn't be a concern. (Remember to show your appreciation to these guys, for the amazing features they have enabled in portals).    — The Transhumanist   06:21, 27 September 2018 (UTC)

@Dreamy Jazz and Pbsouthwood: These are all good points. With regards to the breadcrumbs, I'm thinking they should trace the direct lineage back to the top-level portal it descends from, and in the case of multiple parents, it would just show the main (primary?) parent, or even list two breadcrumb trails. If resolving one of those trails results in another split, the "primary" link is chosen. I think that could be implemented with minimal confusion to the readers (and editors). As for the child and sibling portals, I think each portal should only show their "immediate family" not extended cousin or nephew portals (this metaphor is getting weird). If such a network becomes tedious to maintain by hand (highly likely), we could use Lua to pull Wikidata relationships to track the genealogy. — AfroThundr ^{(u · t · c)} 04:05, 27 September 2018 (UTC)

I think I follow your explanation, and it looks OK. It will probably be quite simple for most portals and horribly complicated for a few. So it goes.

Wikivoyage has a breadcrumb system that, if I remember correctly, only requires the immediate upward link to be made by the user, and automatically follows the existing trail to the top. It is only used for one trail per article, because they structure the site quite rigidly to make that possible. I have no idea whether linking upward to two parent portals would work, but would guess that it will either work all the way up or crash immediately.· · · Peter (Southwood) ^(talk): 12:07, 27 September 2018 (UTC)

{{Breadcrumb}} works but each portal would need to list all its ancestors explicitly. We might create a variant where the portal just needs to name its immediate parent, with the trees above there recorded once, perhaps in the template itself. Certes (talk) 12:34, 27 September 2018 (UTC)

• What are the benefits of a portal? When is a root article with a portal attached better than a root article without one? And why? For example, is Quidditch (sport) a better encyclopedia page because is has a portal link in its See also section? And how do users make use of portals? How should we go about finding this out?    — The Transhumanist   00:02, 27 September 2018 (UTC)

@The Transhumanist: please can you clarify whether you gave any thought to that what are the benefits of a portal question before you went on a rapid-fire spree of creating hundreds of them at a speed which sometimes exceeded over 40 per hour?? What conclusions did you reach then? And have you reconsidered those conclusions in light of subsequent discussions? --BrownHairedGirl (talk) • (contribs) 01:05, 27 September 2018 (UTC)

I wonder how receptive the WMF would be on providing us more detailed analytics on Portal namespace traffic (enwiki and possibly dewiki). I'm talking things other than just generic pageviews. They run traffic studies all the time, so the infrastructure is already there. I'm guessing we'd also need to shanghai an analyst to parse that down for us, since I don't see them handing us the raw dataset (not without identification at least). — AfroThundr ^{(u · t · c)} 04:14, 27 September 2018 (UTC)

BrownHairedGirl, I can attest that The Transhumanist has spent a considerable amount of effort on thinking about whether there are benefits to portals. The question above relates more to whether there is any data available. We have discussed this at length, and agree that they are potentially (and probably actually) useful, but we do not have any statistics, so hard to express a probability with any confidence. This was not done without consideration, but conclusions may differ, as they all appear to be based on personal opinion so far. · · · Peter (Southwood) ^(talk): 05:51, 27 September 2018 (UTC)

@Pbsouthwood I am sure you write in good faith, so I would like to believe you. However, TTH's many replies at MFD show near zero evidence of having done any such thought, as did their post[1] on my talk asking me to withdraw the Pebble Beach MFD ... a micro-portal which TTH subsequently G7ed after others agreed with my assessment of its narrowness. TTH's MFD comments repeatedly amounted to verbose technical descriptions of how portals work rather than why that particular one had sufficient scope to add meaningful value, and at one point he even expressed deep indignation that a portal was MFDed before it was complete because how TTH know its utility before it was fully built. That indicates little or no prior assessment, so I'd like to see TTH respond in their own words.

I am disappointed to see you joining several editors in this discussion talking of "personal opinion" to dismiss other comments. We reach consensus by having reasoned discussion and assessing what evidence is available. I have shown evidence both that narrow-scope portals are little used and that extensive promotion does not significantly raise usage levels. So we would be more likely to sustain courteous and constructive discussion if you refrained from the discourtesy of airily dismissing my evidenced assessments as "personal opinion", which implies that there is no evidence involved.

Sure, the data which we have is limited, and we could have a sensible discussion about the significance of the evidence gaps. It would be great if @AfroThundr3007730 could get more detailed usage info, but I seriously doubt that it would significantly alter the picture. There are so few examples of widely-used portals that there is little chance of learning much new about what makes them successful.

I am concerned that in both your reply and TTH's mass-creation spree the approach you describe seems to me to amount to "inconclusive evidence of utility, so let's massively increase the rate of creation". Apart from inherent perversity, that seems brazenly dismissive of the ~150 editors who at WP:ENDPORTALS expressed support for a mass cull. --BrownHairedGirl (talk) • (contribs) 06:40, 27 September 2018 (UTC)

BrownHairedGirl. Thank you for your explicit assumption of good faith. It is not misplaced, and I extend the same courtesy to you. If you want documentary evidence of considerable thought and discussion, it exists on my talk page and its archives, The Transhumanist's talk pages and archives, in the project newsletters and project talk pages. Whether all possible aspects were exhaustively considered is a claim I will not make, but a lot of discussion exists if one wants to examine it.

If I appear to be airily dismissing your evidenced assessments as personal opinion, I apologise, as that was not my intention. The comment about personal opinion applies equally to my opinions and those of the members of this project, and was not aimed at you specifically. I would however like to see your evidence, as I don't have any, and assumed that no-one else does either. I have been wrong before, but am amenable to evidence based correction.

I don't think I have even expressed my opinion about how fast portals should be created. I am not supporting the current rate, I am defending some of the reasoning behind it. I do not see this as a black and white issue, and do not even know how grey it is.

Have you examined the code of a new model portal? I ask this for background, as it would affect how I might explain my opinions, and do not wish to make an assumption either way. Cheers, · · · Peter (Southwood) ^(talk): 07:18, 27 September 2018 (UTC)

@Pbsouthwood: no, I have not examined the code of a new-style portal, and I do not intend to do so ... because I do not see how the coding alters the well-evidenced fact that microportals get microviews. If you would like to present some concise explanation of how the code has altered pageviews, I would be delighted to read it it.

As to my evidence on pageviews, I have presented some at MFD and some elsewhere on this. I do not intend to collate it, because I am pretty sure that anyone working on portals knows the data: that only the ten most-used portals even top 400 daily pageviews.

I hope you will understand why I am not going to trawl archives and multiples user pages for snippets of discussion. I assume that responsible editors follow WP:MULTI -and centralise discussion so that it can read and joined by others. It is those centralised discussions and proposal formations which I would be interested in seeing, if yo can offer any links. But I note with alarm the lack of discussion at WT:PORTAL. Not a good sign. -01:07, 28 September 2018 (UTC)

• Many thanks to @AfroThundr3007730 for starting this discussion. After the community reached a consensus at the RFC not to delete all portals at this time, this project had a reboot and some great work was done to improve the templates. Sadly, that good work does not seem to have been accompanied by similar attention to the main issue raised in the RFC: that most portals get very few views. With the exception of a very few broad scope portals, readers hardly use them. Over 150 editors supported either deletion of the whole portal namespace or a massive cull. There is absolutely no evidence of broad consensus for a massive expansion of portals, or for adopting low scope thresholds.

Some commentary in various place suggested that low usage was due to inadequate promotion. However, I have evidence to the contrary, wrt Portal:Years. Earlier this year, User:Fayenatic london and I did a lot of work on adding automatic portal links year-in-foo categories. One of the results of that is that there are now 393,762 links to Portal:Years ... but it still has a 90-day average of only 16 pageviews per day. The conclusion of obvious: promotion has not helped, and readers don't want that portal.

Similarly, Portal:France has only 75 daily pageviews vs 15,000 views per day for the head article France ... and >11,000 daily views] for London vs 36 daily views for Portal:London. Or 10,000 daily views for Queen (band) but only (band) 17 daily views for Portal:Queen (band).

Despite obvious community disquiet about the v low usage levels, the Portals Project seems to have concerned itself primarily with the how of portals, and not the why and what. On the contrary, Wikipedia:WikiProject_Portals#The_current_plan says Create new portals for all the core topics that have enough coverage to need a portal, and for whatever other topics portal creators are interested in. The lack of guidance about what constitues "enough coverage to need a portal" is a bizarre oversight, and the "whatever interests a creator" is silly. This failyre to define thresholds seems to me to be serious collective case of WP:IDIDNTHEARTHAT.

So the result has been that one editor (The Transhumanist (talk · contribs · deleted contribs · logs · filter log · block user · block log)) has been engaged in rapid-fire creation of small-scope portals: over 400 in the last 12 days, sometimes with only a few minutes between them (e.g. on 22 Sept, 9 new portals created in 60 minutes, or on Sept 17th 73 new portals created in 91 minutes). That clearly involves no scrutiny of the scope or viability of the portal .. and shockingly, the same editor has specifically objected to being asked why they chose to create a portal with a particular scope, at least until the portal has been completed. That is a daft way to approach any such task: the very first step should be to be assess whether the topic is suitable for a portal.

The failure so far of this project to address any of these issues is stoking up trouble for the future. The "keep" votes at MFD seem to have come overwhelmingly from a few regular participants in this project; there is no sign of wider community for the new microportals. Even the portal-project keepvotes have mostly been qualified.

My own view starts from the fact that portals are not content; they a device for navigating between content pages. We already have tools for navigating small sets (lists, categories and navboxes) ... so a portal should be a gateway to a large collection of info, not simply a shelf with a few dozen items. I deplore the attempt to use portals simply as a different way of presenting the list of titles in a navbox.

My preference would be for guidelines that restrict portals to:

1. broad topics: e.g. a country rather than a county or village; a musical genre rather than a single band; a literary movement rather than a single writer; a sport or league rather than a single team.
2. topics whose scope extends to at least five thousand non-stub articles, at least a dozen good articles, and preferably a few feature articles/lists.
3. topics where a properly-advertised discussion has shown that there is both a consensus to create it, and a group of several experienced editors who are willing to commit to maintaining it.

Others clearly have different preferences, so we need an RFC to find a broad consensus. I would be happy to work with other editors to draft such an RFC to be posted in a neutral location such as WP:VP ... but in the meantime I strongly urge this project to recommend a moratorium on the creation of new portals until such an RFC is concluded.

I also recommend that before an RFC proceeds, there should be some collaborative effort to collect evidence on the usage of portals, and on whether difft types of promotion have an effect on usage. --BrownHairedGirl (talk) • (contribs) 00:51, 27 September 2018 (UTC)

@BrownHairedGirl: Lots of good stuff there. I'm just going to poke at a couple of points, since I don't have time to post my own wall of text in response.

1. New portals - While I agree that the new portal creation should be slowed considerably until we have a decent set of criteria in place, I don't think it needs to stop entirely. Instead of starting with the "low-hanging fruit" at the bottom of the hierarchy, we should instead be filling out the top-level subjects that are still missing (a la the vital article topic list on the project main page), then work our way down from there. By the time we reach questionable eligibility territory, we should (hopefully) have guidelines in place. Or if we're still spinning our wheels here, we can call a halt then, which brings me to my next point.
2. Scope criteria - More directly on the topic at hand, I don't think an article count in the thousands should be necessary to decide that a portal can be created. That sounds like at least an order of magnitude too high, and would describe the current top-level portals. But as you all know, we have an entire hierarchy of smaller scope subportals (and dare I say sub-sub portals?) under those. The majority of older (pre-reboot) portals would have an article scope in the hundreds at most, and I think that sounds about right for a portal. I do believe that less than a hundred articles is a bit on the slim side, (re: recent MfDs) and while I know the topic area can grow, that's why we have WP:WTAF. Portals are so easy to create now, we can always not make a tiny one now, and come back when it's ready to be created. Put it on a "future portals" list or something.
3. View count - So far as I can tell, view count has never been a priority metric for any of Wikipedia's content, least of all portals. You cited some metrics from Portal links included via categories, which are themselves viewed orders of magnitude less frequently than their member articles. The second-level negative effect that would have on the linked portal views would be expected, IMHO. It doesn't help that portals are only allowed to have a link at the bottom of the article (like many other types of non-article content), meaning that the majority of readers who don't read our sometimes overly-long articles to the end might never have seen them in the first place. Even if they are only in the dozens, if those handful of readers were able to find what they needed and walk away with a better understanding of the topic, then the portal has served its purpose.
4. Role of portals - Portals are significantly more than "fancy navboxes", and while tiny-scoped portals can seem that way, the larger ones provide much more than that. You are correct that the primary purpose of a portal is to aid the reader in navigating a topic, but that is only half their function. See WP:CLNT, which covers this nicely, along with how they coexist despite their overlapping purpose. Categories and navboxes (and even lists and outlines) don't do much more than provide a structured list of links to the reader, and leave them to fend for themselves and figure things out on their own. We have smart readers, so I'm sure they manage that just fine, however, portals can go that extra mile to present the content in a way that allows the reader to engage with the topic in a more interactive fashion (The Transhumanist has written a novel on this already, so I won't go further here.) This also includes drawing the reader in as a potential editor by encouraging them to contribute and improve the topic area, both here and on sister projects. That last part cannot be discounted as immaterial or irrelevant.

This ended up being a wall of text anyway, it seems. All that aside, the actual criteria still needs to be written, which seems to be developing in the thread above this one. Your third criteria for an approval process, was brought up before, but the discussion didn't get very far. Perhaps it should be revisited. — AfroThundr ^{(u · t · c)} 03:18, 27 September 2018 (UTC)

• @AfroThundr3007730: some quick replies:

1. New portals you at least agree on a slowdown, so we are not far apart on this. However, I don't see evidence for a consensus anywhere on what is a "top-level portal" (e.g. where in this tree: Science → biology → zoology → Mammalogy → Primatology → Hylobatidae → Gibbons) ... nor any consensus that the existing set of higher level portals is inadequate. The point was not central at the recent RFC, so not assessed by the closer ... but there were a lot of voices saying that we need only a subset of the current top ones.
2. Scope criteria as I expected, we disagree on that. But if we are going to restrict portals to higher level topics, then the count will be no barrier ... and I have yet to see any evidence of a consensus for micro-portals. Remember, there is a finite number of editors ready to maintain these portals. The more portals we have, the more that manitenance effort is diluted. I am arguing for fewer and better, 'cos it seems to me that some editors here just count numbers and ignore quality, utility nad usage.
3. View count Portals are not content. Repeat after me: portals are not content. They are a navigational aid. The more navigational aids exist, they more they each decline in utitly, as happens when a road has too many signs: the crucial info is lost in the clutter. What exactly is the purpose in creating hundreds of hardly-ever -used portals?
4. Role of portals. We agree on the utility of large portals. But most of their features are useful only on larger sets; in small sets, they are just alt-navboxes and are little used. An unread portal won't draw in editors to improve topics.

Remember, we recently had ~150 editors willing to TNT the whole lot; they lost that debate because a significant swing vote likes a subset of portals, while acknowledging that most of them are pointless. If this project doesn't do a fundamental rethink and focus on quality rather than quantity, then a proposal for a mass cull stands a good chance of gaining community consensus.

The drive-by-portal-making-bot-editor is shaping up to be the poster child for such a cull. Either this project applies some brakes, or the brakes will be applied from outside ... and in my 12 years of experience on en.wp, I have repeatedly seen that when the community decides that a project lacks self-discipline, it can react quite harshly. That WP:ENDPORTALS RFC should be taken as a last warning about community patience. --BrownHairedGirl (talk) • (contribs) 04:09, 27 September 2018 (UTC)

• BrownHairedGirl, Some responses to your points above:
  1. New portals:Your question on which is a top level portal with an example tree: There are two ways of looking at this. The top level portal in that tree is obviously Science, but Science would be a subportal of All knowledge, so I guess that All knowledge is The top level.

1. Scope criteria:The whole point of the new model portal is that it is largely self-updating as far as content goes. maintenance is restricted to updating the collection of templates used as and when new ones become available. This is experimental, but developing relatively quickly, thanks to several skilled coders' input.
2. View count. We cheerfully join your chorus that portals are not content, You are preaching to the choir on this point. If you take a close look at the new model portals you will see that they contain on a first approximation, no unique content. They display content from mainspace in a different way, one which we hope will be useful to a significant number of readers. Whether editors ever use them is not important. We editors who have been here for several years know how to find content through the occult and arcane byways of Wikipedia, and of course the ubiquitous search functions, when we know what we are looking for. The portals should be a relatively reader-friendly system to find out more about a topic of interest, without presupposing a level of skill or requiring the reader to know what they are looking for by name. We are still working on this, I know it is imperfect. On the other hand, I spend a bit of time clicking on the list of one page portals as a sort of QA check, and report any bugs I find, but often find myself down the rabbit hole. Not everone's cup of tea, but I find them sufficiently engaging, particularly on topics I would not normally think of reading.
3. Role of portals: We are exploring the role of portals. One of the things we are exploring is the effect of greater visibility, as that which cannot be seen is unlikely to be used. Hiding portals where no one sees them makes them unuseful.

I assume that the warning in your conclusion is just that, and not a veiled threat, which some may read into it. You may wish to clarify.

In conclusion, a question for you. What harm are the current portals doing? On what evidence is this analysis or opinion based? Bear in mind that they are not in mainspace.

BrownHairedGirl, One of the results of that is that there are now 393,762 links to Portal:Years ... but it still has a 90-day average of only 16 pageviews per day. The conclusion of obvious: promotion has not helped, and readers don't want that portal.. The conclusion is not obvious to me fron the results as quoted. Two questions immediately spring to mind: Did the readers notice the links, and if they did not, why not? If they did not notice the links, they cannot actively not want that portal, as they would be ignorant of it's existance. If they did notice the link, can we draw conclusions about their wanting the portal if they did not click it to see what it is. Can we assume that they know what is at the other end? Has anyone asked them? Of course it is possible that most readers would never use a portal even if they knew exactly what it was, but most readers do not visit most Wikipedia articles. How do we decide what is worth having? For articles it is the notability criteria. For portals it may depend on the overhead. A trivially easy to create and maintain portal which occupies very little storage in the database, and only really exists when someone looks at it is not a very large overhead. That is one of the targets we are working towards. We seem to be getting there. Is 16 pageviews per day for a low overhead portal actually a problem? Cheers, · · · Peter (Southwood) ^(talk): 07:47, 27 September 2018 (UTC)

I also endorse AfroThundr's "wall of text" response above. In most cases I could not have put it better myself (at least not without some hard work and a few false starts). Cheers, · · · Peter (Southwood) ^(talk): 08:47, 27 September 2018 (UTC)

@Pbsouthwood: First, you ask if I am making a threat. Answer: I have described what I see as a problem, and what I think should be done. I believe that there are already far too many portals, and that there has been a recent spree of trivia. There is clearly a v difft view among many project participants, and since several of them popped up at MFDs to say that there should be no deletions without guidelines, I want to see an RFC to set some guidelines on thresholds. I honestly believe that those posting so far have been ignoring the widespread disdain for portal-spam and micro-portals, and that this is a foolish position to take. There is no threat; just a promise that one way or another there will be an RFC on this, and a plea to project members to engage with why so may editors supported a TNT option rather than bury their heads in the sand of groupthink.

The overhead is not primarily in server load; per WP:SERVERLOAD we are generally encouraged to assume that any server load we are technically permitted to generate is fine. The overhead is two-fold: a) maintenance (more pages for editors to monitor); b) navigational. The second is my main concern: a portal by its nature promises a gateway to a large collection, and if it offers only a shelf-full it will disappoint readers who may thereby be less inclined to visit other portals. Such micro-portals will also need pointers from elsewhere, whether articles or categories, which means adding distracting and pointless signposting.

You ask is 16 pageviews per day for a low overhead portal actually a problem? Yes it is, because even aside from the monitoring load, that 16-a-day Portal: Queen (band) is signposted from 489 pages. That's 489 signposts to an almost-entirely unwanted destination. It is navigational clutter, and one the key aspects of effective navigational design is avoidance of clutter. That's why motorway signposts do not signal every village within reach and why sites such as Google and gov.uk use radically decluttered layouts. --BrownHairedGirl (talk) • (contribs) 10:27, 27 September 2018 (UTC)

BrownHairedGirl, I suggested you might want to clarify, thanks for doing so. I shall clarify my position a little too.

• I don't believe there is such a thing as "Too many portals" per se. Too many inadequate or poor quality portals, or too many portals that don't serve a sufficiently useful purpose, sure. That can happen even if there are "not enough" portals, should that be a thing.
• I am entirely in favour of sorting out a guideline for portal creation and portal deletion. As long as it is sufficiently flexible to work in an environment of fairly rapid change, and does not stop people from improving the encyclopaedia with new ideas that might be better. An RfC is the standard way to do this, so no problems there either. It looks like the time is about right. Bold - Revert - Discuss: TTH was bold, you applied the equivalent of revert, we are now discussing. This is good. This project is generally a friendly space for discussion, and we can usually come to an acceptable compromise.
• Welcome to the project discussion pages, you can help us with alternative views. We are generally enthusiastic about some or other aspects of portals, or we would not be in the project. A bit of wider perspective can be useful.
• I am glad that you don't see maintenance as a major problem, because almost all of our efforts go into minimising that.
• A portal promises a gateway to content on the topic. Where does it promise a large collection? Sometimes only a small collection exists, and I agree that there is a lower limit of usefulness, but I don't claim to know what it is. I suspect it varies by topic and even by user.
• If there are 489 articles within the scope of Portal:Queen (band) then I am inclined to think that 489 signposts is not excessive. If they are from pages not part of the topic, then I agree with your point, while noting that there may be even more in-line links to the article Queen (band) scattered through the encyclopedia. I also don't see what that the 16-a-day have to do with this, or where this clutter is that you don't like.
• If there is widespread disdain for portal-spam and micro-portals where is it expressed? Cheers, · · · Peter (Southwood) ^(talk): 11:35, 27 September 2018 (UTC)

Pbsouthwood, Some quick replies to those points.

• You don't believe there is such a thing as "Too many portals" per se. I disagree: only 7 of the 8 portals linked on the front page get over 1000 hits per day. Nearly all of the rest get damn all readership. They are not content; they are navigational devices, and an unused navigatiional signpost is a cluttering distrucation. I say purge the stacks of barely-used ones
• You say A portal promises a gateway to content on the topic. Where does it promise a large collection? It used to do so at the top of WP:PORTAL, as you can see in the version of 2 May 2016, which was unchnaged for two years. The sceind para read "Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers".
  That guidance was removed[2] on 23 May 2018 by The Transhumanist, whose edit summary simple says "update". No evidence was offered of a broad community consenus for such a major change of scope to an entire namespace. So I have reverted to the long-term stable version Discussion at Wikipedia talk:Portal guidelines#Current_version_of_the_guidelines.
• If there are 489 articles within the scope of Portal:Queen (band) then I am inclined to think that 489 signposts is not excessive. The 16-views-per-day for the portal demonstrates that they are signposts which readers do not want to use (16 is only 0.15% of he views of the main article). Unusused and unwanted signposts are clutter, whether on a road or on a webpage.
• If there is "widespread disdain for portal-spam and micro-portals where is it expressed?}}. Answer: in the lede of WP:PORTAL ("Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers") and in plenty of comments at WP:ENDPORTALS

I am sorry to say that my discovery of the undisclosed unilateral rewriting by TTH of the WP:PORTAL guidelines has confirmed my fear that TTH has not been acting in good faith. I would also like other editors to clarify whether they were aware of this change, and if so why they did not mention it in discussion.

Now that the unilateralism has been reverted, we can focus on clarifying the threshold set there, rather than working from first principles ... unless of course TTH or anyone else wants to open an RFC proposing the radical wideniung of scope. --BrownHairedGirl (talk) • (contribs) 00:55, 28 September 2018 (UTC)

Actually, it is BHG who has violated guidelines, not me. See #Response to BHG's accusations and guideline reversion. Thank you.    — The Transhumanist   12:37, 28 September 2018 (UTC)

Metrics request

Tracked in Phabricator
Task T205681

@Pbsouthwood, BrownHairedGirl, The Transhumanist, and Waggers: I don't have time to respond to the latest discussion right now, I'm about to submit a phabricator ticket to ask the analytics team about some of this. Here's what I currently have. Feel free to add to or modify the list. I want to get a solid description drafted instead of tweaking it on phabricator. I'll submit it a bit later. — AfroThundr ^{(u · t · c)} 13:21, 27 September 2018 (UTC)

Extended content

T205681: Metrics request on portal namespace usage Tag: Analytics CC: Pbsouthwood, BrownHairedGirl In preparation for a new RfC on enwiki regarding new guidelines for the Portal system, we would like to gain additional insight into how much the current portal system is currently used. We can get easy stuff like view count already, but that does not take into account other more detailed aspects. Such as: How many people clicked on a portal link from an article, or a category? Which articles, and which categories generated the highest traffic? How many people followed through to another article from the portal, or just closed the tab? Which articles and portals had the highest engagement? (useful for replicating their success) How many people even scroll to the bottom of the article and even had the opportunity to notice the portal link? About what article size tends to result in zero portal link visibility? I'm not sure how detailed the analytics are the WMF is currently collecting, so some of this may not be plausible at this time. I'm basing this off of the various studies I've seen run, like the recent citation usage study m:Research:Characterizing Wikipedia Citation Usage. Granted, that is a more involved example, and I'm not asking you to make schema changes to facilitate this or anything.

This is now tracked as T205681. — AfroThundr ^{(u · t · c)} 01:34, 28 September 2018 (UTC)

Back to the topic

Let's try to keep this discussion on topic, and that topic is: how do we define what is a sufficient scope for a portal to exist? Discussions about the purpose of portals, repeating the "delete the whole namespace" RfC discussion all over again, talk of page views as if this were a commercial, advertising-driven website, or the behaviour of individual editors and whether or not they should stop creating portals are all distractions from that. They might be important discussions to be had elsewhere but let's try to keep this thread on track.

There will always need to be a bit of leeway in any such guidance. For example, if there is a large, notable topic that doesn't have many articles written about it yet, it's still a large, notable topic and therefore suitable for a portal. So the blunt instrument of counting selected articles doesn't cut the mustard (a mixed metaphor that works surprisingly well).

What's interesting about the recent MfD spree is the pattern behind it: it seems The Transhumanist went on a portal creation spree based on the notion that if there is a navbox, then the topic is sufficiently wide in scope to have a portal. Then BrownHairedGirl went on a deletion spree, nominating portals for deletion if they didn't have a corresponding category. So maybe there's something about the existence of a navbox and/or a category for a topic that could form the basis of some guidance. Not as fundamental criteria, but as an indication of whether a topic meets whatever criteria we do decide upon.

Something else we need to consider is that the new format of portals is much more lightweight in terms of the effort needed to create and maintain them, and indeed the space they take up in the Wikipedia database. As such I would argue that the bar for inclusion can be set much lower than it would have been for the old-style, manual maintenance, lots-of-subpages portals. WaggersTALK 08:06, 27 September 2018 (UTC)

Funny thing that. I have been suggesting that the existence of both a navbox and a category of same topic scope, and preferably the same or very similar title, are fairly indicative of a portal being appropriate, and have suggested that if the category does not exist and the portal should exist, then the category should be created. This helps categorisation too, which is also a gain for the whole system. So I am with you on this one.

I will go further, and generally agree on your whole post. · · · Peter (Southwood) ^(talk): 09:30, 27 September 2018 (UTC)

I've found that creating new portals helps identify categories that need creation. In many cases there are subcategories already in place, that lack a parent category which the portal identifies. This happens a lot with singers and bands. There will be categories for their singles and albums, but not one for the singer or band itself.    — The Transhumanist   09:51, 27 September 2018 (UTC)

I've just taken a good look at WP:CAT since it seems to make sense that we use similar criteria for creating portals as we do for creating categories. So what are the minimum criteria for creating categories? Perhaps surprisingly, there don't seem to be any listed at WP:CAT. Users are encouraged to create any categories they think are appropriate provided they are appropriately named and have a parent category. A similar approach for portals doesn't seem unreasonable to me. WaggersTALK 10:05, 27 September 2018 (UTC)

That sounds like a good idea. It allows editors the freedom of not having to get a portal approved by other editors. However (like categories and them being empty consitutes a speedy deletion), I still feel that keeping the speedy deletion for a portal without a substantional base is a good idea. Dreamy Jazz 🎷 ^{talk to me | my contributions} 11:46, 27 September 2018 (UTC)

Yes, I don't think anyone is suggesting getting rid of WP:P2. WaggersTALK 13:34, 27 September 2018 (UTC)

Oh dear . Pile of ABF there, @Waggers.

First, I did not go on a deletion spree and I did not go on a deletion spree, nominating portals for deletion if they didn't have a corresponding category. What I did do was in the course of cleaning up Special:WantedCategories I found a series of redlinked cats which consisted of portals placed in non-existent eponymous categories. In such cases I found that these portals were all populated by

Category:{{PAGENAME}}

, and that they were mostly categories which would not normally be created, or deleted if they existed, such as eponymous categories for musicians and bands. This was odd; having processed tens of thousands of redlinked cats in the last year or so, I had rarely encountered portals. I was surprised to see the use of a poorly-automated category entry like this, and I noticed little effort made at other categorisation. Whatever these were was clearly rapid-fire templating. So I began scrutinising the portals, and when I saw the narrow scope of some of them I began to do what I do when I encounter other apparently inappropriate content in this process: nominate them for deletion. I was shocked by how many such micro-portals were appearing, and by he bizarre reaction of TTH to my first nomination.

In no case did I MFD a portal because it lacked category; that is no grounds for deletion. The redlinked category was solely how I encountered them.

The second point of misrepresentation is that neither I nor anyone else is trying to revive the delete-all-portals proposal. That was clearly rejected.

However, there was a lot of support in that discussion for the idea that there are too many portals. And as I have repeatedly noted, this project has gone in the other direction, creating hundreds of new portals. I do not believe that there is community consensus to do so, and esp not to create portals on such narrow topics. Waggers and others argue at MFD that there should be guidance on which portals are appropriate, and that deletion decisions should be based on that. This is the discussion I also want to have, and since Waggers sought a moratorium on MFDs then it's sensible for everyone to take a break from both creation and deletion while we try to discuss how e frame an RFC on criteria.

Thirdly, there are far more constraints on categories than Waggers sates. See for example WP:OCAT, and the stream of catefory deletion and merger discusisoins at WP:CFD.

Anyway, back on topic after correcting Waggers misrepresentations.

I get that Waggers and Pbsouthwood and TTH want a v low bar (if any) for portals. I hope it is now clear that I want a higher one. We have all made our basic positions clear, and I see a huge gap.

So the principles of this guidance needs to be settled by an RFC, not simply by members of this project. Does anyone in this project actually want o work with me on drafting such an RFC? Or do you just want to form a WP:LOCALCON amongst project members? --BrownHairedGirl (talk) • (contribs) 19:55, 27 September 2018 (UTC)

I'm no expert on RFC-drafting, but I'm willing to work on the process and criteria for setting a bar for portals. There has to be a bar at some level, or anyone could create an atrociously-built portal or a portal about every village in the world. I don't think anyone here would defend those. So could we not try to find an interim solution first, before going to RFC where views are likely to polarise further? Here are some thoughts:

We agree a bar, ideally mid-way between the opposing positions for future portals

The bar isn't retrospective i.e. we don't use that to mass delete existing portals

We only create new portals that meet the new criteria

We run with the new criteria for six months and then review them

We focus our effort on a) improving existing portals and b) creating those new portals considered to be 'top level'. Someone's already posted a pretty reasonable-looking list. Bermicourt (talk) 21:35, 27 September 2018 (UTC)

@Bermicourt: thanks for that prompt and constructive response.

I agree that there should be a bar somewhere. I have my own prefs on the where, but I think the worst outcome is no bar.

However, I think that the gap between the two views is to great for any sort of trial-compromise position to be helpful. At one extreme we have those such as TTH who sets the bar so low that we could have many tens of thousands of portals without ever falling below the threshold. On the other hand, there are those like me who advocate a massive cull in the number of existig portals, reducing the number to below 100. That's nearly three orders of magnitude of difference, and a comprmise across such a big gap satisfoes nobody. As a trial it would tell us little or nothing to inform us of the merits of either propsoal. We need to choose a broad direction.

Both extremes clearly have a lot of support, so we need to seek a community consensus on which broad direction to take. The mechanism for that is an RFC, which may be best done in more than one stage. Phase one, choose the many / fewer / v few options ... then in phase 2 decide how that threshold is defined (some or all of article counts/vital article asessments/pageviews/etc)

I will create a new section below with a first draft of these options. --BrownHairedGirl (talk) • (contribs) 22:40, 27 September 2018 (UTC)

BrownHairedGirl, I can't find the new section with draft. Possibly you have not started it yet. If/when you do, please mention the header here. For the record, I see all these options as temporary until the quantum portal (generated on demand from a template or script, and does not exist unless someone is observing it) is available, at which point the guidelines may become largely redundant, and permanent portals may become showcases built by enthusiasts again. In the meanwhile I prefer a relatively wide scope so experimentation can be more effective. Cheers, · · · Peter (Southwood) ^(talk): 08:37, 28 September 2018 (UTC)

While there is a large gap between the camps, I believe we could still come up with a workable compromise in the meantime. While community consensus is the ultimate deciding factor, it helps if that consensus can be built on an informed opinion, backed by evidence and experiment data. To that end, a trial could still be useful. Otherwise, we'll all be guessing in the dark as to which solution would be best. Should we not make the best decision in the upcoming RfC, it would take yet another RfC to change it again, by then I think the community would be getting a bit tired of Portal RfCs, regardless of which side of the argument they support. If possible, I would like to do it right the first (second?) time. — AfroThundr ^{(u · t · c)} 14:33, 30 September 2018 (UTC)

@AfroThundr3007730: I believe that there are currently over 3000 portals, with a wide variation in scope. It seems to me that any data needed to develop an informed consensus at RFC can be drawn from that existing set.

Do you believe that there are some gaps in that set, gaps which should be filled on a trial basis to allow analysis? --BrownHairedGirl (talk) • (contribs) 14:45, 30 September 2018 (UTC)

The portals that correspond to level 2 vital articles would be a good test pool, possibly level 3 as well. The list is posted on WP:WPPORT#Fill in the gaps and below at #Portal Wish List. I and several others have suggested we migrate portal creation efforts from the more low-level portals to these higher priority ones, working our way down those lists. If these important topics aren't indicative of a good subject for a portal, then I'm not sure what else would be. The Level 2 portals could serve as the "poster child" for the namespace, alongside the top-level and the (historically) featured portals. Once they are all built and linked in place, we could gather better data from site analytics to better gauge reader interaction. This also ties into the #Metrics request I made earlier. — AfroThundr ^{(u · t · c)} 15:24, 30 September 2018 (UTC)

@AfroThundr3007730: I may be looking in the wrong place, but I see a significant number of existing portals at each of those levels. Dozens of them in WP:WikiProject Portals/Vital portals level 2 and dozens in WP:WikiProject Portals/Vital portals level 3.

It seems to me that this set of existing portals is way more than sufficient to get statistically valid data from. Creating more such portals now does not seem to me to be an exercise in building a valid test sample; it looks to me like pre-emption of consenus-building. --BrownHairedGirl (talk) • (contribs) 15:46, 30 September 2018 (UTC)

Re: ABF and the duck test:

People have a tendency to call things as they see them. If a thing looks like a deletion spree it is likely to be called that by someone who is not in possession of the full background. Calling their description an assumption of bad faith does not take into account that they do not have the full picture. It is an error we all make at times, but usually not conducive to civil interaction. I think we here are all trying to build the encyclopedia. It is an evolutionary process as it has not been done this way before. Experiments are not just healthy, they are necessary to allow a robust set of characteristics which can stand up to unexpected external pressures. If there are three optional ways a thing can be done, and for some reason one becomes impracticable, the other two may allow us to survive. Even when all are workable, we cannot predict which may work best after unforeseen changes, and there will always be unforeseen changes. The most dangerous strategy is stagnation. On the other hand unchecked development can sometimes also be detrimental, and needs to be tested against reality. Let us make a virtue of necessity and use this to come up with something that works. · · · Peter (Southwood) ^(talk): 08:54, 28 September 2018 (UTC)

Sidebar #1: Creation vs deletion criteria

"Creation criteria" is potentially synonymous with "deletion criteria". What happens to existing portals that don't meet newly established creation criteria? If the answer is "deletion", then that means the creation criteria discussion is in fact a deletion discussion.    — The Transhumanist   10:15, 27 September 2018 (UTC)

• Since creation is becoming easier, this is not a big deal. Sometimes the post construction checks don't pick up all the problems and a lemon slips through under the radar. We should be glad to have more eyes checking, as if we identify the problems, we can fix them, and recreate the portal another day when the tools are more robust. If a topic really isn't ready for a portal, it is no loss to delete it until it is ready. · · · Peter (Southwood) ^(talk): 13:26, 27 September 2018 (UTC)

(edit conflict)No, deletion would not be automatic, there would still need to be discussion around each case. Yes, a portal that fails to meet whatever criteria we agree would be more likely to be deleted - but the discussion would still need to take place first, unless the portal falls within the remit of WP:P1 or WP:P2, and if there's a good case for making an exception to the new creation guidelines, that would be the place to argue it. WaggersTALK 13:32, 27 September 2018 (UTC)

• (edit conflict) Remember that if it had not been for the RfC for deletion of the whole portal system we would not be here improving portals so effectively, and they might just have fizzled out quietly and unnoticed. That opposition had the effect of revitalising the project. For evolution to work effectively, there must be some standard of fitness to pass or some form of competition. For portals to become robust, a bit of external pressure and selective culling can improve the herd. · · · Peter (Southwood) ^(talk): 13:40, 27 September 2018 (UTC)
• It would also be less likely for portals to be nominated for deletion if we all had a better idea of where the bar is, as we would not create them unless fairly sure they would make it. · · · Peter (Southwood) ^(talk): 13:46, 27 September 2018 (UTC)

It thrills me to witness such independent thinking on the team. I hadn't thought of the points you all raised. I believe portals are in good hands.    — The Transhumanist   21:26, 27 September 2018 (UTC)

@Pbsouthwood: We have a pretty good sampling of portals right now. I would be interested in your take on the current set of portals. Which ones pass muster in their current state, and which ones need to be improved to meet acceptability. We can use currently existing portals as examples of what we are talking about in the whole criteria discussion.    — The Transhumanist   21:26, 27 September 2018 (UTC)

Any criteria for what is an appropriate portal will obviously apply both ways. A portal which exceeds the criteria would usually be kept in a deletion discussion, and those which fall below it would usually deleted -- just as happens in AFDs which consider the notability of a topic. In any such debate, there is scope for editorial discretion.

WP:P1 & WP:P2 are criteria for speedy deletion, i.e. without a discussion. Speedy deletion is reserved for extreme cases which clearly fall so far outside community norms that the community gives admins discretion to delete them without discussion. So far, I see no reason to consider changing them.

I advocate some form of pre-creation discussion, at least for a while, because it means that the viability of a portal can be assessed before an editor puts time and effort into creating it. That saves everyone a lot of work until guidelines have stabilised and clarified. The utility of a pre-creation discussion depends in large part on how high the bar is set: if the criteria are almost-anything-goes, then discussion would in most cases be pointless.

If the criteria remain as per the Portal guidelines (now restored to their long-term stable version), or something tighter, then a discussion would be both useful and infrequent. I suggested a "negative process" where creation proceeds unless there is objection, and objections trigger a discussion whih requires a consenus. Therefore an uncontested proposal does not require others to post a "support". --BrownHairedGirl (talk) • (contribs) 01:25, 28 September 2018 (UTC)

@Pbsouthwood, Waggers, and BrownHairedGirl:

Since the restored version sets the criteria at "around 20 articles" (down from 30 as of May 2009), it will do until a new consensus is formed.    — The Transhumanist   19:50, 4 October 2018 (UTC)

Sidebar #2: Restoration of original portal guidelines

I just spotted today that on 23 May 2018, The Transhumanist substantially rewrote WP:PORTAL.[3].

This rewrite replaced a version which had been stable for two years, since the version of 2 . I have restored the stable version, for reasons explained below.

One of the many changes made was to the lede. The stable version read:

Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers

However, TTH's rewrite removed the stipulation of broad scope, and both of those criteria, i.e. readers and maintainers. The edit summary used was simply "update", which is so vague that it is a clear breach of WP:SUMMARYNO. It is wholly inadequate in this case.

TTH's change radically redefined the purpose of an entire en.nwp namespace. That is an extraordinarily big change, which should have been the subject of a well-advertised RFC. However, I have found no evidence even of this change being the subject of a standalone discussion on a community-wide noticeboard, let alone assessed in a properly-conducted RFC.

I am also very disappointed that in our extensive discussions both on this page and elsewhere, at no point has TTH mentioned that they made such a unilateral rewrite. The effect is sneaky and underhand; I cannot judge whether the sneakiness was intentional or a lack of WP:COMPETENCE, but either way it is disgraceful.

I know that TTH has strong views on why they believe that portals should be chosen on a very different basis to the stable community consensus. However, the way to make such a change is to propose it a WP:RFC. I strongly advise TTH not to simply reinstate the unilateral rewrite.

Unless and until such an RFC is opened, the place to discuss the substantive merits of the guidelines is at WT:Portal_guidelines#Current_version_of_the_guidelines. Guidelines such as this belong to the whole community, not to any one WikiProject, so revisions should be discussed centrally rather than on a project's pages.--BrownHairedGirl (talk) • (contribs) 00:43, 28 September 2018 (UTC)

To what seems to me a large extent, TTH's rewrite of the portal guidelines was not incompatible with the actual process at the time, so could be considered descriptive rather than prescriptive. As in other cases mentioned on this page, not being aware of the larger picture may lead to duck calling.

Discussions often happen where they are started. There may be no particular plan behind this. If someone notices that they are in the wrong place the discussion may be moved, otherwise it is likely to stay, and spin off sub-discussions, also in the same place. No special motivations are necessarily involved. Cheers, · · · Peter (Southwood) ^(talk): 09:21, 28 September 2018 (UTC)

@Pbsouthwood: Thank you for your support and assumption of good faith. That means a lot to me.    — The Transhumanist   11:23, 28 September 2018 (UTC)

I call it as I see it. Sometimes there is no duck. · · · Peter (Southwood) ^(talk): 16:44, 28 September 2018 (UTC)

BHG stated above that I radically changed the purpose of an entire namespace. That is both exaggerated and bit melodramatic. Below, I've reposted the response I provided on the guideline's talk page. (The statement we were discussing was "Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers."):

The purpose of the portal namespace was changed long ago, by the very people who have built portals, from the moment that statement was written. Editors build portals on the subjects that interest them (the same as with articles), rather than on the traffic prospects of a subject, and except for the few portals listed on the Main Page, always have. This practice is therefore very well established. (See WP:PGCHANGE).

In addition to this, the lead statement itself is in error, as portals by their very nature do not attract large numbers of interested readers or portal maintainers. That's because portal titles generally do not show up in external searches of their subject names, which is where large numbers of readers to pages come from. That is, "Portal:Fish" doesn't not come up when you search for "Fish". An external search will show a portal if the word "portal" is included in the search term, but googlers don't typically enter that term. Portals primarily receive internal traffic from within Wikipedia itself, via the internal links that readers click on. They always have.

And while "broad" isn't defined in the lead, guidance for the scope of portals is provided further down the page, where it states the number of articles to be included to be "about 20", a guideline that has been in place since May 2009.    — The Transhumanist   18:36, 5 October 2018 (UTC)

Response to BHG's accusations and guideline reversion

Another RfC wasn't needed, because we had just gone through one that established community consensus concerning portals. Its closing statement was "There exists a strong consensus against deleting or even deprecating portals at this time." Based on the outcome of the WP:ENDPORTALS RfC, I updated the guideline page to reflect the community consensus and the current reality of portals.

This approach is in concordance with WP:PGCHANGE and WP:PGBOLD.

WP:PGCHANGE states:

Policies and guidelines can be edited like any other Wikipedia page. It is not strictly necessary to discuss changes or to obtain written documentation of a consensus in advance. However, because policies and guidelines are sensitive and complex, users should take care over any edits, to be sure they are faithfully reflecting the community's view and to be sure that they are not accidentally introducing new sources of error or confusion.

Because Wikipedia practice exists in the community through consensus, editing a policy/guideline/essay page does not in itself imply an immediate change to accepted practice. It is, naturally, bad practice to recommend a rejected practice on a policy or guideline page. To update best practices, you may change the practice directly (you are permitted to deviate from practice for the purposes of such change) and/or set about building widespread consensus for your change or implementation through discussion. When such a change is accepted, you can then edit the page to reflect the new situation.

Concerning substantive changes to a guideline, WP:PGBOLD states:

Or be bold. The older but still valid method is to boldly edit the page. Bold editors of policy and guideline pages are strongly encouraged to follow WP:1RR or WP:0RR standards. Although most editors find advance discussion, especially at well-developed pages, very helpful, directly editing these pages is permitted by Wikipedia's policies. Consequently, you should not remove any change solely on the grounds that there was no formal discussion indicating consensus for the change before it was made. Instead, you should give a substantive reason for challenging it and, if one hasn't already been started, open a discussion to identify the community's current views.

Editing a policy to support your own argument in an active discussion may be seen as gaming the system, especially if you do not disclose your involvement in the argument when making the edits.

The lead of the guideline before I changed it was "Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers. Do not create a portal if you do not intend to assist in its regular maintenance." That was made a part of the guideline on August 3rd, 2006 in this edit https://en.wikipedia.org/w/index.php?title=Wikipedia:Portal_guidelines&diff=prev&oldid=67490184 . Note that broadness wasn't defined, but it was assumed that any portal on a broad subject would attract large numbers. [Editing note, 10-04-2018: I was mistaken about broadness not being defined. Further down the page it set the bar at "about 20 articles", established as of May 02, 2009 in this edit: https://en.wikipedia.org/w/index.php?title=Wikipedia:Portal_guidelines&diff=prev&oldid=287431020]

Except for a small percentage of portals, that guideline has never been followed [editing note, 10-04-2018: many of the portals from the set that existed in April 2018 have fewer than 20 articles included. Portal:Mathematics, a subject of thousands or subtopics, only has 40 articles, and of those displays only a single 1.]. Portals for the most part, do not, and have never attracted particularly large numbers of readers; and at the time of the RFC, all but about 100 of them were completely abandoned. Large numbers of maintainers never materialized; usually a person made a portal on whatever they were interested in, and then never returned. Or they lost interest over time and faded away. The odd assortment of portals exhibited a wide-range of scope.

Yet, the community decided to keep them all. "There exists a strong consensus against deleting or even deprecating portals at this time." Even though many weren't particularly broad, even though they weren't well read, and even though they lacked active maintainers.

So I removed the outdated statement from 2006. It hadn't represented standard practice in many years, and no longer represented community consensus.

The rest of the guideline was also out of date and lacking in detail about portals, which was spread out in haphazzard fashion among multiple pages. I merged relevant material into it from the WikiProject page, and the entirety of Wikipedia:Portal (the main information page on portals). The record of all these edits are in the edit history of the guideline page, so you can see the progression of development. I also revised explanations to reflect the current way portals were designed. The material has been proofread and refined by other portal-savy editors since, and accurately reflects the current state of affairs and practices concerning portals.

Now BHG is being even more bold than I was, has reverted the work of more than one editor, but is grasping at straws, hanging on to the old lead statement as if the RfC never happened. She has violated this part of WP:PGBOLD:

Consequently, you should not remove any change solely on the grounds that there was no formal discussion indicating consensus for the change before it was made. Instead, you should give a substantive reason for challenging it and, if one hasn't already been started, open a discussion to identify the community's current views.

The guideline needs to be restored to the version reflecting the decision of the community in the WP:ENDPORTALS RfC and current practice on portals. Sincerely,    — The Transhumanist   11:39, 28 September 2018 (UTC)

The text is still in the history. Restoration is not urgent. Getting an acceptable compromise by way of a usable set of creation criteria is better use of time at the moment. What we have here may just be a failure to communicate. Lets take a look at common ground for a start. I get the impression that both BHG and TTH are quite deeply involved in navigation of the site. Well, surprise, so am I. We are on the same side, we must have common ground. In a year or two this will be history that few will bother to read, so lets try to get where we are going with the least stick waving. As my cousin used to say, I'm an arsehole, you're an arsehole, now that we have that settled lets get down to work. A bit crude perhaps, but it gets the message across. And no, I am not saying that either of you are arseholes, it is just an illustrative quote, I actually believe that both of you are acting mostly in good faith and sincerely, and can both make productive and valuable contributions here. If you feel the need, vent at me and then lets get to work. Cheers, · · · Peter (Southwood) ^(talk): 17:01, 28 September 2018 (UTC)

Are you sure that is a better use of your time? You've witnessed an editor use intimidation tactics to push an agenda and disrupt the activities of an entire WikiProject, violating WP:AGF, WP:CIVIL, WP:BULLY (WP:POV railroad, False accusations), and Wikipedia:No personal attacks. Are you going to simply let that continue?    — The Transhumanist   20:01, 28 September 2018 (UTC)

Well we can either take that to arbitration which will be lengthy, acrimonious and unlikely to succeed. BrownHairedGirl is an experienced editor and administrator who is very familiar with Wikipedia and may just have a point. It's always important to look for the "critic's kernel of truth" as Bill Hybels would say. Then we can have a dialogue. That there will be a dialogue is certain, because BHG will take this issue to the community for discussion. So we are bound to have to compromise in the end. I would prefer us to reach some sort of consensus without widening (and thus prolonging) the debate further. Even if we have to curtail the number of portals, we still have plenty to do. Bermicourt (talk) 21:02, 28 September 2018 (UTC)

Then I say take it to arbitration. There is no WP:SENIORITY and we are looking for the best ideas, rules, and the best way to make an encyclopedia here. There is no additional merit to any comment just because it comes from an experienced editor. And since it seems there is support toward a specific editor rather than toward the idea the editor has put forward, that to me calls for arbitration. One other thing... not exactly the greatest time to quote anything from Bill Hybles.--Paul McDonald (talk) 14:17, 29 September 2018 (UTC)

Very gun-ho, but that's just seeking a wider confrontation which we don't need. Of course, experienced editors and admins are worth hearing - that's just common sense. And I wondered if you'd fall into the trap of an ad hominem argument over Hybels. We should beware of shooting the messenger, who is just a human being like the rest of us, lol. Or we'll never learn from the experience of others. Bermicourt (talk) 14:48, 29 September 2018 (UTC)

I think you mean gung-ho.--Paul McDonald (talk) 15:02, 29 September 2018 (UTC)

Oh dear. Yet another irate wall of text from @The Transhumanist.

As I noted above, this is not the place for the substantive discussion. That belongs in a community noticeboard, not on a WikiProject page.

So I will restrict my response to noting that TTH wrote Based on the outcome of the WP:ENDPORTALS RfC, I updated the guideline page to reflect the community consensus and the current reality of portals.

Llemme quote in full the outcome of the WP:ENDPORTALS RfC "There exists a strong consensus against deleting or even deprecating portals at this time".

Nowhere in that one sentence does it say that there is a consensus to remove the restriction that "that portals should be about broad subject areas". The consensus was weighed solely as "do not delete them all."

The community was not asked to decide whether to remove any restriction on the scope of portals. So we simply do not know whether consensus has changed from the guideline which was stable for two years.

I note significant support at the RFC for reducing the number of portals. TTH believes there was support for expansion. But neither of us can say that there was a consensus for either change, because the RFC never tested it. (I was one of several editors who expressed regret at the binary nature of the RFC, but we were too late; it was as it was.)

TTH's verbose response consists mostly of arguments for change which should have been proposed at a followup RFC. That second RFC could have asked "now that portals are not all to be deleted, should we delete most/delete some/keep existing ones/create more/massively expand". But instead TTH yet again mistakes TTH's own view for a consensus. This is wearisome: one person's view is not a consensus for change, no matter good they believe their case to be.

I took a break after reverting the guideline, because after all the discussion about the thresholds for portals, I was frankly disgusted that nobody chose to mention that the guideline had been stealthily rewritten by the editor who went on a mass-creation spree. Maybe other editors were unaware of that rewrite, but TTH was aware and should have disclosed it at the MFDs and in the subsequent discussions on this page. So I took a break from this page, because I wanted to let my annoyance pass.

My views on that non-disclosure have been made clear, but that is done now ... and now we have a restored guideline which nobody is happy with (I think it is too loose, others think it is too tight) and which is clearly incompatible with the recent mass creation spree(s).

So the RFC I was proposing earlier now has a clear focus: to build a consensus on whether to retain the current "broad subject areas" guideline, or replace it with something else. I will start drafting tomorrow, and I hope that we will be able to agree on a smallish range of options to put to RFC, to hopefully build an explicit consensus, whatever that consensus may be. --BrownHairedGirl (talk) • (contribs) 00:51, 30 September 2018 (UTC)

BHG, please refrain from personal attacks.--Paul McDonald (talk) 01:10, 30 September 2018 (UTC)

@Paulmcdonald: Please read WP:No_personal_attacks#What_is_considered_to_be_a_personal_attack?, and please refrain from making unfounded allegations of personal attack.
I criticised the conduct of an editor, but I made no personal attack. --BrownHairedGirl (talk) • (contribs) 01:50, 30 September 2018 (UTC)

I see the comment "Yet another irate wall of text from @The Transhumanist" as a personal attack. It added zero value to the discussion and was a negative comment addressed to an individual by name. Let's keep the discussion about the matter at hand and not about individuals in the conversation.--Paul McDonald (talk) 13:28, 30 September 2018 (UTC)

@Paulmcdonald: I would find it easier to believe in your good intent if you had some reproach for the lastest irate wall of text directed me, rather than simply at my reply. --BrownHairedGirl (talk) • (contribs) 14:24, 30 September 2018 (UTC)

Not that this is in any way on topic, but I agree that some of the sidebar comments are unnecessary, not that they are particularly bad or anything. Also, both TTH and BHG tend to write long responses that some would classify as walls of text. Lots of us do. We have a lot to talk about, and this is a multifaceted subject that requires in-depth discussion. To gloss over the nuances would be doing an injustice to the portals we're here to curate, and to the community. So can we all just agree that walls of text are going to happen, and move on? — AfroThundr ^{(u · t · c)} 14:52, 30 September 2018 (UTC)

It might minimise disruption and show good faith all round if we could respect a couple of temporary guidelines until a proper RfC has concluded (or a few months have elapsed with no RfC outcome, let's say end of 2018):

• Only create portals on the most important topics, i.e. those which would be a WP:SNOW "keep" at any hypothetical MfD.
• Only nominate portals at MfD for being "too narrow" if they would be a WP:SNOW "delete". Poor quality portals may still be taken to MfD for other reasons, but it would be better to report them to this WikiProject for clean-up first.

Does that sound reasonable? Certes (talk) 11:23, 30 September 2018 (UTC)

@Certes: I agree that a moratorium is a good idea until a consensus is established (or clarified, depending on you see it).

However, I am wary of relying on editors to judge what might achieve a SNOW close, esp given the widely different understandings shown so far. It seems to me to be better to simply say no creations and no MFDs. --BrownHairedGirl (talk) • (contribs) 13:22, 30 September 2018 (UTC)

I would be fine with a pause on creation for the smaller type of portal until we have solid critera (the RfC). More important topics (re: Vital topics above) should still be ok, since I don't think there's significant argument against those in particular. I don't think we need to freeze an entire namespace until the RfC is done. — AfroThundr ^{(u · t · c)} 14:52, 30 September 2018 (UTC)

I do intend to present an argument for a low threshold. We clearly have different views on the likely response to that position, but what's the rush to create new portals?

TTH has repeatedly shown that a new portal can be created in less than 90 seconds, but an MFD takes way more editorial time than that when the time of each participant is added up.

The urgent task now is to establish a broad consensus. --BrownHairedGirl (talk) • (contribs) 15:36, 30 September 2018 (UTC)

I disagree that any task is "urgent" for as a general rule there is no deadline. I can agree that it is "important" -- I also disagree with the term "establish" consensus, as that implies building it up and can be considered by some to be votestacking. The task at hand really should be to determine the consensus, not to build it.--Paul McDonald (talk) 15:30, 1 October 2018 (UTC)

BHG, my first "wall of text" wasn't disruptive, as you posted, nor was my next one irate as you accused. Those 2 statements of yours were false accusations, and therefore fall under our no personal attack rule. You accused me of acting a certain way, when I wasn't. Please refrain from doing that. Thank you.    — The Transhumanist   17:10, 4 October 2018 (UTC)

@Paulmcdonald, BrownHairedGirl, AfroThundr3007730, Certes, Bermicourt, and Pbsouthwood:

Note that the present guideline, the one that BHG restored, sets a low-end for scope of "about 20 articles." It was changed from "about 30 articles" in May of 2009. BHG has been objecting to portals (via MfD) based on how many articles they display, such as Portal:Body piercing, which displayed 11 articles at the time she nominated it for deletion. Note that the guideline was referring to the pool from which a portal displays selected articles, because the main design up until last April only displayed a single article per selected section -- a portal's pool of excerpts has been stored as subpages, and in a great many cases, never reached 20, and represents the established practice - though the practice has changed for new and upgraded portals since then. Portal:Mathematics, by comparison, still only has a pool of 40 article excerpts, merely double the number mentioned in the guideline, which it displays one-at-a-time. Portal:Body piercing displayed 11-at-a-time, from a pool of 74. Now it displays all 74.

In order to change the "about 20 articles" guideline, will require a new consensus. Until then, we have the "about 20 articles" standard in place.

I hope the clarification helps. Sincerely,    — The Transhumanist   01:55, 5 October 2018 (UTC)

Sidebar #3: Portals approval department proposal (withdrawn)

Long ago, in a talk archive far, far away... We discussed the possibility of a formal (or semi-formal) portals approval process. I'm trucking out that discussion once more, since it was brought up earlier. For posterity, the discussion is posted below.

On random editors starting new Portals

User:The Transhumanist,

you wrote:

@SmokeyJoe and Paulmcdonald: Approval, by whom? As with other departments, such a page would be facilitated by a few regulars, and so bias always sets in. One was set up, sort of, with dismal results. They denied approval to an editor who wanted to create the cannabis portal, so I advised him to create it anyways. The department also turned into a bottleneck and created a hoop-jumping exercise. Many editors decided not to create any portals because of it. I mentioned "sort of", because it was suggestive only. We can't censor Wikipedia, but we can delete material that doesn't follow Wikipedia content policies. Because of the way the department was portrayed, people were under the impression that approval was required, but it wasn't. The only requirement for creating a page on Wikipedia is clicking the "edit" or "create" tab. The same thing applies to draft space and WP:AfC: they're optional. "Wasn't approved" is not a valid argument at the deletion departments. Wikipedia has developed into the wonderful resource that it is, because people are allowed to take the initiative - it is the core defining principal of the Wiki model and what makes it work. We don't wish to dowse the creative spark. Also, you sometimes don't know if something is going to work until you try it. If a portal proves to be inviable, it can be deleted. I like the deletion system, because it has a good cross-section of involved editors. An approval department is more like a hidden cabal (closed forum). Who do you invite to the discussions? With deletions, that's obvious: the creator and major contributors. But, with a page that hasn't been created yet, you don't know who the major contributors would be. The current system works fine. If it ain't broke, don't fix it. — The Transhumanist 22:30, 3 May 2018 (UTC)

Some good important points. The WikiProject Council is not very active, I would call it haphazard. Requiring approval there might just be a net non-positive bottleneck until a random anybody says "yes". Portals would be the same.

"Approval" is probably too strong a word. It begs "approval by who", suggests there is a committee, bureaucracy, yes TT, probably hopeless.

What I generally favour in many things is that a "second pair of eyes" be involved, minimally and sufficiently, in starting up any new little bureaucratic process. This includes RfCs, WikiProjects, Portals. The "second pair of eyes" is not intended to be an explicit supporter or author, but a check of sanity, technicalities. Someone proposes something (or in practice starts something), and then a second experienced Wikipedian in good standing says "yes, go ahead". Disputes, if experienced Wikipedians in good standing disagree, can go through WP:DR, or even MfD if the thing created is completely a bad idea. This would mean that someone like you can give immediate approval to anyone else, but you can't so easily stop a pair of Wikipedians proceeding with an ill-advised bad idea.

An even softer idea would be to write into instructions something like this:

• If you start, or are thinking of starting a new Portal, start a new thread stating this at Wikipedia talk:WikiProject Portals (this page)".
• For WikiProjects: "If you start, or are thinking of starting a new WikiProject, post a note at Wikipedia:WikiProject Council/Proposals".

It would then be up to the watchers of these pages to choose to offer advice.

> "If it ain't broke, don't fix it"?

It is my opinion, having seen them come to MfD for years, that there are plenty of ill-advised WikiProjects and Portals, and their existence adds disrepute to the rest.

--SmokeyJoe (talk) 23:48, 3 May 2018 (UTC)

And that's why we clean them up. The main problem has been an inactive WikiProject. Keep it going strong, and you'll have the editors you need to monitor and maintain the whole system.

I like your idea of reporting new portals. There could be a section for them to be listed on the WikiProject page. That way, their development could be monitored for quality and even joined by editors who wish to make them better. Finding them is a little tricky, but can be done comparing lists using AWB's list compare feature.    — The Transhumanist   00:09, 4 May 2018 (UTC)

I suggest: A list of portals, a sortable table, columns including Portal name, Parent portal (often occurs), date started, first author, current activity level.

"Current activity level"? It would be great if this were auto-reported. What would it measure? Last manual edit? Last auto-whatever? Number of page views in the last 30 days?

--SmokeyJoe (talk) 00:19, 4 May 2018 (UTC)

We tried that. Editors would edit it once, and then that entry would never be updated again. It became horribly out-of-date. And, it was redundant with Portal:Contents/Portals. List tools make it easier to track portals. SearchSuite can list all the base pages, and then you can use AWB to compare with an earlier version to find all the new ones.    — The Transhumanist   01:29, 4 May 2018 (UTC)

That's how I think it should work. Filled in once at the start, some fields auto-updating. --SmokeyJoe (talk) 02:04, 4 May 2018 (UTC)

My memory was fuzzy on this issue, so I went looking around to refresh my recall...

Portals approval department: rejected by the community

SmokeyJoe wrote: I don’t believe that Portals or WikiProjects should be allowed to be created unilaterally, without approval. For WikiProjects, there is an approval process somewhere under Wikipedia:WikiProject Council. I think a Portal creation board should exist. Does it? —SmokeyJoe (talk) 05:34, 29 April 2018 (UTC)

It took me awhile to recall the history on this, for portals. There was an approval department at Wikipedia:Portal/Proposals, but it got rejected by the community at Wikipedia:Miscellany for deletion/Wikipedia:Portal/Proposals, at my request. Some guy created the Portal:Cannabis, while I created the Portal:Thinking, both of which were nominated for deletion; Cannabis for having been previously rejected (see Wikipedia:Miscellany for deletion/Portal:Cannabis), and Thinking for not going through the approval process at all (see Wikipedia:Miscellany for deletion/Portal:Thinking). I was appalled that a page could be deleted before it was even created, so I nominated the process itself for deletion. It was marked "historical" and "rejected by the community".    — The Transhumanist   01:29, 4 May 2018 (UTC)

"I don’t believe that Portals or WikiProjects should be allowed to be created unilaterally, without approval." Backing back a but from that. Reporting would be OK. --SmokeyJoe (talk) 02:04, 4 May 2018 (UTC)

I agree. Keeping track of what portals we have, so we can look at them, would be good.    — The Transhumanist   02:47, 4 May 2018 (UTC)

On German Wiki, unless a portal topic falls under the various categories of 'relevance' (see for a translation), the creator has to garner support first. I think they have to have 3 'overseers' (i.e. maintainers) and a majority of 10 'supporters' on the approvals page i.e. 12 'support' votes and 2 'oppose' votes gets it through the process but 12 and 3 fails. I'm not saying we should clone that, but it's a less formal approach than a 'Portal Creation Board' and more in line with other Wiki processes and we might want to think about something similar. Otherwise we'll have portals for everything and it's already a challenge to manage them all. Bermicourt (talk) 14:44, 4 May 2018 (UTC)

If we can make them automatically dynamically self-updating, it won't take many editors to maintain them.    — The Transhumanist   04:34, 6 May 2018 (UTC)

For those interested on this discussion, I also initiated a related discussion here. In my opinion we need some minimum relevance/notability criteria or approval process. A portal on a narrow topic (like an individual person, or a specific video game, or a specific movie) - where the main article itself is not yet a featured aricle - should be discouraged and the editors should be encouraged to focus on improving the core article first. Arman ^(Talk) 10:35, 6 May 2018 (UTC)

I think creating a set of guidelines would be good. For example, a portal should be about a broad enough topic to have at least 50 (or maybe 100) or so articles that could be included in the portal. If it doesn't have that many, it's not really worth the effort to create the portal as just visiting the main topic would likely give you enough information and/or links to relevant related articles.

I reject any notion of requiring approval to create one. That's just a layer of bureaucracy. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 20:23, 18 May 2018 (UTC)

I agree with the idea of guidelines and translated German Wiki's guidelines to see what they said. They've kept a lid on portals by requiring evidence that the portal will be maintained (which it will need if it's more than a showcase page and is being used e.g. to support WikiProjects) and strong support from around a dozen editors. So it's not an approval committee, but does reduce the likelihood of someone creating a half-finished portal on a non-notable topic area, which seems to have happened on English Wikipedia. Bermicourt (talk) 21:14, 18 May 2018 (UTC)

So what do you guys think? I see some merit to an informal approval process where more than one editor must agree that the portal should be created, but I don't think we should go as far as the rigorous approval process employed by the German Wikipedia. — AfroThundr ^{(u · t · c)} 03:28, 27 September 2018 (UTC)

• I am open-minded about what sort of pre-approval is best. German-style bureaucracy rarely works well on en.wp, so something lightweight is best. I suggest a negative process, (like with PRODs or speedy deletion or WP:CFD/S) where approval is assumed unless contested. If the project has agreed on criteria for new portals, then it should be simple to create a DYK-style template in which the proposer assesses their own idea against the criteria, and others can chime in if they see a problem.

But something is needed to deter the sort of portal-spam we saw in the @The Transhumanist's recent drive-by spree of >400 new portals in only 12 days. That expanded the total number of portal count by ~20% and in many cases with only about 90 seconds time between them.

If this project is actually about enhancing navigation rather than creating pages for their own sake, then it needs at the very least to put an abrupt halt to such antics. --BrownHairedGirl (talk) • (contribs) 04:32, 27 September 2018 (UTC)

• Oppose – Creation approval = bad idea. Quality control is handled via deletion. If a portal doesn't meet muster, then it is subject to deletion. To have another level of bureaucracy is plain wasteful and inefficient. But it really means that a portal you plan to create can be deleted (prevented) before you even create it. That is, before it ever has a chance to get reader feedback. So no, I'm not in favor of any approval process because it is really an additional deletion process in disguise. Let our deletion systems do what they were designed for: cull the bad after giving them a chance to be good. In essence, approval processes are a form of censorship. We don't really want portals blocked via contest. If all someone has to do is contest a portal creation request to block it, they've managed to delete the portal before it ever exists. That's almost as bad as time travel, where someone could go back in time and erase you, from history.    — The Transhumanist   08:41, 27 September 2018 (UTC)
  • @The Transhumanist: I don't believe this would become an issue in the majority of cases, especially once we have consensus on what the criteria are. Anyone who has an anti-portal stance would not be able to block legitimate portal creation in that case. As we all know Wikipedia is not censored, and any attempts to manipulate policy or other community mechanisms to cause that effect can (and would) be dealt with by the community. Also, as you've mentioned elsewhere, creation and deletion stem from the same criteria. It's the same with articles - if they don't meet the minimum criteria, they could be deleted, or moved to draft space, and if they were created as a draft, they wouldn't graduate until the concerns were met. Perhaps we should have a Portal:Draft where we can build new portals without threat of immediate deletion. Once they are fully built and ready, they can be moved to become a top-level portal. Portals under the draft portal would behave like draft articles do, namely they are "under construction" and are expected to improve before being subject to significant scrutiny. Also see my other responses below. — AfroThundr ^{(u · t · c)} 14:45, 30 September 2018 (UTC)
• Comment – BHG appears to have a problem with portals in general (she suggested a limit above to allow level 1 portals only), and appears to be attempting to limit portals by any means she can, including before they are even created, by mere contest. The portals she has pointed out at MfD as problems look unlikely to be deleted. If there is a problem with the contents of any of the portals I have created, show us. One of two things will happen: either they will be fixed, or they will be deleted. But, the main issue that BHG has focused on is scope, which also pertains to blocking portals from being created in the first place. Don't fall for it. It's another form of deletion of portals before they even exist. It's an approval process put in place in the form of a filter. Be careful what you wish for.    — The Transhumanist   08:41, 27 September 2018 (UTC)
• Oppose having a creation approval process is a bad idea. The main reason I think it is a bad idea is by looking back at history. This WikiProject went inactive and so did the featured portal process. This is one of the reasons why portals, in general, became outdated. Having a process to create portals allows the possibility for the process to become inactive and so no new portals would be created and would also lead to the portal namespace becoming more outdated as new topics are not accounted for by their own portal. Dreamy Jazz 🎷 ^{talk to me | my contributions} 11:35, 27 September 2018 (UTC)
  • @The Transhumanist: The deletion process serves as the counterpoint to the creation, yes, but if for instance, 10% of the recent portals created end up at MfD with 5% actually getting deleted, that may be a sign that we could improve on that. Also Dreamy Jazz, I'm pretty sure nobody here wants the full "approval department" scenario. I'm more suggesting the informal method of announcing the portal beforehand. BrownHairedGirl's negative process is a decent one. Instead of waiting for X more editors to agree on the creation, if there is no objection after a day, it gets created. If someone objects, we go through the whole discussion. I see the latter case being a minimal occurrence. I would also add that the process, being informal, would not be required, but suggested, like AfC is. If you're sure your portal is the bees knees and everyone will love it, they can go right ahead with creation. This is intended to provide an optional venue through which others who aren't as certain (or are certain, but have a problematic creation track record) can get a second opinion. — AfroThundr ^{(u · t · c)} 01:27, 28 September 2018 (UTC)
• Oppose - A portal is akin to an article in this regard to me; any autoconfirmed editor should have the ability to create one. — Godsy ^(TALK_CONT) 05:40, 28 September 2018 (UTC)
  • @Godsy: AFAICT, this would not prevent editors from creating portals directly, as it would not be mandatory. Perhaps I should've explained that better. Nothing technically prevents editors from creating a portal directly, just like nothing prevents them from bypassing AfC entirely. This would be for cases where the success of the portal-to-be is not certain. — AfroThundr ^{(u · t · c)} 14:25, 30 September 2018 (UTC)
    • @AfroThundr3007730 and Godsy: I think we differ here. I don't see much point in an optional pre-creation process, because the most prolific portal-creator is also the most averse to restrictions in scope or to pre-approvals. So an optional process would have negligible effect on the flow. It would be like placing a roadblock on a back road while the parallel 10-lane highway was unmonitored. --BrownHairedGirl (talk) • (contribs) 14:51, 30 September 2018 (UTC)
      • And if the outcome of the RfC restricts portals to, say, +500 articles (disqualifying many of the recently created portals), everyone would have to respect the new consensus. I don't believe anyone here would blatantly disregard the community decision once it has been clearly defined. There are processes for that scenario already in place, should it occur. I'll keep using AfC as an example, but if an editor has a track-record of failed articles, they could be required to use the curated creation and submission process developed by the community, via sanctions. This also goes the other way, should the community decide that small-scale portals are fine. — AfroThundr ^{(u · t · c)} 15:08, 30 September 2018 (UTC)
        • I wish I could share your optimism. But given what I have seen already of TTH's prolonged outrage that anyone might not share their view, I think much drama would be avoided simply by making the pre-scrutiny phase universal. It would save the drama of multiple MFDs. And I really don't see any point in a pre-approval process if the most prolific operator can simply ignore it. --BrownHairedGirl (talk) • (contribs) 15:28, 30 September 2018 (UTC)
          • This only really an issue because the guidelines do not reflect the current state of affairs (and won't until the RfC is done). Everyone has a different interpretation of them in their current state, in conjunction with the (inconclusive) previous RfC closure. As I've mentioned before, I don't believe anyone here would ignore the guidelines, once they have been clearly defined by community consensus. If new portals created after the RfC and revised guidelines continue to fall short of the minimum criteria, they would be MfD'd like usual, and for editors with continuously problematic submissions, there's WP:RESTRICTIONS for that. As I've said, there are already processes in place for this. — AfroThundr ^{(u · t · c)} 15:41, 30 September 2018 (UTC)
            • @AfroThundr3007730: Sorry, but I have a very different experience and assessment of the modus operandi of the most prolific portal creator, and of heir ability to interpret consensus. Either we are going to have a pre-creation scrutiny process which includes that editor, or it's pointless. --BrownHairedGirl (talk) • (contribs) 15:52, 30 September 2018 (UTC)
• Oppose – More unnecessary bureaucracy and red tape. The deletion process can be used to address portals that are significantly deficient. North America¹⁰⁰⁰ 22:51, 5 October 2018 (UTC)

We should attempt to find a consensus on the above in order to draft modernized portal guidelines, along with an RfC that will survive WP:VP scrutiny. Perhaps now that the discussion has cooled for a month, we can now revisit this and make some decent progress toward that goal. — AfroThundr ^{(u · t · c)} 17:19, 5 November 2018 (UTC)

Discussion (continued)

@The Transhumanist, Evad37, Certes, Dreamy Jazz, Pbsouthwood, SMcCandlish, FR30799386, BrownHairedGirl, Godsy, Finnusertop, Cactus.man, BrendonTheWizard, Bermicourt, Paulmcdonald, and Northamerica1000: I know you guys are probably tired of this by now, but if we don't find a solid consensus, this will just rear it's ugly head again later. — AfroThundr ^{(u · t · c)} 17:33, 5 November 2018 (UTC)

The appropriate venue for discussions about the portal guidelines is Wikipedia talk:Portal guidelines. And, to avoid the chaos that occurred in the above discussion in order to keep things simple, issues should be addressed there one-at-a-time, one per thread. See you there.    — The Transhumanist   18:14, 5 November 2018 (UTC)

I am quite happy to consider and discuss polite, positive suggestions that are on topic. I agree with AfroThundr that this should be settled if possible. Does anyone have a reasonable proposal to start from? Maybe someone who does not represent either extreme of the dispute? · · · Peter (Southwood) ^(talk): 07:22, 6 November 2018 (UTC)

@Pbsouthwood and AfroThundr3007730: I think the scope (notability) threshold in place currently is fine (see Wikipedia:Portal guidelines#Article selection), and that there is no compelling reason to seek a new consensus to change it. However, the guideline itself is woefully out of date and needs to be updated. See the thread below to make a start on that.    — The Transhumanist   05:04, 7 November 2018 (UTC)

I think there are some points that should be clarified, such as which items the number of 20 refers to. Is it each or a sum, and if a sum, which parts apply. · · · Peter (Southwood) ^(talk): 06:35, 7 November 2018 (UTC)

"About 20". As written, it applies to each such section, but, as most portals have a single selected articles section, this figure essentially equates to the minimum number of articles a portal is recommended to be populated with (its a guideline). Keep in mind that this number has not been observed as a minimum in practice, as a great number of portals utilizing subpages present far fewer than 20 articles. The defacto minimum has been "1". Click on https://en.wikipedia.org/wiki/Special:AllPages?from=1&to=&namespace=100 to inspect how many selected article subpages the various portals have. You will find that a large proportion of the original portals have just a handful or less.    — The Transhumanist   10:33, 7 November 2018 (UTC)

This discussion is continued in the #Concerning section: Article selection thread, below. Please post new comments there.    — The Transhumanist   10:42, 7 November 2018 (UTC)

As a side note, I may not chime in on all of the below discussions, but I am still watching them develop. — AfroThundr ^{(u · t · c)} 17:31, 7 November 2018 (UTC)

Concerning the inclusion of "Related portals" section

I have boldly removed a requirement for an item which does not have to exist. It was reasonable when the header was "strongly recommended", but that was changed to "required", and subportals and related portals cannot be required as they are external to the portal. If anyone disagrees, feel free to revert with motivation. · · · Peter (Southwood) ^(talk): 05:30, 7 November 2018 (UTC)

I agree with your moving of the related portals feature to Wikipedia:Portal_guidelines#Recommended. We don't have any way currently to automate the maintenance of related portals sections, and so those should definitely not be required, as they would naturally grow stale and out-of-date and detract from portal quality as a whole.    — The Transhumanist   06:03, 7 November 2018 (UTC)

Not having the tools is not necessarily a valid argument, just a convenient one. However, the existance of a portal should not be conditional on the existence of other portals - a chicken and egg situation. We can, and probably should, look into the possibility of automating related portal links, possibly through an extension of navbox content. (just brainstorming here as navboxes are so convenient). · · · Peter (Southwood) ^(talk): 06:42, 7 November 2018 (UTC)

On another note, there are plenty of other pathways to portals, that they don't necessarily need a system of interconnections between them. Drawing traffic from outside the portal system is what we should be focusing on: the placement of links to each portal.    — The Transhumanist   06:50, 7 November 2018 (UTC)

Agreed. Subportals are more useful to link than other related portals, as they cover subsets of the topic when the topic is too big for a monolithic portal. · · · Peter (Southwood) ^(talk): 07:22, 7 November 2018 (UTC)

I disagree with this change. Our primary aim is to have quality portals, not automated portals. Automation may help with quality to certain extent, but we're not going to sacrifice the rest because it can't be automated. Related portals has been a required item for more than a decade so that's where the consensus is at. The automation phase in contrast is fairly new and it shouldn't be allowed to rewrite the rules just because the computer says no. – Finnusertop (talk ⋅ contribs) 12:32, 9 December 2018 (UTC)

I agree with Finnusertop - let's not get so enthusiastic about the automation process that we discard useful features - related portals are useful, and we shouldn't be discarding them because they can't be automated (yet). Simon Burchell (talk) 13:28, 10 December 2018 (UTC)

I agree with Finnusertop. Just because the Computer says no (at the moment), shouldn't mean we remove the requirement. Manual addition should be easy with looking at Portal:Portals. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:41, 10 December 2018 (UTC)

@Finnusertop, Simon Burchell, and Dreamy Jazz:. I would like to point out that the text before my change 'required' links to subportals or related portals. It is quite obvious that some portals will not have sub-portals, so it would be unreasonable to require links to them. The consequence of requiring links to subportals would be that all portals without subportals would be eligible for deletion. Once deleted, the portals for which they were the only subportals would also be eligible for deletion. Apply recursively and there will be no portals at all.

The situation with related portals is less dire. It is possible that for almost any portal, another portal can be found, or if necessary, created, which could be considered a related portal. However, how does one decide which portals are related to any given portal? Without some guidance this is likely to lead to endless squabbling over technicalities, as this could be used as a tool to attempt to delete portals on the grounds that there are no sufficiently related portals and it is a requirement that such portals exist so they can be linked.

Also, who would be responsible for finding at least one sufficiently related portal and linking to it? Logically, as a requirement, this would be the portal creator.

If I remember correctly the original guidance was strongly recommended, and was changed to required recently, I am less concerned with history than with getting a workable guidance document, but if anyone wants to track down who did what and when, go ahead. If we want to rely on a previous consensus, we should be clear on what it actually was, and that it is still relevant. It might also be relevant to check through the old style portals to find out if this "requirement" was universally complied with. If not, it is indicative that the claimed previous consensus was not strictly applied as a requirement, and would be more appropriate as a recommendation.

I put it to those who wish to retain the previous wording that they could help by defining a related portal so we can see if it is reasonably practicable to require the presence of a link to one or more in every portal. · · · Peter (Southwood) ^(talk): 05:49, 11 December 2018 (UTC)

On reflection, I agree with Pbsouthwood in that portals may not always have related portals and that making this required might just be used as a way to delete portals, which meet all the other requirements. I think, however, the related portals section should still be encouraged or required when there are portals which would be appropriate to link to. This could be a bit of a grey area, so what I mean by appropriate links are portals which have shared content, such as articles. The amount of articles/content needed to make a link could be a grey area. I would suggest something like 3, but some portals which warrant a link may only have 1 article shared between them (e.g. Portal:Northumberland and Portal:Morpeth, Northumberland are only connected by the Morpeth, Northumberland article, but Morpeth is the county town and market town of Northumberland), so I would suggest that the amount of shared articles be a recommended minimum of 3, but editors can use their own discretion with the amount links needed (within reason). Furthermore, I would suggest an absolute minimum of 1 article/piece of content to connect the portals to prevent editors spamming links to a portal which has no connection; If a connection exists, but no articles/content link the portals currently, it should be created first. Dreamy Jazz 🎷 ^{talk to me | my contributions} 10:06, 11 December 2018 (UTC)

I would argue that a sub-portal relationship is a clear indication of related portals - both ways. So Portal:Northumberland and Portal:Morpeth, Northumberland would be clearly related in that one topic is part of the other. In this case the main point of having Portal:Northumberland and Portal:Morpeth, Northumberland is so that there is less need for overlapping content. One common article (Morpeth, Northumberland) could quite easily be both necessary and sufficient in such a case. The grey areas are the tricky ones. For example, Portal:Underwater diving has related portal links to Portal:Medicine, Portal:Technology, Portal:Water sports, Portal:Physics, Portal:Occupational safety and health and Portal:Marine life. I can probably think of a dozen more possibilities without straining myself, but where do I stop? Am I going too far? Is marine life really relevant? What about physiology, archaeology, law, employment, education, petroleum extraction, construction, welding? Some of these are getting really tenuous, but the connections exist. Conversely, the first portal had no related portals at all, and the second portal could have been in a rather different topic area, making two unrelated portals. We now have a lot of portals, but to be sure of having related portals to link in all cases it may be necessary to create even more. Depends on how closely related they should be. This is a bit of a minefield in my opinion. Making them optional but recommended seems more prudent. The other way of looking at it is that Portal:Contents is related to every portal in Wikipedia, making the requirement somewhat trivial. Cheers, · · · Peter (Southwood) ^(talk): 10:57, 11 December 2018 (UTC)

Another good reason to think about what makes portals related, it that it is the first step towards automating the inclusion of related portal links. If that is possible. · · · Peter (Southwood) ^(talk): 11:17, 11 December 2018 (UTC)

It seems that the best idea is that it should be left to editor discretion on what a portal is linked to. I think common sense with some discussions here and there are better than trying to think up of criteria for linking a portal. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:09, 11 December 2018 (UTC)

Some guidance would be useful, but it should be flexible enough to deal with unexpected cases. · · · Peter (Southwood) ^(talk): 12:15, 11 December 2018 (UTC)

@Pbsouthwood: Do you have any ideas? I am out of ideas. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:27, 11 December 2018 (UTC)

Dreamy Jazz, As I mention somewhere else, I think that subportals one level down and superportals (for want of a better term) one level up should be linked where known (it is not always obvious). Other related portals are to some extent the opinion of the reader, like the list I mentioned above. I think in those cases just BRD, on a similar principle to including an article in the scope of a WikiProject. If someone can provide a reasonable rationale, then allow the link. I guess it would be possible to go too far, anything that is possible will probably happen some time, but I don't expect it to happen much. Who knows? Like everything else on Wikipedia, things can change, and the creator of a portal should be expected to do due diligence, not an exhaustive analysis, so if they leave something non-obvious out, not to get too excited about it. Question becomes how much diligence is due? Just brainstorming, so if something I mention looks daft, let me know. · · · Peter (Southwood) ^(talk): 14:01, 12 December 2018 (UTC)

Also maybe Finnusertop has some ideas? · · · Peter (Southwood) ^(talk): 14:05, 12 December 2018 (UTC)

I don't think it's difficult to locate related portals. Even back in the old manually compiled portals system, portals had loads of related portals linked. That should be even easier now when we have so much more portals. Related portals are immensely helpful for readers. That way the Portal namespace becomes an entire navigable web of portals instead of just links you stumble upon on random articles. It's simply a question of who will add them. In the old days it was the person who created the portal, since it's only reasonable to include required items when creating one (and they were required already a decade years ago, I checked; "strongly recommended" was a short-lived verbiage that was quickly reverted; it's needless to say that "if there are any" means what it says and it's not an absolute requirement). The downside of the automation phase is that no one is expected to maintain portals, so this task has been relegated to the proverbial someone else. I think we need to combine the best aspects of automation and manual maintenance to really make portals useful. – Finnusertop (talk ⋅ contribs) 17:27, 12 December 2018 (UTC)

Finnusertop, Good point about the "someone else", but how do we encourage portal creators to do the job properly and not pass the buck, while taking into account that we are all volunteers?

I guess deciding which portals are sufficiently related is a BRD and talk page discussion item, as it is unlikely that any simple rule will cover all cases. · · · Peter (Southwood) ^(talk): 17:28, 26 December 2018 (UTC)

@Pbsouthwood, Finnusertop, and The Transhumanist: Just thought of a way to automate this section. We could convert the portal contents page to a lua module in a similar way to Module:Portal does it, but split the data based on the categories that already exist on the portal contents page. Then the module data could be used by some other module to determine related portals, using parameters provided to the template/module or based on the name of the portal (how we determine what is related needs discussion). The advantages of this are:

• This would automate and keep updated the related portals section (so would eliminate redlinked portals being kept in the section and allow more relevant portals to be shown later down the line)
• Portals added to the module would only be completed and working portals, because the contents page only contains completed and working portals
• The contents page would potentially easier to maintain (only needing to add or remove one line of lua code, instead of working out how the slightly complicated structure of the contents page works and then adding/removing a portal)
• Could ensure that redlinked portals never show on the contents page (however, this may be expensive, as the current way to do this is a expensive lua function)

However:

• Certain customisations of the portal contents page may be difficult or impracticable to implement (although from what I can see from the portal contents page the page seems very uniform)
• Mistakes in the lua code would cause problems for the entire contents page and related portal sections, so some level of protection, possibly advanced levels (such as template editor), would be needed to ensure that mistakes in lua code are rare or non-existent. (I do know that by submitting an edit on a lua module the code is checked for syntax errors, but the errors I am referring to are those which wouldn't be caught such as removing data/functions which could remove portals from the contents page/break the page and cause problems with an automated related portals section).

Of course, such a module would add to the total lua time / lua memory for a given page, but for most portals the time for lua execution is 1.773 seconds (taken Portal:Northumberland as the example here) out of a possible 10 seconds and a small increase in this time won't matter much. What are your thoughts? Dreamy Jazz 🎷 ^{talk to me | my contributions} 19:27, 26 December 2018 (UTC)

@Dreamy Jazz: I just noticed your comment. This is a cool idea. It would require extensive testing and probably benchmarking and a pilot before implementation though, to ensure it's well polished. We could gauge how it will perform on a random selection of portals, then tweak as necessary. This is likely the only sane solution to handle organization for the portal namespace moving forward, since the numbers aren't going to shrink. — AfroThundr ^{(u · t · c)} 20:26, 11 January 2019 (UTC)

Concerning section: Required

1. I suggest adding as a requirement the following item:

• Links to the portal:
  1. From the category of the same name or whatever are the root categories in the Category box section.
  2. From the root article.
  3. From the articles in the selected article list.

Without these links the portal is functionally invisible and does not serve a useful purpose. · · · Peter (Southwood) ^(talk): 15:36, 7 November 2018 (UTC)

Discussion: linking criteria

Yes, those should indeed be the minimums, and we have a backlog of portals that don't meet those requirements already. — AfroThundr ^{(u · t · c)} 17:33, 7 November 2018 (UTC)

It would be good PR to get that backlog sorted out before any more bulk creation. (not restricting experimental work) · · · Peter (Southwood) ^(talk): 19:02, 7 November 2018 (UTC)

I would support this change. Dreamy Jazz 🎷 ^{talk to me | my contributions} 23:28, 28 November 2018 (UTC)

@Pbsouthwood, AfroThundr3007730, and Dreamy Jazz: I suggest #3 be changed to "From the corresponding navigation template(s)."    — The Transhumanist   10:07, 26 December 2018 (UTC)

Or add it as #4 (or bumped to #3, as more relevant, with the above #3 being an optional #4). — AfroThundr ^{(u · t · c)} 13:06, 26 December 2018 (UTC)

Portal link from navbox works when there is a navbox to work from, probably as one portal per navbox where the navbox and the portal have a near identical name. Do articles without navboxes get no portal links? Accepted that the new model portals are based on navboxes, so this would generally not be a problem in those cases. There may be some overall gain in binding navboxes and portals in lockstep, but are there any problems this would cause?
AfroThundr's option above allows for flexibility. · · · Peter (Southwood) ^(talk): 18:08, 26 December 2018 (UTC)

Requiring links that are not part of the page itself? Lacking requirements has historically been a criterion for deletion. But, being an orphan isn't a valid reason for nominating a page for deletion. So, it is unclear what is meant by "required" here.    — The Transhumanist   11:31, 9 January 2019 (UTC)

An orphan portal is a totally useless thing, therefore it is incomplete. The target audience will not know it is there, and it will be ammunition for anti-portalists to attack this project. I think it should be a valid criterion for deletion, and until there is a bot that will do a reliable linking job, the only person that could reasonably be obliged to provide the links is the creator. Until someone comes up with either a bot to do the work, or a compelling explanation of the usefulness of an orphaned portal, I would consider being orphaned a fair reason to delete. I would also prefer not to see panic mode deorphaning from a long list of portals for deletion, as this is evidence of lack of due diligence.
A link from the "below" matter in the navbox provides sufficient linkage to cover this problem, and I would like it to be a requirement where a navbox is used to structure the portal. How it should be done for other portal structures can be left to the creator, but orphans should not be considered to be finished portals. Additional links from wherever they may be useful can be optional. There may be places where links are not appropriate, and other places where they are. Recommendations are fine for them, but there must be at least one as absolute minimum, and only one is not really acceptable either. If someone wants to create a portal they must make it useful, which includes incoming links. As mentioned before, I do not consider it important whether this is done manually, as part of the automation system for portal creation, or soon afterwards by bot, and I can see a place for all of these methods.

Being an orphan is not a valid reason for deleting an article in mainspace, for good reasons, I am not aware that this applies to all other orphaned pages regardless of namespace. · · · Peter Southwood ^(talk): 05:13, 10 January 2019 (UTC)

Pbsouthwood, although links may not be on wiki, search engines may have still indexed the page, so deletion of such a orphaned portal could disrupt these external links. I agree that portals which are not linked are pretty much useless and that links should be added as a priority. I think this problem should be fixed in part by the bot, although navigation templates would be harder to deal with. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:40, 10 January 2019 (UTC)

@Pbsouthwood and Dreamy Jazz: I think a tweak to the wording to "require at least one of ..." the criteria would strike the proper balance between WP:NOTCOMPULSORY and WP:ORPHAN concerns. That said, if the bot's patrolling game is on point, we'll have full visibility into orphaned portals shortly after they're created, so they wouldn't languish away in that state for very long. — AfroThundr ^{(u · t · c)} 23:39, 10 January 2019 (UTC)

@The Transhumanist: What do you think of this? Dreamy Jazz 🎷 ^{talk to me | my contributions} 09:18, 11 January 2019 (UTC)

2. We should probably add to this set a link from Portal:Contents/Portals.· · · Peter (Southwood) ^(talk): 19:07, 7 November 2018 (UTC)

Second that as well. — AfroThundr ^{(u · t · c)} 00:29, 8 November 2018 (UTC)

I would support this change. Dreamy Jazz 🎷 ^{talk to me | my contributions} 23:28, 28 November 2018 (UTC)

Takes longer to place that link than it does to create the portal. We need to find another solution.    — The Transhumanist   11:31, 9 January 2019 (UTC)

Portal:Contents is a real pig to edit. It is not too bad if you know where the new portal belongs in an exising hierarchy, but if you don't, it is beyond the skills of a regular editor. There are topics which will not fit into its excessively rigid structure, and topics which will fit into more than one place, and we cannot penalise editors for that defect. However, there really should be a link to every portal from it, or it becomes unreliable and loses its usefulness. There is no obvious way that a bot could do this, as it is unlikely to be able to work out where the topic belongs. Who will do this? · · · Peter Southwood ^(talk): 05:13, 10 January 2019 (UTC)

Pbsouthwood, I don't think it would be able to be done by a bot as you say above. However, my bot could check the wikilinks on the page against every portal, creating a list of portals which are not listed on the contents page automatically. This would be an improvement, but there would need to be editors interested in updating the portal contents page. I am at a stump what could be done here. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:46, 10 January 2019 (UTC)

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

---

Poll on this change: linking criteria

Just because this is probably controversial, I think it might be worth to have a support/oppose discussion on this. I propose that from above we make it a requirement (strongly) recommended that there is a link to the portal from:

1. From the category of the same name or whatever are the root categories in the Category box section.
2. From the root article.
3. From the articles in the selected article list.
4. Portal:Contents/Portals

I propose that, except from the Contents page, this should be automated and also that, except from the Contents page, the links to the portal should be added as soon as the portal is created. I would say that the portal needs to be complete before adding to the Contents page (like it is currently).

Rewritten on the comments by other editors below:

Create a new section called "Linking to portals" as per The Transhumanist. In this section I suggest it says:

To optimize access to portals, each portal should have the following links leading to them:

1. From the root article of the portal
2. From the category of the same name or whatever are the root categories in the Category box section.
3. From the corresponding navigation template(s)

When a portal is complete the portal should be added to Portal:Contents/Portals. Consider adding links to the portal from the selected articles.

Please indicate your oppose/support. Dreamy Jazz 🎷 ^{talk to me | my contributions} 09:56, 9 January 2019 (UTC)

pinging @Pbsouthwood, AfroThundr3007730, and The Transhumanist: as they have contributed above and/or in the discussion about the bot that would add some of these links (all except Contents page for now). Dreamy Jazz 🎷 ^{talk to me | my contributions} 09:56, 9 January 2019 (UTC)

Pinging again as changed section title to not clash with "Poll on this change" above: @Pbsouthwood, AfroThundr3007730, and The Transhumanist: Dreamy Jazz 🎷 ^{talk to me | my contributions} 09:58, 9 January 2019 (UTC)

Please see the updated wording @Pbsouthwood, The Transhumanist, Certes, and AfroThundr3007730: Thanks for your input, Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:34, 9 January 2019 (UTC)

• Support on all items listed in principle, contingent on clarification. · · · Peter Southwood ^(talk): 10:19, 9 January 2019 (UTC)
  • How does the selected items list differ from the articles listed in the navbox for the new model portals?
  • How compulsory would these requirements be?
  • Who would be responsible for ensuring that they exist? Would they be part of the requirements for portal creation, and how does one deal with amendments to the navbox, which could happen any time as new articles are added, old ones are split, merged or are found to be out of scope for any reason? If they are required, would their absence be cause for deletion?
  • If the intention is to do this by bot (would solve a lot of problems, and answer or make some of the questions irrelevant) what would happen with old model portals? · · · Peter Southwood ^(talk): 10:19, 9 January 2019 (UTC)
    • Pbsouthwood mentioned "compulsory", an astute observation. Remember the WP:NOTCOMPULSORY policy. You can't force editors to do more than they are willing to. So, you can't say, "You can't work on this page unless you are willing to edit these other pages too." Wikipedia doesn't work that way.    — The Transhumanist   11:41, 9 January 2019 (UTC)
      • @The Transhumanist: I agree that I don't want this to violate WP:NOTCOMPULSORY and would not want this to turn into the same problem as the poll above fixed, however, I feel that the links to the portal should be added wherever possible. Perhaps the text can say something like

Although portals need these links, this is not a justification for deletion, userfying or redirection, nor is this compulsory for you to do this. A bot will add the links if you don't.

The reason I would want this to be "required" is that if it is not then opens up to an editor to decide whether they want to link the portal without reaching a consensus for this. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:04, 9 January 2019 (UTC)

"Required" doesn't fit well, because it has other connotations. I think the concept we are discussing here is what links to portals should be allowed. There has been some opposition to portal links being placed all over the place, including on pages where they are presumed as off-topic. In solving that issue, we should probably avoid the use of the word "required". — Preceding unsigned comment added by The Transhumanist (talk • contribs)

In answer to Pbsouthwood:

1. I don't think there is a difference. On old-style portals the articles are still in a list of selected articles, so therefore there is a "selected articles list" and in new-style portals they it is navboxes.
2. I have updated the nom to strike required and instead put "strongly recommended" due to the comments by The Transhumanist below.
3. As above, I have updated the nom and would also want to include that portals cannot be deleted/userfyied/redirected just because they are orphans. I think that the editor creating the portal should be encouraged to place the links, but this bot should take care of the cases when the editor did not place the links.
4. Old-style portals seem to be mostly manually maintained now (but not all), so would probably already have links from relevant articles. Because I have changed the the nom to "(strongly) recommmended" I think that these old-style portals won't be affected at all, except that editors may start linking the portal from more articles (hardly a bad thing). I think a bot would check the lead article to see if it has a link and the category, but not the selected article list (unless it was automated) because there is a bit of variation in how the manual article list is structured. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:19, 9 January 2019 (UTC)

• Oppose use of the word "Required" for this – "Required" refers to features a portal must have in order not to be deleted. But, being an orphan isn't a valid reason for nominating a page for deletion. So, referring to links on other pages would be out of context in the "Required" section. And due to WP:NOTCOMPULSORY, we can ask editors to please add links to the portals they create, but we can't require them to do it, nor can we punish them for not doing it.    — The Transhumanist   11:59, 9 January 2019 (UTC)

The Transhumanist, I have updated the proposal to remove "required" and instead make it "strongly recommended". Have you changed your opinion on this? Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:09, 9 January 2019 (UTC)

• (edit conflict) Conditionally Support the criteria above, but we should've also added: from the corresponding navigation template(s).
  • I also second Pbsouthwood's points above. I think for new-model portals, the linking should fall to the creator to implement, where applicable. Then with a bot periodically checking and generating a report for the portals that fail to meet the above criteria, we could do cleanup runs at our leisure. Not wanting to overload {{Portal maintenance status}}, but it could be useful for tracking these issues, even without Lua, if a bot updates the template.
    • The reports could include an analysis of the article changes mentioned above, most likely using the navbox as the primary vehicle, as any article changes of that nature but we know how that goes be reflected there anyway.
    • More in-depth checks would be determined by how much work the botop wants to put into this, so we won't necessarily depend on them to be wholly accurate, but probably as an indicator of manual checking needed.
  • I don't think these links would individually be a hard requirement, just that the majority of them are accomplished, as sometimes one or two of those won't be applicable to a given portal. I don't think it would be grounds for deletion by itself though. An un-linked portal should be treated like an orphaned article, and could be tracked for cleanup.
  • The bot should be set to not touch portals missing the tag <!-- This portal was created using subst:Basic portal start page -->, to prevent damaging them. We should probably have a tracking category for the un-converted ones anyway to make that easier. Once again, {{Portal maintenance status}} could detect that tag and automatically categorize the portal so the bot won't have to.
  • I also agree that the addition to Portal:Contents/Portals should be done after completion. — AfroThundr ^{(u · t · c)} 12:08, 9 January 2019 (UTC)

@AfroThundr3007730: Just in reply to above, I would write a bot that edits the articles directly, although this may take a bit of time, so adding parameters may be unneeded as the bot would do the work anyway. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:38, 9 January 2019 (UTC)

@Dreamy Jazz: That would work great, of course. I was just suggesting that in cases where the edit is not straightforward, the bot could just bug out and tag the portal, rather than trying to automate every edge case. Also, tracking categories tend to increase visibility on these types of issues better than a report page (although the report can give more details), and would allow other editors to manually tag (which the bot could also check and clean up, if desired). — AfroThundr ^{(u · t · c)} 13:12, 9 January 2019 (UTC)

• Partial support I would include 1. and 2. but make 3. optional: "consider adding", perhaps with a prejudice in favour of linking where there's no reason not to. We do need incoming links but there will be cases where they're inappropriate and could be viewed as spam. Certes (talk) 12:15, 9 January 2019 (UTC)
• Suggestion – Create a separate section called "Linking to portals", and describe the links that "should" be placed, and where. That solves the semantics problem we are having with the word "required". Perhaps use the wording "To optimize access to them, portals should have the following links leading to them:"    — The Transhumanist   12:22, 9 January 2019 (UTC)

Poll on this change: linking criteria (updated)

Please place your support/oppose for the rewrite below. Any comments above referred to the original striked out wording. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:33, 9 January 2019 (UTC)

Create a new section called "Linking to portals" as per The Transhumanist. In this section I suggest it says:

To optimize access to portals, each portal should have the following links leading to them:

1. From the root article of the portal
2. From the category of the same name or whatever are the root categories in the Category box section.
3. From the corresponding navigation template(s)

When a portal is complete the portal should be added to Portal:Contents/Portals. Consider adding links to the portal from the selected articles.

• Support – Thank you, Dreamy Jazz. This comes across as a guideline rather than a mandate.    — The Transhumanist   12:38, 9 January 2019 (UTC)
  • P.S.: @AfroThundr3007730 and Pbsouthwood: (pinging other participants above)
• Support, assuming that From the corresponding navigation template(s) means from the template rather than from each of its articles. There is no need to link directly from the articles themselves, especially if they have already gained a link by displaying the navbox. Certes (talk) 12:42, 9 January 2019 (UTC)

Certes, yes that is what it means. Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:40, 9 January 2019 (UTC)

• Support as well, since the new wording solved the above issues. — AfroThundr ^{(u · t · c)} 13:09, 9 January 2019 (UTC)
• Oppose per my explanation above regarding the incompleteness/uselessness of an orphan portal. Some reasonably effective minimum must be stipulated. Links from the bottom matter of the navbox could be considered sufficient where a navbox exists (this is not onerous, though it requires some template editing skills, or a request to a template editor, and could be done before or after the portal is constructed - some leeway must be allowed - maybe a week?.) For manually constructed and maintained portals, adding incoming links is just part of the manual construction and maintenance that the editor has volunteered to do. If they fail to do it, the maintenance is not being done properly. · · · Peter Southwood ^(talk): 05:28, 10 January 2019 (UTC)

  Pbsouthwood, I am neutral on this and have been swayed by the other editors above to make this one not required. The bot (if approved) should be able to ensure that these links are added, but obviously the wording "should" would allow leeway. Dreamy Jazz 🎷 ^{talk to me | my contributions} 13:49, 10 January 2019 (UTC)

  Note: some navboxes such as U.S. places use fixed templates which discard any attempt to add a footer and are protected. I inquired but got no reply on a talk page. Certes (talk) 14:24, 10 January 2019 (UTC)

  Certes, I'll implement this. There has been no attempt to disagree with you in well over 6 months, so it I'll be bold and implement this. Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:33, 11 January 2019 (UTC)

  Dreamy Jazz, I don't follow your statement directly above. Cheers, · · · Peter Southwood ^(talk): 18:44, 11 January 2019 (UTC)

  Pbsouthwood See Template_talk:US_state_navigation_box#Below Dreamy Jazz 🎷 ^{talk to me | my contributions} 18:46, 11 January 2019 (UTC)

  Got it, I have left a comment there supporting a change. · · · Peter Southwood ^(talk): 19:04, 11 January 2019 (UTC)

  I foresee pushback from other quarters if there is no requirement to have links to portals. I would consider that justifiable. Cheers, · · · Peter Southwood ^(talk): 18:51, 11 January 2019 (UTC)

  The problem is, that it implies the breaking of a rule, with punishments to follow. You don't want to punish an editor for creating a page. That is the exact opposite of the wiki-way. There is a clear distinction between "we should have links" to "you must place them, or else." The second one is draconian, as it implies deletion or a block. We want to build roads (guidelines) upon which editors can travel of their own will, not force them where to go with threats and whips. Wikipedia is a fun place to collaborate with others to build a free information source for the world. Please, let's keep it that way.    — The Transhumanist   20:57, 11 January 2019 (UTC)

  • Beware of all-or-nothing-reasoning. Incomplete = partially complete. Free work. Ready and waiting for others to build upon. A glass half full. Ready for drinking...

This situation reminds me of the basic topics lists. These were a set of about 30 orphan pages, just sitting gathering dust for years, in project space. Eventually, someone (me) came along and discovered them, and decided to make them non-orphans, and move them to article space, where they grew to around 300. Eventually, they were renamed to "Outlines" and grew into one of Wikipedia's main navigation systems. There are now over 700 of them. It is a good thing those lists were not deleted just because they didn't have links to them. If those lists weren't there for me to come across to be inspired by them, the outline system may not even exist...

Requiring that an editor place links to a portal he or she wishes to create may deter that editor from creating it. We want to encourage, not discourage portal creation. Editors are allowed to specialize. If an editor has a knack or desire to create portals, that is a positive thing. We need to feed, not dowse, their creative spark. It is better to have orphan pages than not have those pages at all. I look at them as part of the job being done. Because page creation puts us one step closer to having pages with links to them. This is a collaborative environment, where editors build upon the work of each other. Orphan pages are islands. New places to build bridges to. And therefore, valuable. You can't build a bridge to an island that doesn't exist. Some editors like to build islands, and some like to build bridges. What a great combination. More new islands, please...

Another analogy that fits here are plants in a nursery. They are orphans, without a garden. Should we get rid of them because they are not planted in a garden yet? No. Flowers are nice. Make them available to gardeners who will plant them in their final locations...

That a page isn't transplanted yet cannot be a deletion criterion. Each page is judged on its qualities whether or not it should be kept or deleted. That other pages lack links to a page is not a valid deletion argument, and if it was, thousands of well-written stubs (flowers waiting to be transplanted) would be subject to the compost pile (deletion) right now, regardless of their quality. Getting rid of them, would be a step BACKWARDS...

Three different programmers are working on automated (or semi-automated) solutions for placing links to portals. Why? Because we have thousands of portals that need them. Thousands of healthy plants waiting to be transplanted. Without those new portals sitting there waiting to be linked to, there would be little or no impetus to do this. So, bring them on! More portals, please.    — The Transhumanist   19:49, 11 January 2019 (UTC)

• Comment @The Transhumanist, AfroThundr3007730, Pbsouthwood, and Certes: Peter Southwood has raised a point above about how linking to portals may be hard if there is no requirement to do so. What do you think of this issue?

I have a suggestion that might fix this problem. Perhaps another sentence should be added to the proposed text to say that if an editor (or BRFA approved bot) wants to add a link to a relevant portal, they shouldn't be stopped? This could be something like If an editor or BRFA approved bot, adds or wants to add a link from one of the above pages to the portal for the topic directly relating to the page, they must be allowed to. If the editor or BRFA approved bot does not hold the rights to make such an edit, an editor with appropriate rights can do this for the editor. This would get around the WP:NOTCOMPULSORY problem, in that an editor does not have to add the links, but also ensures that if this editor or another editor who wants to add a directly relevant portals when added can't be just reverted on grounds without discussion. What do you think? Dreamy Jazz 🎷 ^{talk to me | my contributions} 19:16, 11 January 2019 (UTC)

The guideline proposed above, recommending the placement of links to new portals, is fine. We want to encourage linking, not demand it. Because if you make it a rule, it will be broken, and one of the things that sometimes happens when a rule is broken is that someone gets punished. In this type of case, it would be punishing an editor for doing something positive: creating a new page. In other words, for building an encyclopedia, the very purpose for which we are here. The case would go to the Arbitration Committee, who would have no other choice than to quash the rule leading to such ridiculous punishment. Upon reading "You stand accused of growing a new plant without planting it in the garden. How dare you! You can never grow plants again!" They would laugh their asses off. Growing new plants, that is, creating new pages, is one of the main reasons Wikipedia exists.    — The Transhumanist   20:07, 11 January 2019 (UTC)

The Transhumanist Fair enough. The rule I suggested does not require the creator to place links, but says that if an editor or bot wants to add the link they should be unimpeded, but only for those 3 pages. I can, however, see that rules/musts would not be supported by the majority, so won't add this to a proposal unless this changes. Dreamy Jazz 🎷 ^{talk to me | my contributions} 20:12, 11 January 2019 (UTC)

Good point. I believe your concern is taken care of by the phrase "should have the following links leading to them", which strongly implies that "placing these links should not be impeded". The implication is already there, pretty strongly, because the guideline is guiding that such links should exist and should be placed. If someone removes such links, or opposes their placement, the editor placing them can point to this guideline.    — The Transhumanist   20:21, 11 January 2019 (UTC)

I agree with TTH, that the proposed verbiage in this guideline would be sufficient protection for link placers. — AfroThundr ^{(u · t · c)} 20:28, 11 January 2019 (UTC)

I play devil's advocate here because I foresee someone taking this to full RfC via VP (proposals). I would prefer not to see the kind of dramah that might be brought upon the project if that happens. I would particularly not like to see any of the members ending up with blocks or topic bans if goaded into intemperate bahaviour. That would not help build the encyclopaedia. If you are all in favour of this not being a requirement, I will go with the consensus, but would point out that it is a fairly local consensus, and could quite plausibly be overthrown if taken to the full community, because I do not think that the reasoning is sufficiently robust.

The reasoning that portal space is necessarily subject to the same requirements as mainspace is dubious. An incomplete article in mainspace is subject to a small but rather strict set of requirements, all of which are intended to ensure that the article is useful. Usefulness or potential usefulness to the reader is the prime directive for mainspace. Any article in mainspace that is not useful, or potentially useful, as encyclopaedic content is unlikely to survive RfD.

It is clear that virtually any portal is potentially useful, but nevertheless we have requirements for portal creation, because it would be possible to create a portals which would require a great deal of additional work to become actually useful. Links to a portal so that it can be found is a quantum increase in actual usefulness, and likewise a decrease in the burden on other editors who would otherwise have to fix the consequences of someone else's failure to do a proper job. I recognise that we are all volunteers, and do not have to fix other people's errors and omissions, but that is what a large number of our editors do all the time to keep the encylopaedia in as good a condition as we can. Opening another door to making work for others that would keep them fom more useful work is not optimum. If the number of orphan portals grows large enough there will be an unacceptable additional burden on those trying to clean up the mess left by others, whether through inattention, ignorance, malicious intent or lazyness. If this gets big enough there may be a further attempt to close portal space. I would not like to see that happen.

I do not see a fundamental difference brtween the existing requirements and this proposed one. All of them address the usefulness of a portal. This one is arguably more necessary because even an badly formed and formatted portal is immediately more useful than an invisible portal. · · · Peter Southwood ^(talk): 18:21, 15 January 2019 (UTC)

Pbsouthwood, I think that the consensus here is to go for the revised proposal.

I understand that our local consensus could be overridden, but feel that if an editor has problems with the text here they would take it to RfC, like you say. If this was the case then so be it. I would say that discussion over guidelines does not always merit a RfC nor going to the VP.

Also, my bot would ensure that these links are added for new portals, so the potential for any orphaned portals would be next to none (unless someone deliberately stopped the links from being added, or the portal has no introduction/category sections, which then wouldn't meet the "Required" section).

Thanks and happy editing, Dreamy Jazz 🎷 ^{talk to me | my contributions} 22:49, 15 January 2019 (UTC)

Dreamy Jazz, You are probably right on the local consensus. I think this may come back to bite us, but do not consider this a very high probability, and will go with the flow.

Your bot is the main reason why I will go with the flow. I look forward to it doing the work and making the problem go away in practice. If anyone deliberately blocks the bot, they thereby take responsibility for the lack of links. If the links were a requirement there would be a stronger argument that blocking the bot would be disruptive, but strongly recommended still provides a bit of pressure. Cheers, · · · Peter Southwood ^(talk): 09:02, 16 January 2019 (UTC)

Pbsouthwood. Ok. Per [I]f the consensus is clear, any editor—even one involved in the discussion—may close the discussion on Wikipedia:Administrators' noticeboard/Requests for closure coupled with that discussion has been open for a week (so it has given editors time to respond to this) and you and other participants agree that the consensus is for the addition, I will close this and add it to the guideline. Dreamy Jazz 🎷 ^{talk to me | my contributions} 09:58, 16 January 2019 (UTC)

Pbsouthwood On second thoughts, this discussion does change a guideline. Should I take it to the noticeboard? Formal closure by an uninvolved editor or administrator should be requested ... where there are wiki-wide implications, such as when the discussion is about creating, abolishing or changing a policy or guideline. Dreamy Jazz 🎷 ^{talk to me | my contributions} 10:09, 16 January 2019 (UTC)

Pbsouthwood On third thoughts, this is not really a "wiki-wide" discussion, as it won't affect every page. Therefore, I feel that I don't need to take it to the noticeboard. Dreamy Jazz 🎷 ^{talk to me | my contributions} 10:27, 16 January 2019 (UTC)

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

Should Portals contain noticeboards?

There are a few portals that also have a noticeboard-type subpage; my view is that these subpages should be in the Wikipedia:WikiProject space and not in the Portal: space. What do other editors think? UnitedStatesian (talk) 19:51, 10 January 2019 (UTC)

@UnitedStatesian: Well, considering one of the purposes of portals is to serve as a bridge between the readership and the editorial population of Wikipedia, things like noticeboards or WikiProject links, are not necessarily out of place, depending on the context. Do you have any particular examples that raise these concerns? — AfroThundr ^{(u · t · c)} 23:26, 10 January 2019 (UTC)

The four that are in the portal space are Portal:Armenia/Armenia-related Wikipedia notice board, Portal:Azerbaijan/Azerbaijan-related Wikipedia notice board, Portal:Ukraine/Ukraine-related Wikipedia notice board, and Portal:Vermont/Vermont-related Wikipedia notice board. My only concern is that users will not know where to find them if all the others noticeboards are in the Wikipedia:WikiProject space. I think I will go ahead and move those four if there are no strong objections here. UnitedStatesian (talk) 13:33, 11 January 2019 (UTC)

I agree with UnitedStatesian that noticeboards belong in project space. While portals are to serve as bridges to WikiProjects, they are not intended to be WikiProjects. The "bridges" referred to in the guidelines are links to project space, typically links to related WikiProjects.    — The Transhumanist   18:13, 11 January 2019 (UTC)

Ok, yeah.. In that case, those pages should be moved to a relevant WikiProject, where they'd (hopefully) be more useful. A link to the WikiProject should be sufficient for the portal itself, and the project page can link to a noticeboard from there. — AfroThundr ^{(u · t · c)} 20:30, 11 January 2019 (UTC)

I agree that these noticeboards belong in project space not portal space, but it can be useful to transclude them on a portal rather than providing just a link to a WikiProject. A typical reader might not know what a WikiProject is and would therefore be reluctant to click on such a link, but if presented with a list of things they can do to help Wikipedia, they might be more inclined to get involved. I think that was the logic behind including them in portals to begin with, and it still holds good. WaggersTALK 14:30, 23 January 2019 (UTC)

If I remember correctly, the old style portals sometimes transcluded a "To do" subpage from the relevant project. There is one in Portal:Underwater diving. I have mixed feelings about them. On the one hand they do provide some potentially useful information about what is still to be done in the scope of a project, but on the other hand, they can be quite big and in your face. I would be interested to hear more impressions and opinions. I agree that the information belongs in the project, so if there is no project it is a bit pointless. To me the question is whether it is worth having them in the portal in addition to the project, i.e. by transclusion, and whether this is a thing that should be mentioned in the guidance. Also whether there should be limits to what kind of information is considered appropriate. Cheers, · · · Peter Southwood ^(talk): 15:54, 23 January 2019 (UTC)

Portals on "Subject bar" template

Greetings, Wondering if guidelines should include mention of Portal placement on "{{Subject bar}}" template? And maybe an example or two?

On many articles I've been adding {{Subject bar |portal1= Biography |portal2= Catholicism |portal3= Italy}} for example. For placement of this template, I remember "S A D" = Subject bar, Authority control, DEFAULTSORT lines in that sequence.

Also, there is a bug in "Authority control" that causes it to not showup. Often (but not always) just removing the blank line before & after Auth.control causes it to magically appear. And changing the initial "a" to A.

Regards, JoeHebda (talk) 13:41, 15 January 2019 (UTC)

JoeHebda, I have no particularly strong opinions on which template is best for portal linkage and where they should go, but I guess that anything that is accepted usage can legitimately be mentioned and a link to the relevant guidance provided. It is probably better to mention and link all accepted methods, formats and locations, so that people are less likely to edit war over them. What would you suggest?· · · Peter Southwood ^(talk): 19:17, 15 January 2019 (UTC)

Pbsouthwood just a suggestion. Perhaps this can be included in the "Linking to portals" proposed above. Dreamy Jazz 🎷 ^{talk to me | my contributions} 22:17, 15 January 2019 (UTC)

Dreamy Jazz, That would be the obvious place to put it, since that is what it is. It is just a matter of what all there is that we should put there to be reasonably complete without going into excessive detail. Until fairly recently I was not even aware that {{Subject bar}} exists There may be other information that should be included that I still don't know about. It is probably better to sketch out the additions on this page until they stabilise, then add to the guidance to avoid potential complaints of lack of consensus later. It would be nice if a few proposals came from people outside the core group.

There are quite a few ways to link to portals. In some ways this is good, but in one way not so good. It makes it more confusing to the reader when there are too many options in too many places. This steepens the learning curve. Ideally there would be just enough methods to deal with all circumstances effectively, as that would be easier to learn and remember. Unfortunately we lack stats on what is most effective, so are working on gut-feel, guesswork and opinion. Not the best way to optimise quickly, but so it goes. Keeping it flexible and allowing some redundancy may be the way to go in the absence of good data. · · · Peter Southwood ^(talk): 09:20, 16 January 2019 (UTC)

I have a hunch that navigational aids should be clustered for best visibility. That way the proximity of an unfamiliar aid to a familiar one may help getting the unfamiliar one noticed. Navboxes, portals links, portal bars, subject bars, see also sections, categories are all navigational aids, even external links, references and sister project links can be seen as related, so I think they should all be grouped in one place in an article. Although regular Wikilinks, hatnotes and infoboxes are also navigational aids, their placement is constrained by their function, and inter-language links are tied to the sidebar. There are a lot of options. · · · Peter Southwood ^(talk): 09:36, 16 January 2019 (UTC)

Portal icon request

Hello all, I've done this once before but couldn't recall if this was the place to ask—but I'm posting it here anyway. I was wondering if someone could assign an icon to a portal for me. The portal is Portal:Courtney Love, and I'd like to assign this icon if possible. I believe someone qualified has to do this, or if there is a way for any editor to do so, let me know. Thank you! --Drown Soda (talk) 02:22, 14 February 2019 (UTC)

The icon names are stored in protected templates. Please see Template:Portal#Image. Certes (talk) 02:43, 14 February 2019 (UTC)

 Done ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:13, 26 February 2019 (UTC)

Pause on mass creation

I opened a discussion at the Village pump, Wikipedia:Village_pump_(proposals)#Hiatus_on_mass_creation_of_Portals. UnitedStatesian (talk) 14:35, 26 February 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)

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 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 4

I am going to suggest a variant of @Dreamy Jazz:'s.

Every portal must have at least 20 selected articles. Articles that have already been selected by another portal are not counted towards the 20 for the latter portal(though obviously they can still be included).

My reasoning for this amended proposal is partially similar to that of proposal 1:

• "It is generally accepted 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."

With the key added reasoning:

• It doesn't make any sense for an article not to add value at all, just because two portals have claimed it. Splitting in this way means that articles which obviously apply to more than 1 portal can exist in them and supporting some portal existence, while still requiring a unique remit for a new portals, to avoid needless duplication.

As obviously a partially amended version, if proposal 1 decides to change this can obviously be merged/scrapped. However I feel it is a substantial difference and warrants a separate consideration until that point.

A couple of questions that affect the practicability of this proposal:

1. How does one check whether an article is already used in another portal?
2. Which portal gets to claim an article? Sometimes the portal where the article is most relevant will not be the first portal created. This will happen when a portal is split into subportals because it is too large, but in that case it is unlikely that there will be a dispute, but many articles are shared by very different projects, as can be seen by the presence of multiple navboxes. I think this rule will lead to much unneccessary drama, but you may have a solution which is not currently obvious to me.
3. Where is the harm in duplication? It requires no additional content, and no additional maintenance. All it takes it presence in the navbox. If it adds no value in the navbox, remove it from there and it will softly and silently vanish away. The new model portals are Boojums you see.
4. A potentially useful portal may be possible where every one of the articles is shared with another portal, but no two articles with the same portal. Would this still be considered a problem? · · · Peter Southwood ^(talk): 14:45, 28 February 2019 (UTC)

• Support (as proposer) - it seems to have the benefits of proposal 1 while avoiding a key problem. Nosebagbear (talk) 11:56, 28 February 2019 (UTC)
• Tentative support in principle depending on whether the questions above can be satisfactorily answered. I agree that excessive overlap is undesirable, but it may be difficult to test, and there may be overlap with multiple portals. I would say excessive overlap means a large proportion of articles are shared by any two portals. I don't know where I would draw the line though. 50%? · · · Peter Southwood ^(talk): 14:45, 28 February 2019 (UTC)
  • Per your point #4, I would say any two portals that have over X% overlapping articles (50% sounds okay) would count, but not the portal with a single article overlapping with dozens of others. And if we're limiting the criteria to the two-article case, comparing them for overlap becomes trivial. Nobody is likely going to pony up the cycles to do an "overlap percentage analysis" on the portal network for the higher-number cases. This distinction could be better captured in the proposal though. Tweak the second sentence to something like A portal should not contain a significant proportion of articles that overlap with another portal. maybe? The concern, I think, should be less about the number of "unique" articles per portal and more about how "unique" two particular portals are when compared. — AfroThundr ^{(u · t · c)} 02:59, 1 March 2019 (UTC)
    • Sometimes it is obvious that a portal already exists that uses an article, because there is a link to the portal from the article, but when one is considering creating a portal, what checks do you have in mind to avoid the problem of excessive overlap? · · · Peter Southwood ^(talk): 06:04, 1 March 2019 (UTC)
      • @Pbsouthwood: Due diligence might include a namespace search for existing portals covering a similar topic, or close to the proposed portal in the (as yet to be created) navigation tree. Then using What Links Here might be helpful, although the nature of the selected excerpt templates would mean the results wouldn't exactly be complete. Also, comparing the wikisource would miss links in the navigation boxes... hmm...
        I wonder if we could build an "index" of portals and the articles they link to (rendered as a wikitable, or even just JSON or something). It'd take a bot crawling the namespace regularly (and expanding all templates) to generate such an index, which could then be hosted on-wiki and made searchable. A userscript could accompany said index to make the "uniqueness" checking easier. This is a case that I don't expect to be enforcing immediately after implementation, since we've got bigger fish to fry, so we'd have time to build that.
        @Dreamy Jazz, Evad37, Certes, and The Transhumanist: Thoughts on this idea? I figure a technical solution wouldn't be out of place here, considering the scale. — AfroThundr ^{(u · t · c)} 06:48, 3 March 2019 (UTC)
        • A Quarry query on pagelinks could detect when a portal overlaps others. It only works on existing portals and may be too expensive to run on all portals at once. Therefore it would only be a tool to evaluate an existing portal that looks suspicious, rather than a pre-creation check for a prospective new portal or a way of finding candidates to delete or merge. An offline tool (read-only bot) could select all links from portals and generate statistics such as listing portals which share almost all outgoing links with other portals and naming those overlapping portals. I don't think this can be done efficiently on Quarry, as we can't create temporary tables. The results may vary depending on which articles are being randomly selected for display today. There's also no notion of articles being "already selected by another portal". Portal:Australia and Portal:Mammals both link to Kangaroo, and the query won't resolve the resulting bunfight over which portal gets to count that article towards its quota. Certes (talk) 11:59, 3 March 2019 (UTC)

I've produced a couple of Quarry queries which aren't exactly what we want but may be useful.

1. Portals linking fewer than 20 "new" articles, where "new" here means "not also linked to a portal which was created earlier"
2. Portals which also link to a portal's articles, which needs to be amended with the title of a specific portal before use

Hope that helps. Certes (talk) 16:04, 3 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)

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. [4]), 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)

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)

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". [5] 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)

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)

[6] & (not as recently as I'd thought) [7] 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)

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)

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)

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)

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)

Dispute that this is a guideline

I call this guideline’s status disputed. It was never approved by the community, if fact it was rejected. It then took a sleepy backroad route avoiding the {{rejected}} tag to later, quietly, be tagged {{guideline}}. As a guideline referred to frequently from MfD, it is demonstrably of pariah status. It commands no respect, and gives poor guidance. —SmokeyJoe (talk) 03:14, 2 June 2019 (UTC)

SmokeyJoe, some of the guideline does command respect, e.g.:

• The requirement for creators to maintain portals
• the requirement for broad topics
• the requirement that portals must attract readers and maintainers
• the requirement that portals must be regularly updated.

The What content to include section has less support, because most of that is redundant.

The real problem here is not with the guideline. The problem is that the portals project has never upheld the guideline, which is why editors from outside the project have been busy for three months at MFD removing crud which should have been cleared out long ago.

As of now, the total number of portals is 1023, which is a 30% fall from the total of ~1500 before the automated spam began. All these deletions have been happening because the guideline is finally being upheld. --BrownHairedGirl (talk) • (contribs) 01:01, 3 June 2019 (UTC)

"some of the guideline does command respect"? Really? Evidence? Even if you point out evidence, no series of true statements justifies the guideline tag without community input, especially with a history of community rejection as a guideline. "Commands respect" would mean that a link to WP:POG would correlate with the !vote matching the MfD outcome. It doesn't. --SmokeyJoe (talk) 01:09, 3 June 2019 (UTC)

@SmokeyJoe, my point is that MFD outcomes do overwhelmingly reflect the 4 items I mentioned above from POG. --BrownHairedGirl (talk) • (contribs) 20:05, 3 June 2019 (UTC)

"The requirement for creators to maintain portals"? Not true. Creators don't own pages, including portals. A portal could be maintained by another. A portal could be maintenance-free. One auto-portal experiment failed, but one experiment doesn't make a proof.

"the requirement for broad topics". Without a definition of broad, it is useless guidance.

"the requirement that portals must attract readers". Not well composed, nonsense. Is it the job of a portal to attract? Does this mean a portal should generate notices? Should it generate spam emails? Should it encourage visitors to tells their friends to come look to?

"the requirement that portals must attract ... maintainers"? This pre-supposes that portals need maintenance, and I disagree that portal maintenance is a good idea, certainly not a base level requirement.

"the requirement that portals must be regularly updated"? Does this include auto-updates? What is so wrong with a static portal? Is this related to a wish for flashing lights and fluttering ribbons to attract attention?

I think everything, including your points, is unfounded by the failure to answer the most basic question: "What is the purpose of a portal". The purpose of the main page is to provide an interesting Wikipedia landing page. Portal:Biography? What is its purpose? Does it help in finding biographies? Over 1000 land there daily, but does landing there help them? --SmokeyJoe (talk) 11:57, 4 June 2019 (UTC)

BHG, I see you are repeatedly using these POG lines to argue deletion of portals, and then portals are deleted. A correlation, but causal? I think the portals, most of them, need deletion (archiving could have been done), because they are a failed experiment and are not compatible with being Wikipedia content for readers, and you POG line fails are lesser reasons, not fundamental reasons. --SmokeyJoe (talk) 12:06, 4 June 2019 (UTC)

One odd rational is deletion of City portals for being small is scope...that long ago was determined to be great candidates for portal creation. City portals literally can lead to thousands of pages ...bios, geo articles, history articles, political articles, culture articles, sports articles, etc. Again really not sure the deletion noticeboard should be spearheading the so called cleanup when there is zero attempt to fix the content involved as per Wikipedia:Miscellany for deletion and WP:PRJDEL. So perhaps best to look at portals as a whole and if the community really wants them all gone. The main problem is the majority of content editors never look at the deletion board and don't notice what's going on till its too late....and then they are confronted with a note saying don't recreate said portal that again is not how things work here. --Moxy 🍁 13:45, 4 June 2019 (UTC)

I literally see red most mornings when I get notification of undone edits restoring an ancient portal which goes straight to MfD, but I think we just need to be patient for a little longer. Soon, one of two things will happen. One possibility is that the handful of editors who support these MfDs will accept that they have deleted all the portals they can, and will leave us to resume more positive work. The other is that they will succeed in deleting so many portals that we can clearly demonstrate to the community a blatant breach of ENDPORTALS and get the process stopped and perhaps reversed. Either way, we can look forward to a time when WikiProject Portals will no longer be dominated by editors who would prefer to delete the entire namespace. Certes (talk) 14:12, 4 June 2019 (UTC)

@Moxy: I don't know where or when you claim that city portals were determined to be great candidates for portal creation, but assuming that there was some broad consensus for that, policy is that consensus can change. And in this case it clearly has changed, because the evidence is that after of 14 years of creating city portals, the vast majority of them have been long abandoned in a pitiful state. It is sad a small minority of portal fans continue to bemoan the deletion of this abandoned junk which is shunned by readers.

@Certes: it's astonishing that after all this time you still show little or no sign of having actually read the proposal and closure of WP:ENDPORTALS. That was a proposal to delete all portals, and it was rejected. That consensus to not delete everything was not a consensus to keep every piece of abandoned junk in portalspace.

The reversion of the navbox-cloned automated portals was completed about a month ago, so if you are seeing that most mornings, then you must be time-travelling.

The 13-year failure of the portals project to clean up the abandoned junk is what led to this cleanup. The continued moaning of some portal fans about the ongoing cleanup is a sad indicator that the portals project has yet to move the mentality which led to the disastrous automation spree: never mind the quality, just count the the numbers.

I don't know how long the deletion process will continue. Every time I think we are nearing the end of the tunnel, another layer of abandoned junk comes into view. But my guess is that there are another few hundred to go, leaving us with perhaps 700 or 900 portals.

When that cleanup process is complete, the next issue is what portals should actually do now that mouseover-preview has rendered redundant the hideous model of content-forked sub-pages which change only when the page is purged. Those editors who want to work on portals could be having that discussion now, and examining whether the mega-navbox model of e.g. Portal:Harz Mountains and Portal:Mecklenburg-Vorpommern is more widely usable. But the fact that most of the active portal fans prefer to moan about the cleanup of abandoned junk suggest to me that the phase will again be led from outside the project. --BrownHairedGirl (talk) • (contribs) 21:44, 4 June 2019 (UTC)

The issue is not so much a need for an owner or continual updates. Rather it's getting the editors interested in a given topic area to support all of the pages associated with that topic. Take navigation boxes as an example: some need regular periodic updates based on scheduled events, others stay the same for long periods of time. So some need regular maintenance, while others may just need some guards against vandalism. But they aren't in danger of being deleted, because the interested parties who would weigh in at a deletion discussion are the ones who decided on the appropriate navigation boxes to have. Those who are vested in seeing portals continue should go work through the different topic areas and solicit the editors in those areas for their support and collaboration. Yes, it kind of sucks to have to do so many at once right now, but it's a necessary tax. Failing to pay it at creation time just defers it to being paid later. isaacl (talk) 21:45, 4 June 2019 (UTC)

@Isaacl: why would the editors who work on creating and maintaining content want to divert their time and energy into building and maintaining portals which add no value for readers, and are almost unread?

Unless and until the portal fans gain broad community support for some model of portal which actually meets the WP:PORTAL principle that "Portals serve as enhanced 'Main Pages' for specific broad subjects", then portals will continue to be a sideshow where a limited number of portal fans scurry around doing a few tweaks to a set of pages which hardly anyone uses and which few other editors see any value in maintaining. So they will continue to rot. --BrownHairedGirl (talk) • (contribs) 22:13, 4 June 2019 (UTC)

That's up to them to decide. If they don't want to spend energy into developing something called a portal, they don't have to. If they want to, then it's their time to invest. Exactly as how navigation boxes are managed. isaacl (talk) 22:40, 4 June 2019 (UTC)

Indeed. And if they choose to let portals rot so that they are no use to readers, then the community is entitled to delete the abandoned or useless portals. --BrownHairedGirl (talk) • (contribs) 23:01, 4 June 2019 (UTC)

Yes, this scenario is covered by "If they don't want to ... they don't have to". isaacl (talk) 00:33, 5 June 2019 (UTC)

Yes yes portals are crap and useless we get your POV....but you really think that your rationale is still valid consider all the protest? As mentioned before.... we should be following the guidelines that are outline for any other type of page. I know you think your doing right by our readers....but the community has said otherwise very recently. Just like mass deletion..... the community starting to protest this verture of yours. --Moxy 🍁 01:08, 5 June 2019 (UTC)

Please don't put words in my mouth. I don't think all portals are crap and useless.

The MFD nominations I make are based on the long-standing portal guidelines, and the community gets asked about every single portal which is proposed for deletion. That's what MFD is: a community process.

As to the community starting to protest, what I see is a small number of portal fans objecting to long-standing portal guidelines being upheld. And no, the community has never said no to the principle of deleting portals which don't meet the guidelines. --BrownHairedGirl (talk) • (contribs) 12:27, 5 June 2019 (UTC)

We are asking for you and friends to try and help fix them..... or at the very least give people notice so they have time fix them. Your all or nothing position is contrary to how things work here. --Moxy 🍁 21:57, 5 June 2019 (UTC)

I am not taking an all-or-nothing position. --BrownHairedGirl (talk) • (contribs) 23:39, 5 June 2019 (UTC)

• User:UnitedStatesian, “failure of a dispute to be reslved does not mean it is a failed proposal”, true. Failure to achieve consensus support after a reasonable time means that the guideline proposal has failed. For 13 years, this proposal never gained support. —SmokeyJoe (talk) 04:43, 30 June 2019 (UTC)

• User:SmokeyJoe I disagree. This page described how portals operated for 12 of those 13 years. At no point in that time did anyone object to it, questioned that it was a guideline, or open a talkpage discussion to propose a better, improved version. And many of the participants in the WP:ENDPORTALS discussion referred specifically to this guideline. There does not need to be a page where people !voted their approval in order for it to be a guideline. UnitedStatesian (talk) 04:52, 30 June 2019 (UTC)

Portals serve as enhanced 'Main Pages' for specific broad subjects

Let us try to look at this claim logically and without undue emotion.

There are two main properties specified here, one of them with two requirements. They appear to all be required (necessary).

1. Enhanced "Main pages".
   • In what way should they be enhanced, that would not be more appropriately done at the topic title page in mainspace?
   • It might also be useful if it was made clear and unambiguous what is meant by "Main pages" in this context.
2. Specific broad subjects. This is a slightly self-contradictory requirement, as broad and specific can have somewhat opposing meanings.
   • specific subjects:

     specific: clearly defined or identified. synonyms: particular, specified, certain, fixed, set, determined, distinct, separate, definite, single, individual, peculiar, discrete, express, precise[8]

   • broad subjects:

     broad: covering a large number and wide scope of subjects. synonyms: comprehensive, inclusive, extensive, wide, wide-ranging, broad-ranging, encyclopedic, all-embracing; general, universal, catholic, eclectic, unlimited; cross-disciplinary, interdisciplinary, multidisciplinary

     broad: general; without detail. synonyms: general, non-specific, unspecific, unfocused, rough, approximate, overall, sweeping, basic, loose, indefinite, vague, hazy, fuzzy, woolly; informal: ballpark[9]

I assume that the first meaning of broad is the one we are intended to use. but it would help if we were more specific. (there are several other meanings which appear irrelevant, so I left them out)

So - How specific, how broad?

Cheers, · · · Peter Southwood ^(talk): 15:21, 3 July 2019 (UTC)

Pageviews

This statement in the lead is another part of WP:POG that needs another look: ...likely to attract large numbers of interested readers and portal maintainers.

No portal can at present expect to achieve this. The best possible portal on the broadest imaginable subject cannot attract many readers because readers are hardly offered them. On most topics the main article attracts 100+ times the pageviews of the corresponding portal, because a search on that topic presents readers with the article, not the portal. Editors aware of this are unlikely to devote much effort to a portal for the sake of a very sparse readership.

Most of the deletion nominations currently appearing at MfD make great play of these pageview statistics, just as though readers at large were aware of portals and had chosen to avoid them. The fact is that very few readers ever get to inspect a portal to see if it's useful to them or not: any such inspection would swell the pageview figures. The MfD arguments from pageviews are fallacious.

The answer would be to alter search engine functioning to give portals a fair crack of the whip. However, this is far from straightforward, as we cannot expect either editors here or staff at WMF to start considering ways and means until there is a consensus that portals are worth the effort. To seek such consensus would require us to have produced high-quality portals on a range of topics, designed to resist the criticisms repeatedly levelled at portals in general, and to satisfy the community that portals can add real value for readers, as an overview of all aspects of Wikipedia's coverage of a broad topic.

Meanwhile, because the quoted text is being weaponised as an argument for deletion, it should be struck out for the time being: Bhunacat10 (talk), 16:26, 5 June 2019 (UTC)

It's a relevant point to bring up at MfD, because it's the reality of how things work now and unlikely to be altered, even if the WMF was interested (and why would they be?) Portals and outlines seem like wikignome cataloging that doesn't mirror real-world behavior of readers; there's a reason why web portals and directories died decades ago, because search engines were a better way of getting to the single targets (articles) people wanted. Der Wohltemperierte Fuchs ^talk 17:50, 5 June 2019 (UTC)

I agree that page views content on the guideline page should be edited to reflect actual reality, rather than being based upon a desired, but unattainable goal to attract large numbers of interested readers and portal maintainers. Portals almost always receive less page views compared to articles. As a comparison, many WP:STUB articles often receive very few page views as well and have few or no active maintainers, but this is not a valid rationale for their deletion. Furthermore, the notion of any sort of required maintainer goes entirely against the grain of WP:NOTCOMPULSORY. North America¹⁰⁰⁰ 06:48, 6 June 2019 (UTC)

How refreshing, Der W. F., to see a civil and reasoned response on this issue of Portals! – Granted, if a reader comes to WP to find out specifically about the 2015 Women's Junior African Volleyball Championship, they can easily home in on our article, bypassing portals, navboxes, category trees and the rest. The type of reader I have in mind is someone who maybe doesn't yet know much about (say) volleyball, but wishes to explore the sport through Wikipedia. Searching on "volleyball" will bring them to what is, rightly, a lengthy article going into detail about the rules and tactics. Only at the very end do they come to some navigational aids guiding them to aspects of the sport not covered in the article itself.

A well-designed portal can benefit such a reader by bringing together different elements of Wikipedia's coverage in an attractive, compact package, from which they can branch out in any desired direction. But to achieve a portal system that is high quality, useful, and used, will require a real upsurge of active interest among all those who voted last year not to ENDPORTALS: Bhunacat10 (talk), 08:24, 6 June 2019 (UTC)

Some portals seriously lack links to them, such as links placed in article namespace that link to the portals. This is often a reason that portals receive low page views. More visible links = more page views. North America¹⁰⁰⁰ 10:30, 6 June 2019 (UTC)

I totally understand that view, and see in theory the point to it. The problem is it's not based in a pragmatic evaluation of how our readers use our site, but rather the orderly way we’d perhaps like them to. The only portals that have any level of readership (or can actually approach regular articles) are the ones right at the top of the main page. Otherwise, discoverability is virtually non-existent. You can argue this is a problem you can solve, but dumping a bunch of portals that are still relatively low-traffic on the main page is essentially taking attention away from the rest of the content and making user experiences worse by requiring more clicks to get to stuff. It's a similar problem with stuff like outlines that practically serve no real purpose because no one uses them. This isn’t even a problem that’s solely an issue with these "out of article space" content—people go to specific film articles rather than the general and more broad articles on Wikipedia as well, but I think the simple argument against portals and the like is that they are timesinks that are fundamentally generating more views and time and attention debating their existence than they are actually serving readers. Der Wohltemperierte Fuchs ^talk 13:31, 6 June 2019 (UTC)

User:Northamerica1000: I'd argue the bit about low-traffic stubs actually suggests places where merging or other strategies are a better option than low-traffic stubs that are never going to get improved (if they can, someone can spin the content out.) Centralizing and concentrating content is always a good idea for a general encyclopedia. Der Wohltemperierte Fuchs ^talk 13:36, 6 June 2019 (UTC)

• Oppose removal, and ping some participants in recent MFDs: @Robert McClenon, Pldx1, UnitedStatesian, Britishfinance, and StraussInTheHouse to alert them to this proposal. This text is long-standing, and the plea to remove it is clearly a WP:GAMEing exercise, as evidenced by Bhunacat's comment that because the quoted text is being weaponised as an argument for deletion, it should be struck out for the time being. That's hilariously self-serving reasoning, which amounts to "if a utility test results in junk being deleted, abolish the test so that we can keep the junk". #YCMTSU

As David Fuchs notes above, the reason that portals get low page views is that editors don't need them to navigate. Most web portals were killed in the late 1990s when Google provided decent search, and Wikipedia portals are no exception: they are unused because there are better ways to navigate.

It's amusing to see NA1K trotting out the old chestnut that more links means more portal views. That's obviously true, but also highly misleading, because even the most highly-advertised portals still achieve risible pageviews. For example, there are 9 portals linked in the absolutely prime place on the main page: the top right. The mainpage averages over 15 million pageviews per day, but the portals linked there get between 694 and 2,480 views per day, which is a range of between 0.0046% and 0.017%. That's even less than the common ratio between portal and head article of between 0.05% and 1%.

I agree with Bhunacat about one thing: to achieve a portal system that is high quality, useful, and used, will require a real upsurge of active interest among all those who voted last year not to ENDPORTALS. But a year after ENDPORTALS, that hasn't happened. Huge numbers of portals remain rotted and abandoned junk, and most others offer too little added value to interest readers. But instead of trying to define what would actually make a useful portal, portal fans have mostly been engaged in various forms of denial. Bhuancat has been angrily defending an automated navbox clone which they created, obliviously to the utter pointlessness of its redundancy. NA1K is running is running around creating yet more swathes of content-forked sub-pages, despite being well aware that the whole model of displaying previews is pointless now that preview is built into the Wikimedia software.

And now we have a proposal to try to deal with the fact that most portals are on topics where readers don't want portals by ... yes, removing the test that portals should actually serve a need. This is utterly ridiculous. --BrownHairedGirl (talk) • (contribs) 12:49, 6 June 2019 (UTC)

• Oppose removal but require one or more additional reasons for Portal deletion. An under-construction portal that has 17 pageviews a day will still get over 6,000 views in a year, and that number will presumably grow as the portal is improved and more broadly advertised, and as the portalspace becomes more focused on topics that are so broad that the article + template coverage has shortcomings. UnitedStatesian (talk) 13:26, 6 June 2019 (UTC)

• Oppose removal. Having participated in Portal MfD discussions, I am waking up to the fact that we have a material problem with hundreds of abandoned portals on WP. I don't mind a low-traffic stub that meets notability; properly constructed, it does not detract or diminish the integrity of WP in the eyes of the reader. An abandoned portal, however, is not the same thing, and is a problem.

We have hundreds of portals that are out-of-date cut-and-pastes of the topic's main article+navbox. To a casual reader, their abandoned state gives the impression that WP is a failing/dying enterprise. To the extent that Portals might have once made sense (e.g. a mini-main page for dedicated/enthusiastic editors of a large topic; a time when our ratio of content to editors was much smaller), that rationale barely holds now. Facebook is a far better platform for such enthusiasts (and they run large pages that link into WP articles as needed).

I see Portals being defended at MfD that have not been touched (in a material sense) for over 5 years, and where the main article is itself heavily tagged for issues? Not only do we need the current wording maintained, but we also need additional wording on Portals to ensure the forces of creative destruction, that are such a fundamental part of the success of Wikipedia (and why my parent's expensive old Encyclopedia Britannica set is now junk), are supported. The ever-increasing ratio of content-to-editors, means that we should decisive here. Britishfinance (talk) 13:54, 6 June 2019 (UTC)

• Comment - An analysis of the Portal:Companies, The most visited portal. (Excluding the main page portals, which together concentrate more than 70% of the portal pageviews space, See Popular portals). Is an obsolete portal, which can not, even with such a broad topic, list more than 10 featured articles. Attempts to turn it into a single-page portal were summarily reverted in a witch hunt against single-page portals, like Portal:Martial arts and Portal:Human sexuality. What is wrong? The most visited portal is a cadaver? There are portals about US state roads with more subpages than monthly pageviews.Guilherme Burn (talk) 14:28, 6 June 2019 (UTC)

Regarding the failure of central directories in general, they've evolved to more targeted curated pages. Listicles have arisen as a compact way to present a set of related facts that has high searchability. Meta-review sites have gained in popularity to sift through comprehensive reviews versus ad fodder. Influencers are now pivotal to reaching millennials. Thousands of one-size-fits-all portals that draw automatically from other pages doesn't fit this trend, but carefully chosen portal topics with hand-curated content does. isaacl (talk) 15:55, 6 June 2019 (UTC)

@isaacl, the problem on en.wp with the notion of carefully chosen portal topics with hand-curated content is that

1. v few portals (maybe a dozen or so) have significant quantities of hand-curated content. The rest have just collections have random articles added to random lists as busywork
2. even the better quality, hand-curated portals have v low pageviews. e.g. in Jan–Feb 2019, Portal:Military history of Australia got an average only 10 pageviews per day. --BrownHairedGirl (talk) • (contribs) 16:42, 6 June 2019 (UTC)

Yes, you don't need to repeat your concerns regarding portals that do not have hand-curated content, or on page views. Rest assured, I have read all of your comments and understand them. isaacl (talk) 16:54, 6 June 2019 (UTC)

I summarised them briefly in response to a post which appeared to overlook the pertinent facts. --BrownHairedGirl (talk) • (contribs) 17:29, 6 June 2019 (UTC)

In the interest of conciseness, I refrain from repeating the discussion context in each of my posts. I've already spoken out elsewhere against portals that aren't hand-curated, and given my opinion on page views as a metric. isaacl (talk) 17:40, 6 June 2019 (UTC)

• Oppose removal - Most of the existing portals are no more navigation tools... or never reached such a state. Most of the time, the reader is facing an abandoned draft, or an abandoned wreck: nothing to see-- or a set of outdated snippets. Readers are learning quickly: it would be stupid to try once more, the odds are so low. Don't imagine other reasons for such abysmal page views for quite all portals. If we don't remedy to this pattern, the only foreseeable future for portals is to rot in oblivion. This should be the concern, and the duty, of the keep !voters, but their business model looks rather as "vote and pray for better days". And mumble when delete !voters don't do the work in their stead. But sorry, peons are on strike! See Wikipedia:Miscellany for deletion/Portal:Korea for a typical case. Pldx1 (talk) 17:33, 6 June 2019 (UTC)
• Oppose Removal and see my remarks below. But who is proposing to weaponize deletion discussions? That metaphor is silly. Robert McClenon (talk) 19:25, 6 June 2019 (UTC)
• Oppose removal: I think it's incredibly well-worded. It is there because it is intended to be used as a rationale to identify portals which are unsuitable and thus ought to be deleted, the venue for that is MfD, so I don't see how this is weaponised as a deletion rationale. That's like saying Wikipedia:Notability is weaponised at AfD. It's not, it's serving its intended purpose and doing it well. The current system of articles, timelines, navboxes and template panels, along with MediaWiki "preview" features work far better as a way to impartially show readers relevant content. I'm against ending portals completely, but in the vast majority of cases I don't know why anyone would stick to updating a page that nobody uses instead of getting a template to do it for them. SITH (talk) 13:32, 7 June 2019 (UTC)
• Remove: See Wikipedia:Arguments to avoid in deletion discussions#Nobody's working on it (or impatience with improvement). That phrase was clearly there to explain why a portal has to be about a broad subject (because, by being broad, it can be easier for it to get readers and maintainers), not to state that a portal should have readers and maintainers or otherwise it should be deleted (a troubling notion if it is put under closer scrutiny). In fact, there are tools to create automated portals, so that once they had been set up they don't really need maintainers. The 5 Pillars explain that, regarding policies and guidelines, "The principles and spirit matter more than literal wording". --Cambalachero (talk) 12:45, 26 June 2019 (UTC)
  • The automated portals have nearly all been deleted. First at two mass deletions (one, and two), and then at hundreds of discussions of smaller groups.
    Cambalachero is entirely right that "The principles and spirit matter more than literal wording". The principle here is that set out in WP:PORTAL: "Portals serve as enhanced 'Main Pages' for specific broad subjects". An abandoned portal which adds nothing to the main page, or which is out of date and misleads readers, is no enhancement. We shouldn't waste the time of readers by luring them to a pseudo-portal which is just abandoned junk. --BrownHairedGirl (talk) • (contribs) 16:02, 26 June 2019 (UTC)
    • I'm not talking about portals that are automatically created, but about portals that automatically renew their contents each time someone visits them. A maintainer may add new content to the queue, but in the meantime the portal does not look bad to the casual reader. This seems as if I built a city and left it in the dark during the night because I do not have an army of lamplighters to susbtain a large system of gas street lights, ignoring that I could simply install electric lamps that work without manual intervention. Cambalachero (talk) 16:34, 26 June 2019 (UTC)
      • There seem to be two distinct questions here, and their answers may differ. Putting aside the reasonable but minority viewpoint that the entire namespace should be scrapped, I hope we can all agree that broad subjects deserve portals but narrow subjects do not. Of course, we have different thresholds for "broad". That leaves the question of automation versus manual maintenance. At one end of the spectrum we have the opinion that not having been edited recently is a sufficient rationale for deletion, even if the portal reflects changes in the pages it transcludes. Others feel that portals should be judged on their content, without needing to consult the page history. "Automation" is also an ambiguous term. It earned a bad reputation from the semi-automated mass creation of portals on narrow topics, seemingly done without previewing the output. But automation has other facets, such as the use of excerpts which reflect the latest version of the advertised article whilst neatly avoiding unattributed copying. Such improvements should not be reasons for deletion; in fact they might even raise a marginal portal's standard above the deletion bar. Certes (talk) 17:31, 26 June 2019 (UTC)
        • Certes, I agree that some measures of automation are helpful. In particular, the automated extraction of lead excerpts is a vastly superior way of building a portal than creating a forest of content forks.
          However, that's a bit of a diversion from what's being discussed here, and Cambalachero seems to be missing the point. The wholly-automated portals are nearly all gone. Other portals are being deleted as unmaintained or abandoned because no new content has been added to the queue for years, or because the content there is just a set of outdated content forks. --BrownHairedGirl (talk) • (contribs) 17:43, 26 June 2019 (UTC)
          • "Fork" is another ambiguous term which may be causing confusion. Many portals have content forks in the sense that they contain text pasted from an old version of an article's lede. That problem is soluble and should be a reason to improve rather than delete (without prejudice to deletion for other reasons). "Fork" is also used to indicate that part of a portal, typically a "Selected articles" panel, bases its choice of articles on a template such as a navbox. I think we disagree on whether the use of a template in this way is grounds for deletion. Certes (talk) 22:46, 26 June 2019 (UTC)
• Oppose Removal and improve - Not only I agree with the above arguments for keeping as I suggest a more objective writing to avoid future invalidation of current MFDs.Guilherme Burn (talk) 19:20, 26 June 2019 (UTC)
• Oppose removal and recognise the important fact: It is central to the premise of a portal, and the failure of the whole portal concept. Oppose hiding the reasons to wind back portals. —SmokeyJoe (talk) 23:46, 26 June 2019 (UTC)

Analyzing the Guideline

The guideline in question is really a three-part rule, which says that portals should be on broad subject areas that will attract large numbers of readers and portal maintainers. The first part of the guideline is the term "broad subject area", which is being used by the defenders of portals as an abstraction. The second and third parts of the rule are the concept of a large numbers of readers, and the need to attract a portal maintainer. The underlying reason why pageview statistics are being quoted is to refute empty statements that a given area is a broad subject area and so needs a portal.

Multiple types of problems are being identified in MFD, including portals that have very few viewers, and portals that have no portal maintainer. Often but not always the same portal has both problems. If the guideline should be revisited, its three parts should be discussed separately.

A Priori and A Posteriori Knowledge

Philosophers make a distinction between a priori and a posteriori knowledge, between knowledge that is available in advance and knowledge that must be based on observation. A particular topic is often said to be a broad subject area, and so the subject should support a portal. It is possible to decide a priori that particular types of subject areas, such as countries, or big cities, are broad subject areas, possibly by estimating the number of articles about the subject, via categories, or via links, or an outline. It is not possible to decide a priori that a subject area will attract readers and portal maintainers. That must be observed, and assessed a posteriori. The a priori statement that a subject area is a broad subject area only addresses one-third of the guideline.

Changing the Guideline

The suggestion is made that the guideline in question needs to be amended or struck for the time being because it is being used to "weaponize" deletion discussions. Is anyone being threatened with the weapons? Is it being suggested only that the reference to a large number of readers be suspended, so as to support portals that no one uses? Is it being suggested also that the reference to portal maintainers be suspended, so as to keep portals that are abandoned? Most of the deletion discussions are about portals that are seen a posteriori to be abandoned. Is it being further suggested that portals no longer need to be about "broad subject areas"?

If it is only being suggested that portals which do not attract large numbers of readers be kept, what will the purpose of these portals be (if not for readers)? If it is also being suggested that portals which have no portal maintainer be kept, what is the purpose of these portals (other than as litter on the information superhighway)? Robert McClenon (talk) 19:39, 6 June 2019 (UTC)

• If it is also being suggested that portals which have no portal maintainer be kept, what is the purpose of these portals. I think this is a very important point. As noted many times in Portal MfDs, "portals are not content" (and not even a stub article), they are dynamic mini-main pages for a given topic. If there is no clearly identified owner and active updater of a Portal, can it really exist?

I believe almost all of the Portals at MfD fail this test. Even where a good-faith editor comes out as a Keep for a Portal and is put to them to take on managing the portal to make it viable, they often decline, this being a representative example: Wikipedia:Miscellany for deletion/Portal:Umayyad Caliphate.

We should consider a rule that a says a portal abandoned for 7 years (e.g. no material content-based edit; ignore housekeeping etc), AND no identified editor-owner today who will commit to its upkeep, gets deleted? I believe that hundreds of WP Portals would fail this test today. Britishfinance (talk) 11:54, 7 June 2019 (UTC)

We cannot say a priori that articles which are unmaintained are of no use because it is not the purpose of articles to be updated. We can say that of portals because they are navigation tools which require regular updates in order to fulfil their reason for existing. I propose something being added along the lines of If a portal has not meaningfully changed or been updated in the past year, a portal can be deleted, provided the maintainer is notified first. Although this may lead to people just updating their portals every 11 months. Ugh. SITH (talk) 13:32, 7 June 2019 (UTC)

Links from Articles to Portals

Both in deletion discussions and on this talk page, there is sometimes mention of the need for links from article space to portals. My question is exactly what is being discussed. Is the idea that the head article should have a link back to the portal from its See Also section, and that any other articles that are within the scope of the portal may likewise link back to the portal from the See Also section? If that is what is intended, I agree that, if there is a portal, there should be links to it, as navigation aids, similar to the use of categories and navboxes and other linking mechanisms. I doubt that such links will significantly increase the viewing of the portal, but I agree that if there is a portal, it should be linked to as a navigation aid. If something else is intended, such as links within the body of an article, I disagree. I think that the absence of links from articles to portals is not a reason to keep an underviewed portal, but I agree that articles should link to portals that exist.

If the portal is deleted, will a bot automatically delete the links? If not, can that be a requested task for a bot? For that matter, can a bot populate articles with links to portals? Robert McClenon (talk) 22:56, 7 June 2019 (UTC)

• The lack of links to portals is the main reason for lack of views, and this is half the problem with the state of portals. The other half of the problem is that portals fork content and do so without sources meaning that they can become disconnected from content policies and present content to readers in a way that would be unacceptable in mainspace. I don’t think it is ok to fix the first problem without fixing the second. —SmokeyJoe (talk) 00:44, 8 June 2019 (UTC)
  • @SmokeyJoe, I disagree that lack of links to portals is a major problem.

The major problem with portals is that very few of them add any value for the reader, so readers don't want to visit them even when signposted. Web portals faded out rapidly because deep linking and powerful search made them redundant, and readers who visit Wikipedia portals will usually come away disillusioned because most of them are so poor.

For evidence of that assertion, just look at the abysmal pageviews for the portals linked prominently on the main page. Way more than most portals, but way less than other mainpage elements. And crucially, after trying those portals, readers aren't exploring other portals.

I would strongly oppose any greater promotion of a type of page which readers clearly don't want. --BrownHairedGirl (talk) • (contribs) 10:41, 8 June 2019 (UTC)

I’m in agreement with that. Portals don’t warrant incoming links, as long as they don’t add value. —SmokeyJoe (talk) 12:23, 8 June 2019 (UTC)

• What a great idea to create infuriated edit wars in quite all articles. Adding each and any wreck of a former portal into the "see also" section of as many articles as possible! This would skyrocket the edit counts of the adders, and the volume of controversies as ANI: he dared to add his so shitty portal to my so nice article! Perhaps, should we start by increasing the number of admins to deal with the mess this will create. Pldx1 (talk) 11:04, 8 June 2019 (UTC)
• To answer RM's technical question, nearly all of the portal links are implemented using the {{Portal}} template, which suppresses the display of a redlink for any of the listed portals that do not exist; it also normally lists the portals to the right of the see also section; see United Kingdom#See also for an example; the template link to the deleted Portal:Commonwealth realms is not displayed. I am less concerned that such links will cause drama, mostly because that horse as already left the barn: the portals team used a bot to add many thousands of such links to articles already (as well as categories; if you beleive the documentation the tempalte is used on 7.7 million pages), and if they noticed, any editors who objected just reverted the adds. UnitedStatesian (talk) 12:12, 8 June 2019 (UTC)

The reason portals have no views anymore is they are not seen by 60% of our readers.....not cause they don't want them or add no value or other BS....it's very simple no one sees them to use them.....like the Wikipedia app....simply not used by many.--Moxy 🍁 23:08, 8 June 2019 (UTC)

So why bother? 60%? Or is it 99.60% who never see a portal? When using Wikipedia as a reader, I sure never see Portals. I land on a page from google, and may read around the topic by following a few wikilinks. —SmokeyJoe (talk) 00:29, 9 June 2019 (UTC)

Agree ....mobile readers don't see the portals and of those 40 percent using desktops only 2 percent will scroll more then 2 times to even make it to see the portal ....same now goes for navtemplates at the bottom of pages. ..again not seen in mobile versions thus why they are not used as the once we're. Noting to do with quality or format or any other guess....simply not seen.--Moxy 🍁 01:37, 9 June 2019 (UTC)

• I believe that prior to this discussion a standardization in all portals of the "related portals" and "subportals" sections should be discussed, so that the reader could navigate through all the portal space from a single portal. For example {{Portals tree}}Guilherme Burn (talk) 15:20, 9 June 2019 (UTC)

Removing Disputed Tag

I have boldly removed the "Disputed" tag from the guideline page. I think that most of the community agrees that we should have some portal guidelines. What that tag on the whole guideline meant was that it was disputed whether there are portal guidelines, and I don't think that is a real position. I suggest that advocates of portals who think that too many portals are being deleted should either suggest some constructive changes to these guidelines, or should recognize that there are a lot of cruddy portals that are candidates for deletion, or maybe should start actively maintaining more portals, or should suggest some constructive changes to these guidelines, or should leave them alone. Robert McClenon (talk) 00:09, 29 June 2019 (UTC)

• Absolute nonsense. It failed early in its proposal cycle, and it has never had support of more than a few enthusiast, much to the grief of the encyclopedia. It failed. To reverse the historic failure, you need an RfC. —SmokeyJoe (talk) 00:15, 29 June 2019 (UTC)

Agree its simply not working...no movement forward. A few have been banned a few more have given up and moved on to other more productive things. Only people still around are people that dont edit portals or those advocating for them but not willing to help. My guess would be to start over at the project page and see if we can come up with some guidelines that all can live with...join us at Wikipedia talk:WikiProject Portals# Single-page layout portals are dead? about trasclution. --Moxy 🍁

User:Moxy - Are you one of "those advocating for them but not willing to help", or can you show us an alternative to deletion of unmaintained portals? (This is meant to be the same request as I have made at Wikipedia:Miscellany for deletion/Portal:Papua New Guinea. Robert McClenon (talk) 20:20, 29 June 2019 (UTC)

It's very concerning that your deleting portal after portal but have no clue how to fix them or are aware of how to inform the community that a portal needs updating. Really not sure you should be involved at all if you're not aware of some basics..... at the MFD I giving you some examples of how to fix the portals and how to tag them.--Moxy 🍁 13:41, 30 June 2019 (UTC)

Ancient History Question

Can someone please direct me to when what have been passing as the portal guidelines became a failed proposal? I have not succeeded in tracking down the failure. I see that the key operating sentence that has been the basis of all discussions about the deletion or creation or retention of portals is: "Please bear in mind that portals should be about broad subject areas, which are likely to attract large numbers of interested readers and portal maintainers." That sentence was added to the guidelines by User:Quiddity on 3 August 2006. I don't see where the discussion was that caused either that sentence or the whole guideline to be a failed proposal. Will someone please provide me with a link or diff? Robert McClenon (talk) 02:53, 29 June 2019 (UTC)

• [10]. Following edits served to obfuscate the failure of the proposed guideline, and serious attention had left. —SmokeyJoe (talk) 07:20, 29 June 2019 (UTC)

Thank you, sort of, User:SmokeyJoe - It appears, from reviewing the talk page archives, that there either never was a formal discussion of the guidelines, or that the discussion was somewhere else. In any event, I can't find where that guideline failed discussion, so I am guessing that it failed discussion because it was never formally discussed. Unless someone else proposes something constructive, I will throw in an RFC to implement the current version of the portal guidelines as guidelines, so that any alternate versions can be discussed at the same time if they are proposed almost immediately after the RFC clock starts. Does anyone else have a different constructive idea? Robert McClenon (talk) 20:20, 29 June 2019 (UTC)

In the meantime I reverted the addition of the "failed" tag. This page hasn't been a proposal for 13 years, so marking it now as a failed proposal is not appropriate, IMO. But if there is talkpage consensus to do so, if course I would have no issues with applying such a tag. @Robert McClenon: where to you intend to open the RfC? UnitedStatesian (talk) 04:34, 30 June 2019 (UTC)

• WP:PROPOSAL.

  If consensus for broad community support has not developed after a reasonable time period, the proposal is considered failed. If consensus is neutral or unclear on the issue and unlikely to improve, the proposal has likewise failed.

After the proposal first failed, the page was abandoned as a backwater. Someone slipped the guideline tag on, but it never had consensus. Portals are moribund, and they never did have support. They were an idea, but they do not come close to serving their nominal purpose. —SmokeyJoe (talk) 04:56, 30 June 2019 (UTC)

They got a lot of support in WP:ENDPORTALS (and in the 12 years preceding), the outcome of which we are stuck with until a future broad community discussion comes to a different conclusion. UnitedStatesian (talk) 05:18, 30 June 2019 (UTC)

The ENDPORTALS showed that the notion of wiping ALL portals was not supported. It did not demonstrate that this page has consensus support as a guideline. A reasonable guideline would recommend when a portal may or should be created, and when not. And many other things that this page woefully fails to fulfill. One thing I would submit is that there are zero wanted missing portals, and that if any guidance is needed, it is on the scope reduction of existing portals. And in the meantime, the progress of Portal MfD shows the guideline to be of pariah status. Either it needs massive improvement, or tagging as failed. —SmokeyJoe (talk) 08:50, 1 July 2019 (UTC)

@SmokeyJoe, feel free to propose a new guideline. --BrownHairedGirl (talk) • (contribs) 00:18, 2 July 2019 (UTC)

It has a completely dubious history, the last couple of years have shown that it has no credibility. What limited serious proposal stage it went through failed. Every point you raised far above I answered. Now you want to deny that there is any dispute over its standing as a guideline, and you want to soft protect the wording. I'm confused. I can only guess that you don't want to address the issue seriously until after all portals have been put through MfD? --SmokeyJoe (talk) 03:45, 3 July 2019 (UTC)

Commentary on Portal Arguments

That is an interesting conclusion by User:SmokeyJoe immediately above, and I will comment on it. This pseudo-guideline, although never formally approved, had been used as a guideline for about a decade. It was then called into question by portal advocates, one of whom said that it should be suspended because it was being used to weaponize deletion discussions, and they then put the disputed tag on it, which I then reverted, but which is now back on. So we don't have a real guideline and have never had a real guideline. But the problem had been that the pseudo-guideline said that a portal subject should be a broad subject area that would attract readers and portal maintainers. The portal advocates were fine being able to wave their hands and say that a given topic was a broad subject area, until other editors began using a quantitative approach, and began using pageview metrics, as well as counting months without maintenance. When portal skeptics began quantifying the concept of a broad subject area, portal advocates said that the guideline should be suspended, so it has been found to have never been a real guideline.

I am willing to put an RFC tag back on this pseudo-guideline and get it approved after all, but it seems that the idea of an RFC on the present page does not have support. So in that case, we have no guideline, which means that portal deletion can use common sense, which is trending toward deleting little-used and little-maintained portals.

That seems to be where we are, for now. Robert McClenon (talk) 21:05, 1 July 2019 (UTC)

Just need to work on the page.....gear it towards what is needed in a portal to keep it update. We need to fix what the criteria are so deletionest cant use it in a bad way,,,should be greadre towards improvement and sustainability over deletion criteria. As on now 70 percent of the portals are gone and all will be gone because of the attribution loop hole that is now being used. We need to setup a tag system to indicate to editors and readers things may need updating or the format change to deal with attributions.--Moxy 🍁 21:31, 1 July 2019 (UTC)

What Moxy means is that he wants the guideline changed so that it prevents the deletion of crap which has been abandoned for a decade.

Per WP:PORTAL, "Portals serve as enhanced 'Main Pages' for specific broad subjects". A set of a dozen decade-old content forks is not an enhanced main page, and I strongly object to any attempt to rig the guidelines against cleaning out that sort of junk. --BrownHairedGirl (talk) • (contribs) 00:16, 2 July 2019 (UTC)

• "This pseudo-guideline, although never formally approved, had been used as a guideline for about a decade." To a massive, monumental failure. I feel a little guilty, having encourage TTH to develop auto-portals, but I don't think that limits me from observing that the guideline approval process for this page never succeeded, but in fact failed, before the guideline tag was surreptitiously added, to the detriment of portals. --SmokeyJoe (talk) 03:48, 3 July 2019 (UTC)

Recreation as redirects?

What are people's opinions of, after a portal is deleted at MfD, recreating it as a redirect to a higher level portal? Examples would be redirecting deleted U.S. State portals to Portal:United States, or deleted India state portals to Portal:India. My current view is this would usually do a disservice to our readers, as someone following the link is likely to be disappointed that the broad higher level portal does not have the specific information they are probably looking for. I also think it is contrary to the MfD consensus; if the consensus of !voters and the closer felt a redirect was the best option, the MfD discussion would have been closed as "Redirect to . . .", not as Delete. Thoughts?

• This seems to be exactly my proposal of March 2017 at Wikipedia_talk:Portal/Guidelines/Archive_6#Portals_are_moribund. Archive moribund portals by redirection to viable portals; or failing that, by redirection to the parent article. If there were broad agreement to do this, then MfD would not need to be part of the process.

If the redirect to a viable portal would be a "disservice" (does this speak to the general failure of portals to serve their ostensible purpose?), then don't do that redirect. Consider redirecting to the parent article. Generally, I think this is more likely to be a good service, navigation from articles is very good, better than from Portals, more NPOV-compliant for example.

I advise against trying to read any depth of consensus from the many MfD discussions, as they are poorly participated. I think the limit of reading is that most of these portals are not a good idea, going forward. I think they are generally silent on options such as redirection, and when I've mentioned redirection no one engages. Post deletion, creation of a redirect has always been considered an acceptable editorial action, barring the reasons to delete a redirect. --SmokeyJoe (talk) 05:21, 5 July 2019 (UTC)

Regional Portals

Some editors have stated that particular levels of regions should have portals. User:Kusma wrote (in April, in an MFD): "all countries should have portals". User:Northamerica1000 wrote: "I consider U.S. states to meet WP:POG guidelines in terms of being broad enough in topical scope to qualify for a portal." Such statements raise a two-part question, having to do with people, and with policies.

Who Should Do What?

The first part of the question is: Who is expected to do what in order to provide the portal? Should Wikipedia provide and maintain a portal? Should Wikipedia provide a portal without maintaining it? Should Wikipedia provide a portal, contingent on having a portal maintainer and a portal maintenance plan? Should the Internet, of which Wikipedia is a prominent site, provide a portal? If only that, the government of the nation, state, or province can and almost certainly does provide and maintain a portal in the form of its web site, as do lesser regions such as counties, cantons, districts, communes, cities, towns, townships, boroughs, and villages.

If Wikipedia is expected to provide and maintain a portal, how can that obligation be reconciled with Wikipedia is not compulsory? If Wikipedia is only expected to provide an empty portal, what good is that? It appears that the implication is that Wikipedia is expected to provide a portal to a maintainer and to continue to keep the portal facing outward toward the readers whether or not it is being maintained. Portal advocates who think that particular levels of regions "should have" portals should clarify what obligation they are implying and on whom.

Impact on Policies and Guidelines

The second part of the question is how the idea that countries or states "should have" portals should be reflected in Wikipedia's policies and guidelines. At present, the page that is designated as the Portal Guidelines states that portals should be about broad subject areas that will attract readers and portal maintainers. Portal advocates have focused on the reference to "broad subject areas" and have disregarded the two-part reference to readers and portal maintainers. At present, the status of the portal guidelines is in dispute. Those who would like to retain existing regional portals, and possibly create more regional portals, may either deal with the existing guidelines or propose to revise them. If they prefer to deal with the existing guidelines, there are two issues. The first is that the status of the guidelines is in doubt, appearing to have been a failed proposal. The second is that the existing document refers to readers and maintainers, who cannot simply be assumed or willed into existence. Since the present (contested) guidelines refer not simply to broad subject areas, but to broad subject areas that will attract readers and portal maintainers, any specific portal can be shown by observation not to be attracting readers or maintainers.

The other option for the advocates of regional portals, or for anyone who wants to provide better guidelines with regard to portals, would be to publish a Request for Comments to implement new portal guidelines, either the old guidelines, or a slightly revised version of the old guidelines, or an entirely new set of guidelines. In that case, advocates of regional portals should be on notice that the new guidelines either should explicitly identify certain subjects that are considered portal-worthy even without maintenance, or it can be understood that regional portals, like other subject areas, are only considered to be broad subject areas if they demonstrate that they attract readers and maintainers. Robert McClenon (talk) 15:05, 5 July 2019 (UTC)

Regions should not have portals

Regions should not have portals. Countries certainly should not have portals, because countries have strong biased POV attractiveness. Country portals read like tourism glossy brochures. --SmokeyJoe (talk) 07:25, 5 July 2019 (UTC)

Color-coded own-country bias of Wikipedians. --SmokeyJoe (talk) 07:29, 5 July 2019 (UTC)

Is User:SmokeyJoe referring to countries (nations) or counties (subdivisions in some nations) or both? Robert McClenon (talk) 15:05, 5 July 2019 (UTC)

Typo. Countries, aka nations, not counties. —SmokeyJoe (talk) 00:41, 6 July 2019 (UTC)

Regions that have either governments or tourist bureaus can always provide their own on-line tourist brochures on the World-Wide Web, and Wikipedia can always link to those from the External Links section. Robert McClenon (talk) 15:05, 5 July 2019 (UTC)

No. Wikipedia is not for linking promotion. —SmokeyJoe (talk) 00:41, 6 July 2019 (UTC)

Only Front Page Portals

The only viable portals are the front page portals, which roughly correspond to Vital 1 articles, which corresponds to portals currently achieving 1000 views per day (rounding to the nearest 1000). These are:

• Portal:Arts
• Portal:Biography
• Portal:Geography
• Portal:History
• Portal:Mathematics
• Portal:Science
• Portal:Society
• Portal:Technology

Every region should be served by navigation tools under Portal:Geography. Every country should be findable within two clicks below Portal:Geography, and Portal:History, and Portal:Society.

The free-for-all Portal creation allowed by this pariah guideline is demonstrably a monumental failure. As pointed out in MfD after MfD, portals are barely viewed compared to their parent articles, and they are neglected. Was it ~500 portals per active portal editor, using a very low threshold for active portal editor?

Archive all other portals. Re-create them ONLY of they are worthy of being listed with the other front page portals, meaning they are philosophically distinct, well recognized as a top level subject, and are not subject to whole-portal biased POV attractiveness. --SmokeyJoe (talk) 07:25, 5 July 2019 (UTC)

Any proposal to delete/orphan/hide 99% of portals is effectively a re-run of WP:ENDPORTALS. If you feel that community opinion has reversed since 2018, I suggest that you raise another RfC to overturn the current consensus. Certes (talk) 07:32, 5 July 2019 (UTC)

Indeed, that appears a good way forward. Reversed community opinion? No. WP:ENDPORTALS was fatally flawed by including these Front Page Portals. There is an obvious role for these Front Page Portals going forwards. The trend at MfD shows no sign of relaxing before reaching these portals. --SmokeyJoe (talk) 07:38, 5 July 2019 (UTC)

Per WP:AGF, I remain confident that the assurances that we are on our last few MfDs will be respected. Certes (talk) 07:45, 5 July 2019 (UTC)

I am not aware of any assurance that we are approaching the last few MFDs. A statement by User:BrownHairedGirl may be misinterpreted. She has said that she has, more than once, thought that she is almost finished nominating portals for deletion, and then she repeatedly becomes aware of more unmaintained cruddy portals. The "assurance" may be a wishful-thinking misinterpretation of her statement. She has never said that she intends to finish at some particular time, but only that she hoped to be finished and then saw that the job was bigger than she thought. I am aware of many more portals for which I am prepared to !vote for Delete or Weak Delete if someone else nominates them. I know that I am surveying portals, and am currently at 467, of which at least a hundred more should be deleted. There is a difference between Assuming Good Faith on the part of editors who reasonably disagree, and wishful thinking that misinterprets what the other reasonable editors have said. I am aware of no assurances that we are approaching the end of the cull. Robert McClenon (talk) 15:13, 5 July 2019 (UTC)

What assurances? What is the criteria being used for the nominators. If the nominators have a criteria, I guess that is the de facto line. Are many-portals advocates not defending portals due to this assurance? --SmokeyJoe (talk) 07:50, 5 July 2019 (UTC)

Agree with SmokeyJoe, I for one have given no such assurances. There are still a lot of portals (including at least one newly recreated one) that IMO do not cover broad subject areas, a set which overlaps but does not exactly conform to the set of portals that are abandoned/unmaintained. But disagree with SmokeyJoe that this guideline allowed the free-for-all creation; in fact members of the creation team made major undiscussed edits to the guideline (since reverted) in order to give cover for the free-for-all. UnitedStatesian (talk) 14:51, 5 July 2019 (UTC)

@Certes, see the comments by Robert McClenon, who gets it right. I have several times given estimates of where I think that final numbers will fall, but the last few times I have noted that my previous estimates shave been wrong because we keep finding yet portals which are abandoned, stillborn, or otherwise fail POG.

The answer is that I will continue to bring substandard portals to MFD for as long as I find them. There are currently 904 remaining portals, and I personally know of at least another dozen which I will bring to MFD when I have time. Beyond that, we'll see what we find.

One of the great sadnesses for me in all this is the sheer sullen passivity of the portal fans. Certes has repeatedly labelled the deletion of abandoned portals as a "war of portal", a term which he first applied to deletion of the automated portalspam unleashed by TTH. This unreasoned kneejerk defence of any page in portalspace has been repeatedly rejected at XFD, and it's very sad to see any adult continuing with such nonsense.

Other portal fans moan about the alleged evils of "deletionists". Others such as NA1K pop up at MFD to moan that assert that they personally believe that a certain type of topic is axiomatically "broad", despite the clear evidence that a portal massively fails the requirements of POG.

What's missing in all of this is any active assessment of portals by the portal fans. How many still use the redundant content-fork model? How many have been abandoned? I see absolutely zero sign of any of portal fans been trying to answer this sort of question. So far as I can see they have no vision for portals and no plan, let alone a broad community consensus for either ... just a reactionary desire to stop the deletions of a type of pages which they eroanly like creating, but which readers don't want. --BrownHairedGirl (talk) • (contribs) 14:40, 6 July 2019 (UTC)

• Many of the lesser portals should be merged into the Front Page Portals. Also, Portals should not be linking to WP:Space, including the WP:WikiProjects. --SmokeyJoe (talk) 07:53, 5 July 2019 (UTC)

Regarding your last point - is there any problem with a portal having a link to the corresponding wikiproject (a small advert for a single wikiproject) ? DexDor ^(talk) 11:47, 5 July 2019 (UTC)

That sounds ok. If it were clear that the link was taking the reader from the Portal to Wikipedia backrooms, that would be ok, good even. I was browsing portal links, and found whole lists that were unexpectedly taking me to WikiProjects, which are not reader pages, and worse they are mostly inactive. —SmokeyJoe (talk) 12:01, 5 July 2019 (UTC)

• I disagree with this proposal; it reverses cause and effect. The main page portals get lots of views because they are on the main page; I believe if we put Portal:Briarcliff Manor, New York on the main page it would get thousands of daily page views also. The question is, if the main page portals were removed from the main page, would their viewership drop to the very low background level also? UnitedStatesian (talk) 14:51, 5 July 2019 (UTC)
• The choice of these several portals is not really because they only achieve 600+ views per day. It derives from past sensible decisions, is extreme high visibility, on the main page, as to what are the most important set of different portals. Now, as we see that by being located on the top of the main page, they still only get 1-2 thousand hits per day, this says that there is only very limited interested in browsing portals. It would be improved with better presentation, eg a heading “Encyclopedia entry portals”, and that might be a good suggestion for change of the main page, at the moment they are words hanging with little context. Another to put this is: There should only be so many portals as belong being listed at the top of the main page. All other portals should be converted to belonging under these portals, or deleted. —SmokeyJoe (talk) 00:54, 6 July 2019 (UTC)

What do you mean by "belonging under these portals"? If you mean that the others are linked to from the 8 top level portals (possibly via intermediate portals) then that may already be the case - e.g. Portal:Technology currently has links to 28 related portals. DexDor ^(talk) 05:56, 6 July 2019 (UTC)

What do I mean? I am a little bit brainstorming and not entirely sure myself. I know that when I go to a portal, Portal:Technology for example, what I find is not what I think one should find on entering a navigation portal. There is too much information, a variety things of interest that I might follow if I didn't arrive with some kind of interest, but there is a lack of logic that I can follow to what I think I want.

Portal:Technology#Related Portals seems to be a semi-random mix of guesses of what I could also be interested in. It seems peculiar to find Portal:Geography as a related portal when Portal:Geography is already a top level portal. The related portals are a mix of price and broad, it feels very half done, in fact nowhere near half done.

Under Portal:Technology, on its front page, I expect to find easily navigable, logically organised, sub portals of specific technologies. There may be crossover with geography, but geography is not a subtopic of technology. Bridges is too specific at this level. War is way too broad to be considered a technology subtopic. Radio, television and telecom are way too similar to be worth listing together at the top level of technologies.

I'm afraid, there more I look at portals, the more I find them frustrating. So many good intentions, so little discipline. --SmokeyJoe (talk) 07:32, 6 July 2019 (UTC)

Discussion of New Guidelines

I have started discussion of new guidelines at Village pump (policy). My intention is, in about a week, to start a Request for Comments on three or four alternate sets of portal guidelines. One of the candidates will be the current guidelines (or long-term pseudo-guidelines). A few other candidates can be proposed. I see that one idea is that of User:SmokeyJoe who will limit portals to those linked to the Main Page. Other ideas have included that every portal should be sponsored by a WikiProject. Alternatively, some guideline that is more permissive of portals may be considered, such as one that accepts regional portals.

Take your thoughts to Village pump (policy). Robert McClenon (talk) 06:43, 6 July 2019 (UTC)

Do not expect other editors to maintain a portal you create.

Says who? Senegambianamestudy (talk) 05:46, 15 July 2019 (UTC)

• It implies that the community does not want new portals, but will give you leeway if you are actively working to make it good. --SmokeyJoe (talk) 07:09, 15 July 2019 (UTC)

  Indeed it does. However, that's not the way Wikipedia works: pages outside userspace are collaborative projects rather than personal responsibilities. The creation of a new portal might provoke outrage from a few vocal editors, but the community has never deprecated it. Certes (talk) 10:34, 15 July 2019 (UTC)

  • In any other context, that comment by Certes would be a extraordinary remark.

Hundreds of portals have been created over the years by a lone enthusiast, and then left to rot as the creator moves on to other interests, or stops editing.

That's why over 600 such old portals (out of a total of 1500) have been deleted at MFD in the last few months: they were abandoned and did't attract readers.

Out of a total of 1,500 portals, that 40% ratio of abandoned junk is appalling, and that's not even the full extent of it. There are at least 50 more portals which have failed my preliminary checks and which as time permits I will scrutinise further for probable MFD.

It seems to be a matter of zero concern to Certes that such a high proportion of portals are abandoned junk. The portals project has never even done any systematic assessment of the state of portals; when I checked last week, ~73% of portals were in Category:Unassessed Portal pages.

Per WP:PORTAL, "Portals serve as enhanced 'Main Pages' for specific broad subjects". But the Wikipedia main page requires huge amounts of work; it is maintained by several large teams of busy editors. A mini-mainpage also needs lot of ongoing work if it is going to value over the head article. Yet for years, reader have been lured to hundreds of pages which fall abysmally short of that goal, but the reaction of Certes to this sea of abandonment is that is simple that it's not expressly forbidden.

I see no concern in this for readers. --BrownHairedGirl (talk) • (contribs) 12:10, 15 July 2019 (UTC)

• It is a very useful warning. When you create (or take over) a portal, you should be aware just how much work that is going to be in the future. If you are lucky, others might help (depending also on the subject area and how well tied in your portal is with a WikiProject or other group of editors), but you should expect to do all of the necessary maintenance work for the next five years or so, or not create the portal. —Kusma (t·c) 12:39, 15 July 2019 (UTC)
• I believe the sentence's origin comes from the 2 May 2016 version that BrownHairedGirl reverted to in September 2018. The related sentence isn't introduced in 2 May 2016; I'm just noting that it predates all of the current discussions on portals. In that version, the sentence reads as follows: Do not create a portal if you do not intend to assist in its regular maintenance. I think there's a more literal reading of the sentence than some of the portal-specific interpretations being offered. Just like any initiative, until you have people signed up to help and are following through, don't assume they're going to appear. isaacl (talk) 13:46, 15 July 2019 (UTC)
• I thought Wikipedia was suppose to be a collaborative project where we all chip in to help better this project? Has Wiki turned into a bureaucracy and "you do your thing and I'll do mine" all of a sudden? If so, what are we all doing here?Senegambianamestudy (talk) 06:15, 16 July 2019 (UTC)
• I do not see portals as part of the project, it is an overlay that only exists by force of will; in theory or implementation they are not collaborative content and highly vulnerable to deletion. The creators who arrive and are persuaded this is a worthwhile endeavour, that preservation as articles or other cited content as part of wikipedia's processes is a reasonable expectation, are being misled and should question how they invest their time. Portals are near-deprecated, if there were one or two retirements then they might be used as editor collaboration pages (again). cygnis insignis 18:53, 16 July 2019 (UTC)

Alternatives to deletion

I think too many people remain oblivious to the merits to exhausting alternatives to deletion before seeking deletion. It has a strong policy basis, in WP:ATD. Jumping straight from structural disputes to deletion is very divisive, is damaging to editors on the XfD losing side, and when overdone results in the loss of good work that could have been reused elsewhere. XfD discussions are strongly time-limited, closers are encouraged to make rough consensus calls, and doing this repeatedly is not a collegial method of consensus decision making.

At per my recent post at Wikipedia:Miscellany for deletion/Portal:Seventh-day Adventist Church, I am thinking that for not horribly failing portals, they should be moved into the WikiProjects they serve. Within the ProjectSpace WP:WikiProject titling scheme, they can exit the failing premise that they are proving suitable reader-facing material.

--SmokeyJoe (talk) 01:10, 16 July 2019 (UTC)

As mentioned above and many other talks most would have no problem with this but the deletion board is not even aware of what to do for attribution to keep these let alone even going to try to fix any problems or agree to giving any time for a fix. Your best bet is to try and be ahead of them fixing or moving portals they have not seen yet....once at the deletion board it's all over even if you put effort in to fix them.--Moxy 🍁 01:27, 16 July 2019 (UTC)

Once a viable ATD (alternative to deletion) is proven, it becomes a compelling argument at XfD. Hypothetical ATDs are not compelling, especially if ignored by everyone else. "Keep" arguments, if unpersuasive, are not read as steering majority "delete" arguments to an ATD middle ground.

MfD now has more Portals that are not junk, but even in some ways better looking than their parent article and parent WikiProject. Wikipedia:Miscellany for deletion/Portal:Seventh-day Adventist Church and Wikipedia:Miscellany for deletion/Portal:Climbing (2nd nomination) are two examples on my watchlist. Invite recent editors on these Portals, User:Hecato, User:Catfurball, User:Northamerica1000, to comment.

I propose that middle rank portals, like these, should not be deleted if judged unsuitable as reader-facing. Instead, Move Portal:X to WP:WikiProject X/Portal. This will largely depopulate PortalSpace, without having anything deleted, and the page can continue to serve all the editor-related purposes. --SmokeyJoe (talk) 01:52, 16 July 2019 (UTC)

This would be a great alternative and many projects could take the time to improve them. As of now things like Wikipedia:Miscellany for deletion/Portal:Military of the United States that could have been moved are being deleted for no attribution dispte what can be done to fix that with ease as pointed out during the RfC. Really not a good idea to let portal deletion be done by only 2 or 3 votes....so anything that might help ease the tention between proponents and deletors would be great.--Moxy 🍁 03:27, 16 July 2019 (UTC)

Two of us agree already. See Wikipedia:Portal/Guidelines#Portal culling. --SmokeyJoe (talk) 04:30, 16 July 2019 (UTC)

• An idea is to tag portals that need work with the {{Update}} template and then notify relevant Wikiprojects about a portal's need for updating, expansion, cleanup, general improvements, etc. North America¹⁰⁰⁰ 04:58, 16 July 2019 (UTC)
  • This template, when used on portals, should categorize the portal as being identified as needing updating. After one year that will be good evidence that the portal is moribund. Should it then be deleted, or moved inside the WikiProject? --SmokeyJoe (talk) 05:36, 16 July 2019 (UTC)

• Regarding a one-year mark, I'd have to think this over more, but WP:DEADLINE comes to mind. There is no deadline, at least theoretically. However, I understand that users want portals that are complete, useful, factual and up-to-date. A one-year timespan would be fair in terms of allowing some time for improvements/updates to actually occur. North America¹⁰⁰⁰ 05:53, 16 July 2019 (UTC)

• Seeking harmony with WP:DEADLINE, and WP:Preserve, WikiProjectifying neglected update-requiring portals is a solution, no? --SmokeyJoe (talk) 06:01, 16 July 2019 (UTC)

• Could be. I don't want to rush to a snap judgment, and will think it over. At any rate, thanks for sharing your ideas. Ideas are a good thing, and can lead to solutions. North America¹⁰⁰⁰ 06:32, 16 July 2019 (UTC)

• @SmokeyJoe, note what happened here.

Despite all NA1K's clamouring for tagging portals with {{update}}, the bottom line is that NA1K won't even support Wikiprojectifying portals which remain abandoned for a year after being tagged.

In other words, NA1K wants abandoned crap portals to continue to be advertised to readers indefinitely, regardless of how crap they are or how long they have been abandoned ... and regardless of the possibility of them being moved to another place where they could be developed.

This approach brings zero benefit to readers. It simply underlines what long been clear; that NA1K and many other vocal portalistas are simply engaged in a circular exercise of keeping portals because they like making portals, without regard to reader benefit. --BrownHairedGirl (talk) • (contribs) 09:01, 17 July 2019 (UTC)

• I have some ideas for this, but they might be flawed, so feel free to criticize. If a portal is inactive with an {{Update}} template for a certain amount of time (let's say 1 or 2 years for the sake of the argument), then the maintainer(s) get a notice on their talk page, to which they can respond by editing the portal or giving a good reason for there being no edits (maybe the portal does not require updating for whatever reason). If they do not respond in any way after 14 days, then the Portal is moved to the draft space, or maybe to a newly created "inactive portal" space. There should be a longer grace period for inactive portals than the usual 6 months draft space time. They are not exactly drafts and we decided they were useful or valuable at some point in time. Maybe it could even be indefinite for historical reasons.

Moving a portal to this other space would make the portal link template in articles hide the link to the portal just like if it was deleted, so it is removed from the user space, but still available in the editor space. If another editor wants to take over and they are happy with the quality of the portal, then the portal can be moved back into the proper portal space.

There should also be a clear and easy way for other editors to see what portals need attention and to take over as maintainers. Maybe a centralized technical wiki page where portals are listed by their last edit time and number of maintainers. The rules for adopting a portal should be clear cut to encourage portal adoptions and to avoid angry exchanges between new and old returning maintainers. It would also be good if there was some kind of noticeboard that allows maintainers to look for co-maintainers. --Hecato (talk) 06:51, 16 July 2019 (UTC) (Note: edited 20:05, 16 July 2019 (UTC) )

• Thanks Hecato.

* A portal must have a list of maintainers?

* I don't think that a portal the maintainer-challenge should be applied if the portal doesn't have the {{update}} tag.

* No, please do not use DraftSpace, WP:DUD and DraftSpace is only useful for COI article writers. Every Portal surely should have a WikiProject, why not use the WikiProject subpages?

* {{update}} tag categorization should make it easy to navigate to portals needing updating.

* The rule for adopting a portal should include adding your name to that list of maintainers? Apart from that, why should there be rules?

--SmokeyJoe (talk) 07:25, 16 July 2019 (UTC)

Regarding having maintainers, the {{Portal maintenance status}} template is relatively new, created on 9 June 2018. It is quite likely that many users don't even know about its existence. People aren't going to be adding their names to a template they don't know exists. Another matter is that per WP:NOTCOMPULSORY, requiring maintainers is not particularly policy compliant. Conversely, we do want people to maintain portals to keep them in shape. North America¹⁰⁰⁰ 07:44, 16 July 2019 (UTC)

Yet more tendentious nonsense from NA1K.

1. If an editor is actually maintaining a portal they will be aware aware of {{Portal maintenance status}} having been added to the portals, and they will be aware of whether the portal is categorised in either Category:Portals with no named maintainer or Category:Portals with no named maintainer. NA1K wants us to believe that there are editors who are actively maintaining a portals but are unaware of any of this, which is implausible.
2. This is probably about the millionth time that NA1K has set out deceive editors by claiming that there is some incompatibility between requiring that a portal have maintainers and WP:NOTCOMPULSORY. That is patently untrue, because there is no element of compulsion on any editor to sign up as a maintainer, or to continue to maintain beyond the point they want to.
   This has been pointed out to NA1K at many discussions, who never replies, but simply continues to repeat the same falsehood whenever NA1K believes that it is convenient to do so.

One of the biggest problems in discussing the future of portals is the ongoing problem that most such discussions include participation by NA1K, but NA1K is a liar, by which I mean that NA1K repeatedly makes statements of fact which they know to be demonstrably untrue. This systematic deception poisons the atmosphere. --BrownHairedGirl (talk) • (contribs) 19:17, 17 July 2019 (UTC)

• Given the recent exchanges in the MfD section I assumed a portal needs to have at least one maintainer. Excuse my ignorance, I am a relatively new user. Please tell me if there was some consensus decision on this. Maybe some portals do not need maintainers. This could be marked somehow in the portal.

I agree that portals might be left alone if they do not have an Update tag. That is probably a good idea to avoid moving portals unnecessarily. We don't need to fix a problem that does not exist.

Moving the portal to a dedicated "inactive portal" space would make it easier to keep track of such portals from a technical standpoint. Also I fear declaring the portal to be the "property" (can't think of a better term) of the WikiProject might discourage outside editors from being brave and take over the portal. I do not want portals to be shoved into a dark corner and forgotten about. But if a dedicated "inactive portal" space is impossible, then using the WikiProject might be the second best option. I can already see some problems with sub-page moving though.

In regards to rules, I was thinking about such things as allowing the new maintainers to make drastic changes to the layout without talking to the old maintainers. Or allowing new maintainers to take over before it actually gets so far and the portal gets moved, to avoid red tape. If there is a rule for such things, then the new maintainer is not perceived to be "stealing the portal" from the old maintainers. --Hecato (talk) 08:00, 16 July 2019 (UTC)

I think it is natural that Portal X “belongs to” WikiProject X, if the name X is an exact match. —SmokeyJoe (talk) 08:18, 16 July 2019 (UTC)

They are not always an exact match and some Projects might be related to several portals if the scope of the project is wide enough, like science for instance. Also I want to make clear I would only support moving portals if it was for the sake of improving them and then moving them back into the regular portal space. I would not support it as a way to get rid of a portal indefinitely. --Hecato (talk) 09:48, 17 July 2019 (UTC)

Not all portals need regular maintenance. Today's version of Portal:Mathematics will still be as valid in 2029. A fast-moving field of study needs regular updates, and many portals have been deleted because they became outdated, but "no maintainer" is not in itself a valid argument for deletion. Certes (talk) 10:46, 16 July 2019 (UTC)

Agreed, some fields are not changing very often and could already have most articles that would be worth creating about them. --Hecato (talk) 09:48, 17 July 2019 (UTC)

• A really simple Alternative To Deletion of a portal would simply be "working harder". But practice has proven that while "keep !voters" are not so rare to appear, people willing to maintain a given portal to the point of really doing the job aren't falling from the sky like a hard rain. More than often, a given portal was the emerging part of a WikiProject. But most of these WikiProjects are past and gone, i.e. dead without any hope of resurrection and so is the related portal. Moving a defunct portal from Portal:Defunct_Portal to Wp:WikiProject_Defunct/Defunct_Portal would stop luring the readers by pretending that Portal:Defunct_Portal remains an actual navigation tool (if it ever was), and would provide a better place to let it rot in oblivion. But this would require to patch each and any template, to be sure they will also work in the new space. Is there any keeper who want to spent any part of their precious time to patch what requires to be patched ? Revisiting Wikipedia:Miscellany for deletion/Portal:Korea gives some hint about that: since 19 April 2019, the keepers haven't been able to fix all the outdated snipets of this portal. May be they are waiting for someone else to come and do the job in their stead... but peones are learning! Pldx1 (talk) 08:55, 16 July 2019 (UTC)

  I am not the only editor who stopped improving portals after the pages were deleted, reverted or "alternative-to-deleted" (overwritten by a redirect). As deletions seem to be slowing (April: 4328; May: 689; June: 244; July 1–15: 68) we may soon be able to revert that spiral of decline, if editors can find the motivation to resume their thankless task. Certes (talk) 10:55, 16 July 2019 (UTC)

• 

  Average daily pageviews of portals on en.wikipedia in April–June 2019

  @Certes:, you continue to confuse cause and effect.

The deletion of so many portals has happened because the neglect has been systematic and long-term. Any idea that a twelve-year-old-pattern of neglect is the product of a 4-month cleanup process is tendentious nonsense.

The reality is that the spiral of decline is more than a decade old. It has four components which all feed off each other:

1. editors don't maintain portals
2. editors don't make links to portals
3. readers make little use of portals, even when they are linked.
4. the multi-subpage design of most portals is an outmoded disaster. It requires high maintenance, but makes maintenance hard. New technology means that it adds no value.

The graph of average daily pageviews of portals on en.wikipedia in April–June 2019 shows that isn't an issue of some individual portals being underlinked. It's a systemic problem: readers don't want them.

Even a lovingly-curated, polished portal like Portal:Cheshire, with plenty of incoming links, still receives utterly abysmal pageviews: an average of only 17 per day in the first half of 2019.

So those of you object to deletions: what exactly are you trying to achieve?

Wikipedia clearly still has far more portals than readers want to use, and far more that editors want to maintain. New features have made the multi-subpage model of portal redundant, yet we still have prominent members of portals project scurrying around doing the busywork of creating yet more of these redundant content forks, and piling on the maintenance nightmares ahead.

After months of researching portals, and endless discussions, I have yet to see any plausible case for how most of even the remaining set of portals are a net positive to Wikipedia. Overwhelmingly, they are not being read, and they are not being maintained.

Various mantras are trotted out by portalistas, but never tested

• "involve WikiProjects", say the portalistas. But the related WikiProjects are almost always moribund or not interested in the portal".
• "make more links to the portals", say the portalistas. But the evidence is that even massively-linked portals still have pageview levels somewhere between the pathetic and the abymsal.
• "tag it with {{update}}, say the portalistas. So where is the evidence that this works? Where's the evidence that if the remaining few hundreds abandoned portals are tagged with "update", that they will be updated?

So what exactly is going on here, Certes?

1. 94% of portals get an average of less than 100 page views per day. Do you think that is enough to justify keeping all those portals?
2. What do you propose to do about the redundant content fork model of portal?
3. The portals project is over a decade old, but still has no systematic process of rating portal by quality or importance, let alone with community support

In short, there is no vision, and no plan. All I see is small group of editors who enjoy creating and or editing the unreferenced edifices which they call portals, and who stridently resist any intrusion into the thoroughly unencyclopedic hobby which the pursue on Wikipedia's servers.

You may think that's harsh ... but if so, where's your plan to make the hokey-stick graph redundant? --BrownHairedGirl (talk) • (contribs) 16:16, 17 July 2019 (UTC)