Compute labor supply response revenue_change instead of preserving legacy zero
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
- Área
- backend-api-design
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_lsrsubstitution_lsrtotal_changerelative_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_changefor 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_lsrbehavior.
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
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de PolicyEngine/policyengine.py
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
PolicyEngine/policyengine.py#473 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
PolicyEngine/policyengine.py#436 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
PolicyEngine/policyengine.py#408 ·
-
PolicyEngine/policyengine.py#528 · 1 asignado ·
-
PolicyEngine/policyengine.py#527 · 1 asignado ·
Todos los issues de PolicyEngine/policyengine.py
Issues similares
-
[Bug] reef-hermes tells me to resume with hermes --resume, which does not work from my shell Abiertoarea: harness bug status: needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Human-Agent-Society/reef#625 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
learningequality/kolibri#15351 · 2 comentarios ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Name consistency Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
eellak/triplestore#65 · 1 comentario ·