Wikipedia:Reliable sources/Perennial sources/Index

Shortcuts

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

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

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.
A1: In brief, the reason is that the page is in a critical state currently and is at risk of page failure very soon if nothing is done. For details, see Q1‑a through Q1‑d.
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 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. Several different approaches have been discussed about how to resolve the resource problem; this demo is one of them. For further details and other approaches, 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: 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. (It is slightly lower now, as we have cut corners to claw back another percent in order to give us some minimal breathing room for a short while.)
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. It is 547kb already, and editing a table that size could pose problems for some users; if it grows to 650 rows it might be around 715kb.
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.
  • forever solution – whereas some of the other approaches buy time with respect to the PEIS issue but may run into the same problem again eventually, this is a forever solution: the number of sources may be increased without limit without risking a reoccurrence of the problem, ever.
  • scales well – any number of sources could be added to the project. It just requires one new landing page for each source, and a link from the Index page to it.
  • available now – this solution is available now, and is not pending any kind of work elsewhere to lay the groundwork.
  • 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.
  • 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 – The live table takes about six to seven seconds to load; a landing page loads in about 0.4 second.
  • 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 – Categories apply to an entire page, so individual rows in a table cannot be categorized separately. Stand-alone source evaluation pages can be categorized (e.g., "sources deemed reliable") in whatever categorization scheme is most useful. Converted pages in the demo (the ones with the document icon next to the link) show one possible categorization approach.
  • handles sources with multiple properties well – this approach does not impose a solution, but allows editors to decide how they want to handle sources that have multiple properties, like Buzzfeed (see Buzzfeed landing page, which covers both BuzzFeed and BuzzFeed News) or Dotdash Meredith (see landing page, which covers About.com, and five more sites) whether to have each on their own landing page, or several properties combined into one page, as in these examples.
  • multiple indexes – there is no requirement to have just one index linking the landing pages; multiple indexes could be used for different reasons, perhaps subsets of the full list for use at WikiProjects, or different styles or layouts.
Q4: What disadvantages are there in this new approach?
A4: A few objections have been raised.
  • different look and feel – the new look is definitely different; there may be an adjustment period for editors used to the table.
  • 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 (date of last comment). But categories are another way to achieve this, and Category:Perennial sources deemed generally reliable in the mockup demonstrates how this could be done. If it is decided not to use categorization, since the reliability status of a given source changes infrequently, a static page of 'reliable sources' could be kept up to date without much of a burden; in addition, this advanced search link finds all pages in this demo having a status of gr ("generally reliable")
  • browsability – one issue that no one one person has raised so far, is that some people may just like to browse the table; under the new scheme, this wouldn't be possible.
Q5: If this were approved, how might migration work? It could be quite some time before all the table rows were converted to landing pages.
A5: Migration needn't happen all at once, and could happen gradually, if desired. The links on the Index page could point to a landing page once a row was converted, and before that, links could either directly address a row in the table, or a rump landing page with a copy of the table row, as currently is the case for unconverted rows in the demo, such as DeviantArt or Dexerto. In the table, converted rows could be replaced with a link to the new landing page, or kept as is during the transition. Most table rows have redirects that target them, like WP:BALLOTPEDIA or WP:RSPBBC, and they could be updated to target the landing pages as each row is converted.

On the Index page, we could add icons to links during a transitional migration period, so that one could display, for example:

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

See also

Notes

  1. 1 2 3 PEIS is at 99.77% of capacity (2,092,393/2,097,152 bytes) as of 23 September 2025.
  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 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".
  3. ↑ This demo page uses the term landing page; the Rfc uses the term subpage for the same thing, and elsewhere, the term source page (or, RSP source page) is used. A specific term has not been decided upon at this writing (18 Nov. 2025).
  4. ↑ 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."
  5. ↑ 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'.
  6. ↑ 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.
  7. 1 2 Load time: From WP:NewPP limit report: cpu=6.6, real time; 7.2 seconds to load the table.