Jump to content

Wikipedia talk:Reliable sources/Perennial sources

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
    ↑ To top of page

    Drafting the RFC question about platforms

    [edit]

    Here's a starting point for the RFC:

    Some websites listed in Wikipedia:Reliable sources/Perennial sources are not WP:SOURCES, but are instead digital platforms that host both reliable and unreliable sources. Examples of these platforms include YouTube, which hosts reliable TV news shows (example) as well as many unreliable home videos, and Flickr, which hosts reliable photos from government agencies such as NASA (example) as well as many unreliable personal photos.

    Proposal: Shall we expand Wikipedia:Reliable sources/Perennial sources#Legend to include a new category, "platform", with a description that says the website itself does not determine whether the source is reliable, and instead editors must look at the publisher. For example, on YouTube, editors must base their decision about reliability on the uploader or user. For example,; https://www.youtube.com/@BBCNews is (the verified official account) is reliable because https://www.bbc.com/news is reliable.

    Note:

    • Some websites will need to have two entries. For example, YouTube is only a platform for news videos, but editors discourage citing it as a primary source for views and subscriber counts, so it could have one entry for "platform" and another saying "generally unreliable" for views and subscriber counts.
    • Which items would get placed in this category is subject to case-by-case editorial consensus. Initially, _______ would get re-classified as platforms.

    What should we change first? Are the examples good? What websites (if any) should we put in the blank? WhatamIdoing (talk) 16:34, 19 August 2025 (UTC)[reply]

    I think we should just merge the entries into a category first (c.f. Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Merging some entries), giving it the status-quo GUnRel status, before starting an RfC on the status of that category. Aaron Liu (talk) 16:49, 19 August 2025 (UTC)[reply]
    The problem there would be something like WP:ACADREP where the hosting site is already marked as MRel. Moving those to GUnRel before the RFC could muddy the waters. -- LCU ActivelyDisinterested «@» °∆t° 22:25, 19 August 2025 (UTC)[reply]
    The description at ACADREP is pretty close to what we're saying about platforms: don't look at the hosting site; look at the real source. WhatamIdoing (talk) 19:25, 20 August 2025 (UTC)[reply]
    Ah, I should've realized ACADREP was essentially the same thing. I agree with Void then that focusing on the concept is probably the way to go before turning the RSP stuff into a category. If the PaG thing passes, we should be able to Boldly add a MRel category. Aaron Liu (talk) 19:29, 20 August 2025 (UTC)[reply]
    That looks like a good RFC question, its a bit on the long side but I think it needs to be to illustrate the issue. Personally the only clear area I see for improvement would be some sort of footnote after "the website itself does not determine whether the source is reliable" explaining that these platforms use proprietary content standards very different from that of publishers. Horse Eye's Back (talk) 16:54, 19 August 2025 (UTC)[reply]
    I'm not sure what you mean by "proprietary content standards very different from that of publishers". Does that mean that YouTube lets publishers post almost anything (that's legal), where as some publishers (e.g., the BBC) have higher standards and other publishers (e.g., a vanity press) do not? WhatamIdoing (talk) 20:08, 19 August 2025 (UTC)[reply]
    IMO it means that Youtube hosts what it wants to host (note that they choose not to host a lot of legal content), I believe that even vanity presses generally have more control over and liability for the material than a hosting platform does. Its not key to the RfC though, it can be a discussion that happens later if this proposal goes through. Horse Eye's Back (talk) 16:00, 20 August 2025 (UTC)[reply]
    Youtube hosts what it wants to host, but bbc.com/news does not?
    In the US, a vanity press can refuse to print anything they choose to refuse, because Freedom of the press belongs to those who own one. (Under US law, they actually shouldn't have liability except in specified circumstances such as child porn, as they aren't the publisher – legally, it'd be like blaming the manufacturer of a Photocopier if someone makes photocopies of something confidential.) But the same's true for YouTube and the BBC, so I'm not sure that it's relevant. The relevant point is that the BBC has higher standards than any vanity press. WhatamIdoing (talk) 19:25, 20 August 2025 (UTC)[reply]
    Vanity presses run a gamut, in some cases they are the publisher and in others it really is much more akin to the photocopier analogy. There certainly are aspects in which these platforms and vanity presses are similar though, especially with promoted posts. I agree that the relevant point is that the BBC has higher standards than any vanity press, but I think its also relevant that they have a fundamentally different mentality/tradition. Amazon also seems to fit into a few different boxes here. Horse Eye's Back (talk) 19:48, 20 August 2025 (UTC)[reply]
    I think that's a good RFC question. ~ ONUnicorn(Talk|Contribs)problem solving 17:07, 19 August 2025 (UTC)[reply]
    This seems good assuming we start after "Proposal:". The stuff before seems to assume the conclusion in ways I'm worried would violate WP:RFCNEUTRAL.
    I also think we ideally shouldn't repeat "For example" twice. Loki (talk) 19:18, 19 August 2025 (UTC)[reply]
    Agree with this. First paragraph should be part of a !vote, or otherwise adding "Editors have argued" at the start of the paragraph and linking to this discussion in order to include it. Best not to draw any conclusions into it. CNC (talk) 19:40, 19 August 2025 (UTC)[reply]
    The problem with omitting the explanation is it leaves us with a proposal to create a category called 'foo', with no explanation of what's intended to be in that category. I would expect that to produce confusion.
    "Editors have argued" sounds like weasel words, and besides, I don't think that anybody is seriously arguing the opposite (e.g., that the reliability of anything on YouTube can be determined merely by saying 'well, it's on YouTube, so it is/isn't reliable'). WhatamIdoing (talk) 20:11, 19 August 2025 (UTC)[reply]
    I agree with this proposal in principle but I think it should be proposed as an addition to WP:SOURCES first, and that perennial sources should follow suit. Void if removed (talk) 20:31, 19 August 2025 (UTC)[reply]
    I'm not sure how that would fit into WP:SOURCES: "When editors discuss sources...they are usually talking about the work itself, the creator of the work, the publication, or the publisher of the work, but we frankly don't care which website the work has been posted to; a book on Google Books or on Perlego or on Amazon is still the same book"? WhatamIdoing (talk) 20:38, 19 August 2025 (UTC)[reply]
    I'd suggest pretty much your proposed text be added as a subsection titled "Platforms", alongside WP:NEWSBLOGS, with a WP:PLATFORMS shortcut. Eg.
    Some websites are digital platforms that host both reliable and unreliable sources. Examples of these platforms include YouTube, which hosts reliable TV news shows (example) as well as many unreliable home videos, and Flickr, which hosts reliable photos from government agencies such as NASA (example) as well as many unreliable personal photos. In these cases, it is the reliability of the publisher which should be assessed, rather than that of the platform itself. Where no reliable publisher can be identified, such sources should be considered self-published.
    If there's consensus for that then Perennial sources should follow suit. I'd suggest doing it this way round because IMO it is more clearly a policy amendment/interpretation that should cascade out from WP:SOURCES. Void if removed (talk) 20:49, 19 August 2025 (UTC)[reply]
    I think I agree with Void, or at least I agree that we should do both of these at the same time.
    I'd also maybe include a line saying something along the lines of Information from the platform owner itself (including metadata like view counts as well as announcements directly from the platform) is considered to be published by the platform owner. In general this information should also be considered self-published unless it's reviewed by independent sources. Loki (talk) 21:01, 19 August 2025 (UTC)[reply]
    I think that both of these ideas are feasible.
    That means:
    Does that sound about right? WhatamIdoing (talk) 19:31, 20 August 2025 (UTC)[reply]
    Yes! Loki (talk) 21:29, 20 August 2025 (UTC)[reply]
    Support this. My main opposition previously was the lack of "doing things properly", whereby this is very much a thorough approach, along with UGC referenced below by Sunrise, so there would be no contradictions or varying interpretations of policy leftover. CNC (talk) 09:59, 21 August 2025 (UTC)[reply]
    I also think this is a better approach. My feedback is:
    • I would add Wikipedia:Reliable Sources#User-generated sources as well, given that it describes all such sources as "generally unacceptable". The list of examples may need to be updated, e.g. it seems that an organization's official Facebook page would be covered by this change as well.
    • I would emphasize that there must be some confirmation of the publisher's identity (e.g. uploads by other users are likely to be copyright violations). This could be an expansion or follow-up to Void's text of Where no reliable publisher can be identified, such sources should be considered self-published.
    • Since this is a broad change to policy, editors from the relevant pages should be invited to comment once text for all the changes has been proposed.
    --Sunrise (talk) 23:27, 20 August 2025 (UTC)[reply]
    • I regret to say that I agree with you about needing to restructure Wikipedia:Reliable sources#User-generated content. I'm currently thinking that we need to separate collaborative content (e.g., Wikia's Fandoms, Reddit discussions) from individual user posts (e.g., a teenage boy posting videos of himself and his friends on skateboards). Collaborative content is user-generated, and the rest is perhaps better filed under this 'platforms' concept. (But where to put a multi-person Twitter thread [as opposed to an individual tweet]]? Obviously I haven't thought about this enough yet.)
    • I'm not sure that Void's text is appropriate. Unreliable publishers (e.g., National Enquirer) are not self-published, so they should not be considered self-published. They should be considered unreliable (in the case of the National Enquirer, due to a reputation for the opposite of fact-checking and accuracy). Also, you should be able to determine the publisher on most of these platforms: it's the username of the uploader. The publisher will very frequently be engaged in self-publishing (e.g., that teenage boy on his skateboard) or potential copyvios (e.g., video clips), but IMO the policies and guidelines should normally consider these unreliable (meaning that they have one or more of a long list of disqualifying problems) rather than specifically self-published.
    • As I said above, I expect this to be a very widely advertised RFC.
    WhatamIdoing (talk) 00:09, 21 August 2025 (UTC)[reply]
    On point 2, that's a good point that I overlooked when quoting that. The wording would need to be adjusted - I think the key idea is to clarify that a self-published source does not lose that status simply by being published on one of these platforms. On point 3, to be clear, I was recommending getting input from those pages before actually starting the RfC, since RSP is rather specialized in comparison. Sunrise (talk) 02:11, 21 August 2025 (UTC)[reply]
    Half of the usual suspects are already here, but I've no objection to anyone posting notices.
    The thing on my mind right now is that this really is a technical adjustment (nobody who understands the problem/proposal thinks we are proposing new rules), but with every additional "Oh, and this other section", it risks sounding so complicated that we may get fear-driven opposition ("I can't support anything unless you show me exact wording changes" – followed inevitably by "Thanks for the exact wording changes, but I can't support this because it's too complicated to change so many separate pages at the same time"). Maybe we should consider an explicitly "in principle" proposal. WhatamIdoing (talk) 02:33, 21 August 2025 (UTC)[reply]
    In principle is fine by me and arguably simpler, as the exact wording (based explicitly on the interpretation of the consensus) can be devolved to local consensus. For here, it'd be no different than summarising any other consensus from RSN for example. Being thorough does not mean everything has to be complete(d). CNC (talk) 10:11, 21 August 2025 (UTC)[reply]
    Yes I agree, I've struck "reliable", that wasn't my intent. My intention was that if there's no obvious publisher, it is SPS. Void if removed (talk) 07:52, 21 August 2025 (UTC)[reply]
    @WhatamIdoing Per advertising the RfC (it's come up enough times including from me), I'm happy to notify relevant talk pages, purely so there is assurance that it will happen. Ping me and I'll do it, out of respect for the effort that has gone into developing this RfC. (It'd be lazy for me to push for an RfC and then be unwilling to notify editors). CNC (talk) 10:07, 21 August 2025 (UTC)[reply]
    Yes, it would have to be clear that by "publisher" we're talking about what on YouTube would be the officially identified channel of the publisher. So if it is on the BBC channel, the BBC are the publishers. If it is a clip from a BBC programme on some random user's channel, it isn't, and is self-published and probably a copyright violation. Void if removed (talk) 10:51, 21 August 2025 (UTC)[reply]
    The proposal will ultimately impact many different hosting sites. Maybe there should be less focus on specific sites, and more on the concept. -- LCU ActivelyDisinterested «@» °∆t° 22:27, 19 August 2025 (UTC)[reply]

    This is very good. I've slightly rewritten for brevity and clarity, but I have no intent to change the meaning.—S Marshall T/C 08:23, 17 September 2025 (UTC) [reply]

    Thanks for this. I've been thinking about expanding the first sentence: "are not individual WP:SOURCES, but digital platforms that host both reliable and unreliable sources".
    I've also been thinking about the "in principle" idea, and wondering if we ought to say something like "A digital platform is a website like YouTube that hosts content published by both traditional, reliable publishers and ordinary people. For example, YouTube hosts videos from traditional television news shows (which are reliable sources) and home videos of teenagers showing off their skateboarding tricks (which is not). In principle, should we differentiate between ordinary self-published and user-generated content (e.g., a Wikia Fandom site) and a digital platform (e.g., YouTube, which is used by traditional news outlets as well as self-publishing individuals)?"
    This might be too abstract for some people. WhatamIdoing (talk) 18:09, 17 September 2025 (UTC)[reply]
    Also, I don't think we should use Twitter/X as an example, because my impression is that most of our uses are for primary sources (e.g., Joe Film announced that he's engaged to be married), and the "but a tweet is not reliable SIGCOV IRS!!!1!" could be a distraction. WhatamIdoing (talk) 19:05, 17 September 2025 (UTC)[reply]
    Wordpress or Blogspot might be a good one; I remember participating in an AfD a few months back where we were deciding if a post by a history centre/museum/archival-type-project associated with a local university was reliable for a local history matter. The fact that they hosted part of their site on Blogspot was a deciding factor for one participant. GreenLipstickLesbian💌🦋 19:23, 17 September 2025 (UTC)[reply]
    I like that idea. Do we have a couple of good examples of that? WhatamIdoing (talk) 00:51, 18 September 2025 (UTC)[reply]

    Summary for The Washington Free Beacon

    [edit]

    Can someone explain why the discussions all say it is an unreliable, hyperpartisan newsblog, but the summary says "Most editors considered the Washington Free Beacon to have become generally reliable during the editorship of Eliana Johnson." Is there a missing discussion that has not been included, or did someone just sneakily change the summary without anyone noticing? ເສລີພາບ (talk) 19:32, 5 September 2025 (UTC)[reply]

    I found the missing discussion here, although it does not to me look like a consensus that they are generally reliable, but no consensus. Regardless, this discussion should be linked to on this page. ເສລີພາບ (talk) 20:27, 5 September 2025 (UTC)[reply]
    It was updated[1]. There are now two entries for the Free Beacon, which matches the consensus from the 2025 RFC (that is also already linked in both entries). -- LCU ActivelyDisinterested «@» °∆t° 22:13, 5 September 2025 (UTC)[reply]
    The link takes me to Wikipedia:Reliable_sources/Noticeboard#RFC_on_the_reliability_of_the_Washington_Free_Beacon which doesn't exist. The actual location is Wikipedia:Reliable_sources/Noticeboard/Archive_478#RFC_on_the_reliability_of_the_Washington_Free_Beacon. Now that I'm on my computer though I'm seeing a box showing up redirecting me to the archive. ເສລີພາບ (talk) 01:52, 6 September 2025 (UTC)[reply]
    The link has been updated to show it's been archived, you can fix that the page isn't protected. As with any other page on Wikipedia if it's broken the best solution is to WP:JUSTFIXIT. -- LCU ActivelyDisinterested «@» °∆t° 02:59, 6 September 2025 (UTC)[reply]
    Question #2 seems like consensus. Are you sure you're looking at that instead of Q1 on its status before Johnson? Aaron Liu (talk) 17:37, 6 September 2025 (UTC)[reply]

    WP warns against making defamatory remarks against living persons; yet here Matthew Continetti is characterized as unreliable based on collective editorial assessments of the website's practices and reputation during has editorship. Matthew Continetti is widely recognized as the founding editor and was editor-in-chief of the Free Beacon from its launch in 2012 until 2019. He is also known as a journalist and Director of Domestic Policy Studies at the American Enterprise Institute, with bylines in many reputable publications and authorship of books on conservatism and politics.73.157.112.234 (talk) 08:40, 30 September 2025 (UTC)[reply]

    Template:Press BRD

    [edit]

    Discussion at Talk:CNN#Template:Press_BRD, but the same revert happened on this talkpage, so if you have an opinon, please join. Gråbergs Gråa Sång (talk) 16:52, 6 September 2025 (UTC)[reply]

    New York Post

    [edit]
    This is a waste of time. The opinion of a single person is not going to overturn a community consensus on the issue. Any actual discussion related to the NYPost should be held at WP:RSN, not here where it is completely inactionable. Hemiauchenia (talk) 12:12, 11 September 2025 (UTC)[reply]

    The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    By excluding New York Post as a reliable source, this "consensus" affirms that editors here are biased against a politically conservative news organization, as many people already believe about Wikipedia.

    This policy should be reversed and each New York Post story should be judged on its own merits. Queens Historian (talk) 11:25, 10 September 2025 (UTC)[reply]

    No. Simonm223 (talk) 11:38, 10 September 2025 (UTC)[reply]
    Why? Queens Historian (talk) 16:48, 10 September 2025 (UTC)[reply]
    Please see the discussions that led to it being declared a deprecated perennial source. Simonm223 (talk) 18:15, 10 September 2025 (UTC)[reply]
    Specifically, there was a discussion about the NYP in 2020, and editors came to a consensus that it is generally unreliable as a source about politics, especially about New York City politics. nomen alternativum (he/him • talk • contribs) 18:20, 10 September 2025 (UTC)[reply]
    Thanks! I wasn't aware that there was a discussion in 2020 on this matter that resulted in this consensus. However, I dispute the policy in which "Even in cases where the source may be valid, it is usually better to find a more reliable source instead." That's simply discrediting the messenger even when the message is entirely accurate. I'd like this policy to change, so that New York Post can be used a source when it is accurate. Queens Historian (talk) 11:37, 11 September 2025 (UTC)[reply]
    Well good luck with that but I would not support such a policy change. We are strict with unreliable sources with good reason. Simonm223 (talk) 11:41, 11 September 2025 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Reflist is broken?

    [edit]

    Hey, if I go to Wikipedia:Reliable sources/Perennial sources#References, the reflist is broken. All I see is:

    Template:Reflist

    And nothing else. Not sure why. Endwise (talk) 09:21, 14 September 2025 (UTC)[reply]

    This is likely caused by hitting the template limit, something that's been discussed on the lists talk page before. Replacing {{reflist}} with <references/> allows some of the references to be seen but some are broken. The only long-term solution is to reduce the amount of templates in the article. -- LCU ActivelyDisinterested «@» °∆t° 10:21, 14 September 2025 (UTC)[reply]
    Yes, the page is in the hidden Category:Pages where post-expand include size is exceeded. I don't have time at the moment to investigate. Someone at WP:VPT might be able to help. A lot of content is included, for example with {{WP:Reliable sources/Perennial sources/1}}. An ugly fix might be get rid of those templates and put the content directly in the page. Johnuniq (talk) 11:02, 14 September 2025 (UTC)[reply]
    The transclusions are the result of the last attempt to fix the same issue. Using the reference tag rather than the reflist template shows that even #invoked cites aren't displayed correctly. -- LCU ActivelyDisinterested «@» °∆t° 19:26, 14 September 2025 (UTC)[reply]
    Transcluding was actually the opposite: It pushed us up against the PEIS limit and was done due to complaints of the editor taking a long time to load and browsers crashing when attempting to find the part to edit. Aaron Liu (talk) 19:51, 14 September 2025 (UTC)[reply]
    I'll try pruning the edit filter links and then the unused shortcuts. Aaron Liu (talk) 19:49, 14 September 2025 (UTC)[reply]

    Addressing hard template limits

    [edit]

    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:

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

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

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

    I mentioned pruning the excessive unused shortcuts that have been added in recent months above. Aaron Liu (talk) 11:24, 15 September 2025 (UTC)[reply]
    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)[reply]
    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)[reply]

    WaId's central list, and click to longer explanation

    [edit]

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

    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)[reply]
    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)[reply]
    What I'm thinking of would look more like this:
    On RSP itself, just a simple list with links:
    Sources
    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)[reply]
    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)[reply]
    [edit]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    arbitrary break

    [edit]
    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)[reply]
    Looks neat! SuperGrey (talk) 09:00, 21 September 2025 (UTC)[reply]
    @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)[reply]

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

    Wikipedia talk:Reliable sources/Perennial sources/Archive 10#Page size Aaron Liu (talk) 02:53, 16 September 2025 (UTC)[reply]
    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)[reply]
    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)[reply]

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

    Raladic's table options

    [edit]

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

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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
      Summary text deferred to ad-hoc loading by clicking on a "show summary" button
    • First summary loaded after the click
      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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    Mg's central list plus multiple landing pages

    [edit]

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

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    I also like this idea. Aaron Liu (talk) 22:30, 22 September 2025 (UTC)[reply]
    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)[reply]
    Also, some sort of ==See also== for related RSP entries. WhatamIdoing (talk) 15:55, 22 September 2025 (UTC)[reply]
    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)[reply]
    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)[reply]
    I've put together a mockup at Wikipedia:Reliable sources/Perennial sources/all/Deutsche Welle. WhatamIdoing (talk) 21:24, 25 September 2025 (UTC)[reply]
    @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)[reply]
    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)[reply]
    If we can't, we can't. Gråbergs Gråa Sång (talk) 19:01, 22 September 2025 (UTC)[reply]
    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)[reply]

    Infobox design

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

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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.
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]

    Showcasing different approaches

    [edit]

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

    Approach summary

    [edit]

    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:

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

    Yikes, four bytes left

    [edit]

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

    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)[reply]
    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:
    ---
    ---
    and then get busy splitting things up and repointing the shortcuts? WhatamIdoing (talk) 00:17, 28 September 2025 (UTC)[reply]
    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)[reply]
    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)[reply]

    One giant table approach

    [edit]

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

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

    Implementation planning

    [edit]

    @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)[reply]

    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    Yes, that is one part of the iterative approach below. Mathglot (talk) 23:43, 30 September 2025 (UTC)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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 (document 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)[reply]
    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)[reply]

    Row-builder module approach

    [edit]

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

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

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

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

    Request to revise Army Recognition entry – defamatory & unsourced

    [edit]
    Moved to Wikipedia:Reliable sources/Noticeboard § Request to revise Army Recognition entry – defamatory & unsourced
     – Aaron Liu (talk) 18:32, 17 September 2025 (UTC)[reply]

    Blanket suppression of stale

    [edit]

    @AKK-700 The instructions say considered generally unreliable for being self-published or presenting user-generated content are excluded, not automatically all GUnRel sources. Regardless, please WP:BRD. (Sorry if this is WP:BITEY, I just don't have much time to compose a message right now.) Aaron Liu (talk) 02:12, 19 September 2025 (UTC)[reply]

    It doesn't cover biased, fake news, opinion, or satire news websites, defunct websites, sites that copy content from other sources, blacklisted sites, or articles from websites before their reliability changed (like Newsweek pre-2013). AKK700 02:52, 19 September 2025 (UTC)[reply]
    Is there consensus for any of these options except "from before their reliability changed" anywhere? Aaron Liu (talk) 12:04, 19 September 2025 (UTC)[reply]
    I understand that it is current practice that sources unlikely to change status (say, due to their abysmal reputation) get this suppressed. But that doesn't seem to be the case with most of the sources you suppressed stale for. The Western Journal is also none of the above. @AKK-700 I'll be reverting this tomorrow while we discuss. Aaron Liu (talk) 00:10, 20 September 2025 (UTC)[reply]

    CBR

    [edit]

    How can I add Comic Book Resources to the list? ~Rafael (He, him) • talk • guestbook • projects 02:38, 20 September 2025 (UTC)[reply]

    Please see Wikipedia:Reliable sources/Perennial sources#What this page is. This is not supposed to (and due to technical limits, should not) be a list of every source but rather just the most frequently discussed. You should seek other Category:WikiProject lists of reliable sources to add sources to. Aaron Liu (talk) 04:01, 20 September 2025 (UTC)[reply]
    Does it meet WP:RSPCRITERIA? Per Wikipedia:Reliable_sources/Noticeboard/Archive_487#Reliabilty_of_Comic_Book_Resources_(CBR) there is some previous discussion, but not very much. Fwiw, it's on WP:GAMESOURCES. Gråbergs Gråa Sång (talk) 07:57, 20 September 2025 (UTC)[reply]
    I replied on Rafael's talk page – per WP:VALNET, it's reliable up to 2016. ClaudineChionh (she/her · talk · email · global) 09:56, 20 September 2025 (UTC)[reply]

    YouTube

    [edit]

    The entry for YouTube blends an exception for reliable content into the "generally unreliable" rating:

    • "Content uploaded from a verified official account, such as that of a news organization, may be treated as originating from the uploader and therefore inheriting their level of reliability."

    That should be listed separately with a big "Exception" heading and different color. -- Valjean (talk) (PING me) 14:37, 21 September 2025 (UTC)[reply]

    @Valjean See the Wikipedia talk:Reliable sources/Perennial sources/Archive 12#YouTube is not a source and Wikipedia talk:Reliable sources/Perennial sources#Drafting the RFC question about platforms sections above. Aaron Liu (talk) 16:22, 21 September 2025 (UTC)[reply]
    That's an awful lot of discussion. Does it disagree with the current wording?
    • "Content uploaded from a verified official account, such as that of a news organization, may be treated as originating from the uploader and therefore inheriting their level of reliability."
    If not, then I don't see any problem with just splitting the YouTube portion into a "generally unreliable" pink box and a box that cites ""Content uploaded from a verified official account, such as that of a news organization, may be treated as originating from the uploader and therefore inheriting their level of reliability." That portion should not be buried within "generally unreliable". That's where all these are buried, without naming them, because they all have official "verified" YouTube accounts: Reuters, AP, BBC, AFP, ABC News, NBC News, CBS News, USA Today, Bloomberg News, etc. -- Valjean (talk) (PING me) 19:57, 21 September 2025 (UTC)[reply]
    It does disagree. The plan is to propose making all platforms their own category as the issue also extends to e.g. Wordpress. Aaron Liu (talk) 20:22, 21 September 2025 (UTC)[reply]
    In our ample free time... I apologize for not doing my part to keep this moving forward. I agree that it's a problem that we need to address.
    @Valjean, I think the view of YouTube is kind of three things:
    • Home videos, someone's favorite 10-second clip from a movie, ordinary-user-type content: Mostly don't use it/approximately the same rules as someone's personal blog (including same rules for personal blogs that violate copyrights).
    • YouTube's own 'infrastructure', e.g., "Had 30,000 likes as of 2024": Don't use it/we don't like it and think it could be faked.
    • Official verified accounts of reliable sources: It's just fine. We actually don't care where Reuters, AP, BBC, etc. post their content; that content's reliable because they're Reuters, AP, BBC, etc. and not because of the domain name shown in your browser.
    The first and last are the 'platform' ones. The middle one is a WP:PRIMARY source that would be theoretically okay for WP:V purposes except we (apparently) reject it anyway (think it WP:UNDUE by default?). WhatamIdoing (talk) 23:49, 21 September 2025 (UTC)[reply]

    Semi-automating template RSPLAST

    [edit]

    Currently, the date value passed to template WP:RSPLAST is hand-curated, and subject to going out of date, or to data entry error. This could be partly automated, based on a proposed module that would return the timestamp of the most recent comment in a set of given discussions. To my knowledge, there is no module that currently does this, but archiving bots already do something very like this; for example, Lowercase sigmabot calculates max(stamps) in function parse_stamps. If such a module is forthcoming, we could replace the current invocations of WP:RSPLAST with a new template which would return the latest date given the list of discussions already present in the list column. It still depends on that list being kept up to date manually, which is why it is semi- and not completely automated, but it will still save work going forward, and minimize errors. P.S., If we invoked the module directly instead of through a wrapper template, that would save us several hundred template expansions in the table, and thus gain us a little breathing room regarding PEIS capacity, as discussed § above. Mathglot (talk) 01:50, 23 September 2025 (UTC)[reply]

    @DLynch (WMF), is there an API or something that would let a script/bot grab the date (at least year) of the most recent comment in a discussion? The input would be a link to, e.g., Wikipedia:Reliable sources/Noticeboard/Archive 371#Deutsche Welle, and the thing we want back is the thing that produces "Latest comment: 3 years ago" in DiscussionTools. WhatamIdoing (talk) 00:21, 28 September 2025 (UTC)[reply]
    Ideally, something usable via template (i.e., most likely a module, rather than a user-script which is not template-accessible). The idea is not to limit this to conversion, for which a bot or script would be fine, but to become an integral part of the table (or whatever approach is chosen) so that you have a new template that does {{latest comment|discussion-1|disc-2|disc-3}} and it returns the date (or year) of the most recent comment in the given discussions. (The output of that could be used as input to a staleness-calculator that would remain up-to-date live, as opposed to the current implementation as the very rough, < 4 years or > 4 years binary measure, which is entered manually on the page and becomes inaccurate with the passage of time.) Mathglot (talk) 00:40, 28 September 2025 (UTC)[reply]
    Not trivially right now -- though there's a patch that'll be going out on WP:ITSTHURSDAY which will add it to the headings in the DiscussionToolsPageInfo threaditemshtml API output. DLynch (WMF) (talk) 15:44, 29 September 2025 (UTC)[reply]
    (The patch just gives you some convenient summaries in the API response. You could right now compute all that yourself from it, it'd just be more work.) DLynch (WMF) (talk) 15:45, 29 September 2025 (UTC)[reply]
    Thanks! WhatamIdoing (talk) 18:21, 29 September 2025 (UTC)[reply]

    Smile, you are on twitter!

    [edit]

    Larry Sanger spills the beans to Tucker Carlson: https://x.com/JasonJournoDC/status/1972769213644173385. -- Kautilya3 (talk) 19:31, 30 September 2025 (UTC)[reply]

    You're better off sniffing glue than watching those two fawn at each other. Headbomb {t · c · p · b} 19:42, 30 September 2025 (UTC)[reply]
    Reporting you for egregious violations of Wikipedia's civility policies. Do better, dude. 2601:600:817F:B270:E074:533E:91D4:833D (talk) 20:51, 30 September 2025 (UTC)[reply]
    No lies (nor incivility) detected. Bearian (talk) 21:46, 30 September 2025 (UTC)[reply]
    A "community note" (a twitter fact-checking mechanism) proposed for the post cites this article for arguing that black-listing sources leads to bias. https://www.emerald.com/oir/article/48/5/908/1220830/Polarization-and-reliability-of-news-sources-in -- Kautilya3 (talk) 09:29, 1 October 2025 (UTC)[reply]

    Sanger has also started arguing that Wikipedia is anti-Hindu, citing one of the black-listed sources. The source actually calls it "anti-India". https://x.com/lsanger/status/1973048318373577121 -- Kautilya3 (talk) 09:32, 1 October 2025 (UTC)[reply]

    There's many valid criticisms of Wikipedia, and then there's Larry Sanger. -- LCU ActivelyDisinterested «@» °∆t° 11:10, 1 October 2025 (UTC)[reply]

    There are now 2 Template:Press on this talkpage

    [edit]

    That's not a mistake, they have a limit of 30 items. Gråbergs Gråa Sång (talk) 07:52, 1 October 2025 (UTC)[reply]

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Reliable_sources/Perennial_sources&oldid=1314787707"