PolicyEngine / policyengine-app

PolicyEngine's free web app for computing the impact of public policy.
GNU Affero General Public License v3.0
37 stars 99 forks source link

In the policy editor, raising the minimum wage from $7.25 to $15 produces no impact charts #816

Closed anth-volk closed 10 months ago

anth-volk commented 10 months ago

Seems like raising it should at least cause impacts upon poverty, etc.?

MaxGhenis commented 10 months ago

So far the minimum wage only affects the New Mexico CDCC (per searching the US repo). Raising it to $15 does correctly affect New Mexico, but not the US as we currently only show state-level impacts of state-level reforms.

abhcs commented 8 months ago

@MaxGhenis Your comment explains why the bug exists, but it's still a bug. In the workflow described here and in #1178, the user has no idea that the reform only affects New Mexico, and will assume that PolicyEngine is reporting the effect on the US. In contrast, changing the parameter gov.states.ca.tax.income.exemptions.amount warns the user that the parameter only affects CA:

Screenshot 2024-01-12 at 12 27 08 PM

A similar message could be shown here when the user attempts to run the simulation:

PolicyEngine only models this parameter for New Mexico. Change the simulation region...

Furthermore, in New Mexico, the budget is impacted, but the other metrics are not:

Screenshot 2024-01-12 at 12 30 43 PM

Perhaps only the effect on the budget is simulated in the back end?

Even if I change the parameter to $500 I get the same impact on budget and no impact on other metrics. I am not sure that this parameter is functional.

MaxGhenis commented 8 months ago

We provide a static model of tax-benefit rules, and therefore only model interactions with those systems. Confusion around this seems to reflect a more general opportunity to clarify the scope of the policies we model, and the downstream impacts of adjusting a given parameter. In reality, changing virtually any of our policy parameters would also have some effect on wages, but we only show direct effects.

In the New Mexico case, their CDCC is a small program, and the minimum wage only affects a minor part of it. So it's not surprising that it wouldn't move anyone above the poverty line. As you can see from the decile charts, we model the changes throughout the microsimulation, not only the budgetary impact.

anth-volk commented 8 months ago

At the very least, though, this behavior does seem confusing to the casual user, right? Minimum wage increases have been one of the most visible and contentious tax system-related policies over the last few years, and so I could imagine being a staffer unfamiliar with most of what you've described above using PolicyEngine to attempt to calculate some US-wide policy impact and hitting what looks like a major bug, since we don't even warn users that this isn't a US-wide variable. I think we need to discuss at least doing something on the front end that warns users about this, even if it is intended behavior.

abhcs commented 8 months ago

@MaxGhenis Thanks for that extended explanation: it cleared up some of my confusion. The fact that we are building a "tax-benefit reform" is mentioned on the landing page for the policy calculator. However, once you move on to modifying your chosen parameter this fact is not mentioned again. For instance, on this page, there isn't enough information to let the user know the context in which they are making the change. The user isn't changing the federal minimum wage in a general context but in the context of /nm/tax/income/credits/cdcc/.

My concerns in this comment and the previous one are similar to the ones mentioned in #1033 where I (as a layperson) am getting confused and need more information. On the other hand, too much information/guidance can make the UX cluttered and unhelpful. So, I understand that designing the interface is a challenging task.

The first half of my previous comment (and @anth-volk 's comment) needs some attention. We should warn the user that the context is limited to /nm/tax/income/credits/cdcc/. This problem may also exist for other parameters. To solve this problem more generally, we could compute valid contexts for each parameter by going through each variable in the model (there may exist more efficient ways to do this).

MaxGhenis commented 8 months ago

Yeah, I'm reluctant to hard-code the NM CDCC as the context for the minimum wage, since (a) we don't do that for other parameters, and (b) we would cite the same parameter for other tax-benefit programs if they also depend on the federal minimum wage, and I wouldn't want to miss that.

I'd suggest we take two steps:

  1. Short term: Clarify the minimum wage parameter only affects taxes and benefits, not wages https://github.com/PolicyEngine/policyengine-us/issues/3607
  2. Long term: List variables affected by a parameter - this will take a bit of cross-repo work to get into the app, but I expect we'll start with https://github.com/PolicyEngine/policyengine-core/issues/146

Do these address your concerns?

abhcs commented 8 months ago

Yes, they do. Once we have the long-term item completed, we can extract the regions from the list of variables, and warn the user about the limitations of the simulation by listing affected regions. We can also potentially extract other useful information about the interaction between variables and parameters from such a list of variables.