Mejora en el cálculo de horas para regla de licencia sin sueldo

Qué debe contener:

• 1 o 2 párrafos cortos (no bullets).
• Lenguaje no técnico o mínimamente técnico.
• Enfocado en el problema que existía y la mejora introducida.
• Si aplica, mencionar el área/módulo donde se encuentra el cambio (sin usar nombres internos de módulos).
• Debe contener por lo menos una imagen.

Guía para redactar (estructura sugerida):

1. Situación previa (breve):
   • “Antes, los usuarios experimentaban…”
2. Qué se hizo (resumen del cambio):
   • “Se mejoró / corrigió / ajustó…”
3. Resultado esperado (beneficio general):
   • “Esto permite…”, “Con esto se logra…”.

Propósito de la sección:

Desglosar de forma clara y accionable los cambios más relevantes en formato de lista.

• Entre 1 y 5 bullets como máximo.
• Cada punto debe iniciar con un verbo en pasado:
  • “Se mejoró…”, “Se corrigió…”, “Se optimizó…”, “Se agregó…”, “Se ajustó…”
• Enfocado en cambios visibles o relevantes para el usuario.

Guía para redactar:

Cada bullet debe responder a una de estas preguntas:

• ¿Qué ahora funciona mejor?
• ¿Qué error se corrigió?
• ¿Qué nueva capacidad tiene el usuario?

Propósito de la sección:

 Documentar cambios internos relevantes que no son necesarios para todos los usuarios, pero sí útiles para soporte, auditoría o desarrollo.

Usar cuando: 

• Hay cambios de librerías, arquitectura o lógica interna.
• El cambio puede ser relevante para troubleshooting futuro.
• Se requiere trazabilidad técnica.

Qué debe contener: 

• 1 a 3 bullets como máximo.
• Lenguaje técnico aceptable.
• Evitar detalles excesivamente bajos (logs, funciones internas específicas).