🇮🇷 Iran Proxy | https://www.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Restructuring_RSP
Jump to content

Wikipedia:Requests for comment/Restructuring RSP

Add links
From Wikipedia, the free encyclopedia
Shortcut

RFC

[edit]
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

While the RFC has not ran a full 30 days, I felt that a consensus has emerged early enough to warrant an early closure. I find a clear consensus for RSP to become a list of subpages. There were fairly few dissenting !votes in this RFC (30 - 4) with no shared rationale among them (one !voted for the big list, two argued for a reduced scope to RSP, and one suggested to start over). The two primary reasons that participants in the RFC gave for breaking RSP up into subpages was for accessibility, and for being a more permanent solution compared to the other two alternatives. However, it does seem that there were a few participants that gave further suggestions to what these subpages should look like, which to me (as the closer) suggests that the community would benefit from more time to figure out how these RSP subpages should function. What I suggest in my capacity as the closer is for the community to workshop the RSP subpages format in order to gain consensus on a detailed proposal for what this alternative will look like.

I am fully aware of this being a rather bold closure impacting an important page on Wikipedia, so if anyone has any questions about this, please feel free to ask me about them. Gramix13 (talk) 05:43, 5 November 2025 (UTC)[reply]

    ↑ To top of page
    Shortcut

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

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

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

    Details

    [edit]

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

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

    If more than one approach seems acceptable to you, then for the convenience of the eventual closer, we suggest naming your first choice and a second choice. WhatamIdoing (talk) 22:45, 20 October 2025 (UTC)[reply]

    Discussion and questions

    [edit]

    @GothicGolem29 The One Giant Table approach is not the only approach that would visually appear as one sortable table. For one, the status quo is closest to the Row-builder module approach (yet is NOT at all like the One Giant Table approach save appearance), and the Row-builder module approach would look like what we have now. The One Giant Table is so named because all of the wikitext would be within the same section. Try editing WP:RSPGIANT to see what I mean. (Not sure what you mean by "bar with letters".) Aaron Liu (talk) 02:24, 21 October 2025 (UTC)[reply]

    What I meant by bar with numbers is the bar with contents that lists a to z and if you click on for example a and it takes me to the sources that start with A. The giant module example has that the other table one doesn't. I appreciate what you say about the other table being well a table however so I will modify my answer(via strikethrough)to explain why I prefer the giant table over the module one(I also prefer the giant one due too how long it will last for compared too the other table one.) GothicGolem29 (talk) 02:37, 21 October 2025 (UTC)[reply]
    GothicGolem29, I understand you to be talking about the lack of a compact, horizontal table of contents above the table in the row-builder approach, is that right? This rfc is about which general approach is best, among several that have different pro's and con's. It is not about the exact appearance of any of the approaches, which could be different than the demos linked here. In particular, it is trivial to add a compact horizontal ToC above the table in the row-builder approach, and whether the current demo version of it has one or doesn't is a presentation detail that should not influence your choice of option. Mathglot (talk) 17:27, 21 October 2025 (UTC)[reply]
    Yes I am. Wouldn't adding that contents table in after this RFC require consensus though? Which if it did then editors might decide against that. GothicGolem29 (talk) 18:05, 21 October 2025 (UTC)[reply]
    No, people are generally very reasonable about these things. Anyone can put {{compact ToC}}, which looks like this: on any page where it seems useful. That's just ordinary editing. WhatamIdoing (talk) 18:09, 21 October 2025 (UTC)[reply]
    GG, you could just be bold and add one. If that caused strife, you could start an Rfc about it, but that seems vanishingly unlikely. In any case, it should be clear that in this Rfc, presentation details are not part of it. Hope this clarifies, Mathglot (talk) 18:32, 21 October 2025 (UTC)[reply]
    Thanks for the answer this is helpful. I dont know how to make one at the moment so I wont do a bold edit but given your assurances I will strike that part of my !vote so my !vote is based on my other reasons not that. GothicGolem29 (talk) 22:37, 21 October 2025 (UTC)[reply]
    Just to be clear, I don't want you to change your preference. I just don't want you to worry that the missing horizontal Table of Contents is a deliberate or necessary choice. We're having this RFC now so we can figure out which one of the three designs to polish up later. It's too much work to build them all, when only one will be used/maintained. WhatamIdoing (talk) 22:45, 21 October 2025 (UTC)[reply]
    Ok fair enough I didn't think you were thanks for easing my worries on the contents bar. GothicGolem29 (talk) 22:51, 21 October 2025 (UTC)[reply]

    Fourth approach?

    [edit]

    How about converting this table to a single-column page with each source having its own section? So it will be something like

    Sources
    112 Ukraine
    Shortcut

    Generally unreliable Generally unreliable: 112 Ukraine was deprecated following a 2019 RfC, which showed overwhelming consensus for the deprecation of a slew of sources associated with Russian disinformation in Ukraine. It was pointed out later in a 2020 RfC that 112 Ukraine had not been explicitly discussed in that first discussion prior to its blacklisting request. Further discussion established a rough consensus that the source is generally unreliable, but did not form a consensus for deprecation or blacklisting. The prior blacklisting was reversed as out of process. 112 Ukraine was shut down in 2021; website content is no longer accessible unless archived.

    Discussions

    Last: 2020

    Use

    1 Links Spamcheck
    2 Links Spamcheck

    . sapphaline (talk) 14:32, 21 October 2025 (UTC)[reply]
    @Sapphaline, does that use fewer templates? If not, then it won't solve the problem. WhatamIdoing (talk) 18:06, 21 October 2025 (UTC)[reply]
    It doesn't use tables. sapphaline (talk) 18:45, 21 October 2025 (UTC)[reply]
    The crux of the problem is WP:PEIS, not table length specifically. Have a look at Help:Template limits. Mathglot (talk) 18:53, 21 October 2025 (UTC)[reply]
    The example above has a post-expand include size of 3246 bytes, excluding fake heading templates. If there are rougly 500 entries in RSP, and we assume that all other sections would have the same post expand include size and they all are on the same page, rather than being transcluded, that's a PEIS of 1.6 MB, which would allow rougly 120 more entries to be added.
    Though I don't see any good reason to wrap all these , etc. icons and links to relevant RfCs into templates, so they can just be substituted; in that case, my example above will have a post-expand include size of 2501 bytes, reducing the total to 1.25 MB, and allowing rougly 340 more entries to be added. sapphaline (talk) 19:22, 21 October 2025 (UTC)[reply]
    120 more entries = 2.4 years, which is less than any of the proposed options. 340 more entries = 6.8 years, assuming that editors agree to stop using those templates (historically an unlikely outcome in practice, as someone a few years from now will probably try to "simplify" the page by creating templates, without knowing why they aren't used).
    Is there anything about this idea/layout that you like for non-technical reasons? WhatamIdoing (talk) 21:45, 21 October 2025 (UTC)[reply]
    Is there anything about this idea/layout that you like for non-technical reasons? - easier navigation (all sources are available in the ToC) and mobile friendliness. sapphaline (talk) 08:42, 22 October 2025 (UTC)[reply]
    I don't think the ToC would be any easier to navigate than the list of links in the list of subpages approach. Aaron Liu (talk) 11:05, 22 October 2025 (UTC)[reply]
    I hadn't thought about the effect on the Table of Contents.
    I wonder if the ToC would be so long that editors (especially those using the older skins, like Vector 2010 and MonoBook) would replace it with an alphabet-only ToC, so that they don't have to scroll past 500 ToC entries to get to the end of the ToC. The section heading levels would end up being ==Sources==, ===A===, ====Agence France-Presse (AFP)====, and only the first two would be displayed in the ToC. WhatamIdoing (talk) 19:29, 22 October 2025 (UTC)[reply]
    Or suppress it and just use {{Compact TOC}}. Mathglot (talk) 23:35, 23 October 2025 (UTC)[reply]
    3246 is pretty much the same PEIS as what we have per entry right now. Structurally, this is essentially the One Giant Table approach but with sections.

    Though I don't see any good reason to wrap all these , etc. icons and links to relevant RfCs into templates

    Same as most templates: It's much easier when we need to change them, as is currently the subject of an unrelated RSP proposal. Aaron Liu (talk) 21:46, 21 October 2025 (UTC)[reply]
    Though I prefer giant table this would be better than the subpages one as it notes the reliability next to the sources. GothicGolem29 (GothicGolem29 Talk) 15:17, 31 October 2025 (UTC)[reply]

    Could it use a category?

    [edit]

    As a variant on the list of subpages approach, what would be the limitations on making WP:RSP a category page, rather than a list? In article space, a list that long would, by my understanding, probably be replaced with a category for ease of navigation; this would allow subcategories and so forth and would also eliminate the "editors have to remember to add each new source to the list" issue. I'm sure there are some obvious downsides I haven't thought of though. lp0 on fire () 09:02, 24 October 2025 (UTC)[reply]

    At WP:RSPINDEX, I can ctrl-f and find any entry. I can't do that at for example Category:American billionaires. I assume the finished index page will contain all the not-list stuff, which a cat-page won't (technically it could, I guess, but it'd be weird.). There is no harm I can see in having a cat-page as well. Gråbergs Gråa Sång (talk) 10:38, 24 October 2025 (UTC)[reply]
    @Lp0 on fire, I think this would end up being a both/and situation. Cat: pages don't display more than 200 pages, so you can't ⌘F to the whole contents at once. But they are useful for other things (e.g., you can put redirects in a category), and of course the pages will want some categories. WhatamIdoing (talk) 15:13, 24 October 2025 (UTC)[reply]
    Ah that makes sense. Could there be some way of getting a bot to automatically add every page in the category to the list, or at least to find discrepancies between the two and list them for checking by a human? I don't know much about how coding for Wikipedia works, but that feels like it could make the editing experience a bit easier. lp0 on fire () 16:23, 24 October 2025 (UTC)[reply]
    I'm optimistic that a lot of the conversion and routine maintenance could be automated. WhatamIdoing (talk) 17:22, 24 October 2025 (UTC)[reply]
    User:Lp0 on fire, iiuc, you want a bot to create a link in WP:RSPINDEX if there is an item added to a category, is that right? This isn't necessary, as the reverse is possible semi-automatically without a bot, at least in one possible implementation. That is, as soon as one of the table rows is converted into a landing page under one of the presentation methods, such as the one at Bloomberg, the categories are generated automatically. If you are interested in the technical details, the semi-automatic conversion by regex creates an instance of {{Infobox source reliability}}, and code in the infobox creates the categories. So instead of creating Index links from the categories, it creates categories from the Index links. That begs the question about how a row should be converted—maybe that's where a bot might come in—but that is outside the scope of this Rfc. Mathglot (talk) 20:39, 25 October 2025 (UTC)[reply]
    I don't pretend to understand the technical implementation, but I think(?) your reply is about converting the current table rows into the new list format en masse. I was referring to the process of expanding the list in future, since having to create a page and then also add it to the list was raised as one of the potential downsides. If I'm just completely clueless let me know and I'll shut up. :) lp0 on fire () 21:56, 25 October 2025 (UTC)[reply]
    Categories are added to a page by linking to them. Templates such as InfoboxSourceReliability can output links. Aaron Liu (talk) 01:18, 26 October 2025 (UTC)[reply]
    Sorry, I'm being incredibly unclear (it really doesn't matter but I'm going to try to explain anyway). In the original list of potential downsides of the list of subpages approach, it was suggested that it might be inconvenient to have to create each page and then also add it to the list. My point is: since it's so easy to add pages to a category, could the process of making sure the list follows suit from the category be automated? It's a pretty minor inconvenience that would be avoided, but I'm still suggesting this on the off chance that it's feasibly worthwhile. lp0 on fire () 08:46, 26 October 2025 (UTC)[reply]
    No need apologize; your suggestions are welcome here. Whether it's worth writing a bot to add one link per new landing page is debatable, but if the List of subpages approach is chosen, there will be further discussion after it closes about how to implement it, and that would be a good time to raise your suggestion again. Mathglot (talk) 18:37, 26 October 2025 (UTC)[reply]
    Thanks. I only suggested it here as the issue was listed in the downsides to consider when choosing an option. lp0 on fire () 21:16, 26 October 2025 (UTC)[reply]

    Project-specific source lists

    [edit]

    ZKang123, in your !vote above, you mentioned WikiProject Korea and others having their own list of reliable sources. That is good to know, and led me to the the 147 sources in the table at WP:KOREA/S#Sources. This is mostly off-topic for this Rfc, but there could be some synergy after it commpletes, as the List of subpages approach could easily accommodate project-based list like the Korea-based one as a subset (i.e., with its own index page, and pointing to landing pages in a different directory than the one WP:RSPINDEX currently uses, for example, WP:Reliable sources/Perennial sources/Korea or the current location). This would be worthwhile revisiting when the time comes. Thanks for raising this, and if you know of other projects that have their own reliable sources listing, please link or list them. Thanks, Mathglot (talk) 04:52, 30 October 2025 (UTC)[reply]

    There's also WP:JAPAN/RS. I think this category shows most of the lists outside of the RSP list.--ZKang123 (talk · contribs) 07:16, 30 October 2025 (UTC)[reply]
    I would not move the other sources as subpages of RSP because they are not perennial sources. Aaron Liu (talk) 11:29, 30 October 2025 (UTC)[reply]
    If the index page also collated (or "see-also"d) other source evaluations (without necessarily moving them), that would be really helpful. Here's two I happened to have links to (the NPP one provides recommendations for regional sources):
    Schazjmd (talk) 17:37, 30 October 2025 (UTC)[reply]

    Survey

    [edit]
    • I prefer the list of subpages, because I never want to deal with this problem again. Overall, I don't have strong opinions about the design of the individual subpages, but it's important to me that the list itself provide the links without commentary: people should be able to easily find sources in the list, but it should be just a plain link without further information (only, e.g., "* Daily Mail" and not "* Daily Mail (deprecated) or with color coding). Editors should have to go to the page with all the details to find out more, because we have nuanced views on many sources (e.g., "WP:GREL except for ____" – if an editor doesn't look past a simplistic summary, they'll get it wrong). WhatamIdoing (talk) 23:27, 20 October 2025 (UTC)[reply]
    • One Giant Table The Giant table allows for scrolling down and seeing other sources reliability which I have found useful in the past (while having the bar with letters which helps get too sources easier if people want that.)The Giant table is better than the index because the giant being able to scroll down which is useful in seeing other sources ratings while looking for the source you want. It is better than modula option because that one does not have the contents bar plus it will last less time than the giant table it will last longer than the modula option.GothicGolem29 (talk) 01:14, 21 October 2025 (UTC)[reply]
    • List of subpages per nom. This is also the only listed approach that would fix the VE problem FWIW.
      This is also the only listed approach that is not visually similar to the table we have right now, but it shouldn't be too hard to make a toolforge site that generates such a table from all the subpages. Aaron Liu (talk) 02:27, 21 October 2025 (UTC)[reply]
    • List of subpages per WAID et al. · · · Peter Southwood (talk): 15:59, 21 October 2025 (UTC)[reply]
    • List of subpages. Essentially a permanent solution, so no reason not to go with this one. I'm not too concerned with RSP looking substantially different if the benefits far outweigh this. SmittenGalaxy | talk! 18:02, 21 October 2025 (UTC)[reply]
    • List of subpages. I admit that I like being able to see all of the listings and colors in one glorious scroll as kind of a gestalt of the WP community's positions on reliability, but in practical terms, it's visually a mess and I find it unusable without ctrl+F. The simplicity of being able to read all about a single source on one page and being able to document all of the nuances of the discussions without concern for row size are huge advantages of the subpage approach. It will avoid the problem of a single source having multiple row entries that an editor might overlook after finding the first one (I've done that, not realizing at first that there was more than one row for Rolling Stone). It also addresses the technical size issue with templates. Schazjmd (talk) 22:14, 21 October 2025 (UTC)[reply]
      I think the glorious scroll would be achievable though JavaScript?  — 魔琴 (Zauber Violino) [ talk contribs ] 13:03, 22 October 2025 (UTC)[reply]
    • List of subpages but only if some kind of summary (preferably color coding) is provided on the main page. Yes, there is a lot of nuance that would be lost if you don't look at the subpage, but often what I'm trying to find is if it's a legitimate source or one I definitely can't use. I don't want to have to click through to find the most basic info. (t · c) buidhe 02:44, 22 October 2025 (UTC)[reply]
      @Buidhe, if that's not an option, what's your second choice? WhatamIdoing (talk) 02:56, 22 October 2025 (UTC)[reply]
      OGT would also be fine with me. (t · c) buidhe 03:00, 22 October 2025 (UTC)[reply]
      @Buidhe, if you don't want to read the details, why not just use m:Cite Unseen? Saves you the time to even open the RSP index page. (Self promotion XD) SuperGrey (talk) 10:12, 22 October 2025 (UTC)[reply]
    • List of subpages per long-term. Gråbergs Gråa Sång (talk) 04:13, 22 October 2025 (UTC)[reply]
    • There probably needs to be some workshopping/RFCs on the exact design of the main and subpages such as providing simple, at a glance information and better organization on the subpages (e.g. the CNET old box is more informative then the mock-up summary/infobox, lack of search for RSN discussions) but the best option seems to be a list of subpages in the long run. -- Patar knight - chat/contributions 07:03, 22 October 2025 (UTC)[reply]
      Yes, the point of this discussion is to pick one of the three models for further development. We've mocked up a couple so far, but no decisions have been made. Anyone who is interested in helping with that process (whichever concept is preferred in the end by this discussion) should feel welcome to join in on that work. WhatamIdoing (talk) 19:43, 22 October 2025 (UTC)[reply]
      Do you see the three CNET discussion search links in the Infobox on the mocked up CNET landing page? But they don't have to be in the Infobox, and there doesn't even have to be an Infobox at all—this was just one way to mock it up as a demo of what's possible. As WaId said above, all the presentation details are for later. Not sure what the "CNET old box" is. Mathglot (talk) 00:32, 24 October 2025 (UTC)[reply]
    • Reduce scope We should only be tracing deprecated sources. WP:GREL and WP:GUNREL have reduced the quality of our sourcing standards overall by allowing people to treat sources as universally reliable without considering context. Simonm223 (talk) 11:59, 22 October 2025 (UTC)[reply]
      Citation needed · · · Peter Southwood (talk): 14:00, 22 October 2025 (UTC)[reply]
      You may not believe me but it's what I've observed. I sincerely think we should be avoiding general reliability standards in favour of looking at sources in context. I have faced issues with blanket use of GREL sources in BLPs for material that is likely undue and not suitable for BLP purposes. I will be honest that its interaction with BLP is the specific locus of my concern. Simonm223 (talk) 14:36, 22 October 2025 (UTC)[reply]
      I was hoping there would be some research to support the claim. I have no opinion myself. · · · Peter Southwood (talk): 15:43, 22 October 2025 (UTC)[reply]
      There's a (somewhat) related conversation at Wikipedia:Village pump (idea lab)#More emphasis towards the content of sources being the most important. that might interest you two. The newcomer has written an essay decrying a tendency at AFD to say that if the sources are GREL, then the subject is notable, without checking to see whether the source contains more than a passing mention of the subject. WhatamIdoing (talk) 19:39, 22 October 2025 (UTC)[reply]
    • List of subpages - I really like the accessibility of RSPINDEX, it doesn't just help editing but it also helps viewing. ~ Matthewrb Get in touch · Breadcrumbs 14:31, 22 October 2025 (UTC)[reply]
    • I like the list of subpages proposal. Any change has tradeoffs, and a major change can be especially daunting, but in my personal opinion no longer being limited to table rows is a big plus, and would be an overall improvement even without considering the technical issue. That it also solves the issue in the long term seals the deal. Alpha3031 (t • c) 17:00, 22 October 2025 (UTC)[reply]
    • List of subpages as a permanent solution to the problem. Frankly I'm not the biggest fan of the current table and think it has some accessibility concerns in addition to the technical concerns raised. I believe that if Category:Perennial sources deemed generally reliable and related categories are included, they should probably be maintained by a bot if possible. mdm.bla 19:51, 22 October 2025 (UTC)[reply]
    • List of subpages for permanent solution reasons. --GRuban (talk) 21:01, 22 October 2025 (UTC)[reply]
    • List of subpages personally I prefer one being table, but it has issues beyond just the technical ones. The 'list of pages' is a permanent solution to the technical difficulties, and maybe editors will be more inclined to read the entries if they have to click through to see them. Also RSPINDEX is very accessible. -- LCU ActivelyDisinterested «@» °∆t° 21:51, 22 October 2025 (UTC)[reply]
    • List of subpages as per the concerns by WhatamIdoing and Gråbergs Gråa Sång. This should resolve any technical difficulties. sjones23 (talk - contributions) 03:32, 23 October 2025 (UTC)[reply]
    • List of subpages. Good solution, addresses the problem adequately. Better on mobile.—Alalch E. 08:16, 23 October 2025 (UTC)[reply]
    • List of subpages. Cleaner look for accessibility and much more sustainable long-term. CNC (talk) 13:12, 23 October 2025 (UTC)[reply]
    • List of subpages per all above. Also makes it easier to address when we cross this bridge again in the future, as we can simply subdivide into more subpages. The Kip (contribs) 17:45, 23 October 2025 (UTC)[reply]
    • List of subpages (+ comment) for all the reasons above I think this is a great idea as a permeant solution, even at the cost of a major design simplification. I do have a question though if anyone is able to answer it, but is there anyway we could put each sources current reliability symbol (gen reliable, depreciated, blacklisted, etc.) beside their wikilink instead of the paper icon which is currently there (or in addition to it?). This way you can tell just at a glance what each sources reliability is without having to click on each link, which would save viewers time if they're trying to determine the reliability of a number of sources on a page (for example, in something like a new article review). This is the only change I would make to the current mock-up of the list of subpages, cheers! Johnson524 18:31, 23 October 2025 (UTC)[reply]
      Me and Whatam are so far pretty against that, as RSP already has a problem of editors only seeing the 4-tier status and disregarding the summary's content and nuanced advice, which is required reading, especially with the MRel (yellow) status. Aaron Liu (talk) 21:08, 23 October 2025 (UTC)[reply]
      Don't quote me, but my understanding is that we want to encourage users to look at the full picture and draw their own conclusions from sometimes discordant or subtle opinions about a source, including opinions that might apply to one type of article at the source, but not another type. Adding such an icon would do the opposite, and encourage a lazy adoption of a unsubtle and vastly oversimplified single datapoint as representative of the source as a whole. For an extreme version of this viewpoint, see the opinion below @20:44. (By the way: the "paper" icon at WP:RSPINDEX is *not* part of the Rfc proposal; it is only a device to help navigate the demo.) (edit conflict) Mathglot (talk) 21:12, 23 October 2025 (UTC)[reply]
      @Johnson524: Try m:Cite Unseen. Would suit your need in a new article review. SuperGrey (talk) 01:11, 24 October 2025 (UTC)[reply]
      @SuperGrey: That feature is extremely cool, thank you for introducing me to that! Also I appreciate the words of advice about the required readings @Aaron Liu and @Mathglot, and I agree that the attached readings should be read by all, however, I also know that a number of viewers will just click on the wikilink and look at only the icon anyways. Like you briefly mentioned, I'm sure everyone behind this proposal has already thought about this: but by including the icons it at least makes the process more convenient for everyone, even if some are going to do the wrong thing anyways, without the enshitification that comes from making this feature intentionally less accessible. That’s just my thought though, and I understand if not including them is what you eventually decide on. Cheers! Johnson524 01:46, 24 October 2025 (UTC)[reply]
      Providing a method of seeing the icon, with no chance of even accidentally seeing other relevant information, is a way of guaranteeing that some editors will "do the wrong thing". WhatamIdoing (talk) 04:55, 24 October 2025 (UTC)[reply]
    • What I'm seeing first with the List of common misconceptions and now here is that the technical limits on transclusion should be increased. In both cases, a big part of the page's utility is/was the fact that it is one big page that you can point to that has the answer. It's not the 2000s anymore; computers have gotten a lot more powerful and yet we're still stuck with these outdated technical restrictions. —pythoncoder (talk | contribs) 18:53, 23 October 2025 (UTC)[reply]
      Good luck with that suggestion. Cheers, · · · Peter Southwood (talk): 07:34, 26 October 2025 (UTC)[reply]
      Yeah, right now the WMF seems to be too busy disqualifying Board candidates and going on AI-related wild goose chases to do boring-but-important work like that. Same as it ever was. (And how many years has the graph extension been broken now?) —pythoncoder (talk | contribs) 16:58, 30 October 2025 (UTC)[reply]
      It wasn't meant to be fixed, but replaced with the new Chart extension, which released December 2024. Aaron Liu (talk) 14:21, 31 October 2025 (UTC)[reply]
    • Blow it up and start over, except don't start over, per WP:THESIS3: "The page is ideologically one-sided and essentially blacklists disfavored media outlets. Wikipedians now treat this list as strict— but unofficial—policy. This approach must be reversed." Say what you will about Sanger's rationale, this would be, by far, the easiest solution to implement from a technical standpoint. Tioaeu8943 (talk) 20:44, 23 October 2025 (UTC)[reply]
      Disregarding Sanger's rationale as you request, why should we take this easy way out? Aaron Liu (talk) 21:03, 23 October 2025 (UTC)[reply]
      I do not request it - THESIS3 should be considered seriously. To answer the spirit of the question, though, WP:DYNAMITEing RSP would be a positive-sum outcome for both the editors who don't like the page for technical reasons and the editors who don't like it for policy reasons. Tioaeu8943 (talk) 21:16, 23 October 2025 (UTC)[reply]
      I don't think anyone's against the page for technical reasons to the point where they think it's worth deleting it. On the Theses' merits, I would refer to Consarn's comments on it. Aaron Liu (talk) 21:22, 23 October 2025 (UTC)[reply]
      If someone wants to suggest applying Larry's thoughts somewhere, they can do so in the proper places, like Wikipedia_talk:Ignore_all_rules#Should_IAR_be_overturned?. This rfc is not about that, and any discussion on it here is fairly pointless. Gråbergs Gråa Sång (talk) 06:48, 24 October 2025 (UTC)[reply]
      If someone is barging into unrelated discussions saying Carthago delenda est they probably know exactly what they're doing. Alpha3031 (t • c) 08:28, 24 October 2025 (UTC)[reply]
      I just have to say here that I knew what that meant without looking it up. I think I first encountered it in a Asterix comic. Gråbergs Gråa Sång (talk) 10:48, 24 October 2025 (UTC)[reply]
      The major issue with this is that it the discussions, and consensus in those discussions, would still exist but would just be harder to find. RSP is just a log of prior discussions, all those discussions would still exist in the archives and edit histories. And noone, especially not Snagar, has ever shown that sources of a certain political leaning have ever been treated differently. What they have done is count the results into camps based on their own biases, and stated (without proof) that it shows some kind of hidden malicious action. But different media organisations behave differently, their is no reason to believe that all such organisations divide by their perceived political leaning will all behave the same. In fact such an idea is ludicrous. So as they behave differently they are treated differently, not to do so because of their political leaning is a terrible idea. -- LCU ActivelyDisinterested «@» °∆t° 18:48, 25 October 2025 (UTC)[reply]
    • It should be possible to view lists of pages in each category, e.g by adding all GREL sources to Category:Perennial sources deemed generally reliable (instead of the only categories being by year, which is pretty unhelpful). This would be a replacement for the ability to sort by reliability in the table, and would help with comparing which sources fit between the different reliability categories.
    • On the other hand, I agree that, per Aaron Liu and Mathglot, the main list should not have icons to indicate the sources' ratings. People should be nudged towards reading the summaries of the sources to see what conclusions have actually been reached (the feedback is more important than the grade). On a similar note, I think the "This source in a nutshell" banner at the top of the longer demos is counterproductive—the rating being in the infobox is enough emphasis on the rating imo.
    • RfCs/discussions on a source's reliability—or at least the most recent RfC—should be linked in the infobox, like with the "List" column at RSP, or otherwise be prominent/clearly visible without having to scroll down.
    TLDR the format should take the opportunity to emphasize details over the crude labels. Aesthetics play a role here too!
    On another note, what could the new talk pages be used for? Would it make sense for discussions of listed sources to happen at those talk pages, with RSN being a spot to post notifications about those discussions (and discuss unlisted sources)? That could help slim down RSN from bloated discussions, and if previous discussions were kept right there on the talk page it could mitigate redundant discussions. Heck, would it make sense to expand the list's scope from "perennial" sources to include pages for sources that have substantive discussions but otherwise aren't at RSP, just so there's a spot for those discussions to be easily accessed? Would that create problems though, around which sources get project-side pages or not? A penny for y'all's thoughts Placeholderer (talk) 10:17, 24 October 2025 (UTC)[reply]
    I like this idea -- we could probably archive all future RSN discussions to these subpages; even, we could move old RSN discussions to their respective subpages retroactively. This makes all RSN discussions concerning a source in one talk page, which is way better than having to find each of them in the archives. For those discussion threads that talks about multiple sources (or any other threads that can't be attributed to one source), though, we could keep them in the old RSN archives. SuperGrey (talk) 12:23, 24 October 2025 (UTC)[reply]
    I feel like we should still centralise discussions (and archives) to RSN (and its archives) where possible and keep the subpages linked from the RSP index relatively selective (at least 2 discussions, preferably related to actual use in articlespace for RSCONTEXT reasons)... I suppose for the really large RFCs it might be better to have a pinned notification instead, but just for the regular discussions, having it actually located on the noticeboard is a better way to ensure people who watch the noticeboard see the discussion, and most of them don't get too massive. As for the archives, I think the current way where we link to the discussion is a good enough index without actually copying everything over. On the other hand, there's no reason people can't write detailed source guides in the same format without them being linked to RSP. Alpha3031 (t • c) 11:55, 25 October 2025 (UTC)[reply]
    I get what you mean. I was just suggesting the archives be moved to those subpages. The current discussion, though, shall be best placed at the RSN for best publicity. SuperGrey (talk) 12:25, 25 October 2025 (UTC)[reply]
    Even if archives were kept at RSN, would it be possible to display them at the subpages with something like excerpts? Is there an existing template that could be good for that? Placeholderer (talk) 14:23, 25 October 2025 (UTC)[reply]
    Good point. We could use excerpts, like what we do for GA reviews. SuperGrey (talk) 14:55, 25 October 2025 (UTC)[reply]
    +1 for excerpts suggestion. Alpha3031 (t • c) 18:00, 25 October 2025 (UTC)[reply]
    @Alpha3031 I'm not sure if I understand: Is the implemenation idea to transclude talk page content? —Alalch E. 18:09, 25 October 2025 (UTC)[reply]
    I don't think we have to discuss what the format of the subpages yet, but I would support having excerpts of the actual discussions if we do. Of course, I would also be happy with something more freeform. Alpha3031 (t • c) 18:15, 25 October 2025 (UTC)[reply]
    Thanks. I just feel a need to say that subpages should not have separate talk pages. Talk should remain centralized. —Alalch E. 18:20, 25 October 2025 (UTC)[reply]
    I assume something like this that I just added as an example. I also agree best not to shift around RSN archives to subpages, it'd only make it more complicated having most archived there and some elsewhere, with some discussions that are overlaps between two entries as well. Excerpts would work well for consensus summaries without needing to move anything here. CNC (talk) 10:48, 26 October 2025 (UTC)[reply]
    Placeholderer, thanks for these detailed comments. Re: view lists of pages in each category... instead of... only ... by year: this Rfc is only about what general method to pursue, so I interpret this comment as something to look at down the road if the 'List of subtables' approach is chosen. That said, iiuc, this already exists in the mockup, unless I misunderstood you. Categorization is hierarchical, and if you follow the parent categories of the by-year categories, I believe you will find what you are looking for already there, or almost. See for example, Category:Perennial sources deemed generally reliable. If we wanted something like, say, Bloomberg landing page to be *both* in its by-year category, as well as the higher-level 'generally reliable' category as I think I understood you saying, this is easily doable by using WP:CAT#Non-diffusing subcategories. A wide range of possibilities exist about how categorization should be organized, which brings us back to point one again, namely, that it is for the community to decide, after the general approach is chosen. Re: drop the nutshell: you are not the first to point that out, and it is another presentation detail for community input at some later date. You might like the presentation at Wikipedia:Reliable sources/Perennial sources/all/Deutsche Welle better. Mathglot (talk) 19:28, 25 October 2025 (UTC)[reply]
    The issue I see with the yearly categorization such as Category:Perennial sources deemed generally reliable in 2024 is that it's sources last discussed in 2024, not necessarily a relevant discussion that obtained consensus. It also sort of implies the source was deemed reliable in 2024, or re-affirmed in 2024, which isn't likely the case. It'd make more sense for the date to be when the source was deemed generally reliable, by RfC or discussion, and then categorised as such, or just not categorized by year. I otherwise generally support category usage for this proposal, that's just common sense. CNC (talk) 10:37, 26 October 2025 (UTC)[reply]
    These are very good points; please raise them again should List of subpages achieve consensus. Mathglot (talk) 17:49, 26 October 2025 (UTC)[reply]
    • List of subpages for all and a Lua Module for the most used sources (i.e. more than 500 uses in citations) User:Bluethricecreamman (Talk·Contribs)
    • Reduce scope. The simplest way to fix the technical limitations is to stop increasing, or better still reduce, the number of entries. The more entries RSP has, the more unhelpful it becomes. This gigantic wall of TLDR spam already has too many entries and is growing out of control. If RSP continues grow at this rate, its sheer size will eventually make it totally unusable for any purpose, no matter how it is restructured. James500 (talk) 01:30, 25 October 2025 (UTC)[reply]
      While charming in its simplicity, and highly desirable in concept, this suggestion may be difficult to implement in he real world, and is probably outside the scope of the RfC. Cheers, · · · Peter Southwood (talk): 11:30, 25 October 2025 (UTC)[reply]
      On the face of it, this proposal is within the scope of this RfC, because reducing the number of entries does "fix the technical limitations that will prevent us from expanding Wikipedia:Reliable sources/Perennial sources" within the meaning of the question at the top of this RfC. James500 (talk) 11:18, 30 October 2025 (UTC)[reply]
      There is no need for that. The number of entries does not affect the helpfulness of RSP. —Alalch E. 15:07, 25 October 2025 (UTC)[reply]
      The larger RSP becomes, the more of a WP:TLDR WP:WALLOFTEXT it becomes. The larger RSP becomes, the more unreadable it becomes. The larger RSP becomes, the more it includes sources that are not perennial, have not been discussed for many years, are obscure and unimportant and irrelevant, are not likely to be used anywhere, and in some cases no longer exist. The larger RSP becomes, the more it goes out of date. The larger RSP becomes, the more it includes factual inaccuracies, unverifiable assertions, and fringe opinions. The larger RSP becomes, the more it fails to reflect consensus. The larger RSP becomes, the more it becomes WP:CREEP. The larger RSP becomes, the more it becomes unmaintainable and (largely) unmaintained. In short, there really is an actual "quantity versus quality" problem with RSP. James500 (talk) 11:18, 30 October 2025 (UTC)[reply]
      RSP being larger does not make each entry larger. The entries themselves have to be larger for WallOfText/Creep to apply. The consensus of discussions is not factual inaccuracies, unverifiable assertions, and fringe opinions. The outdatedness of entries is reflected by the year of the last discussion included under the "last" column. The larger RSP becomes, the more it fails to reflect consensus. How? Aaron Liu (talk) 11:29, 30 October 2025 (UTC)[reply]
    • List of subpages would be the best option, in my opinion, as it would make it easier to locate and review each source. Each subpage could include details about the source, links to past discussions, and the community’s consensus on its reliability (or lack thereof). This format would improve navigation and make source lookup simpler than the current table format, which becomes unwieldy as new sources are added. Sean Waltz O'Connell (talk) 11:49, 26 October 2025 (UTC)[reply]
    • List of subpages, assuming someone doesn't come up with a longer lasting fourth option. I don't see the value of a temporary solution to the problem. Chess enjoyer (talk) 21:10, 26 October 2025 (UTC)[reply]
    • List of subpages. The other two options are just delaying making a decision. lp0 on fire () 21:18, 26 October 2025 (UTC)[reply]
    • I'd quite like one giant plaintext list with onward links to the relevant subpages, but there's no need to slap on some temporary solutions to maintain one page so a list of subpages either way. CMD (talk) 14:58, 27 October 2025 (UTC)[reply]
      You could have your one giant plaintext list if you wanted. An advantage of the List of subpages approach is that it is easy to create the Index page links, so different Index pages could be established with different styles. Here's one:
    You could even have your own Index in a user subpage somewhere, if you have a particular style you favor. Mathglot (talk) 07:57, 28 October 2025 (UTC)[reply]
    The particular style I favor is being able to ctrl+f a publication name (or a few variations) to try and find a listing. The index page link format looks viable. CMD (talk) 15:33, 28 October 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.

    Invitation

    [edit]

    Please join me on the talk page to discuss the design of the subpages. WhatamIdoing (talk) 04:40, 6 November 2025 (UTC)[reply]

    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/Restructuring_RSP&oldid=1320836154"