Wikipedia:Reliable sources/Perennial sources/Index

This is a demo page mocking up a new approach to Perennial sources. First time here? Read the intro (and FAQ).

This is a Demo page for an idea being discussed at WT:RSP regarding alternate methods of making reliability data about perennially discussed sources available to users in an effective way, that isn't subject to hard limitations of template expansion, as the current table is over 99% capacity.^[a]

It contains a mock-up of how a "Perennial sources" feature might look, if instead of having one large page organized as a table, it were split up into a starting page (this one) containing an index linking many landing pages, where each page corresponds to discussions and other information about the reliability of one source. One landing page in this scheme corresponds to one row in the table in current operation.^[b]

Some of the links in the index list below have icons attached; these are not part of any proposed new design for Perennial sources, and are here strictly to facilitate navigating the demo. Only some of the pages linked below have been converted to the new scheme; they carry an icon. All links go to a landing page, but the ones that have not been converted to the new scheme just contain a copy of the table row for that source in the live version, presented as a one-row table. (In a few cases, there may be more than one row in an unconverted landing page, where there are two or more rows in the live table that correspond to the same source.^[c]

See the FAQ at the bottom of the page for the answers to some important questions.

Search

Search for words^[d] in perennial sources. If searching on part of a word, append an asterisk; e.g. Bloom* will find Bloomberg, but Bloom will not.^[e]

Search for perennial sources:

ignore suggestions below, and use the search button instead

(This mock-up searches for sources starting with 'B', 'C', or 'D'.)

Tracked in Phabricator
Task T405178

Note: please ignore search box suggestions; they display incorrectly.

List

A

B

C

D

E

FGHI

JKLMNO

PQRST

UVWXYZ

Demo FAQ

Q1: (in four parts) Why do this at all? The table works fine, and I like it the way it is.

Q1a: Why is this even here? I like the existing table at Wikipedia:Reliable sources/Perennial sources, where everything is in one place.

A1a: There is a problem with the existing page that is becoming critical: the page currently uses up over 99% of an available resource called PEIS^[a] because of the many templates on the page, and once it hits 100%, the page will no longer render correctly. Also, it can sometimes be slow to load. See discussions about this at Talk; most recently at WT:RSP#Addressing hard template limits.

Q1b: Okay, so if PEIS is the problem, just get rid of some templates, then. That will reduce PEIS to a manageable level, everything will be fine, and we won't have to spend a lot of effort coming up with some completely new system.

A1b: Reducing the number of templates was the number one thing that was looked at. In fact, there have been several iterations of template reduction, most recently discussion at the Talk page, here. It is getting to the point where all the fat has been squeezed out, maybe even past that where some templates were removed that really should be there. And we are still over 99%.

Q1c: Fine; so break it up into two tables, with A–L and M–Z, or several chunks. Lots of long lists do it that way, and that will fix the PEIS problem.

A1c: That would fix the immediate problem with PEIS, and the idea of splitting the page was considered in June 2024 in this Rfc. The lengthy close concluded that it was okay to split, under the strict condition that there must always be a fully sortable and searchable table that displays on a single page. There are now eight table chunks in separate pages named WP:Reliable sources/Perennial sources/1 through WP:Reliable sources/Perennial sources/8, which are all transcluded to WP:Reliable sources/Perennial sources, which is at 99.77% of PEIS capacity; so we are back to square one again.

Q1d: Couldn't you reduce PEIS by getting rid of the numbered subtables, and copying all their rows into one big table having everything?

A1d: Yes, that has been suggested at Talk and it would significantly reduce PEIS to around 63% of capacity. There were some objections raised regarding size, load time, and maintainability. One giant table is still an option, and may allow growth in the table from the current 497 rows to around 650 rows, but at some point may run into the same issue again.

Q2: Why are only 'B', 'C', and 'D' pages listed? Where are all the rest of the pages?

A2: This is just a demo, and they haven't been included. Not only that, but not all the links in the B, C, and D sections are converted to mockups, either; the ones that are, are tagged with icons to indicate a converted page. If you have a source which is unique in some way, or which would be helpful to include in the demo, please request it at WT:RSP, or feel free to add it.

Q3: Are there any functional advantages to an approach like this, other than being forced to do so in order to avoid a technical problem with a resource limit?

A3: Yes, several.

free-form pages – one advantage is the relatively open format of a standard wiki page, which allows for expanded coverage of a given source's reliability. Currently, reliability information about a source has to be squeezed into the constraints of a table row. This has led to the use of a lot of icons, which require a legend or some getting used to, but are hard for new visitors to the page.
individual page size – some rows with a large summary section take up a lot of vertical space in the table, and are hard to see even on a 15-inch screen, let alone on mobile devices. Having a plain project page is more user-friendly, and mitigates that.
project growth – freed from the PEIS constraint, there is virtually no limit to the number of sources that could be added to the project. It just requires one new landing page, and a link from the Index page to it.
page organization – a plain wiki project page allows for extensibility, such as organizing the page with section headings, and is not limited to information that can be shoehorned into one of six pre-defined table columns. Different project pages need not have exactly the same sections; they can be organized as best suits the individual source being evaluated and summarized.
use of plain English – one consequence of having limited space in a table is the excessive reliance on icons and abbreviations, some of them a bit cryptic or one-off for this project, just so that stuff fits into a six-column table row. If you are not a habitué of this project, what do gu or mean to you? Icons are great as an adjunct, but they should complement plain English text, not replace it.
performance – a single landing page loads more quickly than a big table. From WP:NewPP limit report: cpu=6.6, real time; 7.2 seconds to load the table. That's a lot.
full pagename links – a project page has space for fully spelled-out discussion links including page and section name, instead of just the integers 1, 2, 3... to represent a sequence of discussions, as they now appear in column three of the table row.
categorization – standalone source evaluation pages can be categorized ("sources deemed reliable", "...unreliable", etc.); rows in a table cannot be categorized separately as categories are applied to the page they are on, and any category in a table row would be applied to the page as a whole.

Q4: What disadvantages are there in the new scheme?

A4: A couple of objections have been raised.

extra click – It has been pointed out at Talk that it requires an extra click to get to the information about a particular source under the new scheme. But it isn't clear that scrolling through or Ctrl+F–searching the big table is faster than finding the source name on the Index page and just clicking it. Also, it takes about seven seconds to load the table initially. The other way of getting to a specific row in the table is by following a redirect like WP:BALLOTPEDIA, so that would be just one click away from some Talk page discussion; but that will be the same under the new scheme: once the landing page is converted, the redirect can be retargeted (or the full pagename used).
sortable columns – a table structure allows for sortable columns. Probably the only ones that make sense to sort on, are columns two (status) and three (last comment). In the case of status, it would not be hard to create a static list of links to all the landing pages having a source evaluated as 'generally reliable' (or the other statuses). Reliability status of a given source changes infrequently, so a static page of 'reliable sources' could be kept up to date without much of a burden, and this advanced search link finds all pages in this demo having a status of gr ("generally reliable")
browsability – some people may like to just browse the table; under the new scheme, this wouldn't be possible. No one raised this as an objection so far, and it is hard to see what information is gained by looking at "neighbors" of a given row. More to the point, given the technical problems in keeping the table structure, it's hard to see how to preserve this functionality.

Q5: If this were approved, how would migration work? It could be quite some time before all the table rows were converted to landing pages.

A5: Migration could happen gradually, if desired. The links on the Index page could point to a landing page once it was converted, and before that, they would continue to directly address the row in the existing table, as they do now. Most rows have redirects that target them, like WP:BALLOTPEDIA or WP:BBC, and all rows are addressable by id attribute.

Or, we could use icons during a transitional period, where Index links to converted pages could have an icon attached, so that we could display

Ballotpedia

where the text link goes directly to the table row in the current system, and the document icon would go to the converted landing page in the new approach. When everything was converted, the icons would be dropped.

Q6: If I want to try converting one of the table rows into a landing page in this mockup, can I do that? Are there tools available for that?

A6: Sure, go ahead! There aren't specific tools for that yet, but that is in the offing. For the time being, have a look at some of the pages that have already been converted (the ones with little icons next to the link in the B–C–D index) and copy their style. Some templates that might be helpful: {{Infobox source reliability}}, WP:RSPNutshell, WP:RSPSHORTCUT, WP:RSPIntro, WP:RSPSTATUS/sandbox, WP:RSPLAST/sandbox, and {{Domain uses long}}.

Notes

^ ^a ^b PEIS is at 99.77% of capacity (2,092,393/2,097,152 bytes) as of 23 September 2025.
^ One landing page corresponds to one table row: Usually, but there may be some edge cases, such as whether New York magazine and The Verge—which are two rows in the table ((WP:RSPNEWYORK), WP:THEVERGE)—would both be on the landing page for New York magazine or not (most likely yes, they would), but these cases can simply be decided by consensus. What is certain, is that in the new scheme they would each have their own link in the Index, which would link to the appropriate landing page, possibly to the same one. Either way, the user gets to the right page from the Index links. See related note about "one source".
^ One source: a landing page is dedicated to a single source whose reliability has been perennially discussed. The issue of what constitutes "one source" has been discussed here. For example, "we would have separate entries in the Index for New York (the magazine), and for Vulture, The Cut, Grub Street, and Daily Intelligencer, which are all part of the mag; but they would all link the New York landing page, where they would all be described."
^ For our purposes, a word is: 1) a string of letters as in 'Bloomberg'; or 2) a subword inside a wikiword, like 'Buzz' or 'Feed' in 'BuzzFeed'.
^ And Buzz* will find BuzzFeed, but so will Buzz as well. On the other hand, BuzzF* will find BuzzFeed, but BuzzF (and Buzzf ) will not. This is all due to one of the intricacies of Cirrus search, in this case, its handling of wikiword subwords.

[PEIS-1] PEIS is at 99.77% of capacity (2,092,393/2,097,152 bytes) as of 23 September 2025.

[landing_page-2] One landing page corresponds to one table row: Usually, but there may be some edge cases, such as whether New York magazine and The Verge—which are two rows in the table ((WP:RSPNEWYORK), WP:THEVERGE)—would both be on the landing page for New York magazine or not (most likely yes, they would), but these cases can simply be decided by consensus. What is certain, is that in the new scheme they would each have their own link in the Index, which would link to the appropriate landing page, possibly to the same one. Either way, the user gets to the right page from the Index links. See related note about "one source".

[one_source-3] One source: a landing page is dedicated to a single source whose reliability has been perennially discussed. The issue of what constitutes "one source" has been discussed here. For example, "we would have separate entries in the Index for New York (the magazine), and for Vulture, The Cut, Grub Street, and Daily Intelligencer, which are all part of the mag; but they would all link the New York landing page, where they would all be described."

[word-4] For our purposes, a word is: 1) a string of letters as in 'Bloomberg'; or 2) a subword inside a wikiword, like 'Buzz' or 'Feed' in 'BuzzFeed'.

[Cirrus-5] And Buzz* will find BuzzFeed, but so will Buzz as well. On the other hand, BuzzF* will find BuzzFeed, but BuzzF (and Buzzf ) will not. This is all due to one of the intricacies of Cirrus search, in this case, its handling of wikiword subwords.

[a]

[b]

[c]

[d]

[e]