When taxes and transfers are included, poverty is much rarer than commonly reported. But what actually reduces it?
America has spent more than $20 trillion on fighting poverty since the introduction of President Johnson’s Great Society program in 1964. Sixty years later, how are we doing?
That depends, as it turns out, on how you measure it.
Last month, Senator Kennedy (R-LA) introduced a bill that would require the Census Bureau to report a new poverty metric as an alternative to the Official Poverty Measure (OPM) by including both cash and non-cash welfare benefits in its calculations.
As Kennedy points out, this is a much-needed fix. The OPM’s methodological weaknesses are well documented. Most notably, it ignores the hundreds of billions of dollars the government spends each year to assist low-income families through tax credits like the Earned Income Tax Credit and in-kind transfers such as Medicaid, food stamps, and housing subsidies. In short, the OPM paints an egregiously inaccurate picture of material poverty in America.
Kennedy’s bill would require the Census Bureau to publish the Congressional Budget Office’s more comprehensive poverty measure alongside the OPM in its annual poverty report. A similarly constructed measure was developed by economists Richard Burkhauser and Kevin Corinth in a recent paper with the National Bureau of Economic Research. After accounting for taxes and transfers, they found that the “full-income” poverty measure sat at just 3.7 percent in 2023—1.6 percent after including employer-provided health insurance—a far more optimistic look than the OPM’s 11,1 percent from the same year.
...read more at thedailyeconomy.org
pull down to refresh
related posts
Looks like there's some issue copying last paragraph. I think it has to do with having a point ("11.1") in the text part.
a far more optimistic look than the OPM’s [11.1 percent](https://www.census.gov/library/publications/2024/demo/p60-283.html) from the same year.I swapped the point for a comma and it worked.
cc@soxI tried to copy and paste this post from
thedailyeconomy.orgbut I couldn't reproduce an issue :(Maybe I'm not seeing it?
WTF! (brave PC)
Okay this is getting really interesting, on Brave the link text is not preserved ... but on Safari it is?
I'll check what's going on. Maybe the
outlook'safe' links are the culprit?On my PC (brave) it happens, I’m not sure what it could be, but if I swap the '.' for ',' the error doesn’t happen.
a far more optimistic look than the OPM’s [11.1 percent](https://www.census.gov/library/publications/2024/demo/p60-283.html) from the same year. a far more optimistic look than the OPM’s [11,1 percent](https://www.census.gov/library/publications/2024/demo/p60-283.html) from the same year.On Brave, in `compose` mode, everything seems fine. Our markdown conversion pipeline shouldn't differ between browsers, but on Safari this bug doesn't happen.
I'll keep investigating.
Okay I think I got what's happening here, the clue is:
We check for misleading links, stuff like
[google.com](bing.com)and we replace the 'misleading' link with[bing.com](bing.com). You know, to keep it fair.But the way we check for misleading links seems to differ between browsers. For Safari,
https://11.1 percentis of course not a domain and not even a URL; for Chromiumhttps://11.1 percentis instead a perfectly valid URL and will trigger the misleading link replacement.We need to make the check more clever.
Great!
Solution: make your own function to check for valid links! ~lol
gh issue: https://github.com/stackernews/stacker.news/issues/2889