La capacidad de respuesta mide si el trabajo que llega a un proyecto — informes de errores, solicitudes de funcionalidades, parches aportados — se atiende realmente. Un gestor de issues donde los informes se acumulan sin respuesta, o una cola de pull requests cerrados sin consideración, predice la experiencia que tendrá cada futuro usuario y colaborador.
- Categoría: Sostenibilidad y Gobernanza (25% dentro de la categoría)
- Peso en el índice general: 6,0%
- Clave de la métrica:
responsiveness nullcuando el repositorio no tiene issues ni pull requests decididos
Cómo se calcula el valor
| Componente | Peso | Criterios |
|---|---|---|
| Resolución de issues | 46,75 | proporción de issues cerrados sobre el total × 46,75 |
| Aceptación de PR | 38,25 | merged / (merged + closed unmerged) × 38.25 |
| OpenSSF Scorecard: Code-Review | 15 | resultado 0–10 de Scorecard, escalado a 15 puntos |
Los recuentos son totales de toda la vida del proyecto. Los percentiles de latencia — con qué rapidez se deciden los issues y pull requests, sobre una ventana reciente — figuran en la hoja de ruta publicada de la metodología y llegarán con un cambio de versión (véase versiones de la metodología).
Code-Review es evidencia compartida complementaria: comprueba las aprobaciones sobre los conjuntos de cambios, mientras que la aceptación de PR mide los resultados de fusión. Sigue siendo un componente de Seguridad y se excluye aquí si Scorecard no está disponible o informa n/a.
Qué significan las dos proporciones
- La resolución de issues lee la fracción de issues presentados que alcanzaron una decisión. Los proyectos que hacen triaje con honestidad — corrigiendo, respondiendo o cerrando con un motivo — puntúan bien; los proyectos donde los issues se apilan en silencio puntúan bajo.
- La aceptación de PR lee qué ocurre con el código aportado entre los pull requests que alcanzaron una decisión. Una proporción de fusión muy baja suele señalar un proyecto que recibe contribuciones pero no puede o no quiere absorberlas.
Cómo interpretar el resultado
- Cerrar es decidir. La métrica no exige que cada issue se corrija — un «wontfix» gestionado es una decisión. Lo que penaliza es la acumulación sin límite.
- Las proporciones de toda la vida se mueven despacio. Un proyecto que ha mejorado recientemente su triaje verá esta métrica recuperarse de forma gradual; las medidas de latencia con ventana temporal de la hoja de ruta harán más visible el comportamiento reciente.
- Los repositorios con los issues desactivados y sin historial de PR son
nullaquí, con renormalización de pesos — véase el índice de salud.
Cómo mejorar el valor
- Hacer triaje con regularidad: etiquetar, responder y cerrar los informes estancados con un motivo declarado en lugar de dejarlos abiertos indefinidamente.
- Decidir los pull requests en ambos sentidos — fusionar los buenos y declinar explícitamente los inadecuados cuentan por igual como custodia.
- Las plantillas de la salud de la comunidad elevan la calidad de lo que llega y abaratan el triaje sostenido.
Relacionado: resiliencia de mantenedores · Sostenibilidad y Gobernanza