Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Compute labor supply response revenue_change instead of preserving legacy zero

Abierto
#369 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python

Línea de trabajo

Comienza con calculate_labor_supply_response(...) y revisa el PR #360 para entender la salida existente de LaborSupplyResponse y el comportamiento heredado de budgetary_impact_lsr. Define el significado y la convención de signos de revenue_change y, a continuación, identifica las salidas de simulación disponibles necesarias para calcularlo. Se considera terminado cuando las ejecuciones activas producen efectos no nulos probados, las ejecuciones inactivas siguen siendo cero y cualquier divergencia heredada está documentada.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Context

PR #360 (Add labor supply response macro output) adds a 4.x-compatible LaborSupplyResponse output that preserves the legacy macro output shape.

As part of that parity work, revenue_change is intentionally set to 0.0 because the legacy API initialized budgetary_impact_lsr to zero and never populated it. That preserves existing public behavior, but it leaves a real fiscal-effect gap: callers may reasonably interpret labor_supply_response.revenue_change as the tax/revenue impact caused by labor-supply responses.

Current behavior

calculate_labor_supply_response(...) computes LSR behavioral quantities such as:

  • income_lsr
  • substitution_lsr
  • total_change
  • relative_lsr
  • decile average/relative breakdowns
  • hours effects where supported

But revenue_change remains hard-coded to 0.0 for both active and inactive LSR paths.

Desired behavior

Determine and implement the correct fiscal calculation for LaborSupplyResponse.revenue_change, rather than preserving the legacy zero.

Acceptance criteria

  • Define the intended meaning and sign convention for revenue_change.
  • Compute revenue_change for active LSR runs using available simulation outputs or clearly documented additional required outputs.
  • Preserve zero behavior for inactive LSR runs.
  • Add focused tests for non-zero revenue effects, zero/inactive behavior, and sign convention.
  • Document any intentional divergence from legacy budgetary_impact_lsr behavior.

Related PR: #360

Lenguaje dominante
Python
Estrellas
7
Forks
9
Merge medio
13 h 12 min
PR fusionados (30 d)
11

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PolicyEngine/policyengine.py

Todos los issues de PolicyEngine/policyengine.py

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.