Wikipedia:Requests for comment/Portals guideline

This is a draft of an RfC to revise the portal guideline in a way that accurately reflects current consensus. It is currently Brainstorming. You can help by replacing questions with their answers, adding new questions to develop the text, summarizing key points, and rearranging text for comprehension. Threaded discussion should occur on the talk page, but unsigned discussion can occur on this page, and would help build it.

Background

WP:ENDPORTALS found a consensus against a proposal to delete all portals. No summary of the discussion was provided. Editors in that RFC were discussing the binary proposal in front of them, and so discussions about what to do other than mass deletion did not take off.

What is the background on automation?

What has been going on at MfD?

Big thing now is to get WikiProjects with people in them so one or two folks aren't stuck with a big load of too much work. There are about 188 WikiProjects of many types and sorts. The table above is just for the Parent categories on the Main Page. Please don't join Wikipedia:WikiProject_Wikiportals as an individual. It is intended to be a coalition of WikiProjects. Please DO start or join one of the WikiProjects in the Left Column.

— WP:Portal, 9 July 2005

What questions should the RfC ask?

Why portals?

A number of editors believe portals have value, but it is not particularly clear what values are held by the community. To resolve this, comments are requested on what value the community sees in portals. The list below contains some possible purposes editors see portals as having.

1. Showcasing our best content to readers. The Main Page, for example, is a portal with this very purpose. The Main Page is also very labor-intensive. Showcasing is work.
2. Navigating the encyclopedia. Along with lists, navigation templates, and categories, portals are one way readers can navigate the encyclopedia.
3. Containing content not available elsewhere on the encyclopedia. Some editors have stated that portals contain content, so that content is harmfully deleted when portals are deleted.

   * Unique, forked or transcluded encyclopedic content

   * Explanatory content such as guidance and reviews (others?)

4. Some editors like making portals
5. Planning and management of WikiProjects. Portals allow editors to keep track of the current and planned scope of the project's coverage.
6. Metatext and reviews of the topic.
7. A statement of the importance of the topic. The provision that portals should be about "broad subject areas" is more commonly remembered and quoted than the qualifying clause, "which will attract readers and portal maintainers". A portal is seen as a declaration that a topic is a broad subject area.
8. An invitation to readers and editors to develop particular articles in a topic area.

Comments on portal purpose

Comments by BHG

That summary is very helpful as an initial description of what has happened so far. However, it needs to be broken down into two broad sets:

1. Reasons to create a portal
   • Valid reasons
   • Bad reasons
2. Functions which may be added to a portal
   • appropriate additions
   • inappropriate additions

• Example 1: Tools for Planning and management of articles in a WikiProject's scope are already available, and mostly deployed on WikiProjects. They should be no part of a decision to create a portal, and if a portal is created they should not be duplicated there.
• Example 2: content belongs on content pages. No portal should host or display content which is is not in content pages

Comments that didn't make it into the above refactor

• Portals ought to include some claim regarding their fitness for inclusion.
• Often the showcasing function of portals becomes little more than coatracks and trivia.

What should be the status of Regional Portals?

There are different points of view about what the status of Regional Portals should be. Some editors have argued that:

1. Regions should have portals if they are of a certain administrative level. Editors have argued that

   all countries should have portals.

   major subdivisions of countries---such as states of the United States, provinces of Canada, states of Australia, and states of India---should have portals.

2. Regions should not have portals, and regional portals should be deprecated. They inevitably are non-neutral in their point of view and may be promotional.
3. Regional portals should be subject to the same inclusion criteria as other portals.

What is wrong with the current situation?

There is no clear definition of what portals are for, so decisions about whether to keep or delete particular portals are often arbitrary.

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

What we do know is that the overwhelming majority of portals are almost unused by readers.

The list of portal pageviews for Q2 2019 can be seen in the table below. There are currently 904 portals, of which only 6%, roughly 60 portals, have more than 100 page views per day. In the case of nearly every portal, the head article averages over 1000 pageviews per day; for the higher-level portals, the head article gets over 10,000 daily views.

daily average pageviews	Number of portals	% of portals	Number of portals in this group or higher	% of portals in this group or higher
> 1000	11	1.22%	11	1.22%
501–1000	0	0%	11	1.22%
251–500	3	0.33%	14	1.55%
101–250	42	4.64%	56	6.19%
51–100	90	9.96%	146	16.2%
26–50	181	20.0%	327	36.2%
<25	577	63.8%	904	100%

94% of portals are so massively under-used that they are a waste of time. Most of them are under-maintained, if not totally abandoned. Those which are mainatined serve a tiny reader base.

Inclusion and deletion criteria

A collection of questions and comments about when portals should be kept and when they should be deleted.

• Should abandoned portals be deleted? How do we determine when a portal is abandoned?
• Should there be minimum quality standards for a portal to be kept? See WP:POG#Required and WP:TNT.
• Should there be some process for proposing portals like Wikipedia:WikiProject Council/Proposals? How should proposals for portals be evaluated?
• What gets to have a portal? Are there some topics that are too narrow to have a portal?

Notability (Portals)

Perhaps not with that name (as the general notability guideline is for articles), but with that idea: set some clear rules to define which topics may or may not have a portal. So, if someone wants to create a portal about X, he checks those rules and understand on his own if it is a good idea or not. And, if someone wants to contest an existing portal (and others justify it), have rules to follow and let explanations say how the portal meets or fail them. In the RFC we add some possible rationales.

• Should the parent article be a vital article? Of what level?
• Should the parent article have a category with a minimum of related articles? (in both the parent cateory and subcategories) How many?
• Should the topic have a minimum of recognized content? (good or featured articles, lists or subtopics) How many?
• Should the portal have a minimum of readers per moth? How many?
• Should the portal have a minimum of active maintainers? How many?

Propose other criteria that you may consider. Cambalachero (talk) 20:05, 18 July 2019 (UTC)

What can we do to to resolve the identified problems?

Proposal 1 (BHG)

Step A: acknowledge the fundamental problems

1. Recognise that across the rest of the web, portals and several other navigational devices such as webrings were killed off by two factors:

   • the powerful web search offered by present Web search engines( mainly Google).
   • massive and deep cross-linking.

   Web portals were redundant by the year 2000.

2. Recognise that Wikipedia's creation of the portal namespace in 2005 was an attempt to revive the corpse of a navigational tool which had already been superseded.
3. Recognise that Wikipedia already offered four tools which mirrored the wider factors which killed web portals:
   • Powerful search. The WMF has invested heavily in search technology over the years, and en.wp now has a very powerful search system
   • Easy cross-linking. The ability to link to another topic simply by placing square brackets around its name is a billion times easier than the early 90s web, when a weblink required Frankenstein markup link like <a href="www.somesitesomeewhere.com/~alice/home/web/essays/etomcar.html">Growing electric tomatoes in your car</a>
   • Navboxes. Easily maintained, easily deployed, they perform on wiki most of the job that early 90s portals used to do for the infant web.
   • Categories. The shocking crudeness of the software makes them hard for readers to use, but they do have some role in assisting navigation.
4. Recognise that as a result, Wikipedia portals are locked in a structural death cycle: their redundancy means that very few readers or editors use them, and consequently v few editors want to maintain them
5. Recognise that the structure of each portal is a usability disaster, because:
   • their core offering is a selection of excerpts under two or three headings, with no readily visible list of topics covered
   • new topics are viewable only by the counter-intuitive technique of refreshing the page
6. Recognise that the structure of each portal is a maintainability disaster, because:
   • the structure is so complex that even experienced article editors face a steep learning curve to do anything to a portal
   • they rely on content forks which become out of date
   • they collect unsourced content
   • the proliferation of subpages makes it near impossible to watchlist a whole portal, and understand what does what. For an example of a well-maintained midsize portal, see Special:PrefixIndex/Portal:Cheshire; for an extreme case see Special:PrefixIndex/Portal:Military history of Australia. From a maintenance perspective, both are abominations
7. Recognise that the attempt to solve some of these problems by complete automation was a disaster, and because it was rolled out without consensus, it
   • alienated many portal maintainers, who disliked seeing so many of the automated portals deleted
   • alienated many other editors, who were shocked that the sea of abandoned portals had grown exponentionally with hardly any objection from portal maintainers and creators

What does "recognize" mean? How would an RfC achieve that?

I regard these as equivalent to the findings of fact in an Arbcom case. They set the basis for deciding what actions to take. --BrownHairedGirl (talk) • (contribs) 19:15, 8 July 2019 (UTC)

All rings true except navboxes and popups are not seem by the majority of our readers....thus not viable navigation tools for most (60%plus).--Moxy 🍁 21:56, 18 July 2019 (UTC)

Step B: learn the lessons

1. Portals are largely redundant. They will only only ever serve a small minority of readers, because most readers are already well-served by other technologies
2. Because of the redundancy, only very broad topics will ever attract enough readers to justify their existence and enough editors to maintain them. The existing guidance on broad topics is way too vague.
3. The viewing figures above give us the numbers: fewer than 100 portals have achieved critical mass. Those are our broad topics
4. The baroque forests of content forked sub-pages are a disaster. They should be eliminated
5. The availability of preview mouseover as a built-in-part of the Wikimedia software makes the curation and presentation of lead excerpts redundant.

Step C: prepare for change

1. Identify the core portals to keep.
2. Identify a set of low maintenance designs for two or three of those portals.
3. Run usability testing on those designs
4. Roll out the winning design across other portals

Proposal 2

The RfC should be structured to ask the following questions to which all editors are encouraged to respond:

1. What are the intended purposes of portals?

   Proposals for criteria with Yes or No on each.

2. Should portals be constructed according to the current portal guidelines? (Does this discussion show strong enough consensus for it to be marked as a a guideline)
3. What should be the status of Regional Portals? (See above)
4. Should Proposal 1 by User:BrownHairedGirl be adopted?

Brainstorming #3 and proposal #3 (USian)

Let us concede the point, well made by BHG and others, that search tools make "portal-type" tools for navigation irrelevant. Is there still a role for portals? Let's start with the sentence from the WP:P information page: "Portals serve as enhanced "Main Pages" for specific broad subjects." Well, what is on the main page? It actually has very little navigation, (other than the search bar that is on every page). Instead it includes:

1. Samples of WP's highest quality content (samples of one featured article at a time, the entirety of one featured picture at a time)
2. Current Events/news
3. An "on this date" section
4. A "did you know" section
5. Links to where viewers can go to collaborate (Wikipedia:Community portal)
6. Links to other Wikimedia projects

And why is all that there? Not for navigation, but to draw in viewers and editors.

So if one were creating an online encyclopedia for, say, sports, that anyone could edit, it too would want to draw in viewers and editors. And what would its Main Page look like? It would probably have all the same elements as the WP main page:

1. Samples of highest quality sports content (samples of one featured article at a time, the entirety of one featured picture at a time)
2. Current sports Events/news
3. An "on this date" section
4. A "did you know" section
5. Links to where viewers can go to collaborate (Wikipedia:WikiProject Sports)
6. Links to other Wikimedia projects

Let's call this sports main page Portal:Sports, and recognize two things: 1) it would look and operate nothing like what is currently at that location; 2) it would look and operate nothing like the current article Sport.

For what would qualify to have one of these main pages, it would obviously need sufficient content to support each of the 6 elements: sufficient highest quality content: say 20 featured articles, "on this day" content for every day, sufficient news/DYK flow, a WikiProject that is actively collaborating, etc. The 20 FA minimum has an added benefit of incenting smaller/newer WikiProjects to get 20 articles across the FA finish line in order to "earn" a portal: a good thing.

I believe that portals designed as per the above would get a lot of page views, but I would also be comfortable with the above continuing to exist even if they did not get a lot of page views.

Thoughts, reactions? UnitedStatesian (talk) 03:53, 11 July 2019 (UTC)

Will this restrict portals to only topics broad enough for a WikiProject? Should there be a requirement that the wikiproject wants a portal? What happens to derelict portals?

@ UnitedStatesian, it seems to me that what you are describing is very much like what WP:PORTAL has described for years as the the core purpose of portals: "Portals serve as enhanced 'Main Pages' for specific broad subjects".

But — as @Robert McClenon points out most eloquently — the Wikipedia main page requires huge amounts of labour. It works only because 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 ... and the record of portals is overwhelmingly that the work doesn't get done.

And here's the bit that really puzzles me about your proposal: its purpose which you describe as being to draw in viewers and editors. How on earth can that work?

The Wikipedia main page gets lot of views because it is the default landing point for the whole, of Wikipedia. So in the first 6 months of 2019, the main page got an average of 16,383,063 views per day. Yes, a daily average of sixteen million readers, who want to be pointed somewhere else.

By contrast, in the same period Portal:Sports got a median of 49 pageviews per day.

So I think your plan is missing both the key ingredients needed to make it work:

1. large numbers of visitors wanting signposts
2. large numbers of editors to keep the portal fresh

And as to the idea of incentivising smaller/newer WikiProjects to get 20 articles across the FA finish line in order to "earn" a portal ... may God Preserve Us From That'. That would just be a recipe for the proliferation of yet more microportals, of the type which get abysmal pageviews and are abandoned for decades without maintenance.

I'm sorry to be blunt, but this proposal replicates the two most fundamental failing of en.wp portals over the last 14 years: they have been built to satisfy the desire of editors to create them, rather than to serve any actual need of readers ... and there have never been remotely enough editors to maintain them.

So when I read a suggestion that a WikiProject might somehow "earn" a portal, I just want to scream. If portals have any purpose, it is to assist readers. It is certainly not to "reward" editors or projects.

Sorry, UnitedStatesian, but your proposal is a set of impossibilist ideas which meet no known need. --BrownHairedGirl (talk) • (contribs) 15:49, 18 July 2019 (UTC)

I wish that I could share the optimism of User:UnitedStatesian about a new approach to revitalize portals. I sometimes see editors who are enthusiastic about some new idea, and I wish that I could share their enthusiasm. But I don't, because I don't see where the editors are coming from to do all the work. Maybe the only difference between User:UnitedStatesian's idea, and NA1k's repeated suggestion to put {{update}} on portals, is that USian isn't repeating any untruths. Where do all of the editors to do all the work come from? Do we make it compulsory that new editors support these portals? Robert McClenon (talk) 16:25, 18 July 2019 (UTC)

Merge portals into categories

The purpose of portals is to show off content and help readers navigate Wikipedia. Because pages in the Category: namespace can display wikitext just like any other page, the aesthetic content can be included directly above a hierarchically ordered list of articles within that topic. This would increase the usefulness of both categories and portals to readers by combining the strengths of both, and reduce the need for an additional namespace.

I was trying to find out when the Portal namespace was created and found the Portal namespace setting-up debate. There was an interesting comment from User:Aya 42: "This duplicates the conceptual scope of the category pages. You were aware you could put complex wiki-markup on these pages?" I think this is an interesting suggestion and we should see what people think about it. Wug·a·po·des​ 02:48, 13 July 2019 (UTC)

Sorry, but this is is a really really really really bad idea. It would massively degrade the utility of categories.

Per WP:CAT:

The central goal of the category system is to provide navigational links to Wikipedia pages in a hierarchy of categories which readers, knowing essential—defining—characteristics of a topic, can browse and quickly find sets of pages on topics that are defined by those characteristics.

To do that, a category page needs only 3 things:

1. a terse description of the category's purpose
2. A list of the category's contents
3. Links to parent categories and sub-categories, and ideally to sibling categories.

Everything else detracts from that purpose.

Sadly, the Wikimedia software for categories is shamefully crude. It displays parent categories at the bottom of the page, rather than in breadcrumbs at the top. It displays footer information (such as Commons links) at the top of the page, rather than below the content listings. And it has no built in mechanisms to link to sibling categories, which is why some of us have laboured hard to create tools such as {{Navseasoncats}} and Template:AllIrelandByCountyCatNav.

So categories need investment from the WMF, to improve the software. And I am not holding my breath for that to happen.

But everything on the page which isn't related to that core purpose of actually navigating categories is an intrusion, a degradation of the core function of the category page. --BrownHairedGirl (talk) • (contribs) 16:09, 18 July 2019 (UTC)

These are good points, though I disagree that it's a really really really really bad idea. I'd be willing to compromise to just bad idea.

Kidding aside, you're definitely right that too much header info in categories would distract from the content which is why if this route were taken there should still be the "broad topic" requirement. If anything it might help alleviate some of the problems caused by technical limitations. For example, imagine if Portal:Biology was merged with Category:Biology as an introduction to that category tree? It would make accessing the links in that category slightly harder since you'd need to scroll to the bottom, but maintainers would be able curate what subcategories might be of widest interest and put those at the top like portals already do with the "Category" section. In fact, Portal:Biology gets twice the daily visitors as Category:Biology, so merging them would actually make the category more useful as a navigation tool. Wug·a·po·des​ 16:43, 18 July 2019 (UTC)

Brainstorming #4 - The article is the best possible portal

A question I would like to ask. The vast majority of portals are redundant with the respective article, so the article could function as a portal? Instead of a templete {{portal}} there could be a discrete templete that invite to wikiproject directly from the article. I believe that for the other sections common to the portals "Selected article", "Selected picture", "quotes", "Did you know" already exist templates that do it.Guilherme Burn (talk) 17:52, 18 July 2019 (UTC)

Reversing the question, what does a portal provide that an article can not provide?Guilherme Burn (talk) 17:58, 18 July 2019 (UTC)

An overview of main articles, images and a navigational aid for those with disabilities that is seen by all readers. Navbox templates, categories and popups are not seen by the majority of our readers and are not formated for ease of navigation for those with disabilities. Links to Wikiprojects in mainspace have been rejected by the community many times....so much so that Wikiproject links in article navboxs have been removed.--Moxy 🍁 20:32, 19 July 2019 (UTC)

@Moxy: Don't you think the current format of subpages is inefficient in promoting the functions you cited?Guilherme Burn (talk) 18:00, 25 July 2019 (UTC)

Sub pages don't really affect the end user. Though transclutuon is better from the POV of an editor. Been trying for a few years to get portals visible for all readers (as of now only 40% see them). Portals are good for navigation because unlike a navbox (that are not seen in mobile view ) you don't need to move your mouse over a little box that says "show" to see the content.....I personally have to press tab 80 times in an article before my cursor reaches the "show" toggle on the bottom of a page. Portals sever those with movement problems well and is why they have been acceptable type of fork content for over a decade. This has been explained at the deletion board but to no avail....we are still getting nominations based on a fork system despite this being the purpose of a portal. Still being deleted over being fixed. Portals were also good for recruitment for smaller Wikiprojects as they were the only place a recruitment message can be placed. Portals have minimum views but they server a discriminated segment of the population when it come to function. I personally get chastise all the time for grammar errors and spelling errors in debates all over about accessibility....I can't type well -can't use my hands well thus portals are a great navigation tool on my phone because popups and navigation templates are not seen in mobile view.--Moxy 🍁 22:54, 25 July 2019 (UTC)

• I agree with Guilherme Burn. Portals are redundant, because the head articles do a vastly better than portals of the key portal tasks of navigation and showcasing. The portals are a failed solution in search of a problem. --BrownHairedGirl (talk) • (contribs) 23:07, 5 September 2019 (UTC)
  • Agree, but not quite convinced that "portals are a failed solution in search of a problem" is the perfect description. If it were, then the solution is to delete all portals, and that may be where the current portal cull trend ends. I think the best hope for a refinement of the "problem" is the desire for comprehensive, logical, top-down navigation system.

Currently, to date, portals, even the best and the top Main Page portals, do not even try to serve as a comprehensive, logical, top-down navigation system for readers to navigate to articles. Instead, they obsess with the editor achievement orientated Featured Articles, and they contain a huge amount of linking into Project Space. As such, all Portals in their current form, are better suited for being located in WP:WikiProjects. For readers, all Portals carry negative impact. Their value for editors or future editors is higher, and that value may be positive or negative.

The current best comprehensive, logical, top-down navigation system is the category system. It has logic, and discipline. It starts with broad topics, and you go down to specific topics, and going down you never end up back at the top, as happens when you follow wikilinks. It has the discipline that going down the category tree will never lead you outside to article space.

I think there could be a massive renovations of the top portals to make them into a comprehensive, logical, top-down navigation system, like the category system. This would be a top-down renovation of portals into something that works, if it can work. At the bottom end, it might tie up with what are called WP:Broad concept articles. --SmokeyJoe (talk) 01:58, 6 September 2019 (UTC)