Wikipedia talk:Requests for comment/Restructuring RSP

Further information: Wikipedia talk:Reliable sources/Perennial sources/Index

Handy links

• Wikipedia:Reliable sources/Perennial sources/Index
• List of individual subpages (some examples – feel free to create your own, to show what you would like)
• (add more)

— Preceding unsigned comment added by WhatamIdoing (talk • contribs) 04:53, 6 November 2025 (UTC)

And these:

• lots of links at WT:RSPINDEX#Parts;
• lot of notes about this phase of the transition, at WT:RSPINDEX#Implementation notes.

Do we want to import [some of] them, or just leave links to them here as is? Mathglot (talk) 02:24, 7 November 2025 (UTC)

Goals and anti-goals

My first general question about the design of the subpages: What are our goals, and what are our anti-goals?

I'll go first in case my question isn't clear. Remember that it's okay to disagree (nicely) or to change your mind.

Goal: I want it to be easy to find out something about the source, like "____ is a video game review website" or "____ is a Ruritanian newspaper".

Anti-goal: I don't want to overemphasize the bottom-line classification. Yes, let's say that WP:STRAITSTIMES is WP:GREL, but let's not turn the background of the whole page green, put that status in a {{nutshell}}-type box, or otherwise make it easy for editors to overlook the fact that there are political pressures on this source that make it less suitable for some content. WhatamIdoing (talk) 04:48, 6 November 2025 (UTC)

• Number one goal for me, before getting into any specifics about what should be on the page, is establishing a familiar pattern, without it becoming a straitjacket. I would like there to be a kind of a general parallelism or typical look-and-feel across pages, so that once one sees a few landing pages they will start to form a familiar pattern, while at the same time allowing the flexibility to be different from the pattern whenever that would best serve the purpose of the particular source being described. In this sense, they would be more analogous to articles, with their suggested structure in MOS:LAYOUT while still allowing plenty of flexibility to add or drop sections or other elements as the need arises, and less analogous to the constraints of table rows, with their pretty strict definition of the number of cells and what goes in them.

A pattern would likely involve section headings and what they are called, Infoboxes (or not), See-also or navboxes, and in what order everything is. We might end up (later, after we see what the pattern turns out to be) with a brief suggested layout, something like what MOS:LAYOUT describes for articles, except shorter. Mathglot (talk) 01:45, 7 November 2025 (UTC)

• Goal: plain English preferred – I favor the use of spelled-out expressions, thus "generally reliable", not "gr", and so on. We have the room for that now, and should take advantage of it. I have nothing against the existing icons in use in the table and support icons as a quick, eye-catching way of imparting information once you learn the ropes, but the full expressions should be used as well. Existing icons can still co-exist alongside.
• Goal: lessen the burden of creating new pages – take advantage of automating or providing power-assist tools via template, module, etc. where practical. An example that comes to mind is the semi-automation of existing template WP:RSPLAST mentioned here; another is the use of template {{Edit}} with a preload page, mentioned here, so uses wouldn't have to write from scratch or copy/paste some existing page as a starting point. Mathglot (talk) 02:53, 7 November 2025 (UTC)

  I wonder if this could be done with a preload system. WhatamIdoing (talk) 06:23, 7 November 2025 (UTC)

• Goal: centralized discussion: have one centralized page for discussion of all landing pages. Just as we discussed any table row at the (single) Talk page for RSP, we should talk about any given landing page in a single place. Corollary: when a new landing page is created, the Talk page should be, too, and contain a redirect to the central discussion page. Mathglot (talk) 02:53, 7 November 2025 (UTC)

  This sounds like a good task for a bot. WhatamIdoing (talk) 06:23, 7 November 2025 (UTC)

• Goal: Make entries easy to read on mobile Wikipedia. The current table is very difficult to read on the mobile version of the site, which is increasingly how people view Wikipedia. The Daily Mail demo page linked above is already easier to read than WP:DAILYMAIL on narrow screens and in the mobile theme. Rjjⁱⁱⁱ (talk) 03:37, 7 November 2025 (UTC)
• I'd agree more easily accessible information about the source would be nice. Typical subject, how it's used on Wikipedia, structure of the publication, etc. With size restrictions now being a lesser concern we can probably add a decent amount of information. For example, for something like the NYT, we can write blurbs on the areas of the publication in Template:The New York Times if it seems like it would be helpful. Alpha3031 (t • c) 14:04, 7 November 2025 (UTC)
• Goal: Entries with different ratings by date ranges. See discussion below. SuperGrey (talk) 07:53, 9 November 2025 (UTC)

Infobox

Deutsche Welle

other names	DW, DW-TV
source type	news
publisher	Germany (state-funded media)
website	https://dw.com/en
classification	Usually reliable for typical purposes

Should the subpage have an infobox? If so, what would you include in it?

I think it should have a logo (if not copyrighted), alternate names, website, and of course the RSP general classification.

I'd also like something about the publisher, which isn't going to be that interesting for ordinary sources like newspapers or magazines, but it might be enlightening for some political websites ("Oh, that's one of his websites"). WhatamIdoing (talk) 17:53, 7 November 2025 (UTC)

I guess that one of the questions is: If there's an infobox, how long/short should it usually be? WhatamIdoing (talk) 17:53, 7 November 2025 (UTC)

Might want to notify WT:RSP? Kowal2701 (talk) 00:16, 9 November 2025 (UTC)

Feel free, if you'd like to, but this whole RFC was planned there, so I assume that anyone who's interested is already watching this page. WhatamIdoing (talk) 00:28, 9 November 2025 (UTC)

If we have an infobox, then I think it should comply with the main function of an Infobox. MOS:INFOBOX says this:

An infobox is a panel that summarizes key facts about the page's subject.

Bellingcat

type	investigative journalism
shortcut	WP:BELLINGCAT
status	generally reliable
deprecated	no
blacklisted	no
recency	2021
Domain bellingcat.com
in source code external links in articles spamcheck tool
RFC
link	Rfc
date	2019

I would say that the subject of an article and the subject of a landing page are not the same. As an example, the subject of the Bellingcat Wikipedia article is a "Netherlands-based investigative journalism group" and the article summarizes outside reliable sources about Bellingcat, whereas the subject of the Bellingcat landing page is past discussions among Wikipedia editors regarding the reliability of Bellingcat, and the landing page summarizes opinions of Wikipedia editors expressed at Wikipedia. To me, those are very different subjects.

If we agree with MOS about the purpose of an Infobox, then I would say that since the Infobox on a landing page is summarizing a very different kind of content than the article Infobox about the source, it should reflect that by looking quite different from an article Infobox. In my opinion, if we decide to have an Infobox it should summarize reliability evaluations by Wikipedia editors, and might look something like this example.

Items in the article Infobox like the logo, and other information such as the site owner, where it is based, when it was launched, and so on are not a summary of anything in the landing page body and so in theory should be excluded; also, making the landing page Infobox look too similar to the article page Infobox might be confusing, as users are likely to click back and forth to get more information about the site being evaluated, as well they should. A different look and feel of the Infoboxes on article and corresponding landing page will help maintain clarity about where they are.

On the other hand, *some* identifying information is clearly needed – at a minimum, the name of course; should we have more than that? Is it better or worse to have the logo, or does that promote confusion? Maybe 'type of site' in the article Infobox, listed as 'investigative journalism' at the Bellingcat article, would be worth it. A sufficiently different style might help, and I've reduced the size of this example and added a faded khaki background color, which I think could be very helpful in instantly distinguishing a landing page from an article even if both had Infoboxes, like Bellingcat does. Given the other differences, probably even enough so that adding the logo to this one would not cause any confusion, and might help provide a graphic identification to distinguish it from other landing pages, so I've added it to the example. Mathglot (talk) 03:04, 9 November 2025 (UTC)

Suggestion to the infobox example you provided: we shall merge "deprecated" and "blacklisted" to "status" param. Currently on RSP, "deprecated" and "blacklisted" are also status ratings, alongside "generally reliable", "generally unreliable", and "no consensus". SuperGrey (talk) 07:31, 9 November 2025 (UTC)

I'm inclined to keep blacklisting separately, because sites get put on the spam blacklist without any kind of RS problem. WhatamIdoing (talk) 19:49, 9 November 2025 (UTC)

Is that so? I guess I'm not familiar with the enwiki enough. Can you enlighten me which sites are on the spam blacklist but is considered at least reliable in some parts? SuperGrey (talk) 23:59, 9 November 2025 (UTC)

The spam blacklist is for WP:Spam. Some of the entries are just ordinary websites about recipes or gardening or whatever else people are interested in. If you'd like a case study, then we've blacklisted legaldictionary.net, which is no worse than any of the other free dictionaries on the internet, and which MediaWiki talk:Spam-blacklist/archives/October 2021#legaldictionary.net blacklisted for behavior, not with any question about reliability. WhatamIdoing (talk) 01:20, 10 November 2025 (UTC)

Another suggestion to the infobox, also serving as a goal of the restructured RSP -- we need to allow (& promote) rating by date periods. E.g., WP:KOTAKU. There is a more detailed consensus on WP:VG/S, where they define News posts from Kotaku between 2010 and 2022 are considered reliable [...] Articles published before 2010 had comparatively weaker editorial standards, while articles published from 2023 onward should generally be avoided.
As part of the effort, Cite Unseen has provided various ways of differenciating websites by date ranges, individual authors/writing teams, and publishers in "platforms" (see m:Template:CULink for these parameters). This could generally help enrich the RSP rating system to be way more than just a single rating for one website. SuperGrey (talk) 07:47, 9 November 2025 (UTC)

I thought the same thing about the status merging with deprecated and blacklisted at the outset, but I wonder if that isn't out of scope for what we are doing now, which is moving current table info into a new format. Merging status with those fields might require another discussion, plus, some of them can coexist, e.g., Change.org is both 'no consensus', and 'blacklisted', so one field cannot currently handle that, and different people might have different approaches on how to do that, and we already have a lot on our plate just now. Not against discussing it, but don't want to get distracted from the main task, which is already a good amount of work.

Regarding rating by date periods: please have a look at CNET and see what you think about how it is done there. Mathglot (talk) 12:10, 9 November 2025 (UTC)

To me, Change.org looks like a solid "blacklisted" instead of "no consensus", since you can't use it at all anymore if it's already on the blacklist. We can definitely make it a separate discussion, but there is no need to shelf it for later when we have ongoing restructuring and it is essentially setting an example for future RSP ratings.
The CNET page is getting way too bloaty. We only need one infobox, maybe with sub-infoboxes for each date periods. Paragraphs can be long and split into several sections which I don't mind, but there is no need to treat it as "three separate entries" just to mirror the old table. SuperGrey (talk) 12:28, 9 November 2025 (UTC)

Imagine that a site is blacklisted for spam, and the spam problem goes away. If being on the spam blacklist is a commentary on reliability (=its RSP status), then that supersedes the "no consensus". If it's a separate status, then the site is both "no consensus" (a durable RSP status) and separately blacklisted (which could be changed at any time [though I doubt that particular site will be]). WhatamIdoing (talk) 19:52, 9 November 2025 (UTC)

If it's blacklisted, then let's just use one rating "blacklisted"; if the spam problem goes away (which sounds at least like a RSN relisting), we can adjust that to something else by the new consensus, e.g., "no consensus" or "generally unreliable." -- There is no point having two separate status for this situation. SuperGrey (talk) 23:56, 9 November 2025 (UTC)

Spam problems are not handled at Wikipedia:Reliable sources/Noticeboard. Spam problems are handled at MediaWiki talk:Spam-blacklist. WhatamIdoing (talk) 01:22, 10 November 2025 (UTC)

And there is a point in having two notes: If it's on the spam list but usable as a reliable source, then you can ask the spam folks to put it on the MediaWiki:Spam-whitelist for a particular article. If it's on the spam list but not usable, then there's no point in asking for permission to use it. WhatamIdoing (talk) 01:24, 10 November 2025 (UTC)

That's interesting. Thanks for the explanation! Then I agree we can indeed keep them separated. SuperGrey (talk) 07:48, 10 November 2025 (UTC)

Page locations before and after cutover

Let's decide where the project is going to live after it is converted and goes live. We need to know this, to stay organized during development and cutover. Probably the simplest solution is to develop the new index page and landing pages in a temporary area, and at cutover, move the live page to a legacy page and move the index page there instead so all incoming links still work, but now point to the new setup. I think the live RSP Talk page should not be moved at cutover, but should remain where it is at Wikipedia talk:Reliable sources/Perennial sources (WT:RSP).

We should also decide where the landing pages will live, so we don't end up having to move 500 pages later. Currently, about 80 demo landing pages are under Wikipedia:Reliable sources/Perennial sources/all. I don't think they necessarily have to remain there post-cutover, but I don't see a good reason to move them. I do not think they should live directly under the project page, because with 500 of them, they will swamp whatever direct subpages will be needed there and make those pages hard to find. Finally, where do we want to have the discussions we are having now about the conversion; keep them here, have them at WT:RSP, or somewhere else?

I vote for:

1. current project page (table) – live page at WP:Reliable sources/Perennial sources (WP:RSP) moves to WP:Reliable sources/Perennial sources/RSP legacy table at cutover
2. current talk page – Wikipedia talk:Reliable sources/Perennial sources (WT:RSP) stays where it is through cutover
3. new project page (index) – during development, lives at WP:Reliable sources/Perennial sources/Index (WP:RSPINDEX); moves to its parent at cutover
4. landing pages/source pages – currently subpages of WP:Reliable sources/Perennial sources/all; remain at same location through cutover
5. conversion discussions – move to Wikipedia talk:Reliable sources/Perennial sources; nobody will find this Rfc page later. Second choice: leave them here, but set up archiving targeting the exact same archive page as the MiszaBot/config at WT:RSP. No-go: leave here and archive here.

Thoughts? Mathglot (talk) 04:49, 11 November 2025 (UTC)

Note re #5: we currently have conversion discussions in three places: WT:Requests for comment/Restructuring RSP (this page), WT:Reliable sources/Perennial sources, WT:Reliable sources/Perennial sources/Index (and also some bits at User talk:Mathglot and User talk:WhatamIdoing). We should pick one. Mathglot (talk) 05:06, 11 November 2025 (UTC)

Just archive everything to "WT:Reliable sources/Perennial sources/Archive 12" at cutover. Easiest solution. No need to use bots. If someone feel like wanting to continue on one of the discussion thread, they should instead start a new one. SuperGrey (talk) 06:18, 11 November 2025 (UTC)

I'm not sure that we need to archive this talk page, and if we leave it here, we can add a link to it at WT:RSP. WhatamIdoing (talk) 23:36, 11 November 2025 (UTC)

What's the goal behind the "/all/" in the WP:Reliable sources/Perennial sources/all URL scheme? WhatamIdoing (talk) 23:37, 11 November 2025 (UTC)

I read two separate questions here:

1. Why have another directory level; why not place all the RSP source pages (= 'landing pages', = 'subpages') directly under WP:Reliable sources/Perennial sources as subpages of it?

   The main page at WP:Reliable sources/Perennial sources already has 52 direct subpages, exclusive of the 78 pages created as part of the 'List of subpages' demo. It is already somewhat hard to find the original 52 when looking at a search of everything under WP:Reliable sources/Perennial sources, which numbers 130, although they are still listed separately if you use Prefixindex search. However, if we place the RSP source pages as direct subpages, that subdirectory will number 552 when we are done, making it even harder to find the original 52 non-RSP source pages, and Prefixindex will no longer separate them; they will be all mixed in alphabetically. The clear and simple solution is not to place them as immediate subpages of Wikipedia:Reliable sources/Perennial sources, but somewhere else, in a directory containing all of the RSP source pages, and nothing but RSP source pages.

2. If another directory is needed, why call it "/all" and not something else?

   It could be called something else; "/all" was conveniently short, and the idea was that it contains all of the RSP source pages (but none of the non-RSP ones from other projects). Another possibility might be "/main". Anything else seemed longer, but I'm open to other names. "/RSP" seems possible, but is somewhat duplicative, but I'd be okay with WP:Reliable sources/Perennial sources/RSP/Ballotpedia, and so on.

Thanks, Mathglot (talk) 01:57, 12 November 2025 (UTC)

My question was the first, but since you bring up the second, then /source is another possibility. But /all is conveniently short. WhatamIdoing (talk) 02:19, 12 November 2025 (UTC)

Something to consider is nixing this being a subpage of WP:RS and instead either placing stuff at WP:Sources/source/Source (can bikeshed the lowercase source) or at WP:Perennial sources/source/Source.

I agree that it makes sense for these to have their own home at some collection of a subtitle. It also allows for different views e.g. WP:Perennial sources/Video games which could house the current video game list living at WP:VG/S or the country-specific lists I know are living under... AFC or NPP I think it was.

I don't think "all" makes for a very good name but I also don't care enough. Izno (talk) 03:17, 18 November 2025 (UTC)

I suppose all was also a short form in my mind for all sources, to contrast with exactly the possibility you raised regarding subsets, such as 'video games', so that all_sources might contrast with video_games; or, given my bias for shorter paths, so that all might contrast with vg (or korea, and so on). But I also don't care that much, as long as it isn't directly under RSP. Mathglot (talk) 09:20, 27 November 2025 (UTC)

Regarding #3 (Index page) and #4 (source page directory): if we go with sources instead of all for the source pages parent directory, then #4 becomes Wikipedia:Reliable sources/Perennial sources/sources, and source page paths would look like: Wikipedia:Reliable sources/Perennial sources/sources/BBC. Not happy about the reduplication of 'sources' in adjacent directories. Another approach would be to drop the last 'sources' and shorten the parent directory to just '/Perennial', so that we would have Wikipedia:Reliable sources/Perennial/sources which is okay for the source pages under it, but then the index page (#3) at the level above would be Wikipedia:Reliable sources/Perennial/Index which doesn't seem right, because the index is about perennial sources, not perennial arguments or something else. I suppose we could move the Index down into the same directory as the sources and then we would have #3 as: Wikipedia:Reliable sources/Perennial/sources/Index, making it the only item in that directory that wasn't a source page. Or just stick with the all directory, or use sources despite duplication? Any other ideas? Mathglot (talk) 21:49, 3 December 2025 (UTC)

What about Wikipedia:Reliable sources/Perennial/Index and Wikipedia:Reliable sources/Perennial/BBC? We can put WPVG sources at Wikipedia:Reliable sources/Video games/Index and Wikipedia:Reliable sources/Video games/IGN. SuperGrey (talk) 21:55, 3 December 2025 (UTC)

I think taking directory Video_games out from under directory '/Perennial' could confuse users about status. Suppose that some of the VG sources are considered unreliable or deprecated; now you would have page titles like, say: 'Wikipedia:Reliable sources/Video games/Badguy', which sit under 'Reliable sources' but not under 'Perennial [sources]' anymore, so it would be like tagging all the VG sources as reliable, even though some might not be. I think that could be confusing. Mathglot (talk) 22:46, 3 December 2025 (UTC)

“Perennial” means perpetual/everlasting, which isn’t any better in conveying that the source is not reliable. Instead, why not consider “Wikipedia:Reliable sources” a WikiProject (we do have one WPRS though); “Perennial (sources)” to be the name of a source list, and “Video games sources” to be another. SuperGrey (talk) 23:15, 3 December 2025 (UTC)

I wasn't around when the word perennial was chosen, but it is a good choice, as it does not convey anything about a source being reliable or not reliable, and it *must not* because that would bias the evaluations. What perennial means in this project is only about *how often* the reliability of a source has been discussed (i.e., it has been discussed perenially) and has nothing to do with how reliable a source is or isn't. (A more accurate name for RSP would have been 'Perenially discussed sources' using the adverb perennially modifying discussed, but I assume they dropped the word 'discussed' from the page title in favor of a title that is briefer. That makes for a shorter title, but leaves perennial as an adjective modifying sources, which it definitely is not, since sources are neither perennial, nor not perennial. I probably would have voted for the shorter title at the time as well, as a shorter title that everyone understood to mean 'perennially discussed sources'. For those who came along later, or didn't get the distinction, it is explained both in the nutshell and in the lead sentence.)

I do not agree that 'perennial sources' is the name of one source list and 'video games sources' is the name of another. Both are lists of perennially discussed sources. The VG list is narrower, and RSP is general: i.e., video games sources are perennially discussed sources limited to the topic area of video games; RSP is perennially discussed sources from all topics; it is the 'parent' list if you will, in which only the most important perennial sources of potential interest to everybody are included. All such lists are perennially discussed sources, i.e., they are discussed repetitively and sufficiently so that an inference can be drawn about what the community believes about the reliability of items in the list. Mathglot (talk) 20:26, 6 December 2025 (UTC)

Then I would prefer following your “all” idea but capitalize the first letter, aka “/All/”. The WPVG source list can be put under “/Video games/”. SuperGrey (talk) 00:11, 7 December 2025 (UTC)

The reason I raised this section in the first place, about something that might seem to be trivial, or a side issue about how to name the path, is that once it is in place, if we decide later we don't like it anymore and want to change it, that will involve at least 500 page moves (and probably over 1,000 moves and 500 redirect target adjustments, if Talk pages are created and redirect to the central talk page, as they should be). That's why it would be good to get more participation here. I don't care what url path is ultimately chosen, as long as we don't have to change it later. This concern of mine would be mitigated if there is a tool available to do mass moves from one directory to another. I have to believe there is, otherwise some Xfd resolutions with lots of affected pages would be very painful to implement. I'll go ask over there and find out. If there is, then we can just name it /all or whatever at the outset, and adjust later if a better name comes along. Mathglot (talk) 20:36, 6 December 2025 (UTC)

Legend Template

The Legend should probably be turned into a template so it can be included in all of the subpages. - Lillia (plural; She/They) 05:09, 15 November 2025 (UTC)

atleast for the current table based subpages way of doing it. - Lillia (plural; She/They) 05:28, 15 November 2025 (UTC)

Nullnominal, Good example. There are a number of ways templates could be useful; see for example, WT:RSPINDEX#Parts > [show] > 'Templates'. Thanks, Mathglot (talk) 22:59, 17 November 2025 (UTC)

Merging "flavors"/qualifiers of sources?

In the current table there are sometimes separate rows for the specific area of expertise for some sources, eg:

• Al-Manar (general topics)
• Al-Manar (controversial topics)

My parser currently treats these as two separate sources under the assumption that there is a 1-1 mapping between row and source (though we can clearly see that's not the case). I assume that we would want some way to merge these in the final list of source pages/subpages? Maybe there's few enough of them that this could be done manually? audiodude (talk) 20:45, 17 November 2025 (UTC)

I think that's feasible. I think there are few enough that they could be manually merged/redirected. WhatamIdoing (talk) 21:09, 17 November 2025 (UTC)

Audiodude, It was always my assumption to do those manually. See examples at CNET and Dotdash Meredith for two approaches to this. (By the way, I don't mean two approaches of which only one is valid and should be chosen; I think the CNET format is better for the CNET source page, and the DM format is better for its case; that is one of the benefits of the whole subpages/source pages approach: we can just do what is best in each case, not slavishly follow just one pattern.) Note: this is about the mapping, not the internal format used on the page, not yet decided for even the simple 1–1 cases, let alone these more complex ones. See 'Index to subpage mapping' at WT:RSPINDEX#Implementation notes. Mathglot (talk) 22:49, 17 November 2025 (UTC)

First version of bot-generated source pages, 2 formats

Following the discussion on WT:RSPINDEX#Implementation notes I have atuomatically, with the help of a bot, created "source pages" (subpages) for each row in the RSPS table. To help with browsing these pages, I have also created index pages. However it is important to note that these are placeholder index pages that do not even remotely reflect the consensus of how these should look.

Pages in format1 are at User:Audiodude/RSPTest/format1/Index

Pages in format2 are at User:Audiodude/RSPTest/format2/Index

One thing to note is that the structure of format2 includes a "logo", a "source type" and a "publisher" in the infobox, but that information is not part of the original RSPS table, so is not available to the bot and would have to be added manually. audiodude (talk) 03:04, 18 November 2025 (UTC)

And this doesn't mean that we've decided on one of these or these are the only options. Feel free to construct additional format options, and I can easily run the bot to create source pages in that format. audiodude (talk) 03:10, 18 November 2025 (UTC)

Nice work! (See next section for my autoflagellation about forgetting to hit Publish on my comments about templates and classes in time for you to see it before running the bot.) The main thing I noticed was the same issue I ran into when using regex to convert the B–C–D pages at WP:RSPINDEX, namely, the discussion links and Rfc links. Compare, for example, Wikipedia:Reliable sources/Perennial sources/all/Bellingcat vs. User:Audiodude/RSPTest/format1/Bellingcat#Discussions. I had the exact same issue, and used a follow-up regex just on the discussions (talk/archive links, and rfcs), and then added them in a second edit (sometimes the same one, since it was all manual).

Anyway, great to see you can generate these automatically. Do you think the bot could generate the discussion and rfc links, too? Not asking you to do that now, when you just finished running it; let's wait to see if there is other feedback, and bunch them into a new run at some point; no sense running it every time someone comments. Mathglot (talk) 03:51, 18 November 2025 (UTC)

Great catch! My original version actually captured the discussion links, you can see them in the sources.json. When I was debugging I introduced a bug in the parser that caused them to go missing. I'm re-running the bot now to add them (running the bot takes about 15 minutes btw). audiodude (talk) 16:39, 18 November 2025 (UTC)

In section 'Original table row for comparison' (e.g. here), feel free to transclude WP:RSPTableHeader (⟶ Wikipedia:Reliable sources/Perennial sources/Table header) at the top, replacing the {| table start delim, and it will generate the proper table headers, classes and pick up style from the styles.css page. Mathglot (talk) 04:06, 18 November 2025 (UTC)

Done! audiodude (talk) 16:45, 18 November 2025 (UTC)

I note there are 2 seemingly identical links to Wikidata. Gråbergs Gråa Sång (talk) 05:34, 18 November 2025 (UTC)

Gråbergs Gråa Sång, link; explanation? Mathglot (talk) 03:32, 19 November 2025 (UTC)

@Mathglot User:Audiodude/RSPTest/format1/Index lists

• Wikidata
• Wikidata

I don't know if there's some technical reason or just a "typo". Gråbergs Gråa Sång (talk) 06:04, 19 November 2025 (UTC)

Nevermind, I see Wikidata has 2 entries on RSP too, I didn't get that. Gråbergs Gråa Sång (talk) 06:10, 19 November 2025 (UTC)

Maximize flexibility and ease the burden through liberal use of templates and classes

In order to ease the burden of conversion, especially with respect to changes in consensus about what content or wording the landing pages/subpages/RSP source pages should have, or stylistic questions of how it should be formatted, I am recommending maximal use of templates for content and classes for style.

The table approach now live already uses a number of templates, presumably for all the usual reasons, including ease of coding, but also parallel look-and-feel in something that turns up repeatedly in every row. Examples: WP:RSPLAST, WP:STATUS, and WP:RSPUSES (these three are template redirects, as used in the table). This becomes even more important when generating the subpages/RSP source pages en masse. Please see WT:RSPINDEX#Parts > [show] > 'Templates' for a list of new templates created for the source pages linked by WP:RSPINDEX. (Not all are destined for use in source pages; some are for the Index page, some are just notices about the transition we are now going through.)

Important: in two cases, the templates used in the 78 demo source pages underlying the Index are in the sandbox only, namely WP:Reliable sources/Perennial sources/Last/sandbox and WP:Reliable sources/Perennial sources/Status/sandbox. These are working for all 78 pages, but I left them in the sandbox, and the source pages all transclude the sandbox versions, obviously not a permanent solution. I did it that way, because while all test cases for source-page display work and pass test cases using the sandbox versions, I did not do regression tests to make sure the sandbox versions play nice with the live table, because I didn't know if the subpage/source page approach would be chosen and didn't want to spend time doing regression testing for nothing. Now that it has been chosen, we need to use the basepage template, not the sandbox when you do the conversion script, so I will have to do the regression testing, to make sure the sandbox version works for both the table, and the subpage/source pages.

In the case of WP:RSPUSES, that redirects to WP:Reliable sources/Perennial sources/Uses, which in turn employs template {{Domain uses}} to emit some icons displaying some Cirrus search links to find links to that source page domain. Those icons might be needed due to the cramped space available in the table rows, but we are not so constrained in the source pages, so I did not use those, substituting instead {{Domain uses long}} in my landing page format. You can see them in use at the bottom of the Infobox in any of the demo source pages, such as in the Infobox at */Ballotpedia. Again, this is just the format I happened to choose in order to get a demo out there, but is by no means set in stone. The whole point of putting it in a template, is that whatever format is eventually chosen by consensus, instead of having to go back and edit 500 pages to the new format, we just change the template to whatever the consensus is. This is why I favor maximal use of templates for almost all aspects of the source pages, for all common content, i.e., pretty much everything that doesn't come from the eight or ten parameters that vary from row to row in the table, depending on source.

Secondarily, I recommend maximal use of CSS classes on all distinct items in the source pages. In the same way that use of templates can generate parallel content where needed, using classes will allow us to change style on all 500 source pages later, without having to edit the source pages themselves, simply by modifying the styles.css page. That is why, when you look at a demo page like */Ballotpedia you will notice eight classes (not counting the three wikitable classes) defined for portions of content in the page. Not all of these classes yet have an expansion at styles.css, but they don't have to; their raison d'etre is simply to allow them to be defined at styles.css when needed, at which point the style will immediately take effect at Ballotpedia, and the 77 other pages that have those classes defined. Audiodude, as you go through testing your conversion bot, can you keep this in mind, as it will make our lives much easier, once the pages go live, or even before, if regular RSP users find them and start to change them. If you see something you think can benefit from a new template, please lmk and I will create one. As far as new classes, you can just add new ones if needed without defining it. Thanks, (edit conflict) Mathglot (talk) 03:27, 18 November 2025 (UTC)

Crap; wrote this yesterday, and forgot to hit Publish. Really needed to get it out there, before you ran the bot. It's only when I got the notification just now for the section above that I wondered what the heck happened to it, and found it sitting in an edit tab all done, but unsaved. Crap. Mathglot (talk) 03:30, 18 November 2025 (UTC)

Actually, at least for format1 it looks like you did make use of all the new templates, I assume because you modeled against some of the demo source pages, so, good on ya, mate! One thing to note before a second run, is that business about sandboxed templates; I really need to get that done first. Mathglot (talk) 03:54, 18 November 2025 (UTC)

Yes, I copied the pages from there, I didn't create them by hand. I'm a programmer, I'm lazy.

I would like your opinion on the reliability summaries in the infobox on format2. Do we have templates for these? audiodude (talk) 16:40, 18 November 2025 (UTC)

Are you looking for something like Template:No consensus source? (I found this by looking in Special:WhatLinksHere for the icon's image file in the Template: namespace.) WhatamIdoing (talk) 21:39, 18 November 2025 (UTC)

That looks good! But I think we want versions that have whatever explanation we want in them. To @Mathglot's point, then we can update the wording on all the source pages at once. audiodude (talk) 23:33, 18 November 2025 (UTC)

For the "no consensus" setting, I don't think we want the same explanation for every page. There's a difference between "we couldn't decide" and "Uh, it depends on what you're citing" ("additional considerations", which unfortunately isn't handled as a separate category). WhatamIdoing (talk) 00:33, 19 November 2025 (UTC)

Also, some sources have more than one rating (fine for local news but bad for political news, or whatever). WhatamIdoing (talk) 00:34, 19 November 2025 (UTC)

We have no history of using {{No consensus source}} in the table, and that template is certainly not anything I think would be helpful here. What we have been using in the table rows, is the template WP:RSPSTATUS, which puts up the icons , , , , and in column two of the table row without additional explanation (other than a brief tooltip, for those in the know and able to see them), as described in WP:Reliable sources/Perennial sources#Legend. In the source pages (either under WP:RSPINDEX, or under */format1/ in audiodude's dry run) the source pages use WP:RSPSTATUS/sandbox (pending regression testing, not yet moved to live). I am not in favor of replacing those with {{No consensus source}}, but if there is an argument for it, let's hear it. Mathglot (talk) 01:51, 19 November 2025 (UTC)

In the /format1/ approach, these icons are still used, but they are accompanied by text that renders as generally reliable, wikilinked to WP:GREL as shown; the others likewise maintain the icon intact, and add wikilinked explantory text. These long forms currently appear in two places in format1 source pages, namely in the nutshell at the top, and in the status field of the Infobox, generated by templates WP:RSPNutshell and {{Infobox source reliability}}, each interpreting the two-letter reliability code gr from param 1 of the WP:RSPSTATUS transclusion as found in column two of the table row.

At this juncture, I find it irrelevant whether we do or don't have a nutshell in the end, or whether we do or don't have an Infobox; my point is that we have plenty of room for the full description, "generally reliable" for the status, instead of the shorthand gr or a checkmark icon (ditto the other statuses), and we should be using the long form, and we should be generating it by template, whatever the wording is, or ends up being, as that will make it trivial to adjust later, as the situation may call for. Mathglot (talk) 02:39, 19 November 2025 (UTC)

Soliciting input for layout and style

I had kind of envisioned, or maybe hoped, for more participation ere by RSN noticeboard and RSP table discussants, in order to solicit ideas about how this should all look. Have thought about various methods, including going to the xtools stats page and just pinging the most frequent contributors within the last X elapsed time (3 years?), or talk page participants, and one-eighth table chunk editors, and just asking for ideas. One difficulty I foresee is that the possibilities are maybe almost too large; it is like presenting them with a blank sheet of paper, and saying: "Here, design the new format." It's a lot easier, imho, when you don't have so many degrees of freedom. (Michelangelo's instructions for creating the statue of David: "Get an 18-foot block of marble, and chip away everything that doesn't look like David.")

One thing I have been thinking about lately, is that the task we are facing of coming up with an efficient, informative, pleasing, relatively complete, and adaptable model for a source page is almost more of a UX design issue really, than something that you need a ton of noticeboard or RS talk page experience for. A good UX designer, given a description of the task and the parameters involved, may be much better placed to stare at a blank web page, and come up with a good design (or several of them), and if we ask a few designers to contribute, we may have a bunch of designs to choose from. I remember being inspired by the W3C showcase website CSS Zen Garden, which was pretty influential in the early days of CSS, to show what could be accomplished with it, and I take some inspiration from it here. For those of you not familiar with it, or who feel a bit shaky on what CSS is all about (hint: it's more than just boldfacing, borders, and background color), head on over to [1] and check out some of the designs; I still find it kind of magical twenty years+ later. I'm not saying we should solicit CSS-only designs (although that is possible!), just that in the same way that designers there imagineer a whole new way of looking at something, given the constraint of a task definition and some params, we could do something like that ask for some designs to be submitted, and at some later point, submit a half dozen or so to the community as an Rfc. We may have better luck coming up with a really good design, and one that has community support, if not everybody has to stare at that blank page and then write something here; we should leave that, imho, to the people who are good at it.

Having said all that, I came up with a sort of definition above of the task we are facing on this page, but I just threw that out there without thinking much. Maybe we should define the task better, and come up with a list of attributes. To some extent, I think that was the intent, or an overlapping part of the § Goals and anti-goals section above, but this focuses more on appearance, which we might say should incorporate the goals. So, a couple of questions: what do you think of finding/asking some editors known for UX design (first stop for me, would be WP:GL, what about you?) to look at our task, and see what they can come up with, then narrow the designs from that step down to the best six ourselves if we have a lot more than that, then start an Rfc with the short list as options? Or if that doesn't work for you, what are your thoughts on how we are going to get feedback so that this feels like a community built design, and not just a fiat by the usual gang of suspects? Cheers, Mathglot (talk) 03:30, 19 November 2025 (UTC)

On the other end of the scale, we could follow Cunningham's law: Do something, and then wait for people to tell us what's wrong with it. WhatamIdoing (talk) 04:30, 19 November 2025 (UTC)

+1 I came here to see how progress was getting on, also to check whether to update new or old index with discussions. Anyway as far as I can see, the details in the RfC for this were quite broad; it focussed on the layout rather than the specific implementation and appeareance, with a demo not being a guarantee of the results so to speak, so I'd say there's a lot of leeway to implement in the way that those who are working on it deem fit. I don't think anyone will complain if the usual gang of suspects are responsible, they usually are and are quite reliable for that. If there is an issue with the format or appeareance, then editors can focus on that rather than the editors involved tbf. I also get the impression that with the amount of work required to implement such changes, editors will be hard pressed to complain about details unless they are willing to put the work. While that's not a reason to deviate from consensus, the point is they are not here now and have been given the opportunity etc, so there is that. So while I'm not opposed to a few mockups, I'm not convinced we need another RfC to pick a favoured layout. Instead I think an informal disucssion (with RSP notified) could do the job. Sometimes the usual gang of suspects at RSP are good for something, and that's likely knowing how best to format RSP. Expecting broader input from the community at this point otherwise seems unrealistic (aside from going to GL, that sounds useful). And otherwise as WhatamIdoing said, until someone tell you "you're doing it wrong", then feel free to assume you're doing it right. CNC (talk) 12:51, 21 November 2025 (UTC)

That's reassuring; thank you. Further to WaId's comment, it reminds me of Grace Hopper's, "It's easier to ask forgiveness than it is to get permission." Mathglot (talk) 12:07, 26 November 2025 (UTC)

I agree. I think my bot makes it easy to demo any given format for all RSPS entries. I'm sure that any format we come up with will have few authors and many critics. On the other hand it might have many crickets. If no one is engaging in these discussions, than it seems like there won't be much opposition or outcry to whatever we (or the "usual suspects") pick, and we should trust ourselves to make the best decisions for the encyclopedia. As CNC said, if someone is upset enough about something we did, they can always garner their own consensus and change it themselves. audiodude (talk) 17:21, 5 December 2025 (UTC)

Okay, I'm convinced. I'm going to have a look at various things, tweak some templates, maybe add some classes, or address other issues (e.g., I found an unpaired div tag; fixed it at Bellingcat, (here), unmatched divs still visible at Ballotpedia and Dotdash Meredith) and maybe make some suggestions before the next run. Mathglot (talk) 00:49, 7 December 2025 (UTC)