Wikipedia talk:Reliable sources/Perennial sources

Addressing hard template limits

As of 21:00, 18 October 2025 (UTC) PEIS was at 88.87%

(1,863,757 / 2,097,152 bytes)

Section contents (page contents)

• §.1 WaId's central list, and click to longer explanation
• • §.1.1 sidebar on PEIS capacity and saving PEIS bytes by manipulation of templates
  • §.1.2 arbitrary break
• §.2 Raladic's table options
• §.3 Mg's central list plus multiple landing pages
• §.4 Infobox design
• §.5 Showcasing different approaches
• • §.5.1 Approach summary
• §.6 Yikes, four bytes left
• §.7 One giant table approach
• §.8 Implementation planning
• §.9 Row-builder module approach
• • §.9.1 Python demo
  • §.9.2 Aidan's demos
• §.10 How should we word an rfc?
• §.11 Barring new rows from the live table

This page is hovering around the hard template limits imposed by WP:PEIS (see section above). Tinkering with some templates as Aaron Liu and I have done is a temporary solution at best. I believe we must contemplate other larger-scale solutions. I think we need to gather some data first, and then talk over where we want to go. For starters, the general design of the page involves one big table that sources in eight subtables, accounting for roughly 60% (1,259,287) of the hard PEIS limit of 2,097,152 bytes, and they are the following:

Variation in raw wikicode size

Chunk	rows	bytes on 15 Sept	bytes now
1	46	45,502	45,871
2	81	98,279	108,893
3	69	76,611	77,822
4	66	72,651	74,681
5	61	62,623	62,741
6	61	62,118	62,934
7	61	63,261	63,546
8	56	64,791	65,363

• Wikipedia:Reliable sources/Perennial sources/1 – 116,373
• Wikipedia:Reliable sources/Perennial sources/2 – 220,091   (update: 218,245; see below)
• Wikipedia:Reliable sources/Perennial sources/3 – 170,887
• Wikipedia:Reliable sources/Perennial sources/4 – 196,889
• Wikipedia:Reliable sources/Perennial sources/5 – 145,381
• Wikipedia:Reliable sources/Perennial sources/6 – 150,100
• Wikipedia:Reliable sources/Perennial sources/7 – 148,957
• Wikipedia:Reliable sources/Perennial sources/8 – 110,609

One approach would be breaking up the page into two (e.g., A–J, M-Z or wherever the midpoint is), which would bring each half down to roughly 70% of max PEIS, and still allow some room for growth. Another approach is to analyze the custom RSP templates used in each row (WP:RSPSHORTCUT, WP:RSPSTATUS, WP:RSPLAST, and WP:RSPUSES—didn't I miss one?) and see how they might have a lower footprint. Along with those, there are the two templates {{anchor}} and {{efn}} which are fairly easily replaced with non-template code, and would be an immediate savings. I'll have more later, but I'd like to get some feedback at this point. Mathglot (talk) 03:26, 15 September 2025 (UTC)

Splitting the list in any way without giving us a full list somewhere was widely opposed at Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Page size. Aaron Liu (talk) 04:26, 15 September 2025 (UTC)

If a page is unrenderable by Wikimedia software due to hard limits, consensus to display the page anyway holds no water, if it is impossible for technical reasons; consensus can simply be ignored in cases like that. However, we needn't worry too much about that yet, because other approaches are available. Mathglot (talk) 04:54, 15 September 2025 (UTC)

Participants would prefer to centralize the wikitext on one page rather than not have a centralized page. Aaron Liu (talk) 11:39, 15 September 2025 (UTC)

I would suggest making use of the search function. Instead of trying to view a page that's nearly impossible to load, "search in subpages" could save the day without giving away the ability to quickly locate the sources people want to find. SuperGrey (talk) 08:12, 15 September 2025 (UTC)

If making full use of the "search in subpages" function, we could also go even further and make all entries in subpages, like what we do with good article reviews. SuperGrey (talk) 08:17, 15 September 2025 (UTC)

As an experiment, I took subpage #2, the largest template expansion size at 220,091 bytes originally, and applied just the conversions of {{anchor}} and {{efn}} to see what would happen. The new size was 218,245, for a savings of 1846 bytes, or 0.84%. If we projected that over all eight sources with similar results, we might save around 10,500 bytes, out of 1,259,287 for all eight. That is very slim savings; perhaps enough to stave off immediate disaster, but doesn't allow for much expansion, if any. We should investigate simplification of the RSN-related templates used in the rows, to see if there are any savings available there. Mathglot (talk) 05:10, 15 September 2025 (UTC)

I mentioned pruning the excessive unused shortcuts that have been added in recent months above. Aaron Liu (talk) 11:24, 15 September 2025 (UTC)

I know this is going to be ugly, but moving the current sub-page to an 'original' (where template changes update and which can be edited), having a bot on a daily basis (and/or on demand) do a nearly full subst to a protected page which we then transclude? Dirk Beetstra ^{T C} 11:26, 15 September 2025 (UTC)

Also note that a random sample RSP entry (Baidu Baike) took up just 3,407 bytes. 10,500 is more than enough for three new entries. Aaron Liu (talk) 11:40, 15 September 2025 (UTC)

WaId's central list, and click to longer explanation

What about having a single, central minimal list, with each entry linking to a longer explanation? For example:

• The Daily News (dailynews.com)

and you click through to Wikipedia:Reliable sources/Perennial sources/D#Daily_News to see the whole entry. Shortcuts would go straight through to the whole entry. The central list would primarily exist for people who aren't sure whether the publication/site they're looking at actually has an entry. WhatamIdoing (talk) 17:24, 15 September 2025 (UTC)

Support - Good solution. And can pair with the "search in subpages" if people can't find what they want in the central list. SuperGrey (talk) 19:42, 15 September 2025 (UTC)

Yes, had already started in on that approach (which I think of as the "Summary + Detail" approach); wanted to get a working mockup before saying anything, but if you want to see 1/8 of it, and not yet ready for general discussion, see User:Mathglot/sandbox RSP/1. PEIS is 43,580 – only 37% of current size of subpage 1. When I have all 8, or maybe just 4, I'll sew them together, and expose the mockup. Note that this initial attempt mostly borrows the current style of the fuller table, but it doesn't need to; it uses new classes at the stylesheet and can be easily changed, without touching the table. Mathglot (talk) 23:00, 15 September 2025 (UTC)

What I'm thinking of would look more like this:

On RSP itself, just a simple list with links:

Sources

• Ad Fontes Media – entry
• Agence France-Presse – entry
• Al Jazeera – entry

and then on the alphabetical subpages, basically showing them what we have now. This would be a navigation directory with the fewest possible number of templates, smallest amount of decoration, etc., on this page. It would not be a dumbed-down or oversimplified version of this page.

I believe it is ultimately not in Wikipedia's interest to give editors a classification without also putting the various explanations and notes in front of them as well. Editors should not see "Al Jazeera – green is good" without also seeing "oh, and they tend to be a bit biased on ARBPIA CTOPs". WhatamIdoing (talk) 23:11, 15 September 2025 (UTC)

I agree with Whatam: If we do this, we should not include the unexplained status on the centralized page. That would worsen issues with the three/four-color system's reductionism (see e.g. Wikipedia talk:Reliable sources/Perennial sources/Archive 11#MREL subpage) and people asking why a source is a certain status.

(Though again, I do not think any splitting is necessary yet.) Aaron Liu (talk) 00:13, 16 September 2025 (UTC)

sidebar on PEIS capacity and saving PEIS bytes by manipulation of templates

I don't understand why you don't think splitting is necessary, unless you have some kind of ace up your sleeve. We have already gone over the limit once recently, and only through edits by both of us (some of mine were sketchy and would be better off undone) have we managed to claw back minimal breathing room, to arrive at 2,091,215/2,097,152 bytes which amounts to 99.7% of available resources. This leaves us with only 5,937 free bytes (2,097,152-2,091,215), and no room for expansion.

Take a middleweight row with respect to PEIS such as Buzzfeed News: this row is 2,794 raw wikicode bytes, and a PEIS of 10,214 (just the row, without a table header), so it is twice the size of our remaining capacity; another row like that one would break the table again.

There are still multiple approaches to consider, and I think one we should discuss is making every row into its own atomic subpage. At 2,794 bytes, the Buzzfeed News row already exceeds the size of plenty of small stubs, and with every RSP website on its own subpage, that opens up the possibility of direct search, similar to how the search box works at Help:YFA#Search for an existing article to look for articles or drafts. We could have a search box where the user types in the website name, and it searches only RSP websites we define (using the |prefix= param of mw:Extension:InputBox) and as they typed, they would start to get pop-up suggestions. Structured properly, the RSP subpage could be rendered in various ways, including as a table row as currently, although why you would want to see other, unrelated websites in a big table when you already found the one you want via search, I don't know. Browsability would still be covered by the simple flatlist idea, which could be another index into the subpage collection. With atomic subpages, other list subsets could be devised to access them in different ways as well. And of course, there would no longer be any limit on the number of them, which is only likely to increase. Mathglot (talk) 01:43, 16 September 2025 (UTC)

Sorry, I did not see that SuperGrey has suggested something pretty similar to this, iiuc what you meant. Mathglot (talk) 01:51, 16 September 2025 (UTC)

I've mentioned pruning unused shortcuts multiple times, and if it comes to that merging the subpages back in (as Johnuniq said) should free up a ton of room. Aaron Liu (talk) 02:51, 16 September 2025 (UTC)

When you talk about "unused shortcuts", do you mean "blanking unpopular shortcuts"? As in, the first shortcut in the list, WP:112UKRAINE, has no incoming links unrelated to this page (not counting edit summaries, etc., but it also has an average of 1 page view/day, and the editor who created it appears to have been on a shortcut-creating spree rather than needing one for a discussion), so just remove that, and hope that will free up some breathing room?

How much room would we free up, if every single shortcut were removed? If the answer is "less than 5%", then I think this approach will be too small to solve the problem. WhatamIdoing (talk) 03:47, 16 September 2025 (UTC)

Every shortcut takes up about 300 bytes, and there's 613 redirects to RSP. Assuming 200 of them are unused, we'd free up 60,000 bytes. But I'm also using a byte counting methodology that results in far lower numbers than the ones Mathglot has so it might be even more. Aaron Liu (talk) 11:50, 16 September 2025 (UTC)

That's 2.8% of the limit. It would take us from a panic-inducing 99.7% down to 96.9%, but I don't think that's a big enough change.

Using Mathglot's numbers, a typical table entry is 10K. Your suggested change would let us add just six (6) more average-sized sources to the table before we would be right back here with the same problem again. WP:RSN has more than six RFCs listed at the moment.

What can we do that would give us room for a hundred new entries, or even 500? WhatamIdoing (talk) 17:26, 16 September 2025 (UTC)

Placing one per page allows virtually limitless entries. In the early days of the (browsable) internet, Jerry and David's Guide to the World Wide Web was just a list, then a hierarchical list as it grew, and finally was renamed the Yahoo Directory. Finally, in 1995, Jerry and David hit upon the idea of providing a search mechanism instead of just a bigger and bigger list. I think we are approaching 1995 in this discussion. Mathglot (talk) 00:32, 17 September 2025 (UTC)

Firstly, if we the difference between mine and Mathglot's methodology, we get 10214/3721*60000/10000=16.5 new BuzzFeed News–size sources, which... isn't much but does give us a lot more time to look at simplifying templates.

Secondly, I believe unsplitting would also do so, besides the "links" method. With everything on one page we had 1531890/2097152 bytes, and that was before I deployed drastic PEIS measures to what was then 1728538/2097152 bytes. (I'm taking these counts from the Internet Archive to avoid counting the current versions of transclusions instead.) When we get far nearer to the tipping point, by which time it will become evident whether simplification has been successful, we should make a discussion on which option we the RSP people prefer.

Another thing we could drop on top of the links thing if it comes to that is a toolforge thing that renders one big table from the subpages but doesn't put it on the wiki. Aaron Liu (talk) 04:02, 17 September 2025 (UTC)

I think drastic measures isn't the way to go, as it is only an emergency stopgap doomed to future failure. I admit to engaging in the same type of thing, motivated by the emergency I guess, but I'm not really happy about it, and would prefer to undo them; one in particular may degrade accessibility in dark mode; that one needs to be reverted when a better solution is found. Mathglot (talk) 06:14, 17 September 2025 (UTC)

I currently don't see any problem with any of the measures we have right now; an example of something I would have a problem with is substing citations to invoke the modules directly.

Another measure we could do is creating one "shortcut" template for of the statuses you could specify for the RSPSTATUS template. This would make use of the "invoke without any parameters" cache.

one in particular may degrade accessibility in dark mode

Which one is that? I feel a vague déja vu like I did something that caused this before but I don't remember what it is. Aaron Liu (talk) 21:20, 17 September 2025 (UTC)

I had replaced a dozen {{cross}} templates in WP:RSP with [[File:X mark.svg|20px]] () saving 868 PEIS bytes. (And no, I don't know why that results in a fractional average.) I just did a test with */2, replacing 24 occs of {{Wikipedia:RSPSTATUS|gr}} with data-sort-value=0|[[File:Yes Check Circle.svg|20px|Generally reliable|link=Wikipedia:Reliable sources/Perennial sources#Generally reliable]] for a paltry PEIS savings of 6,792 (219,211-212,419). Admittedly, that savings would increase if you replaced all 80 occs of WP:RSPSTATUS (guessing 21k) and with the other 7 (smaller) files, maybe reaching 100-120k in total savings, and perhaps bringing RSP PEIS down to 1,972,370/2,097,152 bytes, or 94.0% of capacity. Worth it? I strongly think not on the face of it; and if you factor in the increase in difficulty of maintenance without WP:RSPSTATUS and the files all being more fragile and error-prone, I think that would be a very bad bargain. Mathglot (talk) 23:02, 20 September 2025 (UTC)

I would not subst the RSPSTATUS templates; these are things that should have centralized change possible. I meant creating separate RSPSTATUS/gr, RSPSTATUS/gun, etc. templates to make use of the PEIS cache, which only activates when you call a template without any parameters, so that's probably why your cross replacements saved so little. Aaron Liu (talk) 16:13, 21 September 2025 (UTC)

I wouldn't either, and I have pretty much abandoned the futile hunting around for crumbs which might save a few tenths of a percent here and there. It isn't worth the effort for the extremely modest gain, and I think all the fat has been squeezed out of the table by this point anyway (with the possible exception of Johnuniq's monolithic table, but that has maintainability or other issues, although it could buy us time). I think we need a ground-up rethink of the entire system, and at this point, I think that WaId's summary + explanation approach is the way to go, and offers limitless expansion. I am extending or branching that idea by looking at non-table solutions which offer the possibility to have more user-friendly landing pages such as Ballotpedia and BBC which are easier to read and expand, and am looking into this via this mock-up. Mathglot (talk) 04:47, 22 September 2025 (UTC)

Aaron, Well, I wasn't hunting, but by chance I was browsing 2026 United States House of Representatives elections which has 688 citations, and I wondered how they dealt with it. Turns out they use Module:Cite, which I had never heard of. Check out the first sentence under Module:Cite#Usage. The Perennial sources page has only 35 refs, so not sure how much savings would come out of it, but we are now at 99.77% capacity, so anything we picked up might be worth it. I'm focused more now on the links+landing pages scenario than on clawing back PEIS bytes, but I thought you would like to know. Mathglot (talk) 06:10, 23 September 2025 (UTC)

Yeah, that's what I meant with the substing citations to invoke the modules directly above; the module is just what all the citation templates use under the hood for obvious PEIS reasons. I would prefer other measures over that, though it'd be our equivalent of extraordinary budgeting measures.

Speaking of, how about we merge all the RSP templates into one Lua module that generates table rows? Would also make the table VE-editable at last. crazy idea but hey I prefer this over substing citations. Aaron Liu (talk) 15:39, 23 September 2025 (UTC)

Threading note: the following comment is a reply to the comment of 01:43, 16 Sept. at the top of this sidebar.

this row is 2,794 raw wikicode bytes, and a PEIS of 10,214

Where's this number from? Is that the total size of the final (MW)HTML output? I'm fairly post-expand size only counts the size of expanded wikitext; counting the size of the output from Special:ExpandTemplates, that should be 3,721 bytes for Buzzfeed News. Aaron Liu (talk) 11:53, 16 September 2025 (UTC)

No, it is only the PEIS. If you extract just the "Buzzfeed News" row from table 2, you will have 2,790 bytes of wikicode (2,786 chars, 2,529 printable). Take that and paste it into a sandbox by itself and Preview it; the PEIS for that page containing only the one row should show 10,214/2,097,152 bytes. There is another row called, "Buzzfeed" (contrast, "Buzzfeed News"); could that be the source of the discrepancy? Mathglot (talk) 05:21, 17 September 2025 (UTC)

I see how you got your figure (I get 3,743 bytes by counting up the result field in ExpandTemplates). I was using the PEIS value reported directly in the table in the Parser profiling data on the wikipedia page after pasting the row there and previewing it. If you also save the page (e.g., here) you can view it either in Preview mode, or in the NewPP limit report in the page Html; both yield 10,216 bytes. Mathglot (talk) 07:25, 17 September 2025 (UTC)

Thanks; I was ignorant of how the transitive dependencies counted as well. Slightly fortunately, quite a bit of that number is invocations without any parameters that are cached, so adding a BuzzFeed-like entry to any existing page would only add 6,521 bytes. Still worrying, though. Aaron Liu (talk) 18:28, 17 September 2025 (UTC)

Good news/bad news: if we get desperate, replacing WP:RSPSHORTCUT will save us quite a bit of PEIS room. I tested replacing all RSPSHORTCUTs in Wikipedia:Reliable sources/Perennial sources/2 with non-template code, generating Wikipedia:Reliable sources/Perennial sources/2/sandbox in this edit, and PEIS went down from 215,537/2,097,152 to 108,543. The replacement code is quite ugly, and I don't think we can expect anyone editing that file to adhere to that pattern when adding new rows, but it would buy time for adding rows the old way, i.e. with the template shortcut. Does anyone think this changes anything in a major way, or that it could be a possible solution option in an Rfc? I don't; I just think it makes the file even more fragile and error-prone than ever, and I would strongly oppose it as even a medium-term solution. I think we can use it in case of dire emergency, so that if someone adds one row that tips the table over 100% PEIS and breaks it, we can replace a couple of WP:RSPSHORTCUTs with their ugly twin to save us just enough PEIS room so the whole table doesn't break. But I wanted to expose the idea, just so we could have something else in our toolkit in case we need to buy a little time while working on the long-term fix. Your thoughts? Adding @Aaron Liu, WhatamIdoing, SuperGrey, and Gråbergs Gråa Sång:. Thanks, Mathglot (talk) 23:23, 7 October 2025 (UTC)

Not a possible option, could be emergency measure, though still I'd prefer just removing underused shortcuts. Unfortunately I haven't much time lately so it would be nice if someone could do it. Aaron Liu (talk) 00:25, 8 October 2025 (UTC)

Do we know which ones those are? Mathglot (talk) 00:28, 8 October 2025 (UTC)

That's the hard part! I'm planning on writing a bot and am somewhat close (?) to fixing an old bot framework so I can code a bot to remove those shortcuts in glorious Kotlin (programming language). Man I do it to myself. Aaron Liu (talk) 00:35, 8 October 2025 (UTC)

As a manual determination, one can just go to the WhatLinksHere page for WhatRedirectsHere, ignore the entries from transcluding/copying parts of RSN, and remove the ones that subjectively aren't used much. Aaron Liu (talk) 00:37, 8 October 2025 (UTC)

If the bot works as expected, what would be its intended use? As part of a proof-of-concept for the first bullet at § Approach summary (remove some templates) in order to demonstrate the usability or likely benefit of that approach in an Rfc, or as something you want to do now before we get to an Rfc, or something else? (edit conflict) Mathglot (talk) 00:49, 8 October 2025 (UTC)

It's going to take time before we get to a more permanent solution, so we do this in the interim so new entries can still be added, and I kinda want to see where this'll get us. Aaron Liu (talk) 01:26, 8 October 2025 (UTC)

Another emergency thing we could do is remove {{no redirect}} from RSPSHORTCUT. The negative implications should be obvious for this option. Aaron Liu (talk) 00:43, 8 October 2025 (UTC)

Seems like a minor cosmetic change, maybe a little less elegant, if it helps, do it. Gråbergs Gråa Sång (talk) 06:36, 8 October 2025 (UTC)

Well, we are (were) in a desperate situation. I've swapped chunk /2 and its sandbox to gain a little breathing room. This doesn't preclude us from using one of the other stopgaps suggested above, and if they are preferable, we can simply unswap the pages. Note: hitting the hard limit and what to do about it is also being discussed here, in the context of whether this means we have to start an rfc in a hurry or not. Mathglot (talk) 18:19, 10 October 2025 (UTC) And here, about how to word an rfc. Mathglot (talk) 18:49, 10 October 2025 (UTC)

After the fact, I realized it would have been easier just to change the transclusion of chunk 2 in the main table to point to 2/sandbox instead, rather than do the round-robin move. Oh, well; next time, if we need to do it again. For the record: parsing and row-building based on content of the chunks should parse 2/sandbox, not 2 as things currently stand, or risk possibly getting hung up on the wikicode introduced to replace RSPLAST and reduce PEIS. Mathglot (talk) 21:46, 10 October 2025 (UTC)

Forgot to mention that there is one more way of saving some PEIS capacity not previously mentioned I don't think. For the record, it involves spinning off the table onto its own page, thus reducing PEIS by the size of the expanded templates in the non-table portion of the current page. If you move the table to its own page with nothing else but the table (and a textual Intro), PEIS would drop by 77,698 bytes, and you could link to it from the main page with the instructions. That would buy you a small amount of time, but hardly seems worth it. Mathglot (talk) 01:16, 11 October 2025 (UTC)

arbitrary break

Threading note: the following comment is a reply to the comment of 23:11 15 September above.

WhatamIdoing, combining your list idea with SuperGrey's search idea could yield something like this demo. Note that the demo only works for B-C-D sources for the moment. Also, the search function links small (one- and two-row) tables, but given that we have search, they don't need to be structured as a single table row anymore, so could be completely rewritten as sectioned pages, however best presents the data, and are not limited to columnar style anymore. The only reason they are one-row tables now, is because it was fast/easy to do that. Mathglot (talk) 08:53, 21 September 2025 (UTC)

Looks neat! SuperGrey (talk) 09:00, 21 September 2025 (UTC)

@Mathglot, I like this. I don't have a preference for whether you end up at a larger table (e.g., all entries start with "B–D") vs a single page.

In terms of layout, sometimes people are looking for alternative names or website domain names. Would you suggest the search box for that, duplicating entries, or expanding them to name+URL (which would require wider columns)? WhatamIdoing (talk) 16:45, 21 September 2025 (UTC)

WhatamIdoing, sorry, thought I responded to this. For alternative source names, we could just add extra links to the page. Already done, in a few cases; see, e.g., any of the four 'T'-sources currently in the demo; those all point to the same landing page (in this case, Dotdash Meredith). Ditto 'Conservative Review' and 'Bloomberg profiles'.

For abbreviations or common short names, e.g., 'Cosmo' ⟶ 'Cosmopolitan', if their links would be adjacent on the Index page, or nearly, I don't think we need to add separate links for them (t.b.d., case by case, I would say). Otoh, to facilitate someone searching 'Cosmo' from the search box, or 'Kos', we could add redirects; but regular Cirrus search is pretty good at finding strings anywhere on the page, preferring title words, so that a search for 'Telegraph' turns up the Daily Telegraph landing page first, followed by two other landing pages that happen to mention it, namely, BBC and CoinDesk. Adding a redirect bumps it up in importance, so that a Cosmo or Kos redirect would appear first, followed by landing pages containing those strings elsewhere on the page.

For domain names, or indeed, any string on the landing page, the search box is always a possibility. I don't think we should add urls to the index page, for the reason you stated, and also because it would double or triple the size of the index, for an edge case easily handled by search. (And also, because it keeps the index page less of a departure from the current table approach, as far being nearly one-to-one wrt table row ⟶ landing page, so less of an adjustment for users if this scheme is adopted.) Mathglot (talk) 20:40, 5 October 2025 (UTC)

I like that demo and think that ditching the table and splitting to individual, searchable pages is definitely the way to go. audiodude (talk) 20:16, 10 October 2025 (UTC)

The problem would be fixed by copying each section (such as Wikipedia:Reliable sources/Perennial sources/1) to where it is needed on the main page, rather than transcluding it. Has that been rejected as too ugly? Johnuniq (talk) 02:27, 16 September 2025 (UTC)

Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Page size Aaron Liu (talk) 02:53, 16 September 2025 (UTC)

To be fair, I don't think those RFC participants knew this would break the PEIS limit (who can blame them). Of course though, the same accessibility concerns would still exist if you put everything back on the main RSP page. Endwise (talk) 13:14, 16 September 2025 (UTC)

Johnuniq's solution would work, but would make the long table harder to edit. One could solve that problem (at a cost) by copying all the data to the page, but dividing it into tables, each in its own section, which would enable section editing of segments that are the same size as the numbered subpages are now. So the editing burden on editors would remain the same, and PEIS would be decrased, allowing for more growth. (Although eventually it would still hit a limit somewhere, likely before it is twice the size it is now.) However, there would be a cost: the utility of sortable columns would be much reduced, being limited to whichever one of the eight tables you are looking at.

The functionality of "show me all the sources of status=X together" could be regained however, using a workaround. The idea would be to tag every row to make it selectable, and create a new page per status, such as */Perennial_reliable, which would simply pick up all the reliable rows by selective transclusion. This method is doable, but would require maintenance every time some source changed from reliable to some other status or vice versa; how often does that happen? Does it happen more often than us bumping into the hard limit on PEIS now, with concomitant maintenance we are now doing, not to mention all the time talking about various solutions?

Another way, could be to extract the reliable rows and paste them into another file, e.g. Wikipedia:Reliable sources/Perennial sources/reliable. If we did one of these for each status, then we wouldn't need sortable columns, and could just link to the appropriate status table. The cost here, is multiple copies of the same data, although if it doesn't change too often, that is probably not too serious, plus the extraction is doable by regex so could be automated. Plus, the "reliable" table has a PEIS of only 353,306 bytes so it can grow for a very long time (and loads fast). Mathglot (talk) 08:42, 21 September 2025 (UTC)

Selective transclusion incurs the PEIS cost of the entire page, not just the cost of the parts selected (unless you're using onlyinclude/includeonly/noinclude tags, but you'd need more than those to sort into 4 statuses). There's been talks to change it to the latter but nobody has done the coding to do so yet. Aaron Liu (talk) 16:18, 21 September 2025 (UTC)

Raladic's table options

I have a different idea, with two options on elegance, though one will require us to install an extension, but it would be both elegant in that we can still keep the table, while reducing the issue of the PEIS, and as a bonus, cutting the entire thing in about half for the average browse to WP:RSP, so perf would also improve. The biggest reason of why our list is so big is because the "Summary" column, which is more or less free text (and plenty of it) and accounts for about 50-60% of the content. So, if we get rid of it for normal page loads, then we're probably good as it would give us a lot of room to breathe. There are two options, they both share the same basis of doing a little bit of simple template magic using conditional wrapping based on whether we're on the subpage, or the root page. Here's the template I cobbled together: User:Raladic/templates/lazySummary (it can serve both scenarios, though if we go with option 1 it can be simplified as it doesn't need the extra scaffolding). The template assumes we have a structure of a root page, with subpages behind it like RSP has with the transcluded subpages. And then there's two options:

Option 1

The template will simply show a traditional link that brings a user directly to the subpage of the entry for when they want to read the summary

Benefits: Simple, requires just a very basic template that checks if it's being loaded on the subpages or the root page, head on over to my User:Raladic/sandbox for illustration purposes (and could strip a good chunk of the template, as most of it is for the lazy loading)

Option 2

The second option, which is a lot more elegant, but takes a tiny bit more effort is that we can dynamically lazy-load the summary on a click of a button. this is pretty easy using JS client-side script and invoking the mw:API to fetch the subpage when a user clicks on "show summary". To make things extra spiffy, we could break down the current fracturing of the subpages into the literal alphanumeric space (aka have 26 ABC + 1 alphanumeric page), as it means the on-demand load would be able to load an even smaller page. The client can also cache the page while the user is on it, so if they want to see a few summaries, we only need to load the pages of the letter and can otherwise just grab it from the temporary cache in the browser. I have a live demo over in my User:Raladic/sandbox.

Note - you will need to install User:Raladic/scripts/lazySummary.js into your user scripts (common.js) and then you can click on the "show summary (lazy load)" buttons and it will dynamically fetch the summaries from the sub-pages as needed).

In order for this option to work for all users, we will need to turn my POC JS script into a proper extension published on MW so that en-wiki can install it and will take a few moments to get through the vetting process. That being said, it would allow the user not to have to leave the page and still get all the information if they want to read the summary.

Anyway, that's my thoughts and ideas on what I've been cobbling together as a proof of concept. Let me know what you think. Given that the two options are not mutually exclusive, we could start with option 1 and just have a static go to summary for now, while working on making option 2 solid. Raladic (talk) 09:55, 21 September 2025 (UTC)

I have doubts on its WP:ACCESSIBILITY. See MOS:PRECOLLAPSE: Wikipedia articles should be accessible to readers using browsers and devices that have limited or no support for JavaScript or Cascading Style Sheets, which is referred to as "progressive enhancement" in web development. SuperGrey (talk) 10:59, 21 September 2025 (UTC)

No, it's not an accessibility issue as long as the selective element is clearly targetable by screen readers, and hasn't been for a long time.

Also, the RSP are not a main space article. But I think it might also be time to seriously overhaul some of the language of that guidance. "Progressive enhancement", a 2003 term when the internet was full of blinking GIFs, is nowhere near where we are 22 years later.

Every reasonably recent browser supports CSS and JavaScript, you can't browser the web without it. Wikipedia is little exception to that nowadays.

The MOS:PRECOLLAPSE is literally citing a 2016 paper from WMF. In computer age, that is literally getting close to historic, in Moore's law terms we've since shrunk chip size two full times. So, we should probably overhaul some of those sections. Raladic (talk) 11:57, 21 September 2025 (UTC)

See #c-Mathglot-20250915230000-WhatamIdoing-20250915172400—the status is inseparable from the summary. People are annoyed enough already by editors relying on the status for blanket judgement ignoring the nuance expressed in the summary. We could do the index idea above + a script/toolforge webpage to transform the index of just links into a table, though. Aaron Liu (talk) 16:21, 21 September 2025 (UTC)

Maybe I’m misunderstanding what you’re saying, but my proposals don’t separate them - they are still together in the source subpages, optically exactly as they are right now as far as readers are concerned and pretty much what @Mathglot was suggesting (note that my manual nav links are also deep links by way of the template jumping to named anchors).

And if we did go down the route of the lazy load even the main list could have the summary still. We could even trigger the lazy loading automatically when a user jumps to an entry and it becomes part of the visible frame in their browser window instead of being click based. Raladic (talk) 18:16, 21 September 2025 (UTC)

Ah you’re referencing your reply to that sub thread that you’re concerned if people don’t see the summary immediately but have the rest that it causes issues - fair, though I think solving that via Option 2 then makes it very elegant if instead of being manual click based, we make it automatic nav-based, which is very easy to do as it’s basically what happens for images already as they get loaded lazy after the page is loaded, but without clicks required, the user just needs to scroll to an image and it will be there by way of background loading. Raladic (talk) 18:25, 21 September 2025 (UTC)

We can't expect every viewer of RSP to install a userscript; the display under default settings has to be somewhat good enough. In regards to writing an Extension, check out Phab:T355150 for an idea of the deployment process. Aaron Liu (talk) 18:44, 21 September 2025 (UTC)

Raladic said,

we can still keep the table, while reducing the issue of the PEIS...

Before we get into your options 1 and 2, I much prefer WaId's list of links idea. Can you please explain what advantage there is to keeping the table, other than that's the way it's always been done? I see no advantage to it, and it is the source of the problems that this entire discussion is trying to solve. WaId's solution solves it forever, with room for near-infinite expansion. I don't see why we should tie ourselves into expensive, lengthy, complicated knots, just to keep the one-giant-table layout. Mathglot (talk) 19:11, 21 September 2025 (UTC)

Well for one it’s the software engineering principle of Useability.

The current table, while not small is extremely easy to use by way of load page, hit ctrl+f and search and have your answer in a single navigate (unless it’s not listed, then you gotta go do the archive search).

The list without status and the other details means we’re splitting this user flow into a multi-page process. It will now require users a minimum of two distinct page loads. CSAT will go down and users tend to give up when things are frustrating.

So I think just a list and link to entries is really no better than just having nothing and a search page that is well scoped to be able to get the answer in just as many clicks.

That being said if we go with option two, we also have the option of instead of lazy loading just summary we could in fact, lazy loads entire section transclusions and append them to the page. This would basically just mean you have an infinite scroll list and whether we automatically just async load it, which is what wiki does for all images on Wikipedia, they’re all tagged for decode=async, which basically means the browser knows where the images are, but it won’t stop rendering the page, even if the images are not yet loaded and they just get loaded in the background. Now our case obviously because we want not just images but entire sections of text to load. We can replicate that behavior with a little bit of client side work since the mediawiki API query is what would do the parsing, meaning it doesn’t count towards the page PEIS because as far as the page is concerned, there is not a single page expansion, instead, as far as the page is concerned, it only needs to expand the page with hints for the fact that we are going to load something afterwards and tell us where it is, and the client side job takes care of when loading happens after the metadata for the page itself is loaded. This is also infinitely expandable because we can start with what we have right now of 10 sub pages, but we can break it down like I said into 26+1 alphanumeric pages, which would have the benefit for users as well that if they know the name of something they could just directly bounce to that letter page without having to go through redirect or knowing the range of the multi letters that it is right now, but also it still leaves the door open for the future. like say a block gets too big. We can break a block down into sub blocks just like dictionaries do sometimes too, where you have Aa - Am, An - Az subsection and because we would asynchronously load actual page fragments as needed, preloading all of them after the page is loaded or only do it when the viewfinder gets there that’s up to us, but it’s pretty easy from a purely technical standpoint. Raladic (talk) 19:55, 21 September 2025 (UTC)

Experienced Wikipedia editors usually hate lazy loading of text. The first complaint is that it interferes with ⌘F text searching, because you have to wait for the page to load, and then scroll to the end/take an action that will trigger the lazy loading.

But maybe you're talking about something a little bit different? It sounds like you dislike this process:

• Go to RSP (which will load quicker than it does now).
• Find name of source/website in the list.
• Click the link to read that entry.

and want to suggest this process:

• Go to RSP.
• Find name of source/website in the list.
• Click "Show summary" button to read that entry.

I also wonder how your proposal would work when the editor is going straight to WP:RSPFACEBOOK instead of the list. WhatamIdoing (talk) 20:27, 21 September 2025 (UTC)

The term lazy loading is a bit overloaded these days, but there is two principal uses:

• Traditional lazy loading - load something on demand only at the point it is needed
  • My POC right now falls into this with having a button to show summary only when a user wants to see it,
  • but as I mentioned, it could also be changed to auto-pull them based on viewport (where the browser is going)
• Deferred loading, or sometimes called async loading or lazy initialization also kind of falls into this - here we are not not loading something, but we're not doing it all at once.
  • HTML5, which was "finalized" around 2014 (turning into recommended status, aka telling browsers to start implementing) basically changed the way that the web is being used nowadays. One of the biggest aspect of it was that JavaScript morphed from being something to make blinky things appear, to now being the base bone of modern website interaction and various frameworks such as React, Angular have taken it to new levels.
  • One of those aspects was that browsers were empowered to load things as needed and tell server what and when they need it by way of the introduction of async properties throughout the framework.
  • One of those pieces led to browsers natively doing this for images since images are stored somewhere and just referenced through the img tag, which now natively has a decoding property in modern browsers (for the past 5-10-ish years or so, see the link following for the full compat table, most browsers built it between 2016-2020 as part of the adoption of HTML5, which can be controlled using the HTMLImageElement property set to either load all images synchronously (aka alongside the page DOM), hybrid (browser decides what to load when), or fully asynchronously (browser will basically finish loading and rendering page to the user and the images get loaded in the background threads and will appear when they're ready
    • This is the behavior on en-wiki for images, which are set to decode=async. Now for images this is native functionality in the browser because without it, most webpages nowadays would make people thing we're back in the early 2000's of modems and early broadband.
  • For text elements, there is no native browser tag for this, since they are not typically referenced by a URL, but just simply placed inline a span/div/table... But that isn't to say that it's not easily doable through a bit of client handling code, which just needs to know where to fetch something from and will then do it asynchronously using the async stack.

So, while I didn't initially go down the full-deferred route, all it would take is a few changes to my script to instead of waiting for a user clicking the link, to just load it asynchronously in the background when the DOM is ready and then just fill it in. Whether we keep it limited to just defer loading the summaries, or whether we'd defer load the entire sections, either are totally doable. Personally, I think keeping the sections loaded, but deferring the load of the summaries gives the benefit of users being able to load the page (a lot faster than today since it will be about half the size), and we just kick off the loading of the summaries in the background to happen as soon as the page is rendered. Since users mostly come here hitting CTRL+F looking for the title of a publication, this info would already be available, and chances are that by the time they hit enter, the summary is loaded in as well.

We can do this by means of an extension, or we could even log a ticket and see if it should be a new native feature of the MediaWiki stack (as it could potentially be used for other actual uses beyond this backend use here for project space).

Hope this helps explain. Also just to be clear, I'm not saying we must do it. But I do think it could solve the issue elegantly and means we are not strictly limited by the current native server-side expansion. At the end of the day, we are using bots and other tools for all sorts of tasks that would not be possible by the native stack. This is no different. Basically, RSP has reached a point where the native tools alone currently just might not cut it, so since we're having this discussion here on addressing it, I think it is worthwhile to consider more technically "advanced" techniques like this. Raladic (talk) 23:16, 21 September 2025 (UTC)

Leaving all the rest aside, "technically advanced techniques" sound like a way for this page to fail the bus test someday. WhatamIdoing (talk) 23:38, 21 September 2025 (UTC)

Well I put "advanced" in parenthesis, because it really isn't (if you check out the code, you'll see it's very little).

If you haven't tried out the script to see it in action at my User:Raladic/sandbox, here are two screenshots to help illustrate:

• 
  Summary text deferred to ad-hoc loading by clicking on a "show summary" button
• 
  First summary loaded after the click

Note I didn't hide the "show summary" button link in the second screenshot, but obviously there's many different options including hiding it.Raladic (talk) 23:45, 21 September 2025 (UTC)

Displaying either summary or status without the other is still a no-go for me. I mentioned that we could have a scripted way of transforming an index of links into a full table. Aaron Liu (talk) 04:24, 22 September 2025 (UTC)

By scripted transform of links and index, I presume you are referring to your comment of § 16:21, 21 Sept and mean programmatically producing the live table we have now given some input links? I don't see how this would be possible, as the summary is the largest section in each row, and is hand-drafted. Mathglot (talk) 05:00, 22 September 2025 (UTC)

Every link goes to a subpage with the summary text placed in a standardized location, no? Aaron Liu (talk) 13:16, 22 September 2025 (UTC)

As I mentioned above - doing on demand loading like my demo is not what we have to do. It’s just the easiest to demonstrate the “how” it works.

We can automatically load all of it as soon as the page is rendered (as far as the browser is concerned). As far as users are concerned it likely makes little difference in user experience as the asynchronous load-ins will happen faster than they can get to the entry they need. We can also optimize it to prioritize loading a section earlier than another. Raladic (talk) 05:45, 22 September 2025 (UTC)

I still wouldn't count on all users to install a script, and an extension would take a very long time to deploy. Aaron Liu (talk) 13:15, 22 September 2025 (UTC)

I'm with Aaron: If you can see red/yellow/green/gray color coding, you must be able to see the text that says "Oh, BTW, the general category doesn't apply to the exact scenario you're looking at". WhatamIdoing (talk) 15:51, 22 September 2025 (UTC)

Regarding "hit ctrl+f and search and have your answer in a single navigate" – we might be getting into the weeds of what constitutes "a single operation", but finding a link on WaId's link page and clicking it seems like one operation to me. But regardless of how many events or operations it is, seeing link+clicking link (and typing nothing) is faster imho than 1) hitting Ctrl+F, 2) typing a search term (five key clicks? ten? more?), and 3) spying the highlighted term on the page, and 4) clicking it. That is, if it is the right one. Is that your main supporting pillar for this scheme? Because I think this "single navigate" argument is a weak one. Unless you are talking about number of page loads rather than events or operations, but I think we are way past the point where we have to worry about server load based on a clicked link. Mathglot (talk) 05:43, 22 September 2025 (UTC)

Whether you manually scroll down the list of the several hundred sources to find the one you’re looking for, or you search for it using ctrl+f, it takes you a few seconds (unless you followed a direct entry shortcut.

Note that scanning visually gets a lot harder when it’s just a dense list of single line links, our brain gets overwhelmed past 7 items, plus minus 2..

Scanning the current table manually doesn’t typically have that issue because one page will typically give you 3-4 entries at a time since they are long sections (due to the summary and links pieces).

But to your question, no, I was talking that currently if I need to check if a source is reliable I know to go to WP:RSP and I’ll have the answer without leaving the page in many cases if there’s an entry for it.

With your proposal, this changes to 2 page navigations. One for going to the list, and then another one clicking on it, waiting for that page to load and only then being able to see the info I needed.

That is, in addition to the how to find the entry, which still applies just as it does today, but will get harder because human cognitive function will become a bigger factor as I referenced above. Raladic (talk) 06:04, 22 September 2025 (UTC)

I disagree with almost all of your assertions, some of which are based on incorrect assumptions, but I will leave that for another day. Perhaps someone else will chime in in the meanwhile with some fresh views. But I will follow your development with interest, to see what it yields. Mathglot (talk) 06:34, 22 September 2025 (UTC)

I based my assumption of the single line link list based on WAIDs example.

I see you also just posted your proposal below now, but that 3 column list doesn’t negate the cognitive brain limits, if anything it adds more elements.

I do value your thoughts however, so I’d love to hear them another day :) Raladic (talk) 06:50, 22 September 2025 (UTC)

A direct-entry shortcut like WP:RSPYOUTUBE should take you to the full list entry, not to the bare list. WhatamIdoing (talk) 15:52, 22 September 2025 (UTC)

Raladic, coming back to this, I can see how your options are a way to reduce initial page load time, but I don't get the part about PEIS improvement. Taking option 1 first, the summary field consists of text and usually some wikilinks, and rarely has any templates at all. For example, I searched the summary field in all 45 rows of Wikipedia:Reliable sources/Perennial sources/1, and not one had a template in it. (The first one I saw was at iNaturalist in WP:Reliable sources/Perennial sources/4, but I might have missed some.) Anyway, templates appear to be rare in the summary field, so whether you move summaries off to another page that loads later, or on demand, that should not affect PEIS of the initial table much. As a test, I checked PEIS of Wikipedia:Reliable sources/Perennial sources/1 and got 117,695/2,097,152 bytes. Then I replaced the summary field in all 45 rows with 'Summary', and now PEIS was 110,301/2,097,152 bytes, for a savings of about 7,400. If subpage 1 is typical, we can multiply by 8 to project savings to the whole table of 59,200 bytes, which is about 3% of PEIS capacity. That doesn't seem like much savings. Or am I missing something? Mathglot (talk) 09:09, 5 October 2025 (UTC)

it depends on how far we’d go with the idea, we can do the asynchronous loading for just the summary portion. Though theoretically the entire text content itself should be part of the bytes contributing to the PEIS since they are being expanded with the transclusion of the page itself.

But we could also do it for the entire rows (or ranges of rows, like say we actually asynchronous loaded the subpages like /A, /B and so on. In which case, it would outsource the entire template expansion for each row/letter to be done by the server call.

So that means the initial page load of /RSP would be very light PEIS wise. Raladic (talk) 18:29, 5 October 2025 (UTC)

Raladic, I get the gist of it, thanks for the explanation; the details escape me somewhat, but that's okay. Part of the reason for these questions, is that I have been trying to compile a very brief summary at § Approach summary of all of the PEIS-reduction approaches we have all come up with, so that eventually it would be possible to describe the approaches as multiple options to choose from as part of an Rfc question. Unfortunately, I don't trust my understanding of your approach sufficiently to be confident about being able to encapsulate your suggested approach in a couple of sentences. Could you please have a look at § Approach summary, and add something there describing the core of your approach? Thanks, Mathglot (talk) 18:57, 5 October 2025 (UTC)

Regarding Option 2, is there a way to get similar "lazy loading" behavior with existing extensions? audiodude (talk) 20:19, 10 October 2025 (UTC)

None that I know of, and in any case, this approach appears to be moribund at the moment. See § Approach summary. Mathglot (talk) 20:56, 10 October 2025 (UTC)

Mg's central list plus multiple landing pages

 Courtesy link: Wikipedia:Reliable sources/Perennial sources/Index

Further information: */Ballotpedia, */BBC

This is an offshoot of WhatamIdoing's § Central list, and click to longer explanation above. Where WaId's approach involves a central list of links that point into a table (which could be the big one, or one of the eight smaller, numbered tables depending how it was set up), this approach copies her central list of links, but each link goes to its own landing page. That is, there will be one page for Ballotpedia, one page for BBC, and so on. I have mentioned this approach in passing before, but it has a tendency to get lost amidst other topics so I thought it was worth starting this section to centralize information about it here.

Benefits of this approach, is that it is a complete, forever-solution to the PEIS problem that sparked this discussion. But there are other important benefits: instead of the reliability assessment for one source being squeezed into a table row, with practical limitations on the text so that the rows don't get too wide tall, and liberal use of icons requiring a legend to keep some columns narrow, the landing page approach looks more like a page for an SPI investigation or Afd nomination, in the sense that you get full use of the page, and while there is an overall suggested format from one landing page to another (just as there is for one SPI or one Afd nom to another) you are free to use the page and expand it to whatever extent is necessary to cover the topic of reliability of that source. Another benefit is that if this approach (or something like it) gained consensus, there would not have to be a "big-bang" cutover when it was all done, trying to keep two systems in sync. A hybrid system is possible, where links on the index page could point into the table until a landing page was ready, and updated at the appropriate time.

Downsides of this approach: no table means no browsing up and down the rows for "neighbors" of this row. That seems minor to me, though, as the fact that 'Blaze Media' and 'Blogger' are near each other alphabetically doesn't bring any benefit that I can see to an editor investigating reliability of a source. And for that, you have the link index anyway. Also, no sorting the table on status, like for example, all the reliable ones. But this is not a big deal, because it can be solved by building per-status tables (a single regex operation to extract all the "reliable" rows, say) and linking them, for example, Wikipedia:Reliable sources/Perennial sources/reliable. Another downside is that many are used to seeing this page as a table, and there may be resistance to replacing the table with individual landing pages.

The main index demo page is at Wikipedia:Reliable sources/Perennial sources/Index, and currently works for sources starting with 'B', 'C', or 'D' (those originating in Wikipedia:Reliable sources/Perennial sources/2). That's it for now; more to say about this later. Mathglot (talk) 09:06, 22 September 2025 (UTC)

Support - I especially like how we have these detailed pages like /Ballotpedia. It can store a lot of useful information. SuperGrey (talk) 09:21, 22 September 2025 (UTC)

Comment This looks quite usable. I can search or ctrl-f on the same page. Gråbergs Gråa Sång (talk) 13:41, 22 September 2025 (UTC)

Support This approach addresses the size problems. I don't think it would take editors much time to adjust. I'm assuming all subentries (for example, the table's New York Post row includes NY Post, The Evening Post, Page Six, and Decider) will have individual entries in the list, which makes it easier to locate them than the table where you have to use ctrl-F rather than look alphabetically for those entries. If it gains consensus, during the transition, I suggest an informational banner on the table to caution editors that the table is being phased out so they don't get in the habit of going directly to the table and bypassing the index. Schazjmd (talk) 14:03, 22 September 2025 (UTC)

Schazjmd, my assumption is like yours regarding NY Post and the other related pages; they should be individual landing pages. There are a couple of edge cases where I wasn't quite sure what to do:

• clearly related entities where the terms match on the left, such as the two separate entries on the Index page for 'BuzzFeed' and 'BuzzFeed News'. I ended up linking both of these index entries to a single landing page at */BuzzFeed. But now I am not so sure; based on WhatamIdoing's comment below about having a See also section, I now believe that these ought to be two separate landing pages, interlinked via See also. What do you think?
• same source, different topics rated differently: at WP:TELEGRAPH in the live table, the The Daily Telegraph (UK) gets two rows, because there were discussions sufficient to rate them as 'no consensus' with respect to transgender topics, and 'generally reliable' for everything else. It seems to me that we should have one landing page per source; now that these pages are not straitjacketed into a table format that requires a single status/background color, the landing page (currently unconverted at */The Daily Telegraph) has two table rows, with the assumption that when converted to a landing page, it will contain all of the information in both table rows, arranged in whatever format makes the most sense. I think the guiding principle here is: one source, one landing page.
• same source, different time periods: see the three rows about CNET in the main table starting with the one labeled 'CNET (pre-October 2020)' in column one (go to WP:CNET, and scroll up a bit). These are all one source, and like the Telegraph should all be on one page. The unconverted landing page at */CNET has all three rows at the moment, with the assumption that they all belong on the same page when converted.
• usurped source: this is an entirely theoretical issue, as I know of no entry in RSP like this. Let's suppose (counterfactual ahead) that after being sued by Sandy Hook victims for defamation at Infowars, Alex Jones would have had to turn over his conspiracy website to the SPLC, which transformed Infowars into a conspiracy theory-debunking website under the same name. Now what do we do—one landing page, or two? Note that being theoretical, this is less worthy of a response, but it might set some expectations about what the guidance for having 'a single landing page' ought to say. Imho, these would be two entirely different sources pre- and post-takeover, that happened to have the same name (and url), and therefore would require two landing pages, maybe Infowars (Jones) and Infowars (SPLC) or something.

Your thoughts on any of these would be appreciated. Mathglot (talk) 20:38, 22 September 2025 (UTC)

@Mathglot, thanks for creating an example page to spark discussion. For "groups" of sources like the NY Post example, I don't think having a single landing page that encompasses all of the related discussions is a problem; I just think they need to be listed separately in the index. If I were looking for the status of Page Six, I wouldn't know to look at the page for New York Post (as it's currently listed in the table). For BuzzFeed and BuzzFeed News, a see-also section would work.

I agree that it's more useful for editors to have all guidance about a source on a single page rather than separate pages (such as CNET and the Telegraph). That would also apply to the three rows of Forbes. Schazjmd (talk) 20:50, 22 September 2025 (UTC)

Taking this on board, then for the entry above it in the table, at WP:RSPNEWYORK, 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, as appropriate; right? Mathglot (talk) 21:39, 22 September 2025 (UTC)

That's what I'm hoping for, yes. When I'm looking up a source at WP:RSP, it's usually because I'm unfamiliar with it. Being unfamiliar with The Cut (for example), I'd have no idea that guidance for it falls under the New York umbrella. So having its own entry in the index, it would be easy for me to find and if it then takes me to the overall page for New York, well, then I've learned even more than I was looking for which is a good thing but it also gets me to the guidance that I'm looking for. Schazjmd (talk) 21:41, 22 September 2025 (UTC)

Makes sense to me. I think as this discussion evolves, all these points could be digested and assembled into what might form the basis for a proposal to redo the RSP page. It's good to air all these issues, even the more minor ones, to see what there is support for, so if and when it comes to it, a proposal could be drafted that is coherent, and not too vague or fuzzy. Mathglot (talk) 21:48, 22 September 2025 (UTC)

I also like this idea. Aaron Liu (talk) 22:30, 22 September 2025 (UTC)

I like the concept, but I'm not wild about the first mockup. Maybe an infobox instead of a nutshell? And ==Summary== first? WhatamIdoing (talk) 15:55, 22 September 2025 (UTC)

Also, some sort of ==See also== for related RSP entries. WhatamIdoing (talk) 15:55, 22 September 2025 (UTC)

Yes, absolutely. Am thinking about creating a preload file to make creating new landing pages easier, and will add this to it. Mathglot (talk) 18:57, 22 September 2025 (UTC)

Re mock-up style, including nutshell v. infobox and layout order: all of these are great ideas. I think we are in the embryonic stage of this, and I strongly believe in demos/mock-ups to get something out there that people can look at, and improve. I had to come up with something to look at, and that was just a first attempt with no claim that is the best format, or even a good one. In that vein, would you be able to take one of the unconverted landing pages and do it your own way? The */Boing Boing page is a fairly simple one, or just pick any one you want that hasn't been converted yet (i.e., lacks the document icon). Note that there is a stylesheet for these page, and you are welcome to use it in your mock-up if you wish, and also to alter any selector that starts .source- (or create new ones). Thanks, Mathglot (talk) 19:10, 22 September 2025 (UTC)

I've put together a mockup at Wikipedia:Reliable sources/Perennial sources/all/Deutsche Welle. WhatamIdoing (talk) 21:24, 25 September 2025 (UTC)

@Mathglot In this scenario, would it be possible/not-stupid to put the status-icon next to every item in the list? Gråbergs Gråa Sång (talk) 16:25, 22 September 2025 (UTC)

GGS, my understanding of Aaron's comment of § 16:21, 21 Sept is that we can have the unadorned links, but not links with status, as that would separate status from the summary, which iiuc is verboten. (subscribed; no ping needed) Mathglot (talk) 18:57, 22 September 2025 (UTC)

If we can't, we can't. Gråbergs Gråa Sång (talk) 19:01, 22 September 2025 (UTC)

Another benefit is categorization. Standalone source evaluation pages can be categorized in administrative categories, e.g.: "Perennial sources deemed reliable", "Perennial sources deemed unreliable", (ditto other statuses), "Perennial sources deemed reliable in 2021", etc., "All perennial sources". Rows in a table cannot be categorized separately as categories are applied to the page they appear on (or are transcluded into, barring inclusion control), and any category in a table row would be applied to the page as a whole, and thus be useless (except the table could be categorized as "Perennial sources", but it would be the only one in the category, so not useful. In addition, this could be made almost transparent by using categorization by template; for example, the WP:RSPSTATUS template could be updated to categorize the template in the correct status category, WP:RSPLAST in the correct year category, and the Infobox could categorize it in the top level 'perennial sources' category. Mathglot (talk) 07:40, 29 September 2025 (UTC)

Didn't know where else to put this, as it is not germane to the already ongoing Rfc, so I am putting it here. Separating the links from the content in the List of subpages approach has another advantage I hadn't considered, as it allows for the possibility of custom indexes. For example, WikiProject Military History might decide they wanted a quickref access point to all Perennial sources evaluations relevant to their project, and they might make a subpage on their WikiProject with a few dozen links to sources they refer to most often. I think that's fine and could be handy for a project. (A possible minor downside is missing new relevant links, but if they watchlisted the main index, that shouldn't be too problematic. An Alexbot-like process could probably even alert them to new relevant landing pages, just as it does for new relevant articles.) For that matter, not only WikiProjects, but maybe some users might pin a few links to their user page for easy reference, and so on. What is less clear, is what happens if a project starts to create their own, local landing pages as well. Imho, that could lead to undesirable fragmentation with ensuing possible dilution of the central landing page repository, but now we are getting into a hazier future, and am content to let that evolve organically. Just wanted to raise this while I was thinking about it. Mathglot (talk) 19:54, 25 October 2025 (UTC)

I think this is unequivocally a good thing. Aaron Liu (talk) 19:58, 25 October 2025 (UTC)

Serendipity: after I wrote that, CMD commented at the Rfc Survey (@14:58, 27 October) about a possible different Index style, so I created this alternate index style to illustrate my reply. Mathglot (talk) 08:33, 28 October 2025 (UTC)

Infobox design

See examples: Ballotpedia, BBC, California Globe, China Daily, Deutsche Welle.

I think that having an infobox on individual RSP pages would be helpful. So far, we've tried two different styles (in terms of content; aesthetics can be worked out later). Here are my initial thoughts on comparing them (numbered for convenience):

1. I think it's a good idea to provide some simple 'types', like 'news' or 'website'. IMO the BBC should be considered a 'news' type. We have very few entries in RSP for offline sources, so they're almost all 'websites'.
2. I think the infobox is a good place for overall summative judgement (e.g., "WP:GUNREL"). I'd like to see more specific contents, especially for no consensus/other considerations apply.
3. I don't like having that summative judgment in a {{nutshell}} because I worry that nobody will read anything else. I don't think we should have a "nutshell" on these pages.
4. I like having the WP:SHORTCUT at the top of the page. I don't care whether it's in the infobox or elsewhere, as long as it's easy to spot.
5. I don't like having spam-related tools shown for generally reliable sources. For less/unreliable sources, I'm not sure whether these should be in the infobox or in a ==Uses in Wikipedia== section, but probably not both.
6. I like providing a basic factual description the source (e.g., "is a newspaper"). Excerpting from the lead, when we have an article, is convenient but maybe not as relevant to RSP's needs.
7. I like having other names/abbreviations in an infobox.
8. I like having something on each page that indicates the purpose of the page (e.g., "____ is a source that has been repeatedly discussed").
9. I like showing the dates of prior discussions and RFCs.
10. I also like showing the section titles for prior discussions, but they're not always useful/relevant/appropriately informative.
11. I like reminding editors that the simple summary isn't the whole story, so they should go read the prior discussions.
12. I'm doubtful that RFCs should be highlighted in the infobox. The current consensus is more important than whether the RFC advertising mechanism was used at some point in time.
13. On sources with multiple bits (e.g., BBC News itself vs their h2g2 website), we might want separate entries with links between all the pages. Or at least separate bits in the infobox.
14. I wonder how much of the custom summary text could be standardized (e.g., "As with any news source, WP:RSOPINION applies to opinion pieces. As with any source, WP:RSBIAS applies to material that an editor believes to be biased. As with any...").
15. I like having infobox entries for "deprecated" and "blacklisted". I'd also like to consider one for "biased", linking to WP:RSBIAS.
16. I would like to have as much of this conversion done via bot as possible. Later entries can be hand-formatted, but the list is long, and help starting would be, well, helpful.

What do you think? WhatamIdoing (talk) 01:02, 26 September 2025 (UTC)

Haven't read all of these points yet, but from a quick lock:

1. Obviously, title-case everything before shipping to production
2. I like this design in general but I like Mathglot's page layout design better
3. Ideally the link searches should be presented as icons near the infobox... somewhere? At the bottom?
4. I liked RSP's three tiers of links: RfCs, RSNs, other. I think it should at least be represented somewhere, though maybe not the infobox.

Aaron Liu (talk) 01:42, 26 September 2025 (UTC)

By the 'link searches', do you mean the trio of links involving insource-search, external link search, and spam search, as produced by {{domain uses}} in the last column of each row of the giant RSP table? There are equivalent links produced by template {{domain uses long}} which is invoked by {{Infobox source reliability}}, and can be seen in any the four or five entries on the Index page tagged with 'ⓘ' (for infobox) , such as at */Ballotpedia, where it can be seen in the three links at the bottom of the Infobox. Are those the link searches you meant? Mathglot (talk) 05:53, 26 September 2025 (UTC)

Yes, the trio of links. No objection to using another template for it instead or even cutting down the amount of links, but I'm saying that I like how it's currently presented as icons. Aaron Liu (talk) 03:27, 13 October 2025 (UTC)

Cite Unseen has "news" rating (m:Meta:Cite_Unseen/sources/type#news). Could be useful if you want to create some "types." SuperGrey (talk) 01:44, 26 September 2025 (UTC)

I think it's great that you started this subsection, so we can hopefully solicit wider input. For starters, let me just say that I am agnostic going into it about exactly what it should look like, though like anybody, I have my opinions, but the main thing driving this for me is, get something out there for people to look at, and stimulate discussion. So this is great. (And numbering them makes it easier to respond.)

Some process notes: I wouldn't say no to bot conversion, but if somebody else is going to be writing it, we don't want to abuse their willingness and effort too much by asking them to run it repetitively if our format keeps changing, so I'd like to see a reasonable level of participation and agreement first as to how it should look, before we ask for a bot. And more importantly, before we get to a bot, we would need a consensus to swap out a tabular format that many are familiar with and has existed for a long time. (Unless you meant a bot to generate landing pages for the demo, that we could then use to formulate a proposal to adopt a new format. But if you meant a bot just to create some of the mock-up pages to present in an Rfc, then sure. But tbh, if we are just doing the B's, C's, and D's for a demo or mock-up, then I don't think we'll need a bot; I just converted Change.org with a regex; admittedly, it was a monster, and probably wouldn't work on rows that look different, but it is doable. That was kind of a flyer to see if it would work at all, and since it did, a clever template would be more powerful and might be able to convert a lot of them. (The preload file is another method; that would require some manual intervention, but not much.) One thing we could do, is either divide up the list, or maybe better, just leave it open, and tag the entries with some kind of format tag that indicates which demo format it is; e.g., you could tag with ⓦ, I with Ⓜ, and so on for approaches by other contributors. Then if we finally do a proposal, responders could view a variety of options.

I'll respond individually to some of your points later, although I'll just mention that I am partial to the nutshell, but not wedded to it. I don't think it causes more bias, in the sense of causing a viewer to rely on the nutshell and look no further. At least, not any more than, say, a viewer seeing a no-entry symbol (meaning unreliable) in column two of the table, right next to the name. For example, how is that big, no-entry symbol in the DeviantArt row in the table any less likely to cause that behavior (i.e., skipping the rest) to happen? We trust our readers with a nutshell on policy and guideline pages, partly to orient them or give them the highlights of what the P/G page is about, without thinking they will stop there, or that the rest of the page is unimportant. I don't think Perennial sources is all that different from a P&G page in that sense, in that we can orient them with a nutshell without fear, or assuming the worst about how a reader might use the nutshell. And if there *are* readers who won't go a single step further, well, they will probably act similarly whether you take them to a table row or a landing page; in the end, we can't make them be thoughtful and read the whole page. I like the slight orientation of a nutshell, and I think we can direct it at our most diligent readers, and not worry too much about the least diligent ones. It's kind of like the trailer on a film I am eager to see: seeing the two-minute trailer, doesn't mean I am done and don't need to see the film, it orients me, and helps me get the context of the film. Just my two cents, but I would of course follow whatever consensus turns out to be for the format. Future flash: I like most of your suggestions, and don't have strong opinions about them generally. More later; but in the meantime, I hope we get more feedback to your points. (edit conflict) Mathglot (talk) 03:06, 26 September 2025 (UTC)

From that (ec) I just got, looks like we already have, which is great! I encourage everyone to pick one of the linked, B–C–D pages you see in the List section at Wikipedia:Reliable sources/Perennial sources/Index, and build a landing page for it according to how you would like to see it done. Thanks, Mathglot (talk) 03:11, 26 September 2025 (UTC)

For the record: I have mentioned various regexes: one is to extract rows from the table; that is a trivial match on the wikitable start row delimiter. The tough one is a replacement regex that parses a table row and converts it to a landing page, and it is not perfect, in that it cannot handle all the variability in row format in the table. (It also does not currently handle discussion links, which have to be added in in a second regex step.) It can handle *some* row variability, which makes it match more rows, but there is a point of diminishing returns in regex design where you get few additional rows for a lot of increased pattern complexity, so any such row conversion regex is a compromise between utility and complexity. The 'monster' I have previously alluded to converts quite a few rows, and is now on version 7. I am including it here just for the record, as I would hate to have to construct it all over again. Note that this is a PCRE, not a Cirrus or Scribunto regex.

Row-conversion PCRE regex that handles many table rows

The match portion is this:

(?s).*?id="([^"]+)"
\|\s*(?-s).*?\[\[([^]]+)\]\]\s*'?'?.*?{{WP:RSPSHORTCUT\|([^}]+)}}(?s)\s*.\|\s*{{WP:RSPSTATUS\|([gruncdb]{1,2})[^}]*}}(?s:.*?)
\|\s*{{WP:RSPLAST\|\s*([^|]+)(?:\|\s*stale\s*=\s*([^}]+))?}}(?s)..?\|\s*(.*?)
\|\s*{{WP:RSPUSES\s*\|\s*([^|}]+)[|}].*$

Note that the match pattern has internal dotall switches ('dot matches newline') to turn it on and off inside the pattern, to properly deal with newlines in the table row wikicode, rather than the global pattern modifier for dotall.

The replace portion (v. 3) is this:

replace string

{{WP:Reliable sources/Perennial sources/Header}}
{{WP:RSPNutshell|\4|shortcut=}}
{{Infobox source reliability
 | type			= website
 | shortcut		= \3
 | status		= \4
 | last			= \5
 | domain1		= \8
 | rfc			= 
 | rfcdate		= 
}}

{{WP:RSPIntro}}
__TOC__

== Summary ==
\7

== Excerpt ==
{{hatnote|Excerpt from the lead of [[\1]]:}}
<div class="source-excerpt">
{{excerpt|\1|paragraphs=1|only=paragraphs|hat=no|references=no|inline=yes}}
</div>

== Discussions ==

=== Links ===
<div class="source-disc-list">
# first discussion
# second discussion
</div>

=== Recency ===
<span class="source-talk-last">{{WP:RSPLAST/sandbox|\5|table=no}}</span>

=== Rfcs ===
# yyyy   link

== Notes and references ==
{{reflist}}

== Original table row for comparison ==
<!-- intentional blank line here, without this comment -->

Putting them together has created the majority of landing pages at WP:RSPDEMO#List, augmented by a second, simple regex to add in the discussion links. Often, some manual post-processing is needed to fix up some field or other. Mathglot (talk) 02:00, 29 September 2025 (UTC)

WhatamIdoing, if you would like to add a few more landing pages to WP:RSP#List in the same style you used at */Deutsche Welle, all you have to do is redesign the 'replace' pattern to indicate what output you want, and I could run the same parsing regex with your replace pattern against a bunch of rows in the list, so there will be more examples to look at in your style. Lmk if you would like to try this. Bear in mind that a regex cannot create or look up content not already in the table row, such as organization logo and so on; you would have to add such content in manually after the fact. Mathglot (talk) 02:12, 29 September 2025 (UTC)

Would it be better to do this with something like mwparserfromhell and a Python script, rather than regex? audiodude (talk) 20:20, 10 October 2025 (UTC)

Audiodude, better than any single bare regex, yes, it would. But any script is going to use a regex, or more likely, a series of simpler regexes, and any such script would probably start by looking at the regexes we have so far. The table rows look similar enough at first glance, but there is a fair bit of variability, and no single monolithic regex will match every row. If you can do scripting and would like to volunteer, we could certainly use your help! Mathglot (talk) 20:34, 10 October 2025 (UTC)

That's why I mentioned mwparserfromhell, because it is a Python library that actually parses wikitext, as opposed to clawing at it with regex. audiodude (talk) 20:51, 10 October 2025 (UTC)

But to your second point, I would love to help but I'm not sure what the requirements or the deliverable would be at this time. audiodude (talk) 20:52, 10 October 2025 (UTC)

Nobody is sure yet, but just knowing that someone with some technical skills is willing to help is already great news. WhatamIdoing (talk) 21:01, 10 October 2025 (UTC)

Well, we kind of do know what they would be, or at least, a key component that would quickly lead to a full solution in several different approaches, namely central list + longer explanation, the Row-builder module approach, and the central list plus landing pages approach.

Audiodude, the deliverable would be a table row parser that takes one row from the table as input, and returns about a dozen key=value pairs, which are roughly the ones outlined by Aaron in the 22:17, 4 October post at § Row-builder module approach (diff). That would need to be specified more formally and precisely as far as exactly where to pull them from in the row (and we already have that info; it just needs to be specified). A second (easier) deliverable is to wrap that in a script that marches through the table and calls the parser for each row, and then does <something>, which could be a module invocation that emits the table row without templates, or it could be creating a landing page in a predefined format (see */Ballotpedia for an example format) with those items. But this is the wrong subsection in which to talk about this, so we should probably continue this at § Row-builder module approach. Mathglot (talk) 15:35, 11 October 2025 (UTC)

There are over 200 comments in this ==Section==. We should be creating new ==Sections==. WhatamIdoing (talk) 18:31, 11 October 2025 (UTC)

Here are some responses, by the numbers, as promised:

1. Types (news, website) – am fine with that; would this be a) a control string or something that we have to limit to 'just these N choices' and validate? Or is it b) just a string, and editors can enter any 'type' they want? Or is it c) a doc page thing, where they can enter anything, but the doc page has some recommended values?

2. Overall summative judgement (SJ) – don't understand like to see more specific contents; where, in the body?

3. Avoid SJ in nutshell – have to disagree, here. I think we should AGF and hope they will treat a nutshell here, the way they would at a policy page. In neither case can we force them to read the details, and in both cases we hope to maximize the likelihood they will do so. Imho, the nutshell sets some context for what lies ahead, and *increases* the likelihood that diligent editors will read on. As for the flakes, well, flakes gonna flake, and that isn't a good argument for removing the nutshell for the diligent users.

5. Spam tools –

• a) present for generally reliable (gr) sources: dropping them for gr sources seems reasonable. Then, keep them for gu, nc? What about deprecated (d)? I'll just mention that in the current, big-table format, spam tools are an indissoluble part of a trio of links produced by {{domain uses}}, i.e., the spam tool links never appear in the table by themselves, but always in the trio. In the new scheme, I followed that same pattern of a trio of links (using {[t|domain uses long}} with longer verbiage) but I see no particular reason we have to follow that old 'trio' pattern. When talking about where or whether to place them, would you like to propose a new way of handling these? Or, always suppress the trio for gr sources?
• b) where to place: I don't feel strongly where they should appear. First, we should decide about a) (the trio) then get back to this point.

6. Excerpt/Basic factual description, e.g. 'newspaper': Agnostic about excerpting the lead; more typical is to just link it (but it already is, in the Infobox header. Am okay with dropping the excerpt, and understand the advantages of just having, the only advantage being, it

7. Other names — this is currently param |other= in {{Infobox source reliability}}, and it is a free form string. I am just entering a comma-sep series, but we could put each name on a new line, or check to see if the names exist and link them if they do, and so on.

8. Intro – that comes from template WP:RSPIntro; feel free to edit it. We could perhaps combine it with #6; then we would have: "FOO is a [newspaper|source] that has been repeatedly discussed", defaulting to 'source' if the |type=newspaper was not given?

11. Remind editors – how should we do this? Perhaps another boilerplate template?

12. Don't highlight Rfcs – I think I disagree, here. An Rfc is not any old discussion, and not just an advertising mechanism that was used; it has some force of structure, formality, and a considered close. Whereas I don't know who is writing up the summary column in the table—are they even interpreting it right?—I do know, or at least I can find out, who wrote an Rfc closure, and I know there is a certain amount of seriousness involved, as they can be overturned, and even sanctioned if they are overturned a lot. So, I do want to know when someting is "just a discussion" vs. an Rfc, and I think that is an important enough distinction to mention an Rfc in the Infobox, but not random discussions. By the way, I think we should only mention one Rfc in the Infobox, regardless how many there were, and that should be the most recent one. The infobox currently has a link to the page section where other Rfcs can be found, if there was more than one Rfc, but I don't know if we even that, as normally only the most recent one is important, and in any case, the most recent one will mention others, if they are still relevant.

13. Sources with multiple parts — we need to define what we really mean by multiple parts. If it is just a collection of related domains, Foo.com, Foo.org.uk, Foo.news.net, then we already handle that with one landing page, and multiple domains in the Infobox (and the body). If it is something more like multiple departments or divisions, as Schazjmd discussed, we might have Vulture, The Cut, Grub Street, and Daily Intelligencer as individual links in the Index which would all link to the the New York magazine landing page; and The Evening Post, Page Six, and Decider all pointing to the NY Post page. There might be some cases where they are so different, they might need separate landing pages; we already have one case where a division is deemed reliable, where the main unit is not; I will have to go back and find that one again, but should we still handle that on one landing page, or two?

14. standardize custom summary text – not entirely sure what you mean, but am I correct in assuming that this is unrelated to the possible use of a new approach, in that even if we kept the table somehow, the summary text could be customized there as well, in whatever way you are proposing. What are you proposing, exactly, and is it related solely to this new approach?

15. infobox 'biased' entry – where would this information come from, if it is not currently in the table row somewhere? And again, is this about the new approach, or could this apply equally well to the table approach?

16. bot conversion – covered in my previous comment. Before asking for a bot, we would need to know what we wanted. On the one hand, I don't think we are there yet; on the other hand, the sense of increasing urgency is palpable. Also, do you mean bot conversion just to build a demo, or only after some proposal gains consensus? If only the demo, I think we maybe have enough examples already, although I still do want to do the Daily Mail one, because it is an outlier in many ways, and would be a good example to add to the mix for that reason.

Thanks Mathglot (talk) 02:33, 28 September 2025 (UTC)

1. I'd like to suggest a few things, but to leave the ability for custom text.
2. About "more specific comments": Imagine that instead of only saying "GUNREL", it also says "politically biased" or "uses AI" or whatever common reasons we have for rejecting a source.
3. I don't think we need to have a nutshell box at all, and I don't think we need to have a nutshell box that only repeats the same thing as you can find in the infobox two inches away. If we're going to clutter up the page with a nutshell box, it would be nice if that use of screen real estate could contain more than one word's worth of information.
4.  
5. I'd only include the tools for finding links to this source when we want editors to remove/replace that source. (I liked having them in the body of the article, where there's more room to describe what they are.)
6. I like having a description of the source, and for non-notable sources, we'll need to have this option available in the design.
7. I think that "other names" can be freeform.
8. I like Wikipedia:Reliable sources/Perennial sources/Intro as-is.
9.  
10.  
11. Imagine something like Wikipedia:Reliable sources/Perennial sources/Intro at the top of the list of links to the discussions, only saying something like "Consensus is determined in discussions. This simple summary is provided for convenience. If this summary doesn't reflect the discussions, please help out by updating the summary".
12. Wikipedia:Requests for comment says at the top that RFCs really are just discussions with an advertising mechanism. They do not produce binding decisions (which would violate the WP:No binding decisions policy).
13. When sources have multiple parts (e.g., Vulture), then I don't care whether it's one or two pages. If it's one, we need redirects. If it's two, we need links between them. Flip a coin, or tell me which is easiest to convert from the existing table.
14. About standardizing the custom text: Right now, we have a lot of entries in which we say the same thing using different wording. For example, there are a lot of sources that are biased. We could standardize some of this by always using the same wording for each common concern. This means writing "Editors are concerned that the publication lacks a reputation for fact-checking and accuracy" every time, instead of using different language each time. This could be handled by a template (e.g., {{RSPconcerns|fact-checking|self-publish|bias|non-independent}}). This idea could be implemented later, assuming we want to do it at all.
15. {{Infobox source reliability}} has infobox parameters for |deprecated= |blacklisted= I think that adding a row for |biased= would also be a good idea. I think these would have to be added manually.
16. I'm interested in a bot conversion later. I agree that we have enough examples for discussion.

WhatamIdoing (talk) 19:03, 29 September 2025 (UTC)

WhatamIdoing, I've been thinking more about this, and about drawing up an Rfc about the critical PEIS issue. I think that the latter is way more important than any Infobox question. Indeed, imho an Rfc should be solely about offering options to resolve the PEIS issue, only one of which would be the "Index page + individual landing pages" approach. Compared to that, all this discussion about whether to have an infobox and what should be in it, whether to have a nutshell, where the Summary should appear on a landing page, and so on—all of those are stylistic choices which pale in comparison to deciding if we want to keep the table with modularized rows, use a giant table, use lazy loading, switch to this approach, and so on. I see the current style of the WP:RSPDEMO landing pages as "just one way to do it", and any Rfc question should focus on which of several radically different approaches we should take for the future design of Perennial sources, and not try to decide the minutiae of style. Do you agree? If the landing pages approach gains consensus, then either a follow-up Rfc later, or even just plain discussion could resolve any stylistic choices involved, as we have started to do here already. What do you think? Mathglot (talk) 21:05, 5 October 2025 (UTC)

I think that simplifying for the RFC is a good idea. People need to be told that the current structure will break soon and must be replaced. Then we solicit their opinions for the general replacement approach (e.g., something that will probably break in a couple of years, something that will never break again, etc.). There can be a future RFC if we want to design an infobox, but there's no need for that now, because they might choose a different approach. WhatamIdoing (talk) 02:17, 6 October 2025 (UTC)

Thanks. One more thing: I am using section § Approach summary as a prequel to help inform a probable forthcoming discussion about how to word an Rfc question. Can you have a look and make sure your approach is fairly characterized, or just rewrite is as needed? There will be more opportunities to do so, but this is just a first attempt to make a brief roll-call of what we've to to work with, as it were. Thanks, Mathglot (talk) 02:32, 6 October 2025 (UTC)

Showcasing different approaches

Ideally, I'd like to see several approaches to compare. One thing that occurs to me, is that larger entries could be a good test bed for showcasing different approaches, to see how they handle some of the limitations imposed by a table row structure. The Daily Mail entry in the table (at WP:DAILYMAIL) is one of the longest I have seen. The row height takes up about 3/4 of the screen height on my 15-inch laptop.

It has two shortcuts (in col. 2), a 'deprecated' icon, three Rfc icons, 54 previous discussions (which are relegated to an explanatory note, as the table-row format is ill-equipped to handle links to 54 discussions), a 226-word summary (which currently occupy 16 lines in my setup, and determine row height), and 11 domains with three links each in the last column, protected with a show/hide toggle to keep the row height from growing further. I plan to convert this one, but I think it's fine if we have multiple conversions of the same table row page linked from the Index page showcasing different approaches. It might even help interested users compare the same source being rendered in different ways. They should all be linked from the Index page, maybe with uniqueness suffixes or something, and could interlink each other via their See_also sections.

P.S. Regarding the summary text: I don't think ipso facto that 226 words is too much by any means, and especially not for this particular entry. Indeed, freed from the confines of a table row, the summary could be broken up into paragraphs, or even subsectioned if that were deemed helpful. Mathglot (talk) 06:18, 26 September 2025 (UTC)

Approach summary

Recapping the critical issue facing the WP:Reliable sources/Perennial sources page: we have been over 99% of WP:PEIS capacity for some time (and occasionally over it), and a solution is urgently needed to prevent the page from breaking. Each time that threatens, it is patched up again with rubber bands and sticky tape. Here is a capsule summary of the approaches discussed so far as possible solutions to the PEIS problem:

• § remove some templates to reduce PEIS
  • pros: first thing we tried; easy fix to reduce PEIS slightly
  • cons: only a stopgap; everything that reasonably can be removed has been, and still at > 99% full; no room for growth; will likely not stop another failure soon
• § module-generated rows
  • pros: should reduce PEIS considerably; would allow for growth of approx. 150 rows
  • cons: module needs to be written to test the concept; at some point would face the same issue again, although not for a while (years?)
• § central list, and click to longer explanation
  • pros: permanent solution to PEIS issue; links page easier to find the source you are looking for
  • cons: one extra click (on the links page) to get to the description of the source;
• variant of above: § central list with landing pages and mocked up demo
  • pros: permanent solution to PEIS issue; more at WP:RSPDEMO#Q3
  • cons: see WP:RSPDEMO#Q4
  • mockup: see Wikipedia:Reliable sources/Perennial sources/Index (shortcut: WP:RSPINDEX)
• § Raladic's table options
  • pros: t.b.d.
  • cons:
• § One giant table approach
  • pros: reduces PEIS from 99.7% to around 63%; room for growth of about 150 600 300+ sources (i.e., table rows)
  • cons: table would be around 477kb with 497 rows currently, with concomitant maintainability and load issues; would hit the same threshold again after ~150 600 300+ new rows were added, when the table will be around 715kb 920kb. updated by Mathglot (talk) at 05:28, 14 October 2025 (UTC); and at 19:50, 16 October 2025 (UTC)

If I missed or unfairly summarized anything, please feel free to edit my comment in situ to fix it (just please add a note below or in the edit summary to leave some breadcrumbs). Thanks, Mathglot (talk) 23:13, 30 September 2025 (UTC)

I think this is accurate, but not the overview summary of the different approaches that I would provide in an RfC to laymen users. Aaron Liu (talk) 01:19, 7 October 2025 (UTC)

Thanks for the feedback. You have expressed what I think is the trickiest issue we will face when trying to devise an Rfc question, namely, how to word it in order to make it as clear as possible to a general audience, while not oversimplifying. I don't have a good answer for that, but we'll get there. I think when we get to that point, we should list the options (looks like five?) where each is at most a sentence or two; I think it would be fine if each option summary linked to a more detailed explanation further down. This is an inherently complex topic, and each option has its fine points; we should at least have details available for the more tecchie editors who may show up and want to give thoughtful consideration and would need a deeper dive in order to do so. I don't see how its possible to do justice to the various options with just a brief description for each.

Raladic, I assume you are still interested in having your lazy-load option(s) included in any future Rfc. Could you add a brief pros-and-cons description to the bullet point above for it? There will be an opportunity to link it to a more substantial description later. Thanks, Mathglot (talk) 02:59, 7 October 2025 (UTC)

I think we can reduce this down to three options:

1. Try to maintain the current environment until it collapses, which could be soon.
2. Build something similar-ish. Collapse predicted in approximately 150 new entries, which might be three years from now. (Time estimate based on seeing that about 100 were added in the last two years.)
3. Do something completely different, using subpages and getting essentially infinite room for expansion (thousands of new entries could be added).

This is a manageable number of options, and non-technical editors should be able to express a preference for postponing change as long as possible vs a bigger change that fixes the problem permanently. WhatamIdoing (talk) 02:51, 8 October 2025 (UTC)

Thanks for the concise and very on-point summary. Can we head to the RSN page and propose them now? I feel like we have already analyzed a lot -- the approaches and their pros & cons -- that we can share with the RSN participants. SuperGrey (talk) 20:27, 8 October 2025 (UTC)

Nothing will happen today, because we need to give the other participants in this discussion a chance to see this and share their thoughts about such a vague question.

Also, there's no need to have the RFC at RSN specifically. WhatamIdoing (talk) 21:53, 8 October 2025 (UTC)

Not only that, but it would be helpful to users participating in any future Rfc to understand what is involved in implementing the various approaches; i.e., what is the migration path, are bots or scripts required, how hard are they, and so on. Wherever it is held, WP:VPR and/or WP:VPT should be notified. Mathglot (talk) 09:16, 10 October 2025 (UTC)

I've struck pro's and cons of Raladic's approach above, as she appears to be retired, and won't be available to support and explain that approach. At first blush, that seems to leave us with five approaches, but I don't know if the first one, i.e., removing some templates, is really a valid one anymore as we have pretty much removed everything we could, so I think we are down to four or maybe three choices, as enumerated by WaId above. That is a good number for an Rfc. Mathglot (talk) 09:25, 10 October 2025 (UTC)

P.S., slightly o/t for this subsection, but we are over 100% again, and I've added a template-based notice that alerts us to where we stand, at the top of this section. Mathglot (talk) 09:30, 10 October 2025 (UTC)

Or two, since "it collapses" has already happened.

@Mathglot, unless you object in the next small-number-of-hours, I'll start an RFC today on the simple/vague question of kicking the can down the road a couple of years vs providing near-infinite room for growth. We no longer have time to sort out the details. WhatamIdoing (talk) 17:43, 10 October 2025 (UTC)

WhatamIdoing, Well, I'd rather wait, as I don't think that being in a crisis situation is the best environment for choosing a good path in an Rfc. We can still buy some time using the "ugly" method I mentioned earlier to RSPSTATUS in subpage /2, and then request protection on all of the pages to stop any new entries from being added. (We are already in a situation where new entries effectively cannot be added, at least, not without breaking something somewhere else.) We can have a hatnote directing users to an "overflow" page were new entries can be added instead. Then we can calmly start an Rfc. That would be my preference. Mathglot (talk) 17:55, 10 October 2025 (UTC)

So, we are down to 98.31%, which gives us time to discuss how best to formulate an Rfc. Mathglot (talk) 18:23, 10 October 2025 (UTC)

Okay.

We have two main options with the RFC: One is to ask for preferences on temporary vs permanent solutions, then sort out functional proposals for whichever is chosen and have another RFC. The other is to develop all of the proposals first and propose them all at once in a single RFC.

I'm inclined to the first but will support whichever approach you and @Aaron Liu want to take, since you're the two that would have to make the functional proposals. WhatamIdoing (talk) 19:30, 10 October 2025 (UTC)

I have copied the comment above (@19:30) to § How should we word an rfc? and have responded there. Mathglot (talk) 19:42, 10 October 2025 (UTC)

I think this analysis summarizes the options quite well and is understandable for non-technical editors, assuming they accept our report that the page is at the PEIS limit, even if they don't inherently understand what that is. audiodude (talk) 21:03, 10 October 2025 (UTC)

I've sometimes needed to have a screenshot to show people what the PEIS limit means. My most recent one (File:Template limits PEIS post-expand include size screenshot.png) actually isn't that good. WhatamIdoing (talk) 21:29, 10 October 2025 (UTC)

WP:NewPP limit report has a writeup that includes it; no image, but a wikicode facsimile, which may be just as good? Otherwise, an image could be added there. Another approach might be the WP:Graphics Lab; the folks there do a great job, and sometimes an illustration can be clearer and more informative than a screenshot, or can start with a screenshot and then have explanatory callouts and labels added, identifying the important bits. If you do try the GL, please request 'svg with translatable labels'. This allows a single image to be generated, with labels stored as text not pixels in such a way that any of us can translate the labels without any image design knowledge using a toolforge image label translate tool, and the same svg can be used by other Wikipedias without starting over again with a new image. Mathglot (talk) 22:04, 10 October 2025 (UTC)

I don't see a wikicode facsimile at that link. It looks like a long XML comment instead. WhatamIdoing (talk) 00:21, 11 October 2025 (UTC)

Yah, not even wikicode, just plain text, but doesn't really matter what it is, the point was whether that section is useful or not as an illustration instead of the image you didn't like. There's only one line about PEIS there and tons of irrlevant stuff about other things, so maybe not so much. Perhaps an extract of it showing just a few lines of text near the PEIS line near the top might be better. Mathglot (talk) 01:04, 11 October 2025 (UTC)

Yikes, four bytes left

I just checked PEIS on a browser that doesn't have a history of my loading WP:RSP, and got this from NewPP limit report:

Post‐expand include size: 2097148/2097152 bytes
CPU time usage: 6.611 seconds
Real time usage: 7.202 seconds

We used to have ~ 4,500 bytes or so; don't know what happened. Can someone double-check me on this? @Aaron Liu and WhatamIdoing: Thanks, Mathglot (talk) 23:31, 27 September 2025 (UTC)

Maybe some entries were added? I've manually removed some unused shortcuts from /2 for now. I still want to see how turning table-row generation into a module goes. Aaron Liu (talk) 23:59, 27 September 2025 (UTC)

If we're looking at an emergency situation, should we just list the subpages, simply as a temporary expedient?

That is, shall we replace the single table with something like:

---

• WP:Reliable sources/Perennial sources/1 – Spans 1,A
• WP:Reliable sources/Perennial sources/2 – Spans B,C,D
• WP:Reliable sources/Perennial sources/3 – Spans E,F,G
• WP:Reliable sources/Perennial sources/4 – Spans H,I,J,K,L
• WP:Reliable sources/Perennial sources/5 – Spans M,N
• WP:Reliable sources/Perennial sources/6 – Spans O,P,Q,R
• WP:Reliable sources/Perennial sources/7 – Spans S,T
• WP:Reliable sources/Perennial sources/8 – Spans U,V,W,X,Y,Z

---

and then get busy splitting things up and repointing the shortcuts? WhatamIdoing (talk) 00:17, 28 September 2025 (UTC)

Or maybe some existing template used in every row had 15 bytes added to it? Anyway, we are down to 2088852/2097152 bytes, or 99.6% usage, with 8,300 bytes left. Thanks for walking us back from the cliff. (edit conflict) Mathglot (talk) 00:24, 28 September 2025 (UTC)

A module would doubtless be a big savings, probably solving the PEIS problem for the foreseeable future. And maybe also the performance, which is now at a sluggish seven seconds or so. It feels a little odd to write a module to produce just that row style, it just feels a little arbitrary somehow, or like it locks in a format in a way that would make it very resistant to change. Maybe I just prefer the landing page approach because it is low-tech, i.e., "anybody can do it", and doesn't require a particular format. With a module, editors won't be able to simply cut and paste a new row into the table anymore; presumably they'll have to paste a new template (or even direct module invocation). Not sure how I feel about that. But if it solves the current crisis, that's definitely a point in its favor. Mathglot (talk) 02:47, 28 September 2025 (UTC)

At this moment, we are at 100% (2,097,111/2,097,152 bytes) and a dozen templates fail to render. Mathglot (talk) 07:01, 10 October 2025 (UTC)

One giant table approach

Johnuniq mentioned the possibility of copying all the table rows from the eight subpage chunks into one table. Inspired by that and the precipice we nearly fell off of in the previous section, I decided to give that a try; see Wikipedia:Reliable sources/Perennial sources/One giant table. It blows through PEIS and ends up with dozens of broken refs (loads slowly). I am not saying John's approach won't work, it seems to me that it ought to. There is a strange width problem with column one taking up 1/2 the screen width and adding a horizontal scroll bar (my attempt to fix that with max-width in the column header had no effect). I must have made a mistake somewhere. It's possible that I made a mistake copying the eight pieces. It is perhaps possible that different pieces need the same named ref or note, and when merging them, you might get a duplicate key error; but that's not the kind of error I am seeing. Be that as it may, there are dozens of ref errors, which look more like a symptom of having hit the PEIS limit somewhere in the table, or maybe only during the resolution of the notes and refs (which I changed from templates {{notelist}} and {{reflist}} to <references />). If I have learned anything from the exercise, it is that dealing with a table of that size (547kb) is fraught with difficulty, and even if this can be made to work, it will be facto impossible to maintain. So I am happy to hand off the One giant table to whoever would like to give it a try. Note that the page in its current state takes 15 to 25 seconds to load. Or maybe just starting over from scratch is a better idea. Good luck! Mathglot (talk) 01:42, 28 September 2025 (UTC)

I notice that you transclude each subpage and then subst that subpage. It seems obvious to me that duplicating the giant table that we have would easily exceed PEIS. Am I missing something? Aaron Liu (talk) 02:58, 28 September 2025 (UTC)

No, I don't transclude each subpage, I copy its content. Where do you see a transclusion? If I hit Ctrl+V twice somewhere, that could account for something being doubled, but it's unlikely I made that mistake eight times, and if I did it even once, there would be duplicate rows in the table; are there any? Btw: the templates start failing in the table starting in column six of the Natural News row. (edit conflict) Mathglot (talk) 03:04, 28 September 2025 (UTC)

You have:

{{WP:Reliable sources/Perennial sources/1}} <!-- Spans 1,A -->
|- class="s-gu" id="112 Ukraine"
<!--{entries 1–A....}-->
{{WP:Reliable sources/Perennial sources/2}} <!-- Spans B,C,D -->
<section begin="deprecated"/>
|- class="s-d" id="Baidu Baike"
<!--{entries B–D...}-->

and so forth for each of the eight subpages.

I wonder if you've tried adding subst: to the start of each transclusion instead of what sounds like some furious Ctrl+C, Ctrl+V-ing? Aaron Liu (talk) 03:08, 28 September 2025 (UTC)

I've now mocked up the page fully with my method. 1326557/2097152 bytes, but with all of the edit lag and overhead problems that caused us to switch to transclusion in the first place.

Transclusion expansion time report (%,ms,calls,template)
100.00% 3026.315      1 -total
 27.90%  844.343    406 Wikipedia:RSPSHORTCUT
 24.52%  742.072    406 Template:No_redirect
 21.38%  647.125    492 Wikipedia:RSPUSES
  5.82%  176.022     19 Template:Cite_web
  5.13%  155.118    497 Wikipedia:RSPSTATUS
  5.02%  151.784      1 Template:Notelist
  4.94%  149.493      1 Template:Reflist
  4.17%  126.222    495 Wikipedia:RSPLAST
  3.63%  109.741     19 Template:Shortcut

Aaron Liu (talk) 03:16, 28 September 2025 (UTC)

Okay, I do see a problem now, but I don't know how it happened yet; probably that page is junk and should be abandoned. It would have to be recreated from scratch. Okay I see it now: I had extra end-hidden text delimiters taht was causing an id line to transclude the files, as you said; fixing the hidden delimiters fixed the problem. Mathglot (talk) 03:14, 28 September 2025 (UTC)

It's already fixed. I wouldn't try substing it as god knows what kindd of awful code that would cause. Anyway, it is working, and we have 1,326,523/2,097,152 bytes PEIS (65%), with page load=7.684 seconds, Real time usage=8.396 seconds. Not great, but not a crisis anymore. But it is a very long page. Mathglot (talk) 03:17, 28 September 2025 (UTC)

I substed. :)

Not sure what you meant by hidden-text delimiters—the transclusions were out in the open. Aaron Liu (talk) 03:18, 28 September 2025 (UTC)

Sorry, but we edit conflicted while I tried to save my change, and I removed your changes and completed my edit with the removal of the extra comment delimiters. It is now at 1,248,178/2,097,152 bytes. Mathglot (talk) 03:25, 28 September 2025 (UTC)

Ah, I see; you meant to place the subpage names within hidden comments instead of out in the open.

Still, I assure you that substing the subpage transclusions worked and was what was in my edit. Aaron Liu (talk) 03:26, 28 September 2025 (UTC)

I think the point is that this is tricky, and leaves us a very long, somewhat slow, but working page. I really don't know how to proceed now; should we try to get some local consensus and install a version of it? Should this be a long-term solution (I don't think so; still worth looking into your module approach). Or should we just keep the current page as is, and fully protect it and the eight chunks while we come up with a permanent fix? Or is this it? (edit conflict) Mathglot (talk) 03:31, 28 September 2025 (UTC)

I don't think we should revert to something consensus has decided to move away from (albeit without realizing PEIS problems) when alternatives exist.

I don't think we need to lock the pages from editing until we actually hit the limit. I got through less than half of a single (though admittedly the longest) subpage and we've already saved over 8000 bytes. Aaron Liu (talk) 05:27, 28 September 2025 (UTC)

I don't quite understand what you are favoring and what you are opposing here. I get that you are continuing efforts to try to save space in the table, but I am not sure if that is because you are trying to buy time while favoring another, more lasting approach, or whether with sufficient savings you hope to keep the table viable for the foreseeable future. Mathglot (talk) — Preceding undated comment added 06:00, 28 September 2025 (UTC)

Implementation planning

@Mathglot, Aaron Liu, Raladic, ActivelyDisinterested, SuperGrey, anyone else:

After this scare over the PEIS limits, I think we need to get something done. Here's what's on my mind:

1. Make a way to convert the table into individual pages. (ω Awaiting design of individual pages)
2. Make a way to convert the table into a list that links to the individual pages. (Is regex enough?)
3. Settle the design for individual pages.
   1. Settle the overall design
   2. Settle the infobox design
   3. Create/update an infobox template
4. Communicate changes to relevant groups of editors (e.g., RSN, WP:ADMINNEWS).
5. Create all the individual pages. (Must have stable URL pattern before this.)
6. Repoint all the shortcuts to the new individual pages. (@Gonnym, do you have any suggestions for automating this?)
7. Add a search box on main RSP page.
8. Replace the big table on the main RSP page with a simple list of all the individual pages.

Is there anything else? WhatamIdoing (talk) 02:04, 28 September 2025 (UTC)

I want to estimate how much PEIS savings porting the page to using a single module for generating each table row instead of our current assortment of templates would provide first. Aaron Liu (talk)

I think it would be substantial, and stave off PEIS limits for a long time, which means we could keep the table approach for a long time. If that works out, would you then prefer to keep it as a table, and if so, organized how: in the eight transcluded chunks, or as one, large, fast-loading table that is not close to the PEIS limit? I think it is just unwieldy at this size, and I prefer the new approach now, even if it isn't required to avoid hitting the limit anymore. Otoh, I don't know if the effort to convert is worth it, vs. the effort to build a module-based row-builder. I think the latter is fewer moving parts, but someone has to do it; the former has more pieces to it, but I think it is relatively low-tech and accessible to more people. I guess I vote to convert, just because it seems easier to grasp, and I can picture it being more useful to more people. I was never that fond of the big table, which just feels restrictive, compared to the way we display project content that comes in multiples in separate pages, like Afds, SPIs, and the like. And then there is the clearly working, albeit unwieldy § One big table approach; now that we have proof of concept on that one, we have a guaranteed fallback position that could be used to buy time in case there is a problem getting over the finish line with some other method. Mathglot (talk) 05:11, 28 September 2025 (UTC)

If some technical magic could solve this problem for at least the next several years, then I'm okay with kicking that can down the road. WhatamIdoing (talk) 17:12, 28 September 2025 (UTC)

Your point #2 (create links) can be done with regex. I first tried it with the 'id' field in the start row delimiter (|-), and that created Wikipedia:Reliable sources/Perennial sources/List of linked ids. But that hit some snags, suc has at #167 gnis-coord; but right under that in the table at that point, is [[Geographic Names Information System]], so maybe we want what is on that line, so I'll have to look at that tomorrow. I'm sure we can create the file one way or another about 95% accurate, and then fix up some stragglers manually.

Your point #1 (create page from table row) is a little trickier, not because we don't have the landing page format, but because the source layout (contents of the table row) is not always the same. If it were, we wouldn't need the destination format just yet; we would just convert the table rows into a canonical list of key=value sets, e.g., id=..., shortcut=..., rfc=..., summary=...., last=... an so on, and then when the format was decided upon, we just convert the k=v file into whatever format we chose. So the stumbling block is the variability in the table we have now, not the unknown destination format. There are still ways to parse variable rows, but it won't be just one regex that works for everything (although my regex worked for quite a few pages, it didn't work for all of them). The way to do it, is multiple patterns pulling out one field at a time, and stringing them together in a template or module; that is more powerful. Doable; just needs more time. Mathglot (talk) 06:50, 28 September 2025 (UTC)

About point #1: If we say that the existing table has entries mostly in style A, but also in styles B, C, D, E, etc., could we send a script through that creates the page for style-A entries, skips the incompatible styles, and removes/tags those style-A entries (so we know which ones are done)? WhatamIdoing (talk) 17:11, 28 September 2025 (UTC)

Yes, that is one part of the iterative approach below. Mathglot (talk) 23:43, 30 September 2025 (UTC)

@WhatamIdoing regarding the question you asked of me at 6, if you know what group of shortcuts have changed to a specific sub-page, then you can use AWB to quickly update those links. If not, then manually fix the links. Gonnym (talk) 12:30, 28 September 2025 (UTC)

The key phrase there being, what group of shortcuts have changed (by which I read, "the table-row target of which shortcuts have been successfully converted to a landing page"). That in turn, is dependent on #5, which is the heavy-lift item ("create all the pages"), so 5 and 6 are kind of the meat of the conversion. Given the number of table rows (497), and the dependence of any conversion procedure on pattern-matching in order to convert table rows to pages, it is not practical to assume that #5 will happen all at once and convert all 497 rows without glitches, which is to say, no pattern (or pattern suite) will be perfect and match all of them. That implies that this #5 is likely to be most efficient as an iterative process rather than hoping for one big bang that converts everything, because the time required to design a perfect conversion that would match all of the rows—if even possible—probably greatly exceeds the time it would take to run a "good-enough" conversion that can be quickly designed and is pretty good at converting a large majority of the rows, observe what remains, tweak the converter to handle the majority of what is left, and iterate until the number of unconverted rows remaining is small enough to convert them manually. I.e., points 4, 5, and 6 actually sit inside a loop, with new points added after point 6, and the list of links should be created before anything is converted, not after; so we would have roughly this:

• 4.1: Make a simple list of all the individual pages (similar to former #8)
• 4.2: point every item in the list into the table using existing shortcuts     (updated @22:41 below )
• 5: Run converter on all remaining unconverted pages (the first time, that is all of them)
• 6.1: make lists of converted, and unconverted pages remaining
• 6.2: Repoint all the shortcuts of converted pages to the new individual pages
• 6.3: Is the unconverted list small enough that it's easier to convert them manually than tweak the converter patterns again?
  • 6.3a: yes
    • 6.3a.1 convert them manually
    • 6.3a.2 go to 7
  • 6.3b: no
    • 6.3b.1 Adjust converter to handle most of what remains
    • 6.3b.2 go to 5

(renumber steps as appropriate). Based on my experience of how these things go in RL, this needs to be conceived of as an iterative process, with manual steps involved (at 6.3a&b) being part of it, because it isn't going to happen all at once; i.e., there will be a transitional period where not all rows have been converted, and most links on the Index page will point to landing pages, but some minority of them will still point into the table, fewer with each conversion iteration, and then gradually picking up the stragglers manually at the tail end of the process. I welcome additional opinion, but I think any planning that is dependent on an all-at-once conversion is very risky. Mathglot (talk) 22:32, 28 September 2025 (UTC)

Actually, I have an improvement on some minority of them will still point into the table: if we simply copy all table rows into the landing pages at the outset, similar to how the Demo is set up, then we can skip step 6.2, and all the links can always point to the landing pages from the start, which will either be converted or not; in the worst case, users follow one of the links, and end up at a landing page having just an unconverted table row, the way the demo is now. That woul give us, 4.1 "Copy all the table rows to landing pages" and 4.2 "Point every item in the index list into the table landing pages using existing shortcuts". Mathglot (talk) 22:41, 28 September 2025 (UTC)

So instead of going from current table row at RSP → fancy new layout on subpage, we would instead go from current table row at RSP → copy of that exact table row on subpage → later convert to fancy new layout.

I like it, assuming Aaron doesn't convince us to keep the existing setup with a more efficient module. WhatamIdoing (talk) 00:58, 29 September 2025 (UTC)

Yes. Basically, it is what the Demo does now, albeit only for B–C–D. Click a few links in section WP:RSPDEMO#List that do *not* have the Document symbol icon () meaning, 'oonverted', and compare to ones that do. (There is also the table icon (), meaning, "This is an unconverted row: click the link text to see the row by itself on its own subpage, or click the icon to see the identical row in its original context in the live table." But I don't know that it is worth including this in a conversion implementation.) Mathglot (talk) 01:13, 29 September 2025 (UTC)

I still pretty much prefer individual pages. It solves the PEIS limits once and for all, and can display more information that one row of table entry cannot provide. SuperGrey (talk) 17:39, 28 September 2025 (UTC)

Row-builder module approach

Aaron, I believe you were the one to first suggest this; at least, you mentioned it here. This is worth breaking out into its own section. Mathglot (talk) 23:00, 28 September 2025 (UTC)

And your earlier comment. Mathglot (talk) 16:12, 1 October 2025 (UTC)

The first question that occurs to me, is that for existing content, perhaps we could have a generic row builder where you simply pass it six parameters, c1, c2, ..., c6 for the six columns, with the value of param c1 being the content of column one, and so on, and split out the existing table, and pass each row to the module with those params. (If feasible, this could theoretically work for any table.) But that would require being able to pass content including new lines, pipe characters, brackets, and other metacharacters; do we know if that can that be done with a module? For adding new rows, passing params with newlines etc. might be very messy and error-prone; it might be more user-friendly to have a dedicated module with parms dedicated to relevant items in an RSP row, like shortcut, status, article (if any) summary, rfc, discussions, and so on. How were you thinking about the module invocation? Mathglot (talk) 23:26, 28 September 2025 (UTC)

I'm thinking something like {{RSP row|name=Aaron Is Awesome|alias1=AIA|status=gu|deprecated=y|summary={insert wikitext here}|domain1=example.org|domain2=example.com|discussions=[[link|1]]<br/>[[VGRS link|A]]|last=2018}} Aaron Liu (talk) 22:17, 4 October 2025 (UTC)

I was thinking something like that, but template-based rather than module based (as I don't know Lua yet). That doesn't solve the PEIS problem in the same way, but it might either solve it by substituting a ream of template calls for just the one, and also, it could just be a prototype to get something up relatively quickly, that could later be ported to Lua for even more savings. I had in mind a further refinement for a template (or module) of that nature, namely, the output of it could be defined by a config file (or set of them) where each config specified what to do with the params, so that using one config would generate a page looking like */Ballotpedia (the landing page format I have been using in the demo), and another would generate */Deutsche Welle (in WhatamIdoing's format), and another one might generate a Wikitable row, except without all the templates it currently uses, which I believe is what you had in mind, but am not entirely sure, as I mentioned earlier.

Are you hoping to keep the table format, either because you prefer the table approach or because you believe it is the quickest path to a solution (whether temporary or permanent) to the PEIS problem, or are you considering some of the § other approaches mentioned in this discussion? Without prejudicing any short-term solutions we might come up with on an emergency basis on our own, it seems to me we now have multiple approaches that deserve to be aired more widely, perhaps via an Rfc, when we are ready for that (not quite yet, imho, but soon). Are we in agreement about that?

In order to prepare for that possibility, we should try to neutrally summarize all the approaches, with a view to drawing up an Rfc question we can all agree on. Section § Approach summary is my attempt to get started on that, and a precursor, in my view, to discussing any Rfc question, because we have to agree what the alternatives are before us, before we can present them to anybody else. Can you please have a look and make sure it fairly describes the approach you have in mind, as well as any of the others as well, and that I haven't missed anything. I should add that I would make any rfc question strictly about the different approaches, and exclude purely stylistic concerns which could and should be worked out later via consensus.

For my part, I am continuing to flesh out the demo for the landing page approach; if you haven't perused it lately, it has upgrades as well as more pages converted. (I originally had decided to stop converting pages for the demo, as we had more than enough, but it turns out that some table rows had unique features, and in thinking how to deal with them, I came up with solutions that were helpful not only individually but more generally, and there was a synergistic effect, so I kept going.)

In a couple of three days I will come to a stopping point with the demo, and I would hope that there would be interest among us in debating whether and how to word an rfc question for general consumption. That doesn't mean that we should stop looking at how to deal with critical PEIS issues in the very short term, and I am available to help with that however I can, but my main focus now is looking at how we are going to have a stable Perennial sources system going forward that is scalable, lasting, and has community support. Thanks, Mathglot (talk) 23:39, 4 October 2025 (UTC)

I prefer the table approach because it minimizes the number of page loads and sorting is sometimes useful. Aaron Liu (talk) 02:47, 5 October 2025 (UTC)

If we can sort the entries in the index page (e.g., use a bot to auto-update sorted lists by last update dates or by reliability ratings), that could make the table approach minus one advantage. And I believe "one huge page load" also isn't an advantage to "two small page loads." SuperGrey (talk) 03:01, 5 October 2025 (UTC)

Aaron, would a category meet the same need as sorting the table? I think it would work for, e.g., finding all the deprecated items. WhatamIdoing (talk) 04:35, 5 October 2025 (UTC)

Having categories is one great solution, and having a bot that auto-create sorted lists also solves the problem (and doesn't need users to install any gadgets). The one-page advantage is also defeated by the progressive loading via modules, which also takes API calls and costs memory usage. I would say that the table approach doesn't really have advantanges imo, except that it's "our tradition." SuperGrey (talk) 04:54, 5 October 2025 (UTC)

SuperGrey, not sure I follow what the bot is supposed to do, or why we need one. Also, what about a gadget? Mathglot (talk) 05:06, 5 October 2025 (UTC)

The row-builder module is a gadget, no?

I'm just suggesting that if Aaron find it useful to have the sources sorted by last discussion dates or by countries/regions, they can use an automated bot to do the trick -- auto generate the sorted lists whenever a new RSP entry (subpage) is added/modified. SuperGrey (talk) 05:11, 5 October 2025 (UTC)

No, a row-builder module is a Lua program, located in the Module namespace; for example, Module:Row numbers is a Lua module, and runs on the server that builds the Html that your browser downloads and interprets. A gadget is a javascript program that runs in your browser on your machine. I still don't follow you about the bot, though. Aaron wouldn't need a bot to see sorted by last discussion date; you just scroll to the top of the table, and click the sort arrow in column four, and then the whole table is sorted by last discussion date. No bot required. Mathglot (talk) 05:31, 5 October 2025 (UTC)

The row-builder module itself is a Lua program, but is the "lazy loading" also written in Lua? I though it needs to have Javascript gadget infused, but maybe I was wrong and Aaron's approach doesn't need that.

About the bot thing -- What I meant is that the "index page approach" need a bot to get sorted lists; Aaron's row-builder approach deosn't need a bot, of course. SuperGrey (talk) 05:43, 5 October 2025 (UTC)

I'm a step closer to understanding, but still not quite there. Why would you want a bot in the Index + landing page approach? What would you sort? The index page is sorted by definition. Status, deprecation, and last discussion are all categorized on the landing pages, and proper use of Defaultsort keeps the source page names in each category alphabetized. See for example: Category:Perennial sources deemed generally reliable in 2020. What would a bot do? Mathglot (talk) 05:56, 5 October 2025 (UTC)

I already said -- categorizations is already great solution; I'm just suggesting that a bot can also solve the problem. Therefore, we have at least two solutions that can counter the "disadvantages" Aaron said. SuperGrey (talk) 06:05, 5 October 2025 (UTC)

Details to the bot solution: Bot can extract params from infobox, and use that to generate lists sorted by other params, that serves as alternate versions of the index page which is sorted by defition. It is definitely more work than simple categorization, but also feasible. Anyway, I was just proposing this additional idea to counter Aaron's points; the categorization is good enough. SuperGrey (talk) 06:10, 5 October 2025 (UTC)

Thanks for the details; I understand now what you meant. Mathglot (talk) 06:35, 5 October 2025 (UTC)

What I'm talking about doesn't include lazy-loading. Aaron Liu (talk) 16:09, 5 October 2025 (UTC)

The demo has categories, and we can find all deprecated items in Category:Perennial sources deemed deprecated. (If you want them all on one page instead of hierarchically, adding Category:All perennial sources deemed deprecated would be trivial.) There are also categories for reliable, unreliable, no consensus, etc. (edit conflict) Mathglot (talk) 05:04, 5 October 2025 (UTC)

Not sure I see the benefit; compared to what? By fewer page loads, I assume you mean fewer clicks? Or least total page load time? If you start out with one click to get to the top of the table (which loads in 6–7 seconds), and then you Ctrl+F search for it, typing the source name to find it. In the Index + landing page approach, you start out with one click to get to the index (which loads in 0.5"), possibly another click if using the Compact ToC to get to the right letter (instant), and then one click to get to the landing page (~0.5"). In either approach, a redirect would take you in one click directly to the table row, or directly to the landing page; so they are equivalent by that method (except the landing page loads faster). An alternate method is to search for the source in the search box on the WP:RSPINDEX page, which gets you a Cirrus search result page with all sources that match your keywords all on one page.

By sorting, I assume you mean sorting by table status (col. 2) or by last date (col. 4). Sorting requires you to go to the top of the table, click the sort arrow, and then find the row you were on again. The landing pages are categorized by status and last date, and category links are available at the bottom of the page, so I see no advantage to table column sorting.

Modularizing the rows will reduce PEIS, but what about load time? List of sauropodomorph type specimens is 546,564 bytes (very close to One giant table), with a PEIS of 1,441,008/2,097,152 bytes, but load time is still around 6.4 seconds for that list article. That might be a first guess as to what would happen if you modularized the rows. (edit conflict) Mathglot (talk) 04:51, 5 October 2025 (UTC)

Since presumably any module invocation definition we came up with would, for user-friendliness reasons in creating new rows, also be invocable as a template by passing the module parameters through the template, we could mock up a template that invoked the (non-existent, or placeholder do-nothing) module, and see if it is possible, for example, to create a mockup that would just rebuild the row it was passed by echoing its params in wikitable format, with dummy wikitable header and footer so it would render as a table, with the embedded row in theory looking exactly like the real table row whose parts were passed. The point of the mockup would be to see what an actual invocation would look like in practice, as that is what users would be faced with when adding a new row. Or else, let users add rows the old way using table wikicode, so that the table would be a hybrid of several hundred template/module-built rows with much lower PEIS for 99% of the rows, followed by a handful of user-built rows at the tail end (well, mixed in, in alpha order) using wiki table syntax, which we would pass through the module later on, when space was needed or whenever we felt like. Mathglot (talk) 23:53, 28 September 2025 (UTC)

Your {{RSP row}} idea works well for new rows in the table. The hard part, is what to do with the 497 498 rows that are there now. You have to parse them before you can pass the pieces to the row builder. I think some proof of concept is needed for this part. First you need to identify the rows, then the fields in a row. It's pretty easy to split out the rows using PCREs, but I'm not so sure about Scribunto regexes (Lua modules). I've been working on some Scribunto patterns for {{#invoke:String|match|...}} that can pick out the fields, and it is tricky and I haven't gotten too far yet. A hybrid approach might be better: use a PCRE offline to insert a tagged line between every row, that could then be an easy pattern for Scribunto patterns to pick up and split on, and from there, further patterns to grab the pieces. The output of that process, would be the inputs to your {{RSP row}}, which would be the easy, row-generating part. Mathglot (talk) 07:26, 7 October 2025 (UTC)

I'm not sure why we're even considering writing a bunch of Module invocations on-wiki to generate the text lol. Just use an offline PCRE or add instructions and have it be a manual team effort. Aaron Liu (talk) 00:27, 8 October 2025 (UTC)

Because you raised the idea of a row-builder module, so now I am a bit confused. Mathglot (talk) 00:31, 8 October 2025 (UTC)

It's parameters(everything non-boilerplate)→module→row, not existing table→module→row.

On re-read I realize I may be misinterpreting "you have to parse them"; could you clarify? What I'm thinking is existing rows are added just like adding new rows. Aaron Liu (talk) 00:39, 8 October 2025 (UTC)

How do you envision putting the existing rows into the new module? Surely you don't want to convert them all by hand. WhatamIdoing (talk) 00:42, 8 October 2025 (UTC)

That's what I thought Mathglot meant, too, but surely we don't want to write a Lua module of all things to automate that, nor a Wikitext stringing-together of Module:String as Mathglot seemed to be verring towards discussing. Aaron Liu (talk) 00:44, 8 October 2025 (UTC)

Yes, how you envision adding existing rows to a row-builder-built table is exactly what I meant. Adding new rows (once you have the module) is trivial. And I didn't think we would want to use a module for the conversion as that would limit us to very weak regex, so I didn't understand how you planned to do that; I started using String because I thought that was what you were implying, so I wanted to see what was possible, and I right away ran into roadblocks. Put another way, I don't understand this sentence: What I'm thinking is existing rows are added just like adding new rows.. Huh? New rows you just pass the individual row items to a row-builder template/module using a dozen parameters, or whatever it takes (somewhat akin to the monster regex I have been using). For existing rows, you pass what? You would have to parse the existing row first to get the items to pass to the row-builder, right? Imho that is the hard part; a row builder is easy-peasy, once you have the items to pass it. Or have I completely missed your intent? Mathglot (talk) 00:59, 8 October 2025 (UTC)

You've gotten my intent correctly as using a dozen parameters. What I don't understand is why you assume converting existing rows into module invocations must be done through a module/chained #invoke:String-s themselves. The row builder with a dozen parameters is on wiki, the PCRE conversion things to generate the row builder invocation can be done outside of wiki. Aaron Liu (talk) 01:30, 8 October 2025 (UTC)

Okay, so we are back on the same page, again. I didn't assume converting existing rows into module invocations must be done through a module, I heard you say, "row-builder module", assumed you meant building them using the current table (or rows from the current table) as input, and tried to investigate it a little by trying to do the parsing part in Scribunto regex (as that is what a Lua module would have to do), and didn't do very well. (I can get status, id, and source name.)

Lua-usable patterns for parsing some row fields:

For the record, if we ever need to look at Lua-accessible regexes for perennial source rows, here are some:

Get status from row 2 of file #1:

{{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-([^"]+)" |plain=false |match=2}} ⟶ gr

Get the id attribute from the row-starter line of row 2 of file #1:

{{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-[^"]+" *id="([^"]+)" |plain=false |match=2}} ⟶ ABC News

Get domain from row 2 of file #1 (note that it expands (US) into (United States); seems like a bug):

{{#invoke:String|match|s={{WP:Reliable sources/Perennial sources/1}}|pattern={{!}}%- class="s%-[^"]+" *id="[^"]+" * *{{!}} *%[*([^{{!}}]+) |plain=false |match=2}} ⟶ ABC News (United States)

Beyond this, it gets very tricky dealing with optional elements, and especially embedded newlines.

Now that I know you were never advocating for that, I won't continue down that (very bumpy) path. Mathglot (talk) 05:04, 8 October 2025 (UTC)

Scratchpad: just using this as a place to preserve some useful regexes. Start with row matcher:

• ^(\|-(?s).*\n)(?=\|-) – match one wikicode row (including terminating newline) and place it in \1

Mathglot (talk) 23:05, 8 October 2025 (UTC)

In the § previous subsection, Aaron Liu said,

I want to estimate how much PEIS savings porting the page to using a single module for generating each table row instead of our current assortment of templates would provide

Have you come up with an estimate? What's involved in creating a module like that? Mathglot (talk) 10:09, 10 October 2025 (UTC)

Python demo

Here is my attempt at a version of the table that would use a module: User:Audiodude/RSP_demo. It uses the module I wrote here: Module:RSP/sandbox. The next step would be to write the Python script that parses the current wikitext and extract the values of each parameter from the existing rows. I couldn't figure out how to get the background color styles into my page, but I don't think it's because I'm missing any wiki markup in my output rows (but feel free to point out something I missed) Feedback welcome! audiodude (talk) 20:07, 11 October 2025 (UTC)

Audiodude, bg color is done via class and a style page. See Wikipedia:Reliable sources/Perennial sources/styles.css and note .s-gr and several similar classes near the top. Then just add a class on the start-row delimiter line naming the correct class based on the status of the source; e.g., |- class="s-gr" for a row about a generally reliable source, and so on. For a short table with four classes you can copy from, see WP:Reliable sources/Perennial sources/X. : P.S., do you prefer pings, or are you subscribed, as I am; no pings needed here. Mathglot (talk) 01:42, 12 October 2025 (UTC)

I'm subscribed, but feel free to ping if urgent. audiodude (talk) 03:26, 12 October 2025 (UTC)

Audiodude wrote,

The next step would be to write the Python script that parses the current wikitext and extract the values of each parameter from the existing rows.

That, in fact, is the key element (really the Holy Grail of this project) needed for building each of three approaches being discussed. It's what I was using my so-called "monster regex" for, and it sounds like your approach with the py lib will be completely different and hopefully more robust, because my regex worked on the majority of rows, but I had to tweak it for some rows because of a lot of missing items and internal row variability.

It would be ideal if you could design your parser separately from the row builder part because as I said, te parser will be needed for several output format styles depending on which approach we are implementing, and rebuilding the row without templates is only one of them. So, for example, when you parse the table row pointed to by WP:BALLOTPEDIA, in your row-builder approach (the one you have started on in your module), you will output a row that renders the same row style but without the templates in the wikicode; however in the § central list with landing pages approach, you would use exactly the same parser but output a project page instead that looks like Wikipedia:Reliable sources/Perennial sources/all/Ballotpedia. So the same parser would work and emit different output for multiple approaches, as long as it had different options on the replace side, which could maybe be a config file whose name we pass in a param to the builder. Mathglot (talk) 02:09, 12 October 2025 (UTC)

Right, I understand the idea of parsing the wikitext of the list into what we call an "intermediate representation", and that this could be used for many of the different proposed solutions. However, I felt the need to try and implement a module as a way of working with the rows and starting to understand what "fields" are related to/needed for a row. I guess we can revisit the module itself if we go further down that route. audiodude (talk) 03:25, 12 October 2025 (UTC)

Great. About identifying what fields are needed, here is the replacement string I used when I wanted a formatless, k=v output for the regex I was using:

id=\1; domain=\2; shortcut=\3; status=\4; last=\5; stale=\6; summary=\7; uses1=\8.

Note that this list skips two fields: a) a set of one or more Rfc links, which were sometimes inline, and sometimes embedded in <ref>...</ref> tags and would appeared as a footnote; and b) a set of one or more (non-rfc) discussion links. You can see five adjacent rows in the table that have both of these types, starting at WP:BTVA. (The first of the five, 'Behind the Voice Actors', has the discussion list embedded in ref tags.) I dealt with discussion links and rfcs in separate regexes after the monster parsed everything else.

Of these fields, id, status, last, stale, and summary are unique; domain, shortcut, and uses can have multiple values. Afaik, id, last, and summary are mandatory; others are optional. 'Status' is a special case and is 'almost mandatory'; that is to say, almost all rows have a status (gr, gu, nc, b) but the original designer designed 'deprecated' as a binary, yes/no field, and apparently when deprecated=yes, they wipe out the status field. For my regex and follow-up, I consider 'deprecated=yes' as internally equivalent to 'status=d' (but no such status appears in any row). Another binary is 'blacklisted=yes'; blacklisted sources do have a status, 'b' for blacklisted. Uses can be derived from domain(s) (three links per domain) and doesn't need to be parsed from the row. Whether the row contains uses or not, if it contains domains, the builder should output uses for it.

'Stale' can also be derived; if {{CURRENTYEAR}} – LAST >= 4 then stale=y else stale=n. And imho, it *should* be derived, as we currently depend on users editing the files to update its value when they think about it, as in these 7 contributions, which is nuts. See section § Semi-automating template RSPLAST for more about this. Mathglot (talk) 04:37, 12 October 2025 (UTC)

Okay here's my first shot at a parser: https://github.com/audiodude/wiki-reliable-sources-parser

You can see the parsed JSON output for page 5 here: https://github.com/audiodude/wiki-reliable-sources-parser/blob/main/page_5.json

It looks reasonably correct to me, from the dozen or so I've checked, but obviously more eyes on it would be helpful. I can render all the other pages pretty easily if that's helpful. Also, the thing I'm most likely to have messed up is what fields are needed. I didn't get a one to one mapping with what you mentioned, specifically I don't think I understand "uses" very well, besides that it's just a domain name (mashable.com). audiodude (talk) 05:48, 13 October 2025 (UTC)

It was easy enough, the rest of the pages are here: https://github.com/audiodude/wiki-reliable-sources-parser/tree/main/data audiodude (talk) 06:04, 13 October 2025 (UTC)

At first blush, looks good; will take a look tomorrow. Thanks so much for your work on this; this gets us closer to a solution (whichever approach gets chosen). I don't think you need to worry about "uses"; it is completely derivable from domain; i.e., only the builder needs to worry about it, not the parser, so unless I'm missing something (but I don't think so) you can just ignore it. Mathglot (talk) 06:59, 13 October 2025 (UTC)

Oh, one thing: can you modify discussion so it is an array of unlinked page names? I.e., for Mail on Sunday (2nd row in page 5), you would have:

"discussion": 
   [
     "WP:Reliable sources/Noticeboard/Archive 278#Does WP:Dailymail apply to the Mail on Sunday",
     "WP:Reliable sources/Noticeboard/Archive 311#Clarification: Does Daily Mail RfC apply to the Mail on Sunday"
   ],

and the same thing for rfcs? If not, no worries; the builder side can easily do it. Thanks. Mathglot (talk) 07:12, 13 October 2025 (UTC)

So, I couldn't resist trying a couple of things, but now I really have to get some sleep. But to stay in sync with you, I copied the first two rows from your file 5 into Module:RSdata5/data, with Module:RSPTest to access it, and wrapper template {{RSPTest}}, so now we can demo a simple access of your parsed data thus:

{{RSPTest}} →

(commented out; see below; Mathglot (talk) 04:42, 14 October 2025 (UTC))

And from that, it's only a matter of expanding it to grab the other fields, and the other rows, and generate the output format desired for each case. And now I really need to let this go for today, but great start, this will lead to a lot of progress. Mathglot (talk) 10:11, 13 October 2025 (UTC)

Okay, I've changed the output format for the `discussion` field to just be a list of page names, is that what you requested? [1]. I don't know what you mean "same for rfcs". The `rsnl` template takes in the fields broken out in the objects listed, specifically the `notice_id` is required by the template for constructing the full rfc link. Are you asking for the link as rendered by that template? I can't do that in offline Python unfortunately. audiodude (talk) 00:51, 14 October 2025 (UTC)

Thanks; good as is. Mathglot (talk) 00:54, 14 October 2025 (UTC)

This looks wonderful! I'd want the RSN discussions singled out (like how we currently have numbers for RSN discussions and letters for anything else) but thi is good enough already. Aaron Liu (talk) 12:49, 14 October 2025 (UTC)

I've made the change you requested. Now `discussion` maps to a dictionary that has the keys `rsn` and `other`. Take a look here audiodude (talk) 16:10, 14 October 2025 (UTC)

Okay and of course now I realize that I did this in a completely boneheaded way, where I just moved all of the existing templates wrapped in a module! Oops. I'm going to keep iterating on it now that I've got something working and try and replace all of the inner templates with function calls. audiodude (talk) 22:49, 11 October 2025 (UTC)

So, I imported the rest of the data into Module:RSdata5/data from Audiodude's parsed subtable 5. The row-builder grabs only two fields from each row with no formatting, but it works. now emits a table with proper background shading per status for each row, and four columns of data. updated by Mathglot (talk) at 08:45, 14 October 2025 (UTC) (UTC)

Run template {{RSPTest}} on subtable 5 (M–N)

Perennial sources

Source	Status (legend)	Discussions			Use
		List	Last	Summary
Mail & Guardian	gr	2021	2021	The Mail & Guardian is a South African newspaper. There is consensus that it is generally reliable.
The Mail on Sunday	d	2020	2020	There is clear and substantial consensus that the Mail on Sunday is generally unreliable, and a slightly narrower consensus that the source should be deprecated.
Marquis Who's Who (Who's Who in America)	gu		2022	Marquis Who's Who, including its publication Who's Who in America, is considered generally unreliable. As most of its content is provided by the person concerned, editors generally consider Marquis Who's Who comparable to a self-published source. There is a broad consensus that Marquis Who's Who should not be used to establish notability for article topics. See also: {{pslink|Who's Who (UK)}}.
Mashable (non-sponsored content) WP:MASHABLE	nc	2021	2021	In a 2021 RfC, editors achieved a consensus that while non-sponsored content from Mashable is generally fine, Mashable tends towards less formal writing and is geared at a particular niche (tech news and pop culture). As such, non-sponsored content should be evaluated on a case-by-case basis, especially if the subject matter is outside of Mashable's usual focus.
Mashable (sponsored content)	gu	2021	2021	In the RfC, editors achieved a consensus that extra attention needs to be paid when it comes to sponsored content, especially ensuring that the content was written by Mashable staff and not the sponsor themselves.
The Mary Sue WP:THEMARYSUE	gr		2022	There is consensus that The Mary Sue is generally reliable. Most editors consider The Mary Sue biased or opinionated. Opinions should be attributed.
MDPI (Multidisciplinary Digital Publishing Institute) WP:MDPI	nc		2021	Publications in MDPI journals are considered questionable. Editors have raised concerns about the robustness of MDPI's peer review process and their lack of selectivity in what they publish. Originally placed on Beall's List of predatory open journals in 2014, MDPI was removed from the list in 2015, while applying pressure on Beall's employer. As of early 2024, about 5% of MDPI journals had been rejected by the Norwegian Scientific Index, and another 5% are under review.<ref>See https://kanalregister.hkdir.no/publiseringskanaler/KanalForlagInfo.action?id=26778 (the publisher's summary page) and click on "Vis [+]" in "Assosierte tidsskrift" line to see the list and their ratings. As of February 2024, 13 (5.2%) of the 250 journals listed were rated X (under review) and 11 (4.4%) were rated 0 (unsuitable for scholarly publications, although they do not label them as predatory per se).]</ref>
MEAWW (Media Entertainment Arts WorldWide)	gu		2021	MEAWW is a tabloid site covering pop culture and the internet. The site often employs clickbait and is considered generally unreliable.
Media Bias/Fact Check (MBFC) WP:MB/FC	gu		2025	There is consensus that Media Bias/Fact Check is generally unreliable, as it is self-published. Editors have questioned the methodology of the site's ratings.
Media Matters for America (MMfA) WP:MEDIAMATTERS	nc	2010  2019	2023	There is consensus that Media Matters is marginally reliable and that its articles should be evaluated for reliability on a case-by-case basis. As a partisan advocacy group, their statements should be attributed.
Media Research Center (MRC, CNSNews.com, Cybercast News Service, MRCTV, NewsBusters) WP:MRC	gu	2010  2019  2020	2020	There is consensus that the Media Research Center and its subdivisions (e.g. CNSNews.com, MRCTV, and NewsBusters) are generally unreliable for factual reporting. Some editors believe these sources publish false or fabricated information. As biased or opinionated sources, their statements should be attributed.
Mediaite WP:MEDIAITE	nc		2023	There is some consensus that Mediaite is only marginally reliable, and should be avoided where better sources are available. Editors consider the source to inappropriately blur news and opinion, and due weight should be considered if no other reliable sources support a given statement.
Medium (website) WP:MEDIUM	gu	2022	2022	Medium is a blog hosting service. As a self-published source, it is considered generally unreliable and should be avoided unless the author is a subject-matter expert or the blog is used for uncontroversial self-descriptions. Medium should never be used for third-party claims about living persons. A 2022 RfC also found that Cuepoint, Medium's music publication, is marginally reliable, with editors stating that its reliability depends on the qualification of the author.
Meduza	gr	2025	2025	Meduza is a news outlet run by Russian dissidents. There is consensus that it is generally reliable.
Metacritic (GameRankings) WP:METACRITIC	gr		2017	Metacritic is considered generally reliable for its review aggregation and its news articles on film, TV, and video games. There is no consensus on whether its blog articles and critic opinion pages are generally reliable for facts. There is consensus that user reviews on Metacritic are generally unreliable, as they are self-published sources. Reviewers tracked by Metacritic are not automatically reliable for their reviews. In December 2019, video game aggregate site GameRankings shut down and merged with Metacritic; GameRankings's content is no longer accessible unless archived.<ref>{{cite web|last=Plunkett|first=Luke|title=RIP Gamerankings.com|url=https://kotaku.com/rip-gamerankings-com-1840250954%7Cwebsite=Kotaku|publisher=G/O Media|accessdate=2019-12-06|date=2019-12-05|df=mdy-all}}</ref><ref>{{cite web|title=GameRankings Shutting down |url=https://www.gamerankings.com/news.html |archive-url=https://web.archive.org/web/20191204051348/https://www.gamerankings.com/news.html |archive-date=2019-12-04}}</ref><ref>{{cite web|url=https://gamasutra.com/view/news/355254/Review_aggregator_site_GameRankings_is_shutting_down.php%7Ctitle=Review aggregator site GameRankings is shutting down |last=McAloon|first=Alissa|work=Gamasutra|date=December 5, 2019|accessdate=December 5, 2019}}</ref>
Metal-experience.com WP:METALEXPERIENCE	gu	2021	2021	Metal-experience.com was determined to be generally unreliable for factual reporting.
MetalSucks	nc		2018	MetalSucks is considered usable for its reviews and news articles. Avoid its overly satirical content and exercise caution when MetalSucks is the only source making a statement.
Metro (British newspaper) (UK) WP:METRO	gu		2025	Daily Mail}} and other British tabloids. Articles published in the print newspaper are considered more reliable than articles published only on the metro.co.uk website. The newspaper articles were previously segregated online via the metro.news domain and are presently tagged under "metro newspaper" at the metro.co.uk domain.
Metro (British newspaper) (UK) (soap operas) WP:METROSOAPS	gr		2025	There is consensus that the Metro is reliable as a source on soap operas.
Middle East Media Research Institute (MEMRI) WP:MEMRI	nc	2020	2023	The reliability of MEMRI is considered to lie between no consensus and generally unreliable. Many editors argue that MEMRI has a history of providing misleading coverage and that the source should be used with caution if at all.
Middle East Monitor (MEMO) WP:MEMO	nc		2024	There is no consensus over the reliability of Middle East Monitor (MEMO). Previously consensus was established that it is a partisan think tank, with opinions ranging from "sometimes usable with attribution" to "unreliable".
MintPress News WP:MINTPRESS	d	2019	2025	MintPress News was deprecated in the 2019 RfC, which showed consensus that the site publishes false or fabricated information.
Le Monde diplomatique WP:LEMONDEDIPLOMATIQUE	gr		2018	There is consensus that Le Monde diplomatique is generally reliable. Some editors consider Le Monde diplomatique to be a biased and opinionated source.
Mondoweiss WP:MONDOWEISS	nc	2024	2024	Mondoweiss is a news website operated by the Center for Economic Research and Social Change (CERSC), an advocacy organization. There is no consensus on the reliability of Mondoweiss. Editors consider the site biased or opinionated, and its statements should be attributed.
Morning Star (British newspaper) (UK)	nc		2024	The Morning Star describes itself as a British "reader-owned co-operative and unique as a lone socialist voice in a sea of corporate media" and has low circulation. There is no consensus on whether the Morning Star engages in factual reporting, and broad consensus that it is a biased and partisan source. All uses of the Morning Star should be attributed. Take care to ensure that content from the Morning Star constitutes due weight in the article and conforms to the biographies of living persons policy.
Mother Jones (magazine) (MoJo) WP:MOTHERJONES	gr		2019	There is consensus that Mother Jones is generally reliable. Almost all editors consider Mother Jones a biased source, so its statements (particularly on political topics) may need to be attributed. Consider whether content from this publication constitutes due weight before citing it in an article.
MSNBC WP:MSNBC	gr	2020	2022	There is consensus that MSNBC is generally reliable. Talk show content should be treated as opinion pieces. See also: {{pslink|NBC News}}
MyLife (Reunion.com)	gu		2019	Due to persistent abuse, MyLife is on the Wikipedia spam blacklist, and links must be whitelisted before they can be used. MyLife (formerly known as Reunion.com) is an information broker that publishes user-generated content, and is considered generally unreliable.
The Nation WP:THENATION	gr		2022	There is consensus that The Nation is generally reliable. In the "About" section of their website, they identify as progressive. Most editors consider The Nation a partisan source whose statements should be attributed. The publication's opinion pieces should be handled with the appropriate guideline. Take care to ensure that content from The Nation constitutes due weight in the article and conforms to the biographies of living persons policy.
National Enquirer	d	2019	2019	The National Enquirer is a supermarket tabloid that is considered generally unreliable. In the 2019 RfC, there was weak consensus to deprecate the National Enquirer as a source, but no consensus to create an edit filter to warn editors against using the publication.
National Geographic (Nat Geo) WP:NATGEO	gr		2023	There is consensus that National Geographic is generally reliable. For coverage by National Geographic of fringe topics and ideas, due weight and parity of sources should be considered.
National Post (Postmedia Network) WP:NATIONALPOST	gr	2024	2024	National Post is considered to be a generally reliable newspaper.
National Review (NR) WP:NATIONALREVIEW	nc		2018	There is no consensus on the reliability of National Review. Most editors consider National Review a partisan source whose statements should be attributed. The publication's opinion pieces should be handled with the appropriate guideline. Take care to ensure that content from the National Review constitutes due weight in the article and conforms to the biographies of living persons policy.
Natural News (NewsTarget) WP:NATURALNEWS	gu		2019	Due to persistent abuse, Natural News is on the Wikipedia spam blacklist, and links must be whitelisted before they can be used. There is a near-unanimous consensus that the site repeatedly publishes false or fabricated information, including an exceptionally large number of conspiracy theories.
NBC News WP:NBC	gr		2024	MSNBC}}
The Needle Drop WP:FANTANO	nc	2021	2021	There is consensus that additional considerations apply when considering whether the use of The Needle Drop as a source is appropriate. There is currently strong consensus that Anthony Fantano's reviews that are published via The Needle Drop are self-published sources. There is currently rough consensus that Fantano is considered to be an established subject-matter expert as it pertains to music reviews and that these reviews may be used in an article as attributed opinion. However, per Wikipedia policy regarding self-published sources, these reviews should never be used as third-party claims about living people. There is also currently a rough consensus that Fantano's reviews do not always constitute due weight and that discretion should be applied on a case-by-case basis when determining if a review from The Needle Drop is appropriate to include in a given article. Articles on the theneedledrop.com website are unreliable due to a lack of an editorial policy.
The New American WP:NEWAMERICAN	gu		2016	There is consensus that The New American is generally unreliable for factual reporting. Some editors consider it usable for attributed opinions regarding the John Birch Society.
New Eastern Outlook	d	2022	2022	In the 2022 RfC, there is consensus to deprecate New Eastern Outlook. Editors note that it is considered a Russian propaganda outlet by multiple reliable sources, and numerous examples of publishing false content.
The New Republic WP:NEWREPUBLIC	gr	2020	2024	There is consensus that The New Republic is generally reliable. Most editors consider The New Republic biased or opinionated. Opinions in the magazine should be attributed.
New York (magazine) (Vulture, The Cut, Grub Street, Daily Intelligencer) WP:RSPVULTURE	gr		2021	Polygon (pre-2025)}}, {{pslink|The Verge}}, {{pslink|Vox}}
New York Daily News (Illustrated Daily News) WP:NYDN	gr		2020	Most editors consider the content of New York Daily News articles to be generally reliable, but question the accuracy of its tabloid-style headlines.
New York Post (NY Post, New York Evening Post, Page Six) (excluding entertainment) WP:NYPOST	gu	2020	2024	This consensus does not apply to the broadsheet publication of the same name, that existed from 1801–1942.
New York Post (NY Post, New York Evening Post, Page Six, Decider) (entertainment) WP:PAGESIX	nc	2024	2024	There is consensus that the New York Post ({{duses|nypost.com}}) and its sub-publications Decider ({{duses|decider.com}}) and Page Six are considered to be marginally reliable sources for entertainment coverage, including reviews, but should not be used for controversial statements related to living persons.
The New York Times (NYT) WP:NYTIMES	gr	2018	2024	There is consensus that The New York Times is generally reliable. WP:RSOPINION should be used to evaluate opinion columns, while WP:NEWSBLOG should be used for the blogs on The New York Times<nowiki />'s website. The 2018 RfC cites WP:MEDPOP to establish that popular press sources such as The New York Times should generally not be used to support medical claims.
The New Yorker	gr		2011	There is consensus that The New Yorker is generally reliable. Editors note the publication's robust fact-checking process.
The New Zealand Herald (NZ Herald)	gr	2021	2023	There is consensus that The New Zealand Herald is generally reliable.
News of the World WP:NEWSOFTHEWORLD	d	2019	2021	The Sun}}, News of the World should not be used as a reference in most cases aside from about-self usage, and should not be used to determine notability. Some editors consider News of the World usable for uncontroversial film reviews if attribution is provided. News of the World shut down in 2011; website content is no longer accessible unless archived.
NewsBlaze	d	2021	2021	NewsBlaze was unanimously deprecated by snowball clause consensus in the 2021 RfC. Editors cite NewsBlaze's publication of false and/or fabricated information, conspiracy theories, the site's sourcing practices, and copyright concerns.
NewsBreak (News Break) WP:NEWSBREAK	d	2020	2020	NewsBreak is a news aggregator that publishes snippets of articles from other sources. In the 2020 RfC, there was consensus to deprecate NewsBreak in favor of the original sources.
NewsFront (website) WP:NEWSFRONT	d	2019	2019	Due to persistent abuse, NewsFront is on the Wikipedia spam blacklist, and links must be whitelisted before they can be used. NewsFront was deprecated in the 2019 RfC, which showed unanimous consensus that the site publishes fake news and Russian propaganda. The use of NewsFront as a reference should be generally prohibited, especially when other sources exist that are more reliable. NewsFront should not be used for determining notability, or used as a secondary source in articles.
Newslaundry	gr	2020	2020	There is consensus that Newslaundry is generally reliable. Some editors have expressed concerns regarding possible bias in its political narratives and reporting on rival publications; in cases where this could reasonably apply, attribution is recommended, and sufficient.
Newsmax WP:NEWSMAX	d	2020	2022	Newsmax was deprecated by snowball clause consensus in the November 2020 RfC. Concerns of editors included that Newsmax lacks adherence to journalistic standards, launders propaganda, promulgates misinformation, promotes conspiracy theories and false information for political purposes, and promotes medical misinformation such as COVID-19-related falsehoods, climate change denialism, conspiracy theories, and anti-vaccination propaganda.
NewsNation (general topics) WP:NEWSNATION	gr	2025	2025	NewsNation (UFOs, UAPs)}}.
NewsNation (UFOs, UAPs) WP:UFONATION	gu	2025	2025	There is a consensus that NewsNation is generally unreliable for the topic of UFOs or UAPs. Editors pointed to NewsNation's lead reporter on UFOs, Ross Coulthart, having a well-documented history of promoting conspiracy theories in that topic area. See also: {{pslink|NewsNation (general topics)}}.
Newsweek (pre-2013)	gr	2019	2019	There is consensus that articles from Newsweek pre-2013 are generally reliable for news covered during that time. In 2011, Newsweek was a reputable magazine with only some minor problems while it was owned by The Newsweek Daily Beast Company (which also owned {{pslink|The Daily Beast}}). Blogs under Newsweek, including The Gaggle, should be handled with the WP:NEWSBLOG policy. See also: Newsweek (2013–present).
Newsweek (2013–present) WP:NEWSWEEK	nc	2019	2024	Unlike articles before 2013, Newsweek articles since 2013 are not generally reliable. From 2013 to 2018, Newsweek was owned and operated by IBT Media, the parent company of {{pslink|International Business Times}}. IBT Media introduced a number of bad practices to the once reputable magazine and mainly focused on clickbait headlines over quality journalism. Its current relationship with IBT Media is unclear, and Newsweek{{'}}s quality has not returned to its status prior to the 2013 purchase. Many editors have noted that there are several exceptions to this standard, so consensus is to evaluate Newsweek content on a case-by-case basis. In addition, as of April 2024, Newsweek has disclosed that they make use of AI assistance to write articles. See also: {{pslink|Newsweek (pre-2013)}}.
The Next Web (TNW)	nc		2019	There is no consensus on the reliability of The Next Web. Articles written by contributors may be subject to reduced or no editorial oversight. Avoid using The Next Web's sponsored content.
NGO Monitor (Non-governmental Organization Monitor) WP:NGOMONITOR	gu	2024	2024	There is a consensus that NGO Monitor is not reliable for facts. Editors agree that, despite attempts to portray itself otherwise, it is an advocacy organization whose primary goal is to attack organizations that disagree with it or with the Israeli government regarding the Israeli–Palestinian conflict. Some editors also express concern about past attempts by NGO Monitor staff to manipulate coverage of itself on Wikipedia.
NME (New Musical Express) WP:RSPNME	gr		2020	There is consensus that British publication NME is generally reliable for content related to its areas of expertise, which include music.
NNDB (Notable Names Database) WP:NNDB	d	2019	2019	NNDB is a biographical database operated by Soylent Communications, the parent company of shock site Rotten.com. It was deprecated in the 2019 RfC. Editors note NNDB's poor reputation for fact-checking and accuracy, despite the site claiming to have an editorial process. Editors have also found instances of NNDB incorporating content from Wikipedia, which would make the use of the affected pages circular sourcing.
NPR (National Public Radio) WP:RSPNPR	gr		2024	There is consensus that NPR, an American public service broadcaster, is generally reliable for news and statements of fact. NPR's opinion pieces should only be used with attribution.

Now it's just a matter of expanding the module into a true row-builder, by formatting the rest of the data, using wikitable delimiters so everything comes out in six columns. I could probably hack it out eventually, but I am a beginner at Lua and someone familiar with it could probably do it in very short order. Mathglot (talk) 04:46, 14 October 2025 (UTC) update: learning Lua, and making some progress with this now. Mathglot (talk) 08:29, 14 October 2025 (UTC)

For the record: for the data conversion from JSON to Lua data module, I used: s!^([^":]+)"([^":]+)":(.*)$!\1\2 =\3!g, followed by another one to replace lone square brackets to curlies. Mathglot (talk) 06:22, 14 October 2025 (UTC)

Please please use a proper conversion from JSON to Lua, not regex! Either via a wiki Lua module that reads JSON natively, or an offline Lua script that reads the JSON and emits the Lua lists. audiodude (talk) 21:52, 14 October 2025 (UTC)

It turns out that there is a way to read JSON natively involving mw.loadJsonData, as I learned from Aidan, but by that time, my module was already using the Lua data version, so it's just using mw.loadData for the time being, and I don't feel like converting it to read JSON just for a demo. Mathglot (talk) 20:14, 16 October 2025 (UTC)

Note: I have made a request at WT:LUA for assistance from a Lua volunteer to help with the row-builder module. Mathglot (talk) 07:03, 14 October 2025 (UTC)

Let's pause for a moment and think about how we're using everyone's time and energy:

There are three main options here. Only one (1) of them is going to be approved and put into practice. If we build all three of them, we'll be throwing two of them in the trash next month. How much effort do you want to be throwing away when the RFC is over? Maybe we shouldn't create the row-builder module until we know that's the one that the community is going to adopt. WhatamIdoing (talk) 18:31, 14 October 2025 (UTC)

Thanks for the motivation and concern about time in that comment. There have been claims made before about to what extent the row-builder approach would help, and I would like to see some hard data about that, and building a module mockup would help with that. I don't believe that following an rfc that chooses a different approach, an unused, mocked up approach is a wasted effort. In my case at least, I have been meaning to get started with Lua for ages, and working on Module:RSPTest is my first Lua module, so nothing is wasted in the learning process. (Wrt the WP:RSPDEMO, nothing is really wasted there either, as it pushed my regex abilities as well.) Plus, whatever approach is not used will still be there down the road if we need them, not to mention serving as a model for how other projects might approach a looming PEIS issue in their project, as there is a rich history here now, as well as a pretty good toolkit that could be purloined. (Finding it here might be an issue, but then, it always is.) So, not too worried about time spent, at least on my part.

If there is an underlying concern about these efforts pushing off the Rfc a bit, I understand. Personally, I am not too concerned about that, although I get that there is a desire to just get on with it. That's a tougher call, as at some point, there will be diminishing returns from continuing to work on the row-builder module, but from my PoV it was never about completing the module to production quality, but rather getting it to a point where we can measure how it does with PEIS, and thus give us a better estimate for projecting how it would affect PEIS in the future to see how it stacks up against the other approaches we will give as options in the Rfc. The module version currently in Module:RSPTest/sandbox may be close enough for that already, or almost. It doesn't contain the discussion links in column 3, but that shouldn't matter as those links may be numerous and long (e.g., WP:DAILYMAIL), but they do not use templates. Otoh, it doesn't yet have "uses" in column 6, which does use templates, and once that is in there, I think it will be quite usable as a predictor of future PEIS usage. We already know how to do "uses" without templates, because {{Infobox source reliability}} already does that. Adding Aidan9382, who has already improved the module considerably beyond my bumbling effort, just so he can observe how it looks down here in the trenches, where these efforts are being used and avidly discussed. Mathglot (talk) 19:53, 14 October 2025 (UTC)

How long do you think it will take to reach that better PEIS estimate? A day, a week, a month? WhatamIdoing (talk) 20:06, 14 October 2025 (UTC)

A day or two, I would say, after we get Uses in there. But we can draft an Rfc now with some blanks to be filled in later, as in, "Method Y should take us to ____% PEIS and allow ___ rows expansion, and should last approx. _____ unit time" so no need to wait, imho. Mathglot (talk) 20:57, 14 October 2025 (UTC)

Drafting the RFC question shouldn't take very long, so I feel like we can wait. It's the end of Tuesday (for most editors), so that suggests that we might be able to start talking about the RFC details on Friday. I think that's soon enough. WhatamIdoing (talk) 21:06, 14 October 2025 (UTC)

1. For the RfC we could just mock up the option with the existing module audiodude made that simply transcludes all the templates needed , and build the actual builder if the option passes.
2. For the rest of the year or so I won't have the time and energy to do a lot of stuff, but here's how I was planning to estimate this: subst absolutely everything on a sample of entries, transclude the resulting page and find out how much PEIS that takes up, and generalize that. It should be about the same as a module. (Though I'm expecting that we'll only call the RSPShortcut templatestyles sheet once throughout the entire page instead of once every entry.) Aaron Liu (talk) 01:20, 15 October 2025 (UTC)

I am not sure whether the method you mention in #2 is a valid proxy for a module or not; see Help:Template limits, in particular §§ Nested transclusions​ and Non-rendered transclusions. Maybe it is, I don't know; can you elaborate? I don't understand why the templatestyles directive affects PEIS, but apparently it does: PEIS of WP:SHORTCUT on its own page is 14,874 bytes; I added 20 more copies of the templatestyles line to the page, and in Preview mode PEIS rose to 18,234 or 168 bytes per inclusion of the 88-byte templatestyles line. Odd. Mathglot (talk) 23:18, 16 October 2025 (UTC)

i don't see any reason it wouldn't lol. Assuming we're #invoking the module directly, the only thing it adds to the PEIS besides the text returned is out = frame:preprocess("{{show begin}}") .. '<div class="center" style="width:auto;margin-left:auto;margin-right:auto;clear:both">' .. out .. '</div></div></div>', so the contents of TM:show begin which are cached and only added once because this invocation has no parameters. (If we instead use a wrapper template that sends all parameters to the module then that simply doubles + adds the wrapper template's length to PEIS used.)

WP:SHORTCUT itself transcludes 14,874 bytes' worth. But when you transclude WP:SHORTCUT, the contents of WP:SHORTCUT itself are added to the PEIS. Since the templatestyles invocation is part of the template's content, it is added to the PEIS.

Or at least that's what I've been assuming for a year now. I dunno, I never learned anyaf this in Uni ("dedication to knowledge"... ha). Aaron Liu (talk) 03:09, 17 October 2025 (UTC)

References

Aidan's demos

I wanted to highlight here some very relevant work being done by User:Aidan9382 on the "row-builder module approach".

First, I now understand the term row-builder module approach as describing a suite of related approaches that differ in conception and/or details of implementation, but which have these features as common elements:

• a Wikipedia Module is involved;
• the result is a wikitable, which to a reader looks indistinguishable from the table we have now;
• use of the module would replace all or most of the current usage of templates in the table in some fashion;
• this results in a reduction in PEIS, which permits addition of more rows to the table and buys us some time before PEIS is exhausted again.

Did I miss anything? Section § Python demo above describes one member of this suite; its design requires an initial external parsing step and importation of a JSON data structure which is parsed by a module to produce the rows; Audiodude, hope I have fairly summarized that.

This subsection highlights some experiments being done by Aidan using a different row-builder module design. It replaces template calls embedded in the existing table rows with module invocations to build pieces of the row, and does not require external parsing. Primary module code is at Module:Sandbox/Aidan9382/RSP, and there is a seven-row RSP test table that goes along with it at User:Aidan9382/sandbox3; previous revs highlight different experiments. Some discussion of these experiments has taken place at Module talk:RSPTest/sandbox#PEIS difference. Projections resulting from one experiment (in this rev) indicated a PEIS savings of about 27% and a projection of room in the table for an additional 137–188 rows before we hit 99% again. (Aidan, please correct this summary as needed.) Adding WhatamIdoing. Mathglot (talk) 18:35, 16 October 2025 (UTC)

I was asked to create a Python parser as a fundamental step to any approach. My own module row builder demo was simply designed so I could understand the number and type of "fields" that are required, so that I could parse them from the current tables. My own module doesn't inherently require Python pre-parsing. However, it seems that the module created by @Aidan9382 requires "arguments" like the ones my module requires, which is what I'm referring to as "fields". I guess I assumed that no one wanted to recreate 600+ calls to a module by hand, and would prefer to generate them automatically based on the intermediate format provided by the Python script. audiodude (talk) 21:39, 16 October 2025 (UTC)

Well, depending on the implementation used, the call replacement should be simple if we use the more basic module replacement method instead of a full row builder, and it'd also end up being more efficient for PEIS, so implementation difficulty specifically shouldn't be a major concern when deciding what to go with. Aidan9382 _(talk) 22:59, 16 October 2025 (UTC)

How should we word an rfc?

Further information: § RFC drafting section

Probably we should start with what our list of options are. Referring to § Approach summary, it sounds like we have three; maybe four. I can easily see the rfc question itself being brief (a sentence to explain why we are having it (i.e., hitting PEIS limits) and a sentence to introduce the options), but we may need a details section after that, to explain what these options are, and what the implications are of each one. I am somewhat concerned with how we best arm participants with sufficient information to make an informed choice, without drowning them in so much detail that it is counter-productive. Mathglot (talk) 18:33, 10 October 2025 (UTC)

Adding @WhatamIdoing, Aaron Liu, SuperGrey, and Gråbergs Gråa Sång:; please ping more as needed. In case you missed it, we are down to 98.31% of PEIS capacity, so there is room to discuss this calmly. Mathglot (talk) 18:52, 10 October 2025 (UTC)

How much work do you want to do, to prepare the options? We have two approaches that would keep a similar appearance and buy ~3 years (§ module-generated rows and § One giant table approach) and two approaches that would mean bigger changes but solve the problem indefinitely (§ central list, and click to longer explanation or § central list with landing pages and mocked up demo).

Do you want to prepare all four first, or have people tell you which half they're most interested in, and then make a proposal for just those two? WhatamIdoing (talk) 19:41, 10 October 2025 (UTC)

Copy of comment originally placed at § Approach summary:

We have two main options with the RFC: One is to ask for preferences on temporary vs permanent solutions, then sort out functional proposals for whichever is chosen and have another RFC. The other is to develop all of the proposals first and propose them all at once in a single RFC.

I'm inclined to the first but will support whichever approach you and @Aaron Liu want to take, since you're the two that would have to make the functional proposals. WhatamIdoing (talk) 19:30, 10 October 2025 (UTC)

Hm, interesting. Am thinking about this; interested in others' views. Mathglot (talk) 19:42, 10 October 2025 (UTC)

I do see the advantage in splitting it into two, with the first one being the choice between medium-term + eventual revisit three? years later, vs. long-term/permanent. What concerns me, though, is I wonder if there is an implication here that the medium-term is implementable more easily than a long-term one, which might influence the choice. The problem I see is that of the two medium-term solutions, only one is implementable easily: the giant table. The other medium-term solution is the modularized row-builder, but if that is chosen, what happens next, what is the migration path, and how long would that take? I can see a part I rfc possibly choosing the row-builder approach, and then having no clear idea of what comes next, and then we are kind of back to square one again. So even to present a two-step Rfc solution still requires some technical work ahead of time, imho, to fairly inform participants on what consensus for one option or another might mean.

Wrt to the giant table, if that were chosen, it might paradoxically become a forever solution, rather than a three?-year one, but at a cost. Imho, choosing that option would likely make adding new rows to the table difficult for many editors; just pulling up a table that big in a preview window and finding the right place to insert something is fraught (it was for me), and inserting characters might cause echo delays. What that would mean, imho, is that new rows would be added only by the most hardy and determined or tecchie editors, the giant table would grow much more slowly than the table chunks used to, and you would buy a lot more than three years, maybe indefinite time, but at the cost of a basically moribund perennial sources project that basically gets stuck in 2025, with a few exceptions here and there. I'm not sure that's a good future for the project. As a test, I highly recommend you try to edit WP:RSPGIANT, and add one row to it; pick a random new source name (real or fictional) ahead of time in your head, and then edit the file and try to add the new entry. (Feel free to publish, or not, as you wish.)

Or, do we simply acknowledge all this in Rfc #1, make it part of the explanation, and if users want that approach anyway, then so be it? Mathglot (talk) 20:12, 10 October 2025 (UTC)

I think "simply acknowledge". Maybe something like "We can do something that will preserve the appearance until the next time this happens (estimated to be three years), but the solutions either make it very difficult to edit the entries or require a lot of volunteer time to create the tools"? WhatamIdoing (talk) 20:32, 10 October 2025 (UTC)

Maybe we could contextualize, "No solution is easy or it would have been done already; all options have their downside." Mathglot (talk) 20:43, 10 October 2025 (UTC)

That's the plain truth. WhatamIdoing (talk) 21:02, 10 October 2025 (UTC)

Is it on-topic in the Rfc to mention that we have a few emergency stopgap techniques in our toolbox, like converting RSPSTATUS, or WaId's replacement of the table with links to the eight subpages (see here)? These all degrade the user experience somewhat, but preserve a functioning table in some form. Or is that irrelevant? Mathglot (talk) 05:47, 11 October 2025 (UTC)

I think we want editors to talk to us about their preferences for non-emergency work. We may need to keep adding emergency stopgap techniques, but emergency stopgaps aren't solutions. WhatamIdoing (talk) 06:01, 11 October 2025 (UTC)

Agree; that makes sense. Mathglot (talk) 18:51, 13 October 2025 (UTC)

I agree that we should have a split that groups the options that would result in one large table together and then the options that would result in a long list of links together. Instead of "less or more permanent", I'd call this grouping "keep large table or use long list of links". Is there still support for the "jump to entry in table" option now that the landing page one has been proposed? Aaron Liu (talk) 03:21, 13 October 2025 (UTC)

I'm fine with having separate Rfcs, if consensus goes that way, and I think I'm leaning that way anyway. Let's see who else weighs in. I would not label the second approach "long list of links" because that isn't the goal, or defining characteristic of that approach, anymore than the label "shortcut access" would be the right name for the table approach, implying that the shortcut to a table row is the goal; it isn't. In each case, they are just a navigation method to the data, which is a table row in one scheme, and a landing page in the other; that is the essential difference between the two approaches. Lists of links and redirect shortcuts are just ways to get to the data, not the goal. Mathglot (talk) 05:00, 13 October 2025 (UTC)

Aaron, your idea is basically asking people which appearance they want. My idea is more like asking people if they want to risk having this problem again in the future. I think that asking about the appearance is will prompt short-sighted responses, based on what present-me wants and not on what future-me might regret. There are times when a short-term POV is the right answer, but I don't think that this is one of them. WhatamIdoing (talk) 17:05, 13 October 2025 (UTC)

Thing is, the two one-table approaches are not necessarily both short-sighted, making your grouping names slightly less than correct. As mentioned above, the one-large-table approach may end up practically permanent because of the sheer amount of space it has left. Something similar is possible but much less likely for the row-builder approach. "Both of these are not theoretically permanent" is a weaker link between options than "they'll look like this". Aaron Liu (talk) 17:22, 13 October 2025 (UTC)

This comment above estimates that "one giant table" has room for 150 additional rows, and then we'll be in the same place again. 150 rows is about three years, which is not "practically permanent". Do you think that estimate is significantly wrong? WhatamIdoing (talk) 17:30, 13 October 2025 (UTC)

The one giant table may be permanent, not because of how much space is left, but because it is so big that it is already tricky to edit, and imho this will stifle editors who might have wished to do so, and growth of the table will slow or stop; not the kind of permanent solution I would hope for. I'm not sure what you mean about the row-builder approach being "less likely"—do you mean it won't buy us much time if implemented, or it won't get implemented? Regarding the latter, there has been a flurry of activity lately thanks to Audiodude and we are closer than ever to implementing it; if you meant the former, what is your estimate and what do you base it on? If that calculation is driving what your preferences are, I think we should concretize that estimate. Mathglot (talk) 18:21, 13 October 2025 (UTC)

By "less likely", I mean it's less likely for the row-builder approach to turn out practically everlasting; TL;DR: the former. (Also I agree with you on the large table being hard to edit.) Aaron Liu (talk) 12:59, 14 October 2025 (UTC)

How about something like "separate list of sources from entries"? Aaron Liu (talk) 17:24, 13 October 2025 (UTC)

Sounds like the same thing as before, with "list" being a way to avoid saying, "links". The distinction between approaches presentation-wise is whether each source gets one row of a table, or gets its own landing page. If you are keen to point out that you have to have a list of landing pages to find them, or that it takes an extra click to do that, that's part of the pro's and con's of each approach, but not what defines them. The crucial difference presentation-wise, is in one you get rows (indissolubly glued together), and in the other you get pages (all entirely separate), but I'm not sure what the best way to say that is.

But I'm with WaId here, regarding how to organize an initial Rfc, namely buys-us-time (giant table, row-builder) vs. permanent (landing pages). I understand you don't agree that giant table and row-builder should be grouped in that way, but I'd like to understand why not. Mathglot (talk) 18:42, 13 October 2025 (UTC)

Or, should we reassess the two-Rfc approach compared to going with just one, where we describe both how different approaches look, as well as how long they might last or how easy/difficult they might be to deal with, all rolled up together? Or is that TMI to deal with all at once? And do we agree that we are dealing with three options, giant table, row-builder, landing pages, or are there others? We need to agree on a path forward here. Mathglot (talk) 19:05, 13 October 2025 (UTC)

@Aaron Liu seems to question the earlier estimate of "one giant table" collapsing when ~150 rows are added. Iff he's correct, then we have:

• One giant table – could stay functional for 10+ years(?)
• Row-builder – will need to be replaced in ~3 years
• Separate pages – could stay functional for 10+ years

Iff that's the case, then "two ways to make a table, but both of them will break in 3 years" is not accurate. WhatamIdoing (talk) 19:59, 13 October 2025 (UTC)

Aaron is correct. The original comment of ~150 rows applied to the row-builder module, not the giant table approach iirc, and then somewhere I mistakenly copied it to the giant table as well. I just ran a test now adding rows to WP:RSPGIANT, and after successfully adding 600 300 rows to it, it still works. PEIS is at 94.3%, it is 919,169 bytes long, CPU 8.97 seconds (Real time usage 9.469 seconds), columns still sort rapidly (in my browser environment), but syntax highlighting took too long in preview mode and was disabled (very minor issue). It is a viable alternative, and Aaron may be right about it lasting ten years. Mathglot (talk) 22:30, 13 October 2025 (UTC) updated by Mathglot (talk) at Mathglot (talk) 19:50, 16 October 2025 (UTC)

Well, that changes everything (for the RFC). It should be three-way, and the options are:

• One giant table – will look about the same, likely to stay functional for about 10 years, and will be difficult to edit entries
• Row-builder – will look about the same, will need to be replaced in ~3 years, and will be about the same to edit entries
• Separate pages – will look different, will stay functional indefinitely, and will be easy to edit entries

Does that sound about right? WhatamIdoing (talk) 23:21, 13 October 2025 (UTC)

So far, yes, but there has been some important work by Audiodude lately (parser; data, e.g.: page 5; and this very dumb template of mine, {{RSPTest}}, that runs off two rows and two columns of his parsed page 5 file) that should make estimating the row-builder a lot more accurate and less hand-wavy, so I'd like to hear from him first. Mathglot (talk) 00:28, 14 October 2025 (UTC)

I've beefed up the module data file so that we now have all of subtable 5 parsed into Lua-readable data, and RSPTest dumps two fields from it for all 61 rows in the subtable. Mathglot (talk) 06:37, 14 October 2025 (UTC)

How did you convert the data into a Lua data structure? I hope you didn't do it manually, I can write a script to do that conversion and put the result (for all rows) in the repo. audiodude (talk) 15:58, 14 October 2025 (UTC)

By PCRE regex. But if it isn't onerous to write a script to do it, that would save me having to run the regex seven more times, but that is no big deal if you have to spend much time on a script. Btw, such a script would be really great if doable here on-wiki, either in Lua or js, so that other editors would have access to it and could use it for their project. I looked everywhere for a JSON-to-Lua-data module here, but couldn't find one. Another option might be Wikimedia's Toolforge platform, but I am only a user, not a builder there, so can't help too much with that. Mathglot (talk) 20:04, 14 October 2025 (UTC)

Audiodude, good news: no need for my regex or your script; Lua can do it. Please see Aidan's comment at Module talk:RSPTest/sandbox. Mathglot (talk) 22:36, 14 October 2025 (UTC)

Too late, see my comment below! audiodude (talk) 22:49, 14 October 2025 (UTC)

Though I also created a full JSON list of all the sources together, which should be useful for loading into Lua. audiodude (talk) 23:07, 14 October 2025 (UTC)

I've added a script to convert the JSON to a Lua table, and the corresponding table from running the script on the new `sources.json` file that I created to store all of the rows. I don't know much about how Scribunto works with external modules, so it will be an extra step to make such a conversion available generally, but I'm sure that can be tackled later. audiodude (talk) 22:49, 14 October 2025 (UTC)

Oops, sorry I didn't get here quick enough to save you the trouble, but I just learned of it myself. Agree with the "tackle later" as far as what method is best, we needn't be concerned about that now. One other thing to be clear on: the main goal with any of these module-based row builders for right now is getting a reasonably good estimate of how much a row-builder would affect PEIS, i.e., a) how much would it reduce it from the 99% it is now, if we used it right now, and b) to predict roughly how many rows we could add to the table, if we had the module to build it. The latter, in turn, implies how long such a solution would be valid before PEIS hits 99% again. That information is needed to start the Rfc. It is actually *not* a goal for right now to get a 100% perfect module that gets everything right, or even a data file that is 100% right; they both have to be good enough so that the PEIS reduction estimate is a valid one, but a module that perfectly duplicates the existing live table is not a requirement. So, some fields that imply template use in the current table (e.g., shortcut, status, last, uses, rfc (if the rfc links use the rsnl template–not all do), and others, but not discussions, even if there are 50 of them, because they are just plain wikicode, untemplated. So, once you think your module is developed enough to use it to fairly estimate PEIS reduction, you can call a truce. Ditto the version at Module:RSPTest, and now also at Aidan9382's Module:Sandbox/Aidan9382/RSP, which I suspect will end up giving us the best estimate, but let's all stay in touch about all these efforts. Mathglot (talk) 23:10, 14 October 2025 (UTC)

Well this is as good a place as any to bring up the fact that, isn't any table that includes all of the rows going to bump into the article size limit, even if it avoids PEIS? Has this already been discussed? Is it being taken into consideration when weighing the alternatives? audiodude (talk) 23:16, 14 October 2025 (UTC)

That was the point of WP:RSPGIANT. The original Giant table was 498 rows (like the live table) and has significantly lower PEIS (can't recall exactly, might have been 65%), but was also already 477kb. The current version of the Giant table is a test to see what might happen in the future, has around 1100 800 rows, and is still viable at 94% PEIS. It may hit other limits, but it hasn't hit them yet. Whether to go with a single table of 498 rows, not to mention future growth to 1100 800, is not a technical question, and should be decided by the community. Mathglot (talk) 23:46, 14 October 2025 (UTC) updated by Mathglot (talk) at Mathglot (talk) 18:39, 16 October 2025 (UTC)

The max page size is around two million bytes per Wikipedia:Article size#Technical issues.

Well before that point we run into editing problems, especially in the 'heavier' editing environments (e.g., if you've turned on syntax highlighting). WhatamIdoing (talk) 02:05, 15 October 2025 (UTC)

Maybe that limit is restricted to articles. In Wikipedia space, this page rev. was 3.7M bytes. Needless to say, it is difficult to load. Mathglot (talk) 19:39, 19 October 2025 (UTC)

The limit applies to all pages with the "wikitext" content model. That page is a mass-message delivery list. Aaron Liu (talk) 19:51, 19 October 2025 (UTC)

WhatamIdoing, are you envisioning some kind of pro's-and-con's section, either in the top question, or perhaps a details/notes section? One thing I am thinking about, is whether it would be fair, when describing pros & cons of One giant table, to raise the topic of why the current table is transcluded from eight separate chunks. I presume that the reason had to do with editing, not viewing; i.e., making it easier for users to edit it by breaking it up. Either way, the One giant table would undo that, and I wonder if the history, or at least the reason it was broken up in the first place is worth mentioning. Mathglot (talk) 00:15, 15 October 2025 (UTC)

If there's a concern with partiality, we can simply add the procons to the nom's !vote instead. Aaron Liu (talk) 01:22, 15 October 2025 (UTC)

No concerns about partiality. Is that related to the question of chunked tables somehow? Mathglot (talk) 02:09, 15 October 2025 (UTC)

I think that we have to present some information about the advantages and disadvantages, as participants will neither have the necessary information (the situation is so far outside the normal editing experience) nor be able to look up the answers (there being no reliable sources about the consequences of how this page could/should be structured).

For example: "If we choose this option, some editors may find the page too large to edit comfortably. They may need to turn off tools such as syntax highlighting or ask others to make changes for them."

BTW, I made an edit to the table in WP:RSPGIANT just now, and it works in the visual editor and in the 2017WTE with syntax highlighting enabled – for me. But that is going to be partially device dependent, and it took >20 seconds to get my change saved. WhatamIdoing (talk) 17:26, 15 October 2025 (UTC)

I misread. Seemingly I have hallucinated someone here saying a procon section in the statement might unduely bias certain procons as larger than they actually are. I personally don't think that would happen, so let's pretend my reply was too a hallucination. Aaron Liu (talk) 02:41, 16 October 2025 (UTC)

Responding the actual question: You are entirely correct. I've linked this above but here goes: Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Page size. Aaron Liu (talk) 02:43, 16 October 2025 (UTC)

Oh, right; thanks for linking that again; I *did* read it the first time, but forgot. Thanks! Mathglot (talk) 17:34, 16 October 2025 (UTC)

Regarding what the rfc should say about the § Row-builder module approach: we have two, or maybe three flavors of that now, by Audiodude, Aidan9382, and I'm not sure Aaron Liu if your conception fits one of those or is uniquely different? (I had messed around with a test module, but I consider it a kind of hybrid of Audiodude's and Aidan's methods, and withdraw it in view of better ones.) I don't think we have to go into details in the rfc about differing row-builder approaches; it's enough that we are offering three very different options in the Rfc (i.e., § Giant table, § Landing pages, § Row-builder) without going into suboptions of the row-builder approach. After explaining it briefly, if we just say something like, "the row-builder module approach will allow room for expansion of about N rows which might last for about X time", that should be enough for this option, I think. Iirc, all of the row-builder approaches come up with very roughly the same order of PEIS savings, even if the estimates differ somewhat, but I don't think we need to have a definitive estimate of each before starting the Rfc. If the row-builder module approach is chosen by the community, I think we can leave any decision on which implementation of it is best for later, based on technical considerations. Do you agree? If so, I think we are good to go to write an Rfc question. Mathglot (talk) 18:06, 17 October 2025 (UTC)

Sounds good to me as far as the RFC goes. To be clear, I'm not intent that any approach I build needs to be the one used, and even if the Python parser turns out not to be useful I was happy to build it. audiodude (talk) 18:39, 17 October 2025 (UTC)

I think my conception fits with Audiodude's. I'd change the parameter names but the gist of it is the same. (Also, I think we should at least try the estimate I mentioned below.) Aaron Liu (talk) 16:13, 19 October 2025 (UTC)

Question, would reducing the number of entries via some systematic method make sense as an option? Basically is the issue really with the PSN table vs that it seems editors are using this table to ask basic sourcing questions that should probably be held at RSN on a case by case basis. It was one thing to use this table for sources that really are discussed every other month at RSN. However, once we get to entries that might only have less than say 5 mentions at RSN why would we add them here even if they are obviously good/bad sources? I know this is a bit of a fundamental RSP question but can such options be on the table here? Springee (talk) 16:27, 19 October 2025 (UTC)

Springee, if you know of cases where editors are using the table to ask questions about sourcing rather than summarize repeated, significant discussions about a source, can you list a few? If that is the case, then I would say those rows should be removed. There is a banner at the top of the page that clearly states: "Only sources that have been repeatedly raised for discussion are listed here". Section WP:RSPCRITERIA goes further, and describes the requirements for "significant" discussions, and as I understand it, no number of "mentions" would qualify for inclusion of a source here. If you know of cases like that, I think you should probably raise it in a new section on this page, or maybe boldly remove the rows. Mathglot (talk) 19:08, 19 October 2025 (UTC)

Yes, that could be asked, but I suspect we will get a knee-jerk "Nooooo, we need all of them!", so I don't think that asking it is pointful.

If you wanted to reduce the number of entries, I suspect that a more successful approach would be to find a particularly weak individual entry and propose its removal (as "shouldn't ever have been added"). WhatamIdoing (talk) 20:55, 19 October 2025 (UTC)

Barring new rows from the live table

P.S., I don't think we'll hit 100% PEIS again while we are discussing, but it might happen during an Rfc, or during implementation of whatever the consensus is, but here is a temporary solution: I have created Wikipedia:Reliable sources/Perennial sources/X which is an "overflow area" table, which we could request users at RSN to use, instead of adding new rows to the */1 to */8 chunks while the Rfc is open or while consensus solution is being developed. That would prevent the live table from breaking while we come up with something, at the cost of barring new rows from the live table, but actually, we are already there, so it isn't really much of a cost and allows user to keep adding new candidates somewhere, even if they won't go live right away. Mathglot (talk) 20:26, 10 October 2025 (UTC)

Support -- A good temporary solution. SuperGrey (talk) 20:44, 10 October 2025 (UTC)

Support implementing emergency procedure if necessary. CNC (talk) 17:28, 13 October 2025 (UTC)

We are pretty much de facto barred from adding new rows to the live table already, because it just squeezes us more and more with desperate measures required to rescue it, taking editor time away from achieving a more lasting solution. I propose that we recognize that we are in a situation where no more new rows may be added to the live table (meaning, blocking new rows from table chunks */1 through */8). We should at a minimum mention this at WP:RSN, and add a warning advisory at the top of each of the eight table chunks requesting that no new rows be added (although they can tweak existing rows for LAST/staleness, new discussions on existing sources, etc.), and that they add their new row to Wikipedia:Reliable sources/Perennial sources/X instead. Any objections to implementing this? Mathglot (talk) 21:25, 10 October 2025 (UTC)

Support. SuperGrey (talk) 22:12, 10 October 2025 (UTC)

You could add a note at Wikipedia talk:Reliable sources/Noticeboard#RSP collapsed. WhatamIdoing (talk) 23:29, 10 October 2025 (UTC)

Done. Mathglot (talk) 03:58, 11 October 2025 (UTC)

Minnow for implementing the notice through dedicated transclusion to every single subpage instead of to Wikipedia:Reliable sources/Perennial sources/Header. Aaron Liu (talk) 03:24, 13 October 2025 (UTC)

Could do, but then you would need special handling for Wikipedia:Reliable sources/Perennial sources/X, either expanding the header and just including the expansion of it without the notice, or else adding a new exclusion param to a header template that has no conditionals or parameters at the moment. Either way works. But I like fish, so it's fine. Mathglot (talk) 05:07, 13 October 2025 (UTC)

• Only just seen this topic, I wouldn't of added to P6 if I had known. Feel free to revert if needed. CNC (talk) 17:29, 13 October 2025 (UTC)

  User:CommunityNotesContributor, no worries, your edit had zero effect on PEIS, the critical resource which is near capacity right now. And just to be clear: you may continue to add plain-text content to existing rows like RhythmOne (WP:ALLMUSIC), including more discussion links, longer or modified Summary, updated status, and so on. The only problematic type of edit is adding an entirely new row to the table. Thanks for the heads-up! You can actually help in one way: if you go back to the P6 page, is the banner at the top noticeable, and is the wording clear in meaning? If it isn't, we can change it. Mathglot (talk) 19:21, 13 October 2025 (UTC)

  Strange as I added a new row didn't I, ie a new entry? Looks clear enough though, have also added it to the group editnotice for good measure, so now appear on all /Perennial sources subpages. [2] CNC (talk) 19:57, 13 October 2025 (UTC)

  Maybe I'm confused, or didn't look far enough in the history.. Oh, I see, I thought we were talking about RhythmOne, but now I see your earlier addition of Popular Mechanics. Well, maybe it shouldn't have been added, but we are still okay on PEIS for the moment (just under 99%), so it can remain for now. For other new rows, though, please use the overflow table, */X. Mathglot (talk) 01:03, 14 October 2025 (UTC)

Given the recent change to WP:RSPSHORTCUT reducing table PEIS to ~89%, do we want to "unfreeze" the subtable chunks, and remove the WP:RSPTableFull message? Mathglot (talk) 22:20, 18 October 2025 (UTC)

Encyclopedia.com

Can Encyclopedia.com be placed on the list given the closure of the recent RFC? ―Howard • 🌽³³ 15:21, 5 October 2025 (UTC)

I think we should, but I don't know if it would cause this page to crash at this time. Gråbergs Gråa Sång (talk) 15:27, 5 October 2025 (UTC)

We could always draft the content as a note here, and then add it when the page is fixed up. WhatamIdoing (talk) 02:28, 6 October 2025 (UTC)

A halfway-house solution might be the following: go ahead and write it up, and include it in the row in the */3 file, where sources beginning with 'E' are stored. Place it in between <noinclude>...</noinclude> tags, and point the shortcut at its row in the */3 file, *not* the main file. This way, it will not blow up the main page when it is transcluded there, and people using the shortcut can still directly view it, in the */3 file. The cost: it won't be seen if you browse or sort the main table; but it also won't contribute to crashing it. Then, when the problem with the main page is fixed, just remove the <noinclude> tags. Mathglot (talk) 05:58, 7 October 2025 (UTC)

Oh, looks like someone already added it. We are now back up to 99.76% of capacity, and 4,959 PEIS bytes short of full. Do we want to add an WP:Edit notice to the eight numbered files, to wave people off of editing them, or at least, warning of the possible consequences? Edit notices show up above the preview window when editing. (Not sure what happens in VE.) One of the things we could mention in the edit notice, if desired, is the noinclude workaround. In the meantime, it would be a good idea if we all added numbered files WP:Reliable sources/Perennial sources/1 – WP:Reliable sources/Perennial sources/8 to our watchlists. Mathglot (talk) 06:07, 7 October 2025 (UTC)

I won't add a WP:Encyclopedia.com shortcut then. Gråbergs Gråa Sång (talk) 07:52, 7 October 2025 (UTC)

In general, as mentioned in the inclusion criteria, do not add a shortcut unless it is used elsewhere. Use {{RSP entry}} instead of creating a shortcut until the entry becomes really really popular. Besides what we already feared about it bumping against technical limitations, ti turns out that the shortcut template is the biggest non-textual contributor that bumps us against the PEIS limits. Aaron Liu (talk) 00:30, 8 October 2025 (UTC)

How can a shortcut to WP:RSP at this stage be used elsewhere unless I add it somewhere else the same time? The point of the shortcut here is to show editors it exists so they can use it when talking to other editors. I don't think every RSP-item needs one but I have seen this one come up in discussions now and then, so it seemed a reasonable one to me. But noted that Template:RSP entry exists. Gråbergs Gråa Sång (talk) 06:48, 8 October 2025 (UTC)

Feel free to create a shortcut if you are using it now. Shortcuts should be created on the same day that you want to use it for the first time. Please do not create shortcuts on the off-chance that someone might someday want to use it. WhatamIdoing (talk) 16:59, 8 October 2025 (UTC)

Noted, but my guess is that most of the shortcuts on WP:RSP were created with the "someone might someday want to use it" motivation. It was certainly mine when I made WP:RSPSCRIPTURE and WP:RSPYT (I also had a "I will certainly use this" motivation). I was right, too. Gråbergs Gråa Sång (talk) 17:18, 8 October 2025 (UTC)

Gråbergs Gråa Sång, there is another solution, which avoids increasing PEIS which involves just adding [[WP:NEWSOURCELINK]] to your row instead of using the WP:RSPSHORTCUT template. Your link will go red, but it won't look like the little bordered box with the map pin. It's possible to get that look-and-feel without impacting PEIS and with not too much extra work; if you want to try that, add [[WP:NEWSOURCELINK|<span class=wp-rsp-sc2>WP:NEWSOURCELINK</span>]], which renders as WP:NEWSOURCELINK, and once you create the link, it will go green (as a redirect). It's fine to use that, if you want. Mathglot (talk) 01:40, 11 October 2025 (UTC) I've gone ahead and added it for you. Note that it doesn't behave identically with the other ones, which if you click them, go to the redirect page and are blue; this is green, and just comes back to the table row again if you click it. But, it gets you a visible, copyable link that users can use. Mathglot (talk) 02:00, 11 October 2025 (UTC)

For the record: the recent change to the template makes the above hack no longer needed, and it could be backed out in favor of just using the shortcut template. But it's probably not worth doing it just now, until the result of the Rfc is in. Mathglot (talk) 17:46, 21 October 2025 (UTC)

Mobile testing for RSPGIANT

Marcocapelle, Laterthanyouthink, Johnpacklambert, Mediocre Legacy, Bluethricecreamman, Sbaio, anyone else who edits from the mobile site:

Would you please make a test edit to the huge table in WP:RSPGIANT, and tell us whether that's feasible for mobile editors? (It's a copy, so don't worry. Just do any basic change, as if you were fixing a typo or adding a simple link.)

It'll be useful to know whether you're using the mobile app or the mobile website. I don't expect it to be pleasant, but it'd be helpful to know whether it's actually impossible (e.g., timed out before it could load the whole page?), and also how you would rate the experience on a scale that runs from, say, "painful" to "manageable". And, I suppose: Can you even read that table on mobile? WhatamIdoing (talk) 06:20, 16 October 2025 (UTC)

@WhatamIdoing: done. It is slow, as expected, but it works. It is readable too, of course both horizontal and vertical scrolling is needed. Marcocapelle (talk) 06:27, 16 October 2025 (UTC)

@Marcocapelle (or anyone else), from the mobile POV, would you prefer a page like /Deutsche Welle or /The Daily Telegraph be better? (Those links show two different styles.) WhatamIdoing (talk) 22:57, 16 October 2025 (UTC)

• @WhatamIdoing: not a question for me, I just look at content and take any style for granted. Marcocapelle (talk) 05:31, 17 October 2025 (UTC)

Unfortunately WP:RSPGIANT has "Post‐expand include size: 1978935/2097152 bytes" which leaves very little expansion room. Some of the helper templates such as WP:RSPSHORTCUT and WP:RSPLAST are used hundreds of times and each occurrence includes a large number of bytes. Tweaking them and dropping some of the functionality would give more breathing room. Johnuniq (talk) 06:56, 16 October 2025 (UTC)

Yes, but it's a test page. We're actually trying to figure out how big we can make it without breaking t. WhatamIdoing (talk) 08:10, 16 October 2025 (UTC)

@Johnuniq That's only because Mathglot copied and pasted the table a few times to see how much space is remaining. IIRC the current estimate is over 600 new rows can be added. (1978935 is after those 600 new rows were added.) Aaron Liu (talk) 22:49, 16 October 2025 (UTC)

At the moment, RSPGIANT might let us add 600 new rows, the row-builder module might let us add about 200 new rows,[3] and the subpages approach would allow thousands (though they wouldn't be rows any longer). WhatamIdoing (talk) 22:54, 16 October 2025 (UTC)

I think WP:RSPGIANT might let us add about 300 new rows. See this edit and this one, which added 150 rows each, for a total of 300 rows added, 800 total. The '600' was probably quoted from an earlier comment by me, and was a mistake. Mathglot (talk) 10:01, 18 October 2025 (UTC)

CBS News

Moved to Wikipedia:Reliable sources/Noticeboard § CBS News

 – Aaron Liu (talk) 18:34, 16 October 2025 (UTC)

RFC drafting section

 Courtesy link: Wikipedia:Requests for comment/Restructuring RSP     (this is the Rfc resulting from this discussion)

Here's my draft:

---

Which option should be used to fix the technical limitations that will prevent us from expanding Wikipedia:Reliable sources/Perennial sources (RSP)?

RSP currently lists about 500 sources, with a growth rate of about 50 new entries per year. With the current format, the page has reached the WP:PEIS template limits. Only templates within the limits are displayed; templates (and their contents) past that point on the page are not displayed. We need to restructure RSP to reduce the PEIS problem and accommodate more entries.

Editors have identified three main approaches to solving this problem. We are calling these three options "One giant table", "List of subpages", and "Row-building module". All options have advantages and disadvantages. Before we invest more hours in developing the options, we want to know which option is most appealing to the community. 02:46, 18 October 2025 (UTC)

Details

All of these are in the prototype stage. Volunteers are already lined up to implement any of them. All of them are expected to be implemented via semi-automated conversion from the existing RSP pages. There are many details yet to be settled, but this is our best estimate of what's possible:

• One giant table: All the table rows in WP:RSP are currently split among eight subpages (example), which are transcluded into the main RSP page. In this proposal, the subpages would be combined into a single giant table in the main RSP page. See WP:RSPGIANT for an editable example.
  • Appearance: It would look the same.
  • Capacity: We estimate that we could add about 300 new sources (about six years) with the "One giant table" approach. After that, we'll have the same problem again.
  • Performance: Loading speed for the page would be similar to what we have now.
  • Editing experience: It would be more difficult to edit the entries because there would be so much wikitext in the editing window. However, it wouldn't be impossible, even on mobile or with the visual editor, for most editors to make changes or add new rows.
• List of subpages: Put each entry (table row) into its own, shorter subpage. WP:RSP would have a list of all sources plus a search box. See WP:RSPINDEX and the linked subpages on it for an editable example.
  • Appearance: It would look significantly different. RSP would have a simple bullet list with links to separate pages (mockup). Clicking on the link will take you to a subpage with information about the source. Shortcuts such as WP:RSPBBC would take you directly to the relevant subpage (example). The exact style of the subpages has not been settled, but see examples for BBC (generally reliable), Ballotpedia (no consensus). California Globe (unreliable), CNET (complicated source), Deutsche Welle (shorter format). On most of these sample pages, you can scroll down to see a copy of the original row table for comparison.
  • Capacity: We could add thousands of new sources (many, many years; essentially a permanent solution) with the subpages approach.
  • Performance: Loading speed for both the main RSP page and each individual subpage would be much faster than what we have now. However, you might have to load two pages (RSP to find the link to the subpage, and then the subpage). The reading experience is probably better for mobile users (no scrolling sideways on a wide table).
  • Editing experience: It would be easier to edit and to add new sources. However, you'll have to remember to add any new pages to the main list in RSP.
  • Other: Use Special:RecentChangesLinked for the main RSP page to see all changes to all subpages (example; scroll down to 6 October or earlier). The function currently provided by table sorting can be replaced with categories; see test pages in Category:Wikipedia perennial sources.
• Row-builder module: RSP and its associated templates will be re-written to use a Lua module.
  • Appearance: It would look similar to what we have now. See this example.
  • Capacity: We estimate that we could add up to 200 new sources (up to four years) with the "Row-building module" approach. After that, we'll have the same problem again.
  • Performance: Loading speed for the page probably would be similar to what we have now.
  • Editing experience: Instead of editing a table, each row would use a template or module invocation, so the wikitext will look different. (A somewhat similar approach is used by {{Episode table}} in articles such as List of The Brady Bunch episodes#Episodes.)
  • Other: Lua programming skills are not common in the community, which means that we might struggle to find a volunteer to make any future changes.

If more than one approach seems acceptable to you, then for the convenience of the eventual closer, we suggest naming your first choice and a second choice.

Discussion and questions

Survey

---

@Mathglot, Aidan9382, Aaron Liu, anyone else: Please read this and especially check whether I've got the correct estimates for expansion sizes. As it's so long, I have highlighted the facts that I think will be most relevant to most editors, and I'm curious about what you think of that.

For any folks who see this but haven't been following the huge discussion above: I don't need to know which one you would !vote for, but I would very much appreciate knowing whether you feel like this description is clear enough that you could figure out why we're asking this question and whether you feel like you could choose one of the options. If it's incomprehensible, then please tell me, so I can do better. WhatamIdoing (talk) 03:10, 18 October 2025 (UTC)

WhatamIdoing, great job. I would not have thought of using this format, but I like it. Not too short and mysterious, not too long and tedious, but just right (the Goldilocks format). A couple of minor points:

• re: emergency measures, we haven't actually been forced to use the WP:RSPOVERFLOW table yet to keep RSP readable; the four 'Z'-items in there now are copy-paste models for ease of use. However, we could mention that all eight chunks or subtables or whatever we call them are now frozen, and the next row will have to go into overflow; it is only through the emergency measures (some of them sketchy) that we have lasted this long. (I wouldn't mention all that, and maybe none of it, but just wanted to correct the record.)
• for 'list of subpages', where it now says "Split each entry", I would write, "Split each entry (i.e., each row in the table)" (or, "spin off"). Wearing my bot-pinged-editor hat, "Splitting an entry" made me pause a second to make sure I understood.
• estimate for row-builder module: where did '200 rows' come from again? That could've even been me; you're right that the thread is long and it's hard to keep track, plus things have evolved. I recall two estimates, high/low, from Aidan of 135 to 185 or some such – depending on some technical issue I don't recall – which to me is "150-ish", and if we are using 50 rows/year, that works out to 3 years. But don't take my word for it, plus there are also Aaron and Audiodude's row builders as well, so maybe that's where it came from.

I think you asked the important question for this rfc question-building discussion at the end, namely, not which one do you favor, but do you understand the question as posed above and the options, or could we do better? I think it's fair to ask a couple of participants who were here early on for feedback on that, namely @Johnuniq and SuperGrey:. If you wanted to have a small number of additional opinions I can think of two more (uninvolved) editors I could ping who I think have an especially good ear for this sort of thing, but I'll hold off for now until I see how this discussion goes. Well done, it's been a long road, I know, but it's been worth it, and here we are on the brink. Kudos. Mathglot (talk) 03:54, 18 October 2025 (UTC)

I'm making copyedits (in this edit) based on your comments. I have removed the reference to WP:RSPOVERFLOW as unnecessary. I got the "200" from Aidan's recent estimate of 188, which I rounded to 200; I'm changing that now to "up to 200", but if you want to change it to "about" 150/3 years, that's okay with me.

I'm happy to have you (or anyone else) ping as many (or as few) other editors as you want. I'd rather have a dozen pings now than have a dozen confused respondents later. WhatamIdoing (talk) 04:58, 18 October 2025 (UTC)

As far as the row count estimate for the row-builder module, my recollection is that 150-ish fits better than 200-ish, but I'll wait till Aidan chimes in. Regarding pings: @Sdkb and Rjjiii: – imagine you were randomly summoned to an Rfc containing the text above, starting with the horizontal rule under "Here's my draft", spanning the portion headed "Details", and ending above the bold header "Discussion and questions". After reading that, your feedback on the following question would be helpful: "[D]o you feel like this description is clear enough that you could figure out why we're asking this question and whether you feel like you could choose one of the options". This is not about asking for your preference or !vote at this time, but about drafting a clear Rfc question. Your views as uninvolved editors would be very helpful. There is a lonnnng backstory; if you want the gory details, see § Addressing hard template limits, but kindly formulate your response before peeking! Thanks, Mathglot (talk) 08:08, 18 October 2025 (UTC)

I read the bit above and made these notes before looking at the technical aspect:

• "the WP:PEIS problems in"
  • Will most readers understand WP:PEIS and do they need to understand it here? Maybe something like "the technical limit reached in" as WP:PEIS is in the next paragraph.
• "RSP currently lists about 500 sources, with a growth rate of about 50 new entries per year. With the current format, the page has reached the WP:PEIS template limits." ← looks good to me
• "When the template limits are breached, content in templates is not displayed on the page." I think it would be better to phrase this in terms of this specific discussion and not templates in general.
  • Maybe, "Beyond those template limits, new entries will not be displayed on the page."
• Is "For the last couple of weeks, we have been using emergency stop-gap measures, such as removing shortcut templates, to keep RSP readable." necessary? It might give the wrong idea that there are more of these tricks in the bag, when the reality seems to be that the bag of tricks has been fully emptied.
  • Maybe just remove this line?
• "Editors have identified ..." ← This paragraph seems very clear to me. I like bolding on the three options for folks who have started to skim.
• "Details" I think the highlighting works really well here. This is inherently technical and the highlighted parts are what will be relevant to most. You might even consider using nearly the same language just for the highlighted parts to lean into that and make things easier to read. So "The visual appearance will be significantly different"→"It would look significantly different" and "easier to make changes"→"easier to edit".

After looking at the technical aspect, I tried several stopgap measures to buy some time for discussion and planning, since the page was already bumping against the limit.

Post‐expand include size was at:

2075765/2097152 bytes (99%)

After removing some template calls it dropped to:

1873301/2097152 bytes (89%)

And after removing the unused r parameter for reversing display order ("r=y") in {{duses}} it dropped to:

1828451/2097152 bytes (87%)

If the show/hide logic were removed (I reversed this and was demonstrating), it would drop slightly more to around 1778271/2097152 bytes (85%), but there might be objections to that change.

That should buy some time, but it might also mean the math needs to be redone above in the above explanation. Rjjⁱⁱⁱ (talk) 11:54, 18 October 2025 (UTC)

I'll note that your changes to WP:RSPSHORTCUT aren't perfect, as it loses the invisible wikilink normally produced by {{no redirect}} to generate "what links here" information, as well as making it not work standalone due to the removed templatestyles. Aidan9382 _(talk) 18:59, 18 October 2025 (UTC)

As an emergency stopgap measure, it's fine. As a long-term solution, it isn't the best. WhatamIdoing (talk) 19:09, 18 October 2025 (UTC)

Thanks for catching that, Aidan9382. I have manually added the invisible wikilink into WP:RSPSHORTCUT now. PEIS is still around 89%. Rjjⁱⁱⁱ (talk) 20:01, 18 October 2025 (UTC)

In light of Rjjiii's space-saving change to WP:RSPSHORTCUT, I think we should undo this sketchy edit made in an emergency attempt ten days ago to get down below 100%, which entirely replaced the RSPSHORTCUT template with its expansion, and which eventually made it to Wikipedia:Reliable sources/Perennial sources/2 after a swap between it and its sandbox version. Undoing it will likely increase PEIS slightly, but now we have room to play with; there's no reason the shortcut code uniquely in chunk #2 should remain so ugly. (Also, we should merge history from the original subtable 2, which now occupies the sandbox, but that should await the result of the Rfc to avoid possibly wasted effort depending what approach is chosen.) Mathglot (talk) 02:40, 19 October 2025 (UTC)

About "new entries will not be displayed": It's not "new" ones; it's whatever's towards the end of the wikitext, which could be very old.

I have taken your advice to remove the "emergency stop gap measures" line as unnecessary and standardize some of the language. [4] WhatamIdoing (talk) 19:20, 18 October 2025 (UTC)

Yes, and what's at the end of the wikitext template-wise are the notes and references, they would begin to degrade first. (This has already happened a few times, and could be linked from the rev history of the RSP page if desired.) When no more notes and references were visible, the content in the 'Z'-rows would start to degrade, and so on. Mathglot (talk) 19:45, 18 October 2025 (UTC)

It's probably a good idea to have links to a few of those revisions handy. WhatamIdoing (talk) 19:52, 18 October 2025 (UTC)

Oh, you are right. I was thinking of it wrong. Also, Archive.org snapshots show multiple times this year where the notes and references broke down when the limit was hit. Rjjⁱⁱⁱ (talk) 20:34, 18 October 2025 (UTC)

That link should be sufficient. We can keep it in our back pocket and pull it out if anyone asks. WhatamIdoing (talk) 21:01, 18 October 2025 (UTC)

Just wanted to underscore the wise choice of using an Internet Archive link to demonstrate this, rather than a link out of the page history of WP:RSP. To preempt possible questions about this, the crucial distinction is that IA preserves the Html of the page as it was at a given time, which means, of course, after all templates were expanded. However, the page history preserves the wikicode of the page as it was then, before they were expanded, and if you click a history link from, say, a month ago, all the templates will be expanded as they are now, not as they were then, thus not a valid picture of what the table looked like in the past. Only a full capture of the page Html can do that. Mathglot (talk) 21:10, 19 October 2025 (UTC)

@Aidan9382, would you rather have the row-building presented as a 150 rows/3 years or as 200 rows/4 years? I don't think our estimates are precise enough to justify being more specific than to the nearest 50 rows/1 year. WhatamIdoing (talk) 19:28, 18 October 2025 (UTC)

@WhatamIdoing: Well, I decided to go all out on my sandbox and try converting all of table 5. Obviously with the RSPSHORTCUT stop-gap in place my estimates might be a bit off, but if my notes are correct, table 5 was 252,249 bytes in its old form (it's 223,128 right now), vs 182,799 for the module approach, which puts the estimate (before the stop-gap measures mentioned above) at ~190 extra rows, which makes 200 a pretty decent estimate. Aidan9382 _(talk) 20:02, 18 October 2025 (UTC)

Thanks. Mathglot, unless you strongly object, then I'm inclined to leave it like it is. WhatamIdoing (talk) 20:15, 18 October 2025 (UTC)

Given these details, leaving it as is sounds exactly right. Mathglot (talk) 20:31, 18 October 2025 (UTC)

The RFC draft looks great. Addressed all the important points -- I don't see anything needed to add. SuperGrey (talk) 04:02, 18 October 2025 (UTC)

Thanks. WhatamIdoing (talk) 04:58, 18 October 2025 (UTC)

A minor point: the first two options link an example; the row-builder module approach links a Lua help page, but we could link an example; should we? Mathglot (talk) 04:07, 18 October 2025 (UTC)

I'd be happy to have a link there, but I'm not sure what looks like an example of the output. WhatamIdoing (talk) 04:58, 18 October 2025 (UTC)

WhatamIdoing, I think the relevant link there would be User:Aidan9382/sandbox3, but I would like to hear from Aidan9382—can you confirm that that would be the best link to include as an example of possible rendered-table output from a row-builder module, if we include just one such link in parallel with the other two (non row-builder) options? Mathglot (talk) 19:56, 18 October 2025 (UTC)

@Mathglot: That's my testing page for the module implementation, yes. If you do want to link it, make sure to use a permalink (I'd recommend Special:Permalink/1317468803), but the key part about how I designed the lua implementations for my testing were to be 1:1 in html to the templates (within reason), so there's no visual difference beyond what the new wikitext would look like. Aidan9382 _(talk) 20:14, 18 October 2025 (UTC)

Ah, yes; good point. WhatamIdoing, I would recommend adding this text:

See [[Special:Permalink/1317468803|this example]] module.

after the words "Lua module" (and maybe unlinking "Lua module"). Mathglot (talk) 20:41, 18 October 2025 (UTC)

I've added it to the Appearance line. WhatamIdoing (talk) 20:58, 18 October 2025 (UTC)

Thanks WhatamIdoing, that is excellent. However, you might think about revising the draft for a punchy RfC question with the information currently in the introduction moved to Details. Example question: What option should be used to fix the WP:PEIS problems in Wikipedia:Reliable sources/Perennial sources?. Re the options, very briefly, what arguments exist to avoid a list of subpages? One would be that having everything on one page allows searching for half-remembered text. Another is that one page makes monitoring changes much easier. An unmentioned advantage of subpages is that it would use familiar wikitext and would allow exceptions from standard formatting if needed. The giant and module options would require uniformity. I wonder if such arguments should be mentioned in Details. An example of subpages is seen at WP:LTA. Johnuniq (talk) 04:19, 18 October 2025 (UTC)

I'm dropping your "punchy" question right at the top, where I think it fits in nicely.

The subpages item is already longer than the others, so I'm hesitant to add any more to it. Also, I think for most editors, the main disadvantage is that it's the biggest change from the POV of the editors who use (rather than edit) RSP. They might like it eventually, but for right now, the cost of the transition is high. WhatamIdoing (talk) 05:18, 18 October 2025 (UTC)

Johnuniq, regarding the advantage of non-standard wikitext in subpages, I had considered this earlier and wrote it up as part of Q3 in section WP:RSPINDEX § Demo FAQ, but I don't see a good way to deal with that at the top level of an Rfc presentation, pretty much for the reasons WaId expressed. Flipping that around: analogous to Demo FAQ Q5, it would be natural for someone in the ensuing rfc discussion to ask about the migration paths, and clearly that is easiest for the Giant table as it is basically already done (or can be redone to pick up late changes), but again, where is the point of TMI in the initial question? Maybe that has to be left until someone asks about it? Mathglot (talk) 20:28, 18 October 2025 (UTC)

On second thought: what if we added italicized bullet Migration path to each approach? I think we could afford to add a sentence about each one without overloading the description. Mathglot (talk) 20:45, 18 October 2025 (UTC)

Are you ready and willing to implement whatever is chosen? If so, then I don't think that the cost of migration should be emphasized. WhatamIdoing (talk) 21:02, 18 October 2025 (UTC)

Ideally, migration for the landing-page approach should be scripted. It would be too hard for me working alone to implement the entire table as landing pages, given that I don't have an off-wiki scripting environment, and implemented the landing pages by executing a regex once per row. That wasn't too bad for the ~80 items under 'B', 'C', and 'D', and I think too me a week or ten days, but would be too much for one person using the regex another 420 times or so. I could do it, but it would probably block all my other Wikipedia activity for months, and I don't know that I'm willing to do that.

In theory, the existing row-builder module, which already does the necessary work to parse out the row fields, could be modified to generate the landing page-style format instead; we just have to specify what that format is (i.e., something that looks like Ballotpedia, or something that looks like Deutsche Welle, or whatever format—that could be decided by separate Rfc). The other major change is that it would have to write each resulting transformed output onto its own page, and I don't know Lua, but I don't think that is too onerous. Aidan9382, can you comment on the feasibility of such a module? (Input: table with rows like WP:BALLOTPEDIA; output: set of individual landing pages, like Ballotpedia, or some other format, t.b.d.)

One thing to keep in mind, is that unlike the row-builder approach, say, where the builder would be a permanent feature of the new table, the migration path for the landing page approach is needed only once: for the conversion of the existing table; after that, it could be thrown away. This has two major implications: it doesn't have to be anywhere near as robust, codewise, as any problems with a given row could simply be patched up after conversion by editing the wikitext of the emitted landing page. Secondly, it does not have to be done on-wiki in Lua—it can be written in any language and done offline; if someone wants to do it in Perl or Python, that works. If there's an advantage of doing it in Lua, it's probably that Aidan's module does a good part of the work already, but it isn't a requirement. So I think we could say this method requires a one-time conversion script that could be run on- or off-wiki, and could be similar to the existing row-builder module, but doesn't have to be. (Note: the Index table links could be generated by a single regex operation off the "id" attribute in the table rows, so that is not an issue.) Mathglot (talk) 21:42, 18 October 2025 (UTC)

The module itself obviously couldn't create the pages, but it would certainly be possible to make a module that made a simple layout in whatever way you'd be looking for based on the existing row data in one way or another and for you to just {{subst: it so it turns into a permanent raw text form. You'd still have to go page by page substituting it for each one, but it'd skip a lot of the work involved. If you really wanted to save time, you could make a bot task to do all of the substitutions with a module (or just have it do the logic itself externally), but that might be overkill depending on the scale in question here. Aidan9382 _(talk) 22:15, 18 October 2025 (UTC)

The table has 500 rows; not sure which would make more sense. Sounds like modifying the module for a new format is not too hard, and then a very simple bot that would loop on table rows invoking the module once per iteration with a single row and writing the resulting module output would be a pretty simple bot, but someone still has to do it. It sounds generic enough, maybe there's something like that already out there. Grabbing a single row from the table is trivial. Mathglot (talk) 23:52, 18 October 2025 (UTC)

If we were in a situation in which we have a volunteer to implement "A" but not "B" (no matter those items are), then we'd want to think harder about whether "B" is a viable outcome. Remember, e.g., WP:LUGSTUBS2, in which the community decided on a particular approach, but then nobody actually implemented it, because "my" part is complaining, and actually doing the work is somebody else's problem.

My impression is that we don't have that situation here. Sure, WP:RSPGIANT requires less effort to implement than the other two (though more effort to maintain), and there's always a chance that we'll need to find help (e.g., a bot, another Lua coder...), but in principle, the transition costs are not a blocking factor on any of the options. WhatamIdoing (talk) 23:55, 18 October 2025 (UTC)

A few comments:

• The first option has a note about reversing the 2024 decision, but the second option does that as well, as there would no longer be a fully searchable/sortable table.
• I would add searchability/sortability as one of the bullet points, as that's the second of the two results from the previous decision.
• I would also include the option for a "standard" page split into 2-3 subpages (or explain why it isn't feasible), since it's one of the options that attracted support in the last discussion. Arguably it's a version of option 2, but it would be very different in practice, as the appearance would remain similar (instead of changing drastically) and it would be partly searchable/sortable with extra steps (instead of only searchable by title or through the search box).

--Sunrise (talk) 05:26, 18 October 2025 (UTC)

In order:

• The first option's purpose is (more or less) to reverse the 2024 decision (to split the wikitext into eight tables and transclude them back into the main page). With the second option, it's more of a side effect than a goal.
• The second option doesn't provide a ⌘F compatible version for arbitrary text strings, but it does provide a search box (so it's "searchable" in a different way).
  The "sortable" function may be replaceable with categories (e.g., if you want to see all the GUNREL sources). It would be useful to know what people are trying to accomplish when they sort (available for only three columns: the name of the source, the status, and the date of the last discussion). If the answers are things like "make a list of all GUNREL sources" or "see how many NC sources there are" or "find outdated entries", then a category is likely to be more effective.
• I'm not sure what you mean by a "standard" page split. Just chop the table in half, and put half on each of two pages, like we once did with List of colours: A-M?

WhatamIdoing (talk) 06:06, 18 October 2025 (UTC)

Sunrise, I echo WaiD's comment about sorting, and just wanted to add that categories are already available in the demo at WP:RSPINDEX. You can view categories by date by status (and more could be added to view it the other way round). Top cat is Category:Wikipedia perennial sources – see the subcats for an idea how that goes. Or, bottom-up: click any source link at WP:RSPINDEX to view it and find the status & date category it is in, and then see other sources sharing the same category (e.g., this one). This is analogous to sort-on-status-column, except there is room for a lot more links on a category page, than table rows that will fit in a screenful. For search, you can search on any text from the search box, not just source names. Mathglot (talk) 06:51, 18 October 2025 (UTC)

In order (and @Mathglot, thanks for the comment about categories):

• I see the two main outcomes (meaning the two bolded portions of the close) as roughly co-equal in importance, in addition to representing the concerns of the two main viewpoints in the discussion. Those who gave opposing rationales might consider the strict condition clause (the result they argued for) to be the key outcome and the impact on performance from splitting to be the side effect. I don't think it makes sense to indicate when one RfC result is being reversed but not the other one.
• Those are important differences, in my view, and I don't think it's clear which system would be more effective. To an extent, the information is already included implicitly, e.g. the inclusion of you might have to load two pages under "Performance". However, as in the first point, this relates to one of the two main viewpoints from the previous RfC, so I would describe it as its own point.
• Yes, exactly. That said, I see that it’s been discussed in Demo FAQ #1c. I don't really agree with the response, since the primary table is not itself split, and it's citing the same RfC that we're already talking about reversing. However, I haven’t spent nearly as much time thinking about this as all of you clearly have (and I might always be misunderstanding something about templates), so I'm satisfied that you’ve considered the topic. :-)

--Sunrise (talk) 08:41, 18 October 2025 (UTC)

The 2024 discussion was not an RFC. There was only one RFC on this page in all of 2024, and it was about a sticky header gadget for the table. Maybe we just shouldn't bother mentioning it.

There are other options that could be considered (e.g., removing entries, so that only the 500 most 'important' are listed), but these are the three that these editors are prepared to offer to the community. WhatamIdoing (talk) 19:06, 18 October 2025 (UTC)

Wonderful draft! I like the idea and execution of this. A few notes though (please excuse me if these are already addressed in comments below):

1. I strongly disagree that making changes would be approximately the same. The Audiod approach can be summarized as "instead of filling out a table, you'd be filling out a template" with an example row syntax, and the Aidan approach would be filling out a JSON, which is a very different experience thanks to the lack of Wikitext tools in the JSON editor.
2. Is "about 50 new entries per year" accurate? It feels quite a bit less than that to me.

Aaron Liu (talk) 19:26, 19 October 2025 (UTC)

Aaron, where do you see Aidan9382's approach as having anything to do with JSON? See User:Aidan9382/sandbox3 and Module:Sandbox/Aidan9382/RSP; are you looking at something else? Mathglot (talk) 19:51, 19 October 2025 (UTC)

Okay, I didn't see that Aidan's approach had changed... It indeed pretty much preserves the existing editing experience. I don't see the reasons to use it though. I'll ask above. Nevermind, me thinkie loopy. Aaron Liu (talk) 19:56, 19 October 2025 (UTC)

@WhatamIdoing We might have restore the earlier wording, as while the current wording is correct for Audiod's approach, the earlier wording is correct for Aidan's, which we seem to be trending towards. Sorry about that. (Also, I'm convinced now that the new rows estimate is indeed correct.) Aaron Liu (talk) 18:45, 20 October 2025 (UTC)

Okay. I'll change it to "instead of filling out a table, you'd be filling out a template".

For #2, the net growth in the table per archive.org copies was 60 rows last year and 40 rows the year before, ergo about 50 rows per year. WhatamIdoing (talk) 21:03, 19 October 2025 (UTC)

I was just reviewing #2 while you did, and I came up with 65 new entries since a year ago, by taking this capture from IA of 16 October 2024, and got 435. However, on that date, there was a banner reporting a merge request from Wikipedia:Deprecated sources#Currently deprecated sources that had been there since June, and presumably that happened in the interim, so the 65 rows added in the last twelve months may be inflated due to that. Your two calendar year analyses before the merge should be more accurate. We could count 2025 and pro-rate for the last three months if we wanted to add this year to the estimate. Mathglot (talk) 22:18, 19 October 2025 (UTC)

I think that we should be thinking in very broad terms this purpose – big round numbers, half an order of magnitude. If we say 50, and it turns out to be 25 or 100, then that's a bit awkward. If we say 50 and it's 35 or 65, then that's no big deal. WhatamIdoing (talk) 22:35, 19 October 2025 (UTC)

In the details section, I would modify the bullet for One giant table as follows:

• One giant table: All the wikitext 500 rows currently split among eight subtables would be merged into a single enormous page table.

The table isn't the only thing on the page now, and wouldn't be after, hence enormous 'table'. If desired, we could link 'subtables' to the first one at Wikipedia:Reliable sources/Perennial sources/1, or add a '(1–8)' parenthetical with both numbers linked, which should illustrate the point sufficiently. Mathglot (talk) 21:44, 19 October 2025 (UTC)

Yes, updated version looks fine. Mathglot (talk) 22:21, 19 October 2025 (UTC)

Okay, are we about ready to post this? Any objections? Any last-minute changes?

Since this talk page is already uncomfortably large at the moment (well above 300,000 bytes), and since there were discussions above about the One True™ Location for this discussion, I think we should put it on a separate subpage (e.g., Wikipedia:Requests for comment/Restructuring RSP). As far as I'm concerned, we should give folks at least a few hours (half a day?) to reply, and then anyone who agrees that it's ready can start the RFC. The RFC cats for the tag could be |tech|policy|prop (or a subset of them). WhatamIdoing (talk) 22:40, 19 October 2025 (UTC)

Minor one: Under Details, Row-builder module, Editing experience:

Instead of editing a table, each row would use a template or module invocation, so the wikitext will look different.

The addition is if we go with something that looks like User:Aidan9382/sandbox3. For that matter, in whatever flavor of row-builder module that is developed, invoking the module directly (i.e., using #invoke rather than a template wrapper) will offer some savings in PEIS, and thus a somewhat longer life. But either method (template or direct invoke) would work with any row-builder that was developed, so it isn't really part of the row-builder approach, but how you employ it once you have it. Other than that (and it is minor) I think we are ready to post. (edit conflict) Mathglot (talk) 22:46, 19 October 2025 (UTC)

Okay, I'm adding that. NB that I've deliberately added it outside the highlighted text, because I want editors to focus on the overall concept and not on "what the heck is a module invocation?!" WhatamIdoing (talk) 23:04, 19 October 2025 (UTC)

No objections, and thanks all for putting so much into this, Rjjⁱⁱⁱ (talk) 23:30, 19 October 2025 (UTC)

I'm launching this now. Join me at Wikipedia:Requests for comment/Restructuring RSP. Sometime during the next 24 hours, the Wikipedia:Feedback request service will send out announcements. Responses from that will slow down in about two days, at which point we should consider posting some manual announcements (e.g., to Village pumps). We don't need to do all the announcements on the first day, but we should make sure that this is widely advertised during the next week or two. WhatamIdoing (talk) 22:48, 20 October 2025 (UTC)

Tangent: when the Rfc is launched, we should update the wording at WP:RSPTableFull, which appears at the top of each chunked 1–8 subtable currently, in order to add a link to the Rfc. Feel free to do so, or {{ping}} me and I'm happy to do it. Mathglot (talk) 08:37, 18 October 2025 (UTC)

Or given the recent change to WP:RSPSHORTCUT reducing table PEIS, perhaps we should "unfreeze" the subtable chunks, and remove the Table Full message? Mathglot (talk) 20:56, 18 October 2025 (UTC)

I'm going to be honest but I've started noticing a bit of an alarming trend with WP:RS/P which is that people think of it as being the final word for the reliability of all sources. IE: I see a lot of editors argue a source is not contextually unreliable either because it's not WP:GUNREL or, even worse, because it's not mentioned. This argument seems to often be put forward to support the use of marginal sources for controversial BLP statements. For instance, today's example is someone arguing we should use the Toronto Sun (which has the worst reputation of any major Canadian newspaper) to call a Canadian political candidate a genocide denier. With this in mind I'm wondering if we shouldn't be considering mothballing RSP and, instead, maintain a list of deprecated sources only. Then people might have to actually engage with context on discussions of reliability. Simonm223 (talk) 18:51, 20 October 2025 (UTC)

Yup. This was predicted before RSP was created (that expectation is why RSP didn't exist until 2018) and the prediction has come to pass. We do what we can to educate editors (e.g., Wikipedia:Reliable sources/Perennial sources#What if a source is not here?) but Wikipedia:Nobody reads the directions, especially if invoking RSP lets me "win". WhatamIdoing (talk) 22:41, 20 October 2025 (UTC)

The fruits of our labor, now live ripe

 You are invited to join the discussion at Wikipedia:Requests for comment/Restructuring RSP. (Using this template for better visibility.) Aaron Liu (talk) 21:48, 21 October 2025 (UTC)

I wouldn't say that we necessarily have to close this discussion, but I added a convenience link at the top linking the Rfc. Mathglot (talk) 00:01, 22 October 2025 (UTC)

Middle East Eye

There have been numerous discussions of MEE on RSN. Would anyone care to summarise them on the RSP list? BobFromBrockley (talk) 19:49, 19 October 2025 (UTC)

Last time I checked, there weren't enough RSN discussions about the source as a whole, instead of e.g. a specific opinion article. Aaron Liu (talk) 19:52, 19 October 2025 (UTC)

There are 20 mentions of Middle East Eye, and of those, I count four discussions that might qualify as significantly about them (1, 2, 3, 4). Mathglot (talk) 20:52, 19 October 2025 (UTC)

1 and 4 do not discuss the reliability in general (4 is the "a specific opinion article" one I mentioned), 2 says Grel but is questionable as the prevailing argument was Middle East Eye, here, is used as a source for an interview with the victim's mother. There isnt any indication that they did not faithfully and accurately report what her mother said. (though the source was evaluated), and while 3 counts I'm unsure what consensus the disucssion has; numerically it's a no-consensus but I'm unsure if the "unreliable"/"attribution" camp was sufficiently grounded in policy.

IAR I would only add this if another significant discussion naturally occurred. Aaron Liu (talk) 23:58, 19 October 2025 (UTC)

Icon image licensing

I noticed that a few of the icons used here with |link= have licenses that require the link to the file description page for attribution and notice of license. These should be replaced with public domain or CC0 icons. See MOS:BLANKALT and MOS:EMPTYALT for details.

Icon	License	Notes
	GFDL / CC BY-SA	is a similar PD file.
	CC BY-SA / MIT	Could very likely be declared {{PD-shape}} on Commons, or replaced with one of .
	CC BY-SA	Could maybe be declared {{PD-shape}} on Commons, or replaced with one of .
	CC BY	I didn't find any existing alternatives in a quick search, but it should be easy for someone to combine something like and one of to make something similar.

I didn't want to just change things without discussion, so I'm starting a discussion here. Anomie⚔ 14:35, 21 October 2025 (UTC)

Are we sure that the copyright for the OOUI icons aren't already covered by that of MediaWiki, which incorporates them?

An easier solution for the first and last icons is to just link them and unset the alt. I don't think their links would be particularly interfering, and I'd be surprised if their alt is blank since they're not purely decorative. Aaron Liu (talk) 20:46, 21 October 2025 (UTC)

My take is that if we use the Commons version, then we need to follow the conventions to comply with the license that's stated on Commons. Many are probably PD-simple of some variety rather than the MIT or CC license they're tagged with, but someone needs to actually make that change on Commons and make it stick. If they give us a parser function or <span class="..."> or something that uses the version that's actually embedded in MediaWiki, then it's covered by MediaWiki.

By dropping the |link= on the first and last, you'd lose the icons linking back to Wikipedia:Reliable sources/Perennial sources#Deprecated and Wikipedia:Reliable sources/Perennial sources#Stale discussions that explain what they mean here. But if that's fine with people here, it'd work to resolve the licensing issue. Anomie⚔ 21:51, 21 October 2025 (UTC)

I personally think WMF's/MW Contributors' licensed us the permission for the OOUI images, but I do see that it's quite vague. I think we can replace them with the suggested alternatives № 2 and 2 for now; there's little perceptible difference.

Would using the unset link in the legend linked to work for attribution (and, of course, since there's no links in the subpages making them have the unset link too)? I couldn't find the exact policy about attribution, though it's referenced in BlankAlt. Aaron Liu (talk) 22:08, 21 October 2025 (UTC)

I don't know to what extent we want to count having to click through multiple pages as satisfying the attribution and notice of license requirements, particularly when we normally use a direct link. Someone might well argue that the CC licenses' "reasonable to the medium" for Wikipedia has been established as "link the image to the file description page" and therefore an indirect link isn't enough. 🤷 Personally I'd rather just use images that don't need such hoop-jumping in the first place instead of trying to justify it. Anomie⚔ 22:47, 21 October 2025 (UTC)

Well, I was thinking unsetting the links in the legend at the same time, so you'd just need to jump to a different section on the same page... Aaron Liu (talk) 23:10, 21 October 2025 (UTC)

Click on the icon in the table → click on the same icon in the legend is still multiple clicks to get to the attribution, although technically the same page. Anomie⚔ 23:17, 21 October 2025 (UTC)

Can't the authorship info and the licensing information just be added to the local image? We don't need to provide credit in every image caption, so why do we need to here? This just reads like tedious pedantry honestly. Hemiauchenia (talk) 22:16, 21 October 2025 (UTC)

We normally provide credit for images by linking the image to its file description page that contains the necessary information. I don't understand what you're proposing as an alternative. Anomie⚔ 22:40, 21 October 2025 (UTC)

Several of these images are literally by WMF employees and are so simple they'd be public domain by default anyway. You're making a mountain out of a molehill about a situation that is currently fine. Literally nobody but you, including the authors of the images has objected to the current situation, so why do anything? Hemiauchenia (talk) 22:45, 21 October 2025 (UTC)

"We can violate the license as long as no one complains" isn't a good argument at all. Try proposing "ignore copyvios until someone complains" at Wikipedia talk:Copyright problems and see what response you get. "Made by WMF employees" doesn't mean we don't have to follow the license either; if the copyright holder wants to give an exception for use on Wikipedia, they can make that part of the license. "So simple they'd be public domain by default" is an ok argument, but in that case why not just update the file description page to reflect that instead of asserting we can ignore the claimed license? I don't because I don't want to potentially get involved in discussions on Commons, I had enough of that years ago. Anomie⚔ 22:56, 21 October 2025 (UTC)

I think we should centralize this above in my reply chain which discusses the same thing you discuss. Aaron Liu (talk) 22:59, 21 October 2025 (UTC)

This isn't about providing credit in the caption. It's about whether you can click the picture to get to the File: page.

I think this should be postponed until Wikipedia:Requests for comment/Restructuring RSP is over, because everything on this page will change as a result of that discussion. We can just make a mental note to get the image licensing right this time. WhatamIdoing (talk) 01:56, 22 October 2025 (UTC)

Allsides doesn't appear to match consensus

So the Allsides rating says "while the high-confidence ratings are generally reliable as they are reviewed carefully by experts" but the close says "The people who are in support of Option 2 point out that the confidence ratings in Allsides are highly variable—while the high-confidence ratings are generally reliable as they are reviewed carefully by experts, whereas the low-confidence ratings tend to be based more on surveys." which seems to be pulling the quote out of context... For context the arguments made by those supporting option 2 were "For the Allsides ratings that are supported by other RS or appear to have undergone a good analysis they are generally reliable, but for the one's that appear to have received little attention and care, they should not be used." "Therefore, to me this is not generally reliable even for the high confidence ratings and should be determined situationally." and "while high confidence ratings are generally usable with attribution, though in some articles, editors may not consider them valuable enough to include." (and thats pretty much it... No-one actually makes that argument per-say) so its a very loose summary which clearly isn't meant to be taken literally, but we've cut and pasted it. Horse Eye's Back (talk) 15:34, 31 October 2025 (UTC)

I would suggest raising the question at RSN. Given the summaries here are meant to be summaries of RSN discussions and given they are often treated as near policy it seems like questions regarding the RSP summaries should be reviewed there rather than here. I do think you raise a valid question BTW, I just think the correct venue should be RSN. Springee (talk) 16:23, 31 October 2025 (UTC)

The main point is that it isn't a summary... Its a quote used in a slightly different context (which changes the meaning in a substantial way) without quotation marks. A summary would say something else. Horse Eye's Back (talk) 16:33, 31 October 2025 (UTC)

The overall framing is also wrong, it says "In a 2022 RfC, editors found no consensus on the reliability of AllSides as a whole." but the result was not no consensus it was a standard "Option 2: Additional considerations apply" so I guess I'm mostly interested in how the summary on this list got to its current state. Horse Eye's Back (talk) 16:37, 31 October 2025 (UTC)

Probably someone did their best, and, like any other page, other editors are asked to do their best to improve it.

I agree with Springee's suggestion of workshopping the ideal wording at Wikipedia:Reliable sources/Noticeboard. WhatamIdoing (talk) 00:41, 1 November 2025 (UTC)

That noticeboard isn't for workshopping wordings at RS/PS... This talk page is. It can't be brought to RSN unless there is some new dispute over its reliability... Which I guess could work. Horse Eye's Back (talk) 00:46, 1 November 2025 (UTC)

I agree that this is the place to workshop the wording unless we want to ask RSN to clarify the close.

But in this case I think you would need to ask to clarify/overturn the close to change that part. The summary is correctly summarizing what the close said, the close is what's allegedly quoting the participants out of context here, and from a quick skim the close seems reasonable as there is a sizable amount of !votes ins upport of high-confidence=generally reliable. I don't see how high confidence ratings are generally usable with attribution, though in some articles, editors may not consider them valuable enough to include contradicts the close; it's generally reliable after all. Aaron Liu (talk) 16:03, 1 November 2025 (UTC)

No, the summary is quoting the close out of context. What the close says doesn't change that point, we have a quote pretending to be a summary and it can't be both. Horse Eye's Back (talk) 16:50, 1 November 2025 (UTC)

I do not see how the summary misrepresents the close. I only see your reasons to believe the close misrepresents the consensus. Aaron Liu (talk) 15:49, 2 November 2025 (UTC)

"while the high-confidence ratings are generally reliable as they are reviewed carefully by experts" is copyvivo not summary.Horse Eye's Back (talk) 16:35, 2 November 2025 (UTC)

I'm not sure if I understand. I'm referring to the "Summary" column of the RSP table as the summary and the statement at the top of the closed RfC as the close. I don't see how the summary misrepresents the close or what's wrong with having an unlabeled quote in the summary. At most just do a dummy edit linking the discussion for attribution. Aaron Liu (talk) 16:55, 2 November 2025 (UTC)

Summaries should not have unlabeled quotes in them, thats one of core principles of encyclopedic writing. Horse Eye's Back (talk) 20:12, 2 November 2025 (UTC)

Why so? Aaron Liu (talk) 20:22, 2 November 2025 (UTC)

Because otherwise we don't actually summarize anything, copying is not summarizing. Do you use unlabeled quotes in your encyclopedic writing? Horse Eye's Back (talk) 22:36, 2 November 2025 (UTC)

1. If there's no legal issue, what's wrong with that? The only other way to cover the information in this clause is close paraphrasing which is not better.
2. How does that have to do with whether the summary matches consensus?

Aaron Liu (talk) 01:11, 3 November 2025 (UTC)

How can it be a summary if its a copy? Horse Eye's Back (talk) 05:37, 3 November 2025 (UTC)

I agree with Horse Eye's Back that the RSP summary needs revisiting. Note that none of Allsides ratings are currently being used in English Wikipedia. As someone who regularly checks how Allsides is used in articles and removes any that aren't high-confidence, I've only come across a few over the years that actually meet the high-confidence criteria. They are removed by others as UNDUE, very quickly from the lede. --Hipal (talk) 18:54, 3 November 2025 (UTC)

Thanks for the clarification. I think it's fair to add the note about Due weight to the entry like what we have in many other entries. How about this? I've shuffled the text around for clarity, added the note on due weight, and also threw in a note on what AllSides usually does.

AllSides is an American company that estimates the bias of sources. In the 2022 RfC, editors found that reliability varies among its articles and should be determined on a case-by-case basis. Many believe that while the high-confidence ratings are generally reliable as they are reviewed carefully by experts, others depend on blind user surveys they consider opinionated and less reliable, though the inclusion of even reliable statements should be evaluated with WP:Due weight. A significant amount of users disagreed and argued that AllSides's methodology, which is partly based on the opinions of users, makes it unsuitable for Wikipedia. A significant minority of users noted that AllSides has been referenced in reliable sources as an accurate source for media bias ratings..

Aaron Liu (talk) 03:06, 4 November 2025 (UTC)

Times of Isreal

Moved to Wikipedia:Reliable sources/Noticeboard § Times of Isreal

 – Aaron Liu (talk) 13:50, 5 November 2025 (UTC)