Wikipedia talk:Portal guidelines

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia talk:Portal)
Jump to navigation Jump to search

WikiProject Portals (Rated Project-class)
WikiProject iconThis page is within the scope of WikiProject Portals, a collaborative effort to improve portals on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Project  This page does not require a rating on the project's quality scale.
Note icon
See also: Instructions • Guidelines • List of Portals

Notability Discussion: Revived[edit]

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:

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)[edit]

@The Transhumanist, Evad37, Certes, Dreamy Jazz, Pbsouthwood, SMcCandlish, FR30799386, BrownHairedGirl, Godsy, Finnusertop,, 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 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. Face-smile.svg — AfroThundr (u · t · c) 17:31, 7 November 2018 (UTC)

Second sentence contradicts WP:NOTCOMPULSORY policy, and should be removed[edit]

From the lead, I removed "Do not create a portal if you do not intend to assist in its regular maintenance" , as it violates the policy WP:NOTCOMPULSORY, which states: "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. " See also Wikipedia:Wikipedia is a volunteer service.

The new portal designs are automated, so that portals keep themselves updated almost fully automatically, taking advantage of edits made to the encyclopedia itself. WikiProject participants handle other maintenance that arise. Regular maintainers are no longer needed, and never materialized anyways. The lack of maintainers is why the portal system overhaul is taking place. And according to the WP:NOTCOMPULSORY policy, we can't compel or require editors to work any harder on a page than they are willing to provide at any given moment.

Someone reverted the removal, but, as the sentence is in error because it contradicts policy, someone should go onto the page and directly remove it.    — The Transhumanist   05:04, 7 November 2018 (UTC)

I agree that the current wording is inappropriate, but could be modified to advice not to waste one's efforts, as an out of date portal is at risk of nomination for deletion.
Something like:
Portals which require manual updating are at a greater risk of nomination for deletion if they are not kept up to date. Do not expect other editors to maintain a portal you create. To avoid this problem portals can be created that automatically update. · · · Peter (Southwood) (talk): 05:30, 7 November 2018 (UTC)
@Pbsouthwood: Nice. This reflects the current state of affairs for portals. Perhaps change "Portals which require manual updating" to "Manually maintained portals".    — The Transhumanist   06:13, 7 November 2018 (UTC)
  • I oppose this change, because its main purpose seems to me to legitimate the bad practice of the proposer, @The Transhumanist (TTH). The same editor has also been the most prolific creator of portals of in recent months, so the change seems to be mostly about personal benefit.
The problem comes in two parts:
  1. The Transhumanist's drive-by creation of portals, sometimes as rapidly as one per minute. The result is portals which are created with basic errors, and then abandoned.
  2. The need for ongoing maintenance has been massively reduced, but not eliminated.
As an example of the problems caused by drive-by creation, I note Portal:Fresno, which I just discovered. It is categorised in Category:Fresno, which is a disambiguation category; it should be in Category:Fresno, California. That is just a variant of the problems which drew my attention to portals in September, when TTH had created dozens of portals whose only category was a non-existent one which then showed in Special:WantedCategories.
In those cases, TTH's sloppiness extend to not even glancing at the bottom of the page to see the category list consisted of a redlink. In the case of Portal:Fresno, the category is blue, but no page should be in it, because it is a disambiguation category. I have just spent five minutes trying to figure out how to correct the category, but it seems to be generated by some some obscure template, so 9 weeks after its creation it remains unfixed.
The same lack of basic care which led TTH to drive on by without even checking whether the portal was in any valid category also led to the categorytree display being broken, because it too was linked to Category:Fresno rather than Category:Fresno, California. I fixed that[4], but the categorisation of the portal remains broken. It isn't even in any subset of Category:Portals, e.g. Category:California portals and Category:United States portals by city. So anyone trying to monitor or maintain portals won't find this one.
These problems with TTH's drive-by-creations are widespread: it is a mass creation of messes for others to tidy up, and here TTH wants to change the guidance to rubber-stamp that bad practice.
Secondly, the need for portal maintenance has been reduced, but not eliminated. Despite the fix I did to the category display, Portal:Fresno does not show up in Special:WhatLinksHere/Category:Fresno, California. So if the category is renamed, there is no way for those implementing the move to detect that the portal needs updating. (The lengthy thread on my talk at User talk:BrownHairedGirl#Linking_to_portals_under_construction (permalink) is mostly about these problems.
So ongoing maintenance is still needed. It has been reduced by technical changes, but not eliminated. I have identified one area which needs ongoing attention, but here may be more ... and given TTH's long pattern of sloppiness in basic tasks of portal creation, I place no weight on their assurances that there isn't much else to check.
The guidance should therefore stay. And instead of trying to change guidelines, TTH should concentrate on cleaning up the mess created by TTH's drive-by-creation sprees. --BrownHairedGirl (talk) • (contribs) 16:39, 11 November 2018 (UTC)
PS note that POrtal:Fresno has only one reader-facing incoming link, from Category:Fresno . As note above, that is dabcat, so readers should never see it; no portal link should be in that page, and it was added[5] in an AWB by TTH who neglected WP:AWBRULES #1: "You are responsible for every edit made. Do not sacrifice quality for speed, and review all changes before saving". The result is that after 9 weeks, the portal is completely unsignposted to readers, which is why it has had only 49 pageviews in 64 days (all presumably by editors).
Part of the maintenance needed is ensuring that the portal is adequately signposted. TTH has neither done that directly, nor made any efort to avertise the pprtal in project space to notify others of the needs for links. (I checked: no links to it from Wikipedia-space[6] or Wikipedia talk[7]). --BrownHairedGirl (talk) • (contribs) 16:52, 11 November 2018 (UTC)
  • Some data.
I just used Petscan to check for portals in disambiguation categories, and found 5 of them:
Note that:
  1. All but the last (Portal:Rio de Janeiro) was created by @The Transhumanist, and TTH is the only other editor of that page.
  2. All of them has a broken categorytree,[8] except for Portal:Fresno, which I fixed.
  3. Three of them Portal:Transformers, Portal:Fresno, & Portal:Woodstock) has only one incoming link from a category or article ... and in each case it is the dismabiguation cat which shouldn't even be linked there.
  4. Only one these portals has a 60-day pageview total of even one view per day: (note the numbers are as of now, but will increase as a result of posting the links here)
  5. These five portals have between them a total of only 4 incoming links from articles: 2 each to Portal:Santiago and Portal:Santiago.
These pages were all created between 26 July 2018‎ and 8 September 2018, so they are between 9 and 14 weeks old. They need maintenance, but instead in all but one case only their creator has edited them (until I edited Fresno today). So these portals do rely on the creator to maintain them ... but instead of doing that maintenance, their creator is trying to change the rules to dump the cleanup task onto others.
And all this for pages which readers do not read. --BrownHairedGirl (talk) • (contribs)
Thank you, BrownHairedGirl, for reporting the disambiguation problem on these 5 portals. I wasn't even aware of such a problem to look for, let alone how to look for it. Now that I do, I will happily use the PetScan procedure that you provided to monitor for such instances in the future. Again, thank you. ;)
Now, getting back to the disambiguation thing...
Portal:Rio de Janeiro  Done
Portal:Woodstock  Done
Portal:Transformers  Done
Portal:Santiago (disambiguated)  Done
Portal:Fresno, California (renamed)  Done
I am highly impressed with your application of PetScan. That thing is an incredible filter. Out of all the portals I created, it found the 4 with that problem (and 1 by someone else). Nice. If there are any other useful PetScan queries you can provide to help detect portal errors to improve quality assurance, please don't hesitate to do so.
By the way, thank you for the heads up on the red categories. I generally leave redlinks in place for them to turn blue via wikimagic, but removed the categorization links that you pointed out were causing problems.
Regarding the maintenance clause, I am concerned that it would deter new or less experienced editors from creating individual portals they are considering making. Because they may not know that Wikipedia is not compulsory. Having an erroneous damper on portal creation in the portal guideline seems counter productive. The guideline should encourage, not mistakenly discourage, portal creation.
Sincerely,    — The Transhumanist   09:56, 26 December 2018 (UTC)
My own preference is that people do not make unnecessary work for others on Wikipedia, but as pointed out above, editing Wikipedia is a voluntary activity and we are are urged to accept good faith edits in the spirit in which they are made, and to assume good faith in the absence of evidence to the contrary. When we find this unbearably tedious we can find somewhere else to do something useful. While the malformed portals are aesthetically unsatisfactory, and may be functionally deficient, I am not convinced that they are actually harmful. There is an argument that by producing larger numbers the bugs will be exposed more effectively, but once a recurring issue has been identified it should be fixed before continuing with creating similar portals with similar faults. Considering the speed and ease of creating a new portal, it would not be unreasonable to expect the creator to apply reasonable diligence to checking for defects, and if there are defects, either self-discovered, or later reported, either fix them, delete the broken portal as a precautionary procedure, or mark it as an example of a problem that is actively being investigated and considered potentially fixable within a reasonable time frame.
Thanks for finding the portals in disambiguation categories. I agree they should not exist. Now that we know they are being created and not noticed at the time, we can look into countermeasures. The first step would be to find out why were they not noticed by the creator, then we can specify what to look out for, or write it into the relevant template.
The point to this particular item is how do we reword the guidance so that it both complies with the spirit of voluntary work, and provides a remedy when the same errors are repeated.· · · Peter (Southwood) (talk): 17:43, 16 November 2018 (UTC)

Poll on this change[edit]

Because this change could be controversial, if you want to support or oppose this change, please do so below:

Implemented by The Transhumanist. Closing on their behalf. Dreamy Jazz 🎷 talk to me | my contributions 23:23, 28 November 2018 (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.

  • Support this change. Portals have changed a lot in the last 2 years (the last stable version of this policy was 2 years ago) and the automatically updating portals do not need necessarily to have a maintainer, although (still) manually maintained portals need to be kept up to date by the creators/maintainers. Dreamy Jazz 🎷 talk to me | my contributions 13:43, 7 November 2018 (UTC)
  • Support, · · · Peter (Southwood) (talk): 15:22, 7 November 2018 (UTC)
  • Support the new wording. — AfroThundr (u · t · c) 17:31, 7 November 2018 (UTC)
  • Oppose. --BrownHairedGirl (talk) • (contribs) 16:00, 11 November 2018 (UTC)
    {{U|BrownHairedGirl)), Do you have a constructive counterproposal to suggest? I don't think the current wording is acceptable. Cheers, · · · Peter (Southwood) (talk): 17:43, 16 November 2018 (UTC)
  • Reword. I like Pbsouthwood's wording above. I prefer Portals which require manual updating, as Manually maintained portals … are not kept up to date could be seen as an oxymoron. The point is that portals which require updating should get updated, or not be created in the first place. Certes (talk) 16:07, 13 November 2018 (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.

Concerning the inclusion of "Related portals" section[edit]

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 (talkcontribs) 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 (talkcontribs) 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)


  • 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 the inclusion of "Selected article(s)" section[edit]

The "Required" section does not currently specify "selected articles". This should probably be corrected, so I will add something which can be amended if anyone has a better way to say it. · · · Peter (Southwood) (talk): 05:47, 7 November 2018 (UTC)

There are a growing number of portals that don't have a section titled "Selected articles", but that still have sections with other titles that transclude article excerpts. It's the inclusion of prose on a subject that we want to focus on here, which is already covered by at least one policy. Wikipedia:Criteria for speedy deletion#P2. Underpopulated portal states:

Any portal based on a topic for which there is only a stub header article or fewer than three non-stub articles detailing subject matter that would be appropriate to present under the title of that portal.

This also means that subject matter (excerpts) are required, and any portal that lacks such can be speedy deleted. Subject matter should therefore be covered in the "Required" section of the guideline. But without requiring any specific wording of its section heading(s).    — The Transhumanist   06:38, 7 November 2018 (UTC)

Agreed, the section title is not the point, but "selected article" is convenient to cover biographies and general topics, as opposed to "In the news", "Did you know", images and suchlike optional extras · · · Peter (Southwood) (talk): 06:48, 7 November 2018 (UTC)
Maybe we should either link P2 or transclude it in the guideline for easy reference? · · · Peter (Southwood) (talk): 06:52, 7 November 2018 (UTC)
Good ideas. I favor transclusion, as it will update automatically. A preference I've acquired from the new design of portals. :)    — The Transhumanist   07:02, 7 November 2018 (UTC)
I also prefer transclusion, because it is right there and harder to miss. · · · Peter (Southwood) (talk): 15:41, 7 November 2018 (UTC)

Concerning section: Recommended[edit]

1. The second item from "Recommended" describes practice which is not generally used, is incompatible with the automation tools, and should be updated. · · · Peter (Southwood) (talk): 06:01, 7 November 2018 (UTC)

@Pbsouthwood: If the second item changes, nobody who reads your post above in the future will know what you were referring to. ;) I'm not sure I do now. :)    — The Transhumanist   06:44, 7 November 2018 (UTC)
Good point, my train of thought was derailed by an edit conflict. I will clarify by a quote:
Selected article – The first instance of the article title should link to the full article. Images should not use thumbnail formatting unless the background color of the portal content is specified as "transparent" (typically in the box-header subpage). Keep images small; 100px (as on the Main Page) is best. Remember that in compliance with WP:NFCC, non-free images cannot be used outside of articles.
(my emphasis, identifying the part that needs revision.) Why not thumbnail, what is the relevance of transparent, and why 100px?· · · Peter (Southwood) (talk): 07:00, 7 November 2018 (UTC)
Image placement is by and large automated. I'd remove that (emphasized) passage altogether. The first sentence should go too, unless the transclusion software is modified to linkify the first instance of the article title. Currently, many of the excerpts don't linkify the first instance, because they are are not linkified in the article leads transcluded.    — The Transhumanist   07:10, 7 November 2018 (UTC)
Just so. All we would be left with is the bit about non-free images. Read more (or preferred equivalent) gets one to the actual article adequately. · · · Peter (Southwood) (talk): 07:15, 7 November 2018 (UTC)
I will strike through pending a decision. · · · Peter (Southwood) (talk): 15:44, 7 November 2018 (UTC)
I think that the bolded part in the statement above is not what is happening (and potentially not what was happening before automation was even a thing: I've seen tiny images and huge images commonly through upgrading and maintenance). I think that it should be removed (as well as the thumbnail formatting). Dreamy Jazz 🎷 talk to me | my contributions 12:15, 11 December 2018 (UTC)

2. The recommendations for Selected picture are similarly out of date. The caption requirement may be difficult with the current templates. Not sure how to reword this one. The intention of a useful caption is good, but can it be done? There are so many strange image formats that might have to be parsed that it could get too expensive. Might be better in extreme cases to just go fix the page. Any suggestions? · · · Peter (Southwood) (talk): 16:00, 7 November 2018 (UTC)

We of course want to avoid making the Lua modules too bloated. Is there a way to make a module conditionally call another submodule to reduce the base run time? We could export the more exotic template/image parsing that way, and only use it when necessary. If that works, we can add all the extra logic we need, and only call it on the problem pages. — AfroThundr (u · t · c) 17:38, 7 November 2018 (UTC)

3. Sections "Recommended" and "Optional" are both optional, and to some extent both recommended. Should they be combined? · · · Peter (Southwood) (talk): 16:18, 7 November 2018 (UTC)

"Recommended" has a stronger impetus for inclusion than "Optional" (also works as "Suggested"). I think they would be better as separate sections, but some of the items might need to move. — AfroThundr (u · t · c) 17:38, 7 November 2018 (UTC)
Is that a suggestion or a recommendation? ;-) Definitely an option... · · · Peter (Southwood) (talk): 11:07, 9 November 2018 (UTC)

Concerning section: Article selection[edit]

1. This refers primarily to the selected article display which I have added to the "Required" section. Should we move this into the "Required" section as a subsection for direct ease of reference? · · · Peter (Southwood) (talk): 06:31, 7 November 2018 (UTC)

2. The number of selected content items is suggested as 20, as a rough guide. do we interpret this as the sum of biographies and other articles, which may be displayed in seperate boxes, or as the recommendation as a minimum for each display box, or something else? The current automation system does not easily seperate biographies from other articles when using a navbox as a structural template. I would prefer to be allowed to have additional selected items when they have fewer than 20 available components, as long as the main one is sufficient. · · · Peter (Southwood) (talk): 06:31, 7 November 2018 (UTC)

  • As a sum. That is the minimum number of articles a portal should have, when being considered for deletion at MfD. We need to be careful that we don't let that threshold get obscured or lost due to a rewrite.    — The Transhumanist   06:59, 7 November 2018 (UTC)
    • I agree that it should be a sum of excerpts from ordinary topical articles and biographies, excluding images and other optional material. The sum of 20 is currently a recommendation rather than a hard limit, and I think that should stand to allow for special cases, where we should let the circumstances be considered. In other words, if there are not 20 available for a good reason, motivate with good reasons why the portal is worthwhile and allow consensus to decide, preferably before creating the portal. · · · Peter (Southwood) (talk): 07:09, 7 November 2018 (UTC)

3. The quality of selected articles as described in this section in not currently checked by the automation systems. In fact as far as I know exactly none of these criteria are checked. Do we try to set some quality criteria for selected articles, and if so, what is reasonably practicable? · · · Peter (Southwood) (talk): 17:03, 7 November 2018 (UTC)

This sort of feeds off of my comment above about submodules in Lua, as I imagine this would be kind of expensive. We could add some thresholds to require a certain number of C-class articles or above (like 10, maybe?), and display an edit warning if it is not met. This would of course not prevent a page from being published anyway, ignoring the warning. We could also add a tracking category for that, which would retroactively allow us to find all the ones that don't currently meet this criteria, after it is added. — AfroThundr (u · t · c) 17:47, 7 November 2018 (UTC)
What we have currently in place is a stub filter. Stubs are automatically skipped over by the lua module, and are not displayed in Selected articles sections. I do not support raising that threshold, because we are talking about information dispersal. Having summaries of topics is half the point of portals, which is thwarted if we hide most of them because their article bodies are not complete. Portals are lead browsing tools. Besides, we want to drive traffic to all articles, so that more people will work on them. If you hide them, you are saving the work for our already overburdened regular editors.    — The Transhumanist   02:41, 9 November 2018 (UTC)
Portals are lead browsing tools. They are. Probably should be. So should we not transclude the whole lead as standard practice? A lot of our leads are pretty shabby, but in some cases the whole lead is quite a bit more useful than just one or two paragraphs, and where the whole lead is too long, we may get people fixing it. · · · Peter (Southwood) (talk): 11:14, 9 November 2018 (UTC)
@Pbsouthwood: That's what the Read more links are for.    — The Transhumanist   10:44, 26 December 2018 (UTC)
The Transhumanist, The Read more links are to get to the whole article, not just the lead. I don't think that we should provide excepts that are deliberately stunted when it takes no more effort to provide the whole lead. A well written lead is a coherent unit, that does not gain by being arbitrarily pruned. Or is this a problem with processing time? Anyway, I would be interested to see other opinions on this. · · · Peter (Southwood) (talk): 17:42, 26 December 2018 (UTC)
Also, this could be another one of the checks we could hypothetically do via userscript (re: portal tool). — AfroThundr (u · t · c) 17:53, 7 November 2018 (UTC)
This would be most useful when looking for subjects with enough information to support portal creation. Currently, what I need is a script to analyze navbox templates, for example, to count how many non-stub articles are listed on them. What I've been doing so far is creating portals in preview mode, and then clicking on the slideshow arrows to count how many articles are displayed in the Selected general articles section. That is both tedious and time-consuming. And if you forget the name of the article you started on, you may count right past it when it comes up again, and you have to start all over again. "497, 498, 499, 500. Wait a sec, I'm pretty sure there weren't 500 articles on the template!" :) With an automated tool, you could have it add such templates to a list, then change their namespace prefixes to "Portal:" and use the list for portal creation. We can avoid having underpopulated portals by never building underpopulated portals in the first place. Auto-tools could sure help with that.    — The Transhumanist   02:41, 9 November 2018 (UTC)
Could a bot periodically work through navboxes and leave normally invisible pointers indicating current article quality? This would allow only articles above a given bar to be selected. · · · Peter (Southwood) (talk): 11:19, 9 November 2018 (UTC)
@Pbsouthwood: The articles aren't so much selected, as simply displayed. For example, if you use "Template:X", all the topics on there, except stubs, get displayed on "Portal:X". It is handled by the underlying Lua modules. It is not clear what you envision the bot would do.    — The Transhumanist   12:05, 9 November 2018 (UTC)
The article displayed is randomly selected from all articles in Template:X, clicking through lets you display all the other {non-stub?) articles. If it were possible to select articles by quality class, there could be a set of selected article boxes for the different classes, or a box displaying only the better quality articles. · · · Peter (Southwood) (talk): 09:04, 10 November 2018 (UTC)
@Pbsouthwood: Not all of the articles. A maximum of 50 are displayed. Some templates have over 50 articles, and you can specify more than one sourcepage for the Selected articles section, which may add up to hundreds or more articles between them. You can also specify other page types besides navigation templates, like lists. The Selected historical figures section of Portal:History pulls its entries from the page Wikipedia:Vital articles/Level/4/People, which includes a few shy of 2,000 entries. You can also specify sections. One of my favorite techniques is to specify a section of the portal itself, such its Recognized content section. That is the only way I know of so far of selecting articles by quality class.    — The Transhumanist   10:58, 26 December 2018 (UTC)
The Transhumanist, Ok, maximum of 50. Randomly chosen? If so, would it not be better to showcase the content by displaying 50 of the better quality articles when random 50 could display a large proportion of stubs and starts? A counterargument is that random gives them all fair exposure, so it is a bit of an interpretation of portal function problem. Is quality or breadth more important?
How many of the new portals actually have a Recognised content section? Is there a way to identify them from those which do not? It might be a useful maintenance category. · · · Peter (Southwood) (talk): 17:55, 26 December 2018 (UTC)
Also related to the portal tool, we could use it to help with redcat detection on portal creation. This would solve those red categories and category trees, as was mentioned by BHG above. We should also take more time to QC them as they are created. — AfroThundr (u · t · c) 17:21, 13 November 2018 (UTC)
Red Cat Vector.svg This query lists the redcats in portal namespace. Certes (talk) 18:41, 13 November 2018 (UTC)
Cute icon. Face-smile.svg    — The Transhumanist   11:00, 26 December 2018 (UTC)

Concerning section: Required[edit]

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[edit]

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)
Consensus is found for the text in the updated proposal to be implemented. Dreamy Jazz 🎷 talk to me | my contributions 10:29, 16 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[edit]

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 (talkcontribs)
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 should 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)[edit]

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)
  • 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)
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?[edit]

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)

Portals on "Subject bar" template[edit]

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)