Wikipedia talk:Reliable sources/Perennial sources

It's RFC time

For some time now, I think it's been years, I and others have raised various complaints about RSP, such as:

• The entire list is too long, making it unmanageable and difficult to use
• It includes sources about which there is absolutely no genuine dispute as to reliability, such as mainstream media (e.g. BBC)
• It includes sources where there have only been one or two discussions
• It includes sources where there haven't been any discussions in a very long time, like 5+ or 10+ years
• It includes sources where the discussions have only been attended by a few people, like less than 5
• It includes sources where the only discussions have been discussions that were only started for the purpose of listing a source at RSP, not because there is actually any perennial dispute about the reliability of the source (e.g., The Onion)

This is supposed to be a list of perennially-discussed sources, but it instead has morphed into a list of "approved and unapproved sources". I have seen a number of editors try to prune the list, and been reverted each time. Recent examples on this page right now: #Entries that might be trimmed, #List purge.

I find this to be an intolerable state. We need to tighten up the inclusion criteria for RSP, we need to prune the list of RSP, we need to stop adding sources to RSP that aren't actually in dispute. Because some editors clearly disagree with this (as judged by their reverts of pruning efforts), I guess we will need to have an RFC. So let's have an WP:RFCBEFORE.

I think the "RFC question," or proposal, should be to change WP:RSPCRITERIA, which currently requires the following:

1. two or more discussions
2. each discussion must be "significant"
   • "significant" means two editors where the source's name is in the section heading, or three editors otherwise, each of whom must make at least one comment on the source's reliability
3. Or alternatively, at least one RFC at RSN

I think we should change that criteria to be something more like this:

1. at least three discussions
2. within the last 10 years (or 5 years)
3. each discussion must have at least 5 editors commenting on the source's reliability

Additionally, we should have a rule that there can be no RSN RFC unless there have been at least 3 past discussions with no consensus, or a prior RFC (to see if consensus has changed), and that prior RFC had to have been at least 3-5 years ago (or there has been some event that justifies revisiting the issue, e.g. a major scandal at the source).

The idea is to beef up "significance" by requiring 5 editors to participate; to ensure "perennial" by requiring 3 discussions and requiring the dispute to not be stale (because 10 years is a long time and things change... if no one has brought it up in 10 years, it's not perennial anymore, even if it once was). I think we should cut down on the RFCs, especially RFCs that are designed to add/remove an entry to RSP, rather than designed to resolve an actual perennial dispute over the source. The idea is to stop the notion of: just because two or three people disagree about a source once or twice, doesn't mean we add it to RSP. The idea is to end up with a much shorter WP:RSP that really only lists perennial discussions, and does not waste time listing sources that are obviously reliable (BBC) or obviously unreliable (The Onion).

Brainstorming/ranting here out loud, but I'm pretty keen on having an RFC about making RSP more usable and breaking the logjam. Any feedback on this proposed criteria, on what the RFC question should be, on what the proposed changes to RSPCRITERIA should be? Levivich (talk) 17:13, 17 September 2024 (UTC)

This sounds like a change in the right direction, though I'd need to think through the details of the proposal. Alaexis_¿question? 20:18, 17 September 2024 (UTC)

I would like to bring into consideration for contrast the Wikipedia:New page patrol source guide, which is a project by @Rosguill: that backlinks every source discussed by 2+ editors on RSN (which I think is useful to do) and then makes their own 3-tier judgement on the outcome of that discussion. That page's categorization has been incorporated uncritically into editors' bot scripts and occasionally referenced in on-wiki discussion, despite single-editor oversight. (Now, as is clear from the essay's Talk page, this state was never that editor's intention.) I am hoping to help make that essay more usable going forward. In the meantime, it should serve a very clear and distinct purpose from a more definitive, consensus-driven, RSP.

RSP meanwhile, should be thorough enough that it is a useful primary reference for quick manual lookup, bot scripts, and at least a small amount of conflict mitigation (or at least more mitigation than causation). The notion of "obviously reliable" versus "obviously unreliable" is not always obvious, or at least not for the 2nd and 3rd uses I listed. The Onion and BBC will likely still be listed because the Beeb is stratified in various categories of various reliability standards, while Rottentomatoes' "top critic" The AV Club used to be part of The Onion publication and is still owned by them, so also may be worth noting as a separate category. (Of course it may be just obvious that AV Club is RS and BBC Bitesize (or whatever else the youth section used to be called) is yellow at best). That nobody finds the need to question/update the ratings here still is that the ratings are still noncontroversial as the content standards have changed which lends to the notion that they're "obvious" -- but I'd still think that my 2nd and 3rd use cases are important enough to warrant their listing.) SamuelRiv (talk) 21:12, 17 September 2024 (UTC)

Thanks for sharing your view. I wonder how widely it's held, because it's the opposite of my view, and I think both views are held by some number of editors, but I'm not sure which is consensus, and I think it would be helpful to find out. What you're describing is what I'd call a "source list" or "source index": a list of sources and whether they're reliable, useful for manual lookup, bots, scripts, and as a reference for conflict resolution. This is not the same thing as a list of perennial sources, which is, to quote the first sentence of WP:RSP: "sources whose reliability and use on Wikipedia are frequently discussed".

A source list and a perennial list have two very different purposes. The source list is to tell people about the reliability of sources. This is helpful for anyone (human or computer) who wants to find out the reliability of source--they can look it up on the list. A perennial list isn't for that purpose; rather, it tells people about whether sources have been discussed frequently. The point of the perennial list like RSP isn't to tell people which sources are reliable and which aren't, it's to reduce the number of unnecessary new threads at WP:RSN. So before somebody starts a discussion at RSN, they check RSP to make sure that source hasn't already been discussed frequently before. If it has, they can reference those discussions (and then decide if a new one is worth starting); if it hasn't, then they start the discussion.

Maybe instead of an RFC about changing RSPCRITERIA, the RFC should be about whether RSP should be a source list or a perennial list (or if it should be both, or we should have two lists). Because if it's going to be a source list instead of a perennial list, then we probably should move the page to WP:Source list or WP:Source index, and rewrite it accordingly (which would, anyway, require changing RSPCRITERIA). Levivich (talk) 21:31, 17 September 2024 (UTC)

• Personally I think the problem is not too many items on the list but that we should categorize the list better and provide the option for more, not less detail, which might mean having more detailed separate subpages about each source and the discussions or broken up in some different way. Maybe even shorter overview on the main page and an expando-collapsed template subpage. I also think one of the gaps is that there are not particularly rigorous criteria about what are acceptable arguments in RSN discussions. For example, we specifically mark self-published fact-check sites like Ad Fontes, MBFC etc as unreliable, but people still use them in arguments because there isn't a formally rigorous bar on doing so. Andre🚐 21:40, 17 September 2024 (UTC)
• Could you elaborate on the rationale for the recency requirement? I would anticipate that having something added here would cut down on future discussions of it, because it provides a "definitive" answer one way or the other, meaning entries would be removed due to "timing out" rather than an actual consensus change. Nikkimaria (talk) 04:18, 18 September 2024 (UTC)

  At some point, the determination becomes outdated. If we want to know if a source is reliable, it doesn't really matter what people thought about it 15 or 20 years ago. If nobody has sought to revisit the issue in that much time, it's not perennial. Levivich (talk) 14:14, 18 September 2024 (UTC)

• The determination becomes outdated when something changes, which could happen in ten weeks or ten years. But in the absence of change, consensus doesn't expire, and removing it from the list would just make that consensus harder to point to. Nikkimaria (talk) 00:59, 19 September 2024 (UTC)

  I tend to agree with Nikkimaria. While WP:CCC an old consensus still is useful. WP:RECENTISM I think otherwise. Andre🚐 01:03, 19 September 2024 (UTC)

I fail to see how the list is "too long", let alone "unmanageable". You can just use Ctrl+F or your phone browser's search function to easily find sources on the list. Furthermore, regarding the BBC News example: the reliability of its Arab version (now discontinued) was questioned not too long ago, and there's cases like that for many sources, even ones that have been considered to be reliable for a long time. I can also promise you that as soon as you remove sources like that from the list, this is going to be used as a bad faith attack vector by people who want to remove well-sources content from Wikipedia. Cortador (talk) 08:37, 18 September 2024 (UTC)

WP:CHOKING has a little on that. Gråbergs Gråa Sång (talk) 09:04, 18 September 2024 (UTC)

Fwiw, the Wikipedia_talk:Reliable_sources/Perennial_sources#Page_size discussion is listed at WP:CR. Gråbergs Gråa Sång (talk) 09:02, 18 September 2024 (UTC)

I do think a table to lay out the clear problematic sources like Fox News, Breitbart, Forbes contributors, etc, where an explanation of why they are yellow or red, is necessary, but I would suggest that for those sources that are typically green or have little doubt to other states (like BBC, NYTimes, etc) as to list them out with links to relevant discussions as we have done at WP:VG/S at the end of the page. We should try to document and index those discussions, but inclusion in the table is too much. emphasis for t — Masem (t) 15:27, 18 September 2024 (UTC)

Whatever happens there needs to be a list of prior discussions on RSN, so that the same discussions aren't just repeated endlessly. This is at odds with making a comprehensive list where sources are added so they can be formatted green by scripts. As to old discussion maybe after a defined time maybe they could be moved to an archive list. I think the question of what should this list be is the first one to answer. If it should be a list of prior discussions the criteria should likely be tightened up, if it should be comprehensive then criteria should be quite different and a new listing of prior RSN discussions needs to be made. -- LCU ActivelyDisinterested «@» °∆t° 16:23, 18 September 2024 (UTC)

At this point I think the contention between having a general list and a summary of past RSN discussions can only be solved by splitting. That way the two purposes want be at odds with each other. This page could be marked as historical a new "Sources list" could be created listing all sources and something else created to only list past discussions. The past discussions list could then have it's inclusion criteria tightened. -- LCU ActivelyDisinterested «@» °∆t° 17:19, 19 September 2024 (UTC)

I am basically with Andrevan, in that I think the issue is not the length but the lack of organization. If anything I would like to add as many sources as possible to the list. Loki (talk) 22:52, 18 September 2024 (UTC)

Concur. Maybe have a general source list and a subset of those listed as "perennial"? But at that point the second page seems sorta redundant. Elli (talk | contribs) 16:51, 19 September 2024 (UTC)

• I'm strenuously opposed to mass-removing entries from RSP, or to any significant changes to how sources are added to it. Not everyone has heard of eg. The Onion; and a lack of recent discussions about a source is often a sign that it is working. Documenting even a loose or limited consensus about a source is, to me, more valuable than having nothing here about that source or forcing editors to waste time digging up previous discussions themselves. I also don't see any purpose to insisting on a specific number of discussions - sometimes it is obvious that a source could be / will be a problem, especially if its reliability differs from what you'd think just by glancing at it; there is no disadvantage to just labeling it immediately. We live in an age of widespread misinformation, including many new websites specifically dedicated to misinformation and many previously-reliable sources that have suddenly declined sharply in reliability; being able to identify those sources rapidly and indicate them in a central place like RSP is valuable, whereas insisting that they be discussed X times before we can indicate that they're unreliable here would only harm our ability to deal with them.

But I do think that it might be worth emphasizing that entries here are, in most cases, just broad temperature-checks; they're not intended to be the final be-all and end-all, they're intended to save time by reducing redundant discussions and by giving people an easy starting point when considering or discussing a source. Improving its organization might also be a good idea, although if possible having everything on one page so it can be easily searched is valuable - possibly we could have one page with every entry and move the detailed text to subpages (or just move it to subpages in cases where a conclusion is obviously straightforward.)

Overall it's important to recognize that RSP is working - our sourcing has improved dramatically since we started using it. We have gotten lots of coverage describing Wikipedia as one of the few sites on the internet that has successfully handled the modern age of disinformation: [1][2][3] I don't think there's any real justification for sweeping changes. --Aquillion (talk) 18:30, 21 September 2024 (UTC)

RFC question

Thank you to everyone for taking the time to share their thoughts. I think it's pretty clear that my proposing the tighter criteria I suggested above is not the way to proceed. I'm thinking, instead, of a much broader, open-ended RFC question, maybe something like:

Should WP:RSP be changed?

That would allow responses that advocate for change in various directions (smaller/bigger, looser/tighter, one list/two list, etc.), or no change at all. Thoughts? Levivich (talk) 17:42, 19 September 2024 (UTC)

I doubt an open-ended RFC like that would likely produce a useful consensus. We should spend some more time on workshopping potential reforms first. Elli (talk | contribs) 17:23, 20 September 2024 (UTC)

• That's a bit too open-ended; it changes constantly by definition. I would break it down into specific directions for change, like eg. whether we should restrict what can be added to it or mass-remove significant numbers of existing entries. --Aquillion (talk) 18:32, 21 September 2024 (UTC)

  Like multiple choice? Levivich (talk) 19:00, 21 September 2024 (UTC)

My suggestion would be to break out sources by category.

So for example, breaking out all the WP:NEWSORGs into a separate page, then maybe all the social media, then all the NGOs, etc etc. Loki (talk) 18:40, 21 September 2024 (UTC)

• I would think for entries to be credible as a WP-wide guidance it should be about multiple articles involved, not multiple times discussed in perhaps just one article which would be more cleanly handled at that article. And for there to be some guidance about if and how the list is cleaned -- is it a forever ban regardless of years later changes, is it by they just age off, is it someone has to jump hoops to do a new RFC, or is it just WP:TNT the whole existing list and start over ? Cheers Markbassett (talk) 04:59, 13 October 2024 (UTC)
• Yes/Support, reform is needed, if not abolition. The RSP list is an often misused tool with many people using it forgetting WP:RSPISNOT and WP:RSPIS and just outright using the list as an excuse to widely remove source citations that have been deprecated from any and all articles in which the sources appear.Iljhgtn (talk) 16:11, 31 October 2024 (UTC)

Why is this not a guideline?

Considering how much this page gets cited in talk page discussions and the number of bytes typed out to make minor adjustments to single entries (for example), is there any real reason why it hasn't got upgraded to formal WP:PAG status yet? ~~ AirshipJungleman29 (talk) 13:07, 2 October 2024 (UTC)

Trivial answer: because there wasn't any interest the last time it was suggested. Personally, this just doesn't feel like guideline material, which possibly isn't any more satisfying of an answer. It's hardly the only widely-cited project page which isn't a guideline: for instance WP:BRD is an essay, and WP:NOTHERE is part of WP:BUILDWP which is also an essay. Caeciliusinhorto-public (talk) 13:29, 2 October 2024 (UTC)

Because as an explanatory essay, it's a list of how to apply a guideline. It's not consensus; instead, it's a summary of existing consensus found elsewhere. Usually, PAG contain procedures or principles that aren't subject to much change. Aaron Liu (talk) 20:29, 2 October 2024 (UTC)

And because it should not be. If it were to be, then it should receive much, much, much more broad based consensus than it has. It already does quite a lot of damage to Wikipedia as it is right now. Iljhgtn (talk) 16:28, 31 October 2024 (UTC)

I agree, but damage‽ Aaron Liu (talk) 16:40, 31 October 2024 (UTC)

In the form of misuse and abuse. See WP:RSPISNOT and WP:RSPIS. These are oft ignored, and until that is resolved, yes, damage is being done to the encyclopedia's credibility and quality. Iljhgtn (talk) 18:03, 31 October 2024 (UTC)

Posting a source to RSP

Hi editors. I’m posting here to ask if someone will add Bloody Elbow to RSP list for its content prior to March 2024 based on an RfC and two prior posts that found it to be generally unreliable. [4], [5], [6]. While not attracting wide participation, the RfC (which I started) and at least one of the two discussions meet the specific WP:RSPCRITERIA for minimum participation: For a source to be added to this list, editors generally expect two or more significant discussions about the source's reliability in the past, or an uninterrupted request for comment on the source's reliability that took place on the reliable sources noticeboard. For a discussion to be considered significant, most editors expect no fewer than two qualifying participants for RSN discussions where the source's name is in the section heading, and no fewer than three qualifying participants for all other discussions. I may have a COI since I am a paid consultant for WhiteHatWiki, whose clients include One Championship, which was covered by Bloody Elbow. Bloody Elbow is cited as a source on the One Championship page, where it is used inappropriately as an unreliable blog. So even though the discussions on the merits are concluded, I think an independent editor should prepare and post the RSP summary. There is a distinction between the blog pre-March 2024, and the site under new owners since then, which needs to be part of the description. If other editors think the RSP needs to be handled differently, or think I should just do it, please discuss.

User:ActivelyDisinterested suggested this request be posted here instead of RSN, so I have closed that request. Brucemyboy1212 (talk) 21:39, 15 October 2024 (UTC)

Not at all sure that this qualifies as a Perennial source. Only two discussions and an RFC?

I don’t know the source well enough to judge the sources reliability… but I would agree that the consensus seems to be that it is unreliable. My question is just whether we need to list it at RSP. Remember, RSP isn’t supposed to be a list of every source deemed unreliable. Only those that have been perennially discussed.

Out of curiosity, How frequently is this one cited? Blueboar (talk) 21:54, 15 October 2024 (UTC)

This is a big problem in many of the most important articles about professional fighting. Bloody Elbow is cited 1778 times on Wikipedia, including Boxing, Judo, the UFC, Muhammad Ali, Mike Tyson, Bruce Lee. Floyd Mayweather Jr., Joe Rogan, and Connor McGregor. There are many highly reliable sources available for these topics, yet a tiny blog (sometimes written by fans), and without professional editorial standards and oversight of a larger editorial publication (which sometimes results in the publication of unsubstantiated rumors), continues to be heavily used. Most of these citations followed the 2013 RSN determining the source was generally unreliable. [7]. I had no intention of requesting placement on RSP, but on the One Championship page, an editor flat out refused to even entertain the notion that Bloody Elbow was unreliable, despite the 3 RSN discussions over 11 years. Talk:ONE Championship#Paid Edit requests for September 2024. Then I looked more deeply into how pervasive the blog has become on the most important articles on this topic. Without the visibility of the RSP, I think the misuse of this blog pre-March 2024 will remain pervasive on many of the important professional fighting pages. The alternative is to leave the citations unchallenged or repeatedly have the same discussion as RSN on article Talk pages, since at least some editors give no weight to ordinary RSN. @Blueboar: I hope this answers your question. Brucemyboy1212 (talk) 16:25, 16 October 2024 (UTC)

Editors interested in the WP:RSCONTEXT should see Talk:ONE Championship#Paid Edit requests for September 2024. -- LCU ActivelyDisinterested «@» °∆t° 21:56, 15 October 2024 (UTC)

Legal Information Websites as Reliable Sources

I feel like websites that let you find cases (criminal & civil) such as FindLaw, Justia and Casetext (now CoCounsel) should be on here. Me and other users have used them for crime related articles and were proven to have been useful. With that being said, shouldn’t they be on the list for reliable sources or are the uses for it too limited? News websites seem to be used for any topic, but for sources that deal with law, it appears they have only a specific use. YatesTucker00090 (talk) 03:05, 20 October 2024 (UTC)

Only sources that have been regularly discussed on the reliable sources noticeboard appear on this list. As an aside I suggest being careful with such sites and articles about living people due to WP:BLPPRIMARY. -- LCU ActivelyDisinterested «@» °∆t° 19:39, 20 October 2024 (UTC)

Find-a-Grave is partly reliable

The "Find a Grave" website is listed as unreliable because content is "user generated". However, this is only partly true. Reliable information includes: location of the cemetery; photographs of grave markers, showing name and birth/death dates. WCCasey (talk) 15:49, 22 October 2024 (UTC)

@WCCasey: Having worked on thousands of graves on the site, I've found countless issues and found quite a few headstones incorrectly attached to various families. I can't speak for everyone, but I definitely wouldn't support it being listed as anything other than unreliable. Hey man im josh (talk) 16:51, 22 October 2024 (UTC)

I have also found headstones misidentified. However, this is very unlikely for anyone notable enough for inclusion in WP. To be clear, I think additional sources are necessary for verification of info on a Find a Grave page. The case that prompted me to write this was an article where a person's burial location was deleted because Find a Grave was cited as a source. I guess my real issue is with editors who automatically delete any instance of Find a Grave sourcing along with the the information it's attached to, without bothering to look for other sources. WCCasey (talk) 16:31, 23 October 2024 (UTC)

@WCCasey: They should remove information that's only verified by Find a Grave. If they're notable enough the information provided by a headstone will have been mentioned elsewhere as well. We simply cannot rely on user generated content that has no oversight. There's countless examples of people fighting to have incorrect information updated on a Find a Grave page. I've actually also found incorrect information on a number of graves, and my Find a Grave profile has upwards of 2,000 profiles managed. Hey man im josh (talk) 16:35, 23 October 2024 (UTC)

And even if you're positive it's the correct gravestone, the gravestone itself may not be reliable. See this footnote to Dorothy Shaver, the year of birth on her gravestone is deliberately false. Schazjmd (talk) 16:47, 23 October 2024 (UTC)

Much like Discogs with pictures of album labels, the only thing Find a Grave could be could be considered reliable for is a photograph of a tombstone, which would be a primary source at best. Ignoring the not-uncommon errors of transcription (e.g. someone records 1958 as 1953 because of glare or moss or carelessness), I've seen many birth & death dates on tombstones that contradict other published sources. The user-submitted genealogy info (that often doesn't come from individual grave markers themselves) is often incomplete, and sometimes wrong. --Animalparty! (talk) 21:42, 26 October 2024 (UTC)

Inclusion of the Metro on the list

Reading through the listed discussions the only ones that are about the Metro are that it's reliable for details about soaps and sports, all the other bar one are but passing mentions my individual editors in discussions about other sources. The last one is a that an opinion piece is not reliable for calling a BLP a "horrid person". -- LCU ActivelyDisinterested «@» °∆t° 16:45, 22 October 2024 (UTC)

Sticky header, loss of color

@Headbomb and Timeshifter: I am not sure what went down, but sometime in the recent past, the user interface deteriorated. The header that follows around is highly annoying, then more recently everything turned into the same color. I reverted to how it's been for ages. I skimmed through talk and I don't see consensus in favor of change, but feel free to revert if there's been discussion elsewhere and the change was the result of community consensus. Graywalls (talk) 03:05, 27 October 2024 (UTC)

"header that follows around is highly annoying"

No idea what you're referring to here. Headbomb {t · c · p · b} 03:32, 27 October 2024 (UTC)

If you were to go to WP:ADFONTES, then it will take you to that entry in RSP with it indexed at the top edge of the browser. With sticky header enabled, it is buried under the header that moves around and you have to scroll up to see it. In my opinion, this is highly annoying. The loss of table color was not an improvement either. I've just undone the changes to table code that transpired in mid August. Graywalls (talk) 04:07, 27 October 2024 (UTC)

If that's the only problem with sticky-headers, that's a specific breakage that affects usability and should be avoided. That's actionable from several ways, rather than simply what comes off as a just IDONTLIKEIT "it's annoying". DMacks (talk) 10:14, 27 October 2024 (UTC)

For user interface, I think it comes down to like / dislike by community input. For a great length of time, it's been without the floating/sticky header and some editors thought it was more likeable with it, and I and perhaps others thought it is more likable without it. So, return to the past, and WP:BRD, right? Graywalls (talk) 11:59, 27 October 2024 (UTC)

The loss of color is a side-effect of a change in the sticky-headers css that was made yesterday to address a different color problem in sticky-header tables. I filed a note about it. DMacks (talk) 11:24, 27 October 2024 (UTC)

See discussions:

• Template talk:Sticky header#This template stops another from working without the wikitable class - scroll down for the perennial sources connection.
• Wikipedia talk:Reliable sources/Perennial sources/styles.css

For testing see the old version of the article that uses {{sticky header}}.

The loss of color has been fixed as far as I can tell. The WP:ADFONTES problem remains for any skin other than Vector 2022. See:

• Template talk:Sticky header#Sticky header covering jump result.

--Timeshifter (talk) 08:53, 29 October 2024 (UTC)

Sticky header should work better now for Vector 2010 users

I made the table header one line. Added {{sticky header}} back since colors are working again.

Narrower one-line header should make shortcuts work better for the few logged-in users who use Vector 2010. Default is Vector 2022 and it works perfectly with the shortcuts.

I tried doing this in a sandbox but kept getting stopped by the software due to all the illegal links. So I did it here so that people can try it out.

It is this version of the article.

Here is the "Ad Fontes Media" shortcut used with the improved version of the table:

• https://en.wikipedia.org/w/index.php?title=Wikipedia:Reliable_sources/Perennial_sources&oldid=1254335413#Ad_Fontes_Media

In Vector 2022 it is working perfectly. In Vector 2010 one can now read "Ad Fontes Media". --Timeshifter (talk) 14:51, 30 October 2024 (UTC)

Sticky header user interface community input

There has been an initiative to change the interface so that the gray header at the top of the table "follows around" as you scroll down. See: {{sticky header}}. Which of the choices below (A-E) do you prefer? What other ideas do you have?

The header is now 2 lines tall. What Timeshifter is now proposing (scroll down this example) is a narrow one-line sticky header with a link from the "Status" column head back to the "Legend" section of the article. And a link from the "Sources" column head back to the "Sources" section of the article. Notes explain this just above the table. He states this allows new users of the table to quickly return to the table TOC, or to quickly find the meaning of the legend icons.

An issue in any skin other than the default Vector 2022: When you use the horizontal table TOC, or if you follow ("jump to") an anchored link within the table such as WP:FORBESCON, the top line of the note in the row you jump to would be covered by the narrow sticky header. 2 lines are covered by the 2-line header. Template discussions have not found a way to fix this. Timeshifter does not believe this is a serious problem. Others do. One solution (see E below) is to add a line's worth of blank padding at the top of each row.

• A: No sticky header, same style (2-line) header as before.
• B: Full size (2-line) header with sticky enabled.
• C: Narrow (1-line) header without sticky enabled.
• D: Narrow header with sticky header that follows you around.
• E: Same as D, but with padding at the top of each row.

Graywalls (talk) 15:04, 30 October 2024 (UTC). Edited per WP:RFCNEUTRAL by Timeshifter (talk) 11:46, 3 November 2024 (UTC).

Another shortcut (for Forbes.com contributors) with the improved narrow-header version of the sticky table:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Reliable_sources/Perennial_sources&oldid=1254540261#Forbes.com_contributors

The benefits of having the sticky header far outweigh the small inconvenience for the relatively few people using Vector 2010 of having to scroll up a tiny bit to see one line of missing text at the top of the notes column. They can see everything else in the Forbes.com row.

By the way, your history is off. The {{sticky header}} was up without complaints for over 2 months (since Aug 21, 2024) after I changed from {{sticky table start}} and did my final tweak. See Aug 21, 2024 version.

Recently, there were changes by the template editor that messed up the colors, but those have been fixed.

--Timeshifter (talk) 15:38, 30 October 2024 (UTC)

"This template is used on approximately 4,400 pages" sums up the use of the sticky banner. How does it look on mobile? Why reinvent the wheel here when the people shifting through the table know what the columns represent. Also, it's a Wikipedia namespace, not an article. Do whatever you want, I guess. – The Grid (talk) 17:11, 30 October 2024 (UTC)

• A, C, D, B in decreasing order of preference, unless something can be done to prevent the overlapping of the header and the cell content (which might be fixable with a bit of cell padding at the top of the cells, at the cost of making the entire page visually longer; there might also be a JS way to fix this, by forcing a slight scroll-up after page load if a #Section link is in the URL). The overlap interfering with utility for everyone is not surpassed by the sticky header provding some utility to a minority of new editors at the page who aren't sure what the columns are. Especially given that it's pretty obvious what they are, and nearly no one needs most of them anyway, only Source and Summary. If the sticky header were imposed, then use the more concise version; the bigger one isn't actually any more helpful as a sticky. But if sticky is not imposed, maybe keep the more explanatory version, which provides a hint of organizational/thematic clarity as a top-of-table header that appears once. If not sticky, also put the header at the bottom of the table, so someone who doesn't remember what the columns are but is nearer bottom of page can scroll there to find out instead of all the way back to the top.  — SMcCandlish ☏ ¢ 😼  19:06, 30 October 2024 (UTC)

Cell padding at the top of each row would work.

A JS and/or CSS solution would be better. Any ideas how? That's beyond my level of skill.

I set up (and immediately reverted) a sticky narrow header with the "Sources" column head linking to the Sources heading. The "Status" column head links to the Legend heading. I substituted that version link for "D" above. Click it to see the changes.

This makes the sticky header much more useful. It allows one to instantly go to the legend section. New people are going to be confused by the legend symbols, and will want a rapid way to get back to that section. Especially important in Vector 2010 where the TOC doesn't follow you around.

The Sources column head link takes one instantly back to the horizontal table of contents from anywhere in the table without tedious scrolling. So one can choose another letter.

A header at the bottom of a long table is not as useful as a sticky header. It takes a long time to scroll from the middle of this long table to the bottom of the table.

I added a couple notes just above the table. See sticky narrow header with notes here.

--Timeshifter (talk) 14:26, 31 October 2024 (UTC)

It still causes the first line to be missing. Graywalls (talk) 03:39, 3 November 2024 (UTC)

• A if editors want the benefit of a sticky header, they should enable that preference in the gadgets section of their preferences page. On this particular page, the benefit (if any), is minimal at best. When I use RSP, I know what source I am searching for and am basically looking for the color of the source and the discussion. I also use ctrl+f to quickly find what I am looking for sometimes. I was pleased when it was changed back to the status-quo. Isaidnoway (talk) 14:41, 2 November 2024 (UTC)

Non-logged-in editors don't have that gadgets option.

So you have the meaning of the legend icons memorized? Good for you. But non-regular users of this page do not. The "status" column head link takes them to the Legend section. That link is handy because the sticky header follows the reader as they scroll down the table. Is it not useful to users who don't have the legend icon meanings memorized? --Timeshifter (talk) 12:08, 3 November 2024 (UTC)

• A all the way. It simply works. Graywalls (talk) 03:40, 3 November 2024 (UTC)
• D, E, C in decreasing order of preference. Benefits, especially for new or infrequent readers of this page, outweigh the tiny problem of one line of notes being covered in secondary skins. People know how to scroll up to see it. Vector 2022, the default skin, does not have the problem. --Timeshifter (talk) 11:53, 3 November 2024 (UTC)