Capacidad de respuesta

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: 5.75%
• Clave de la métrica: responsiveness
• null cuando el repositorio no tiene issues ni pull requests decididos

Cómo se calcula el valor

Los dos primeros recuentos son totales de toda la vida del proyecto. La aceptación de PR de nuevos contribuyentes lee en cambio una ventana de 30 días; excluye los pull requests de automatismos y queda ella misma excluida — con renormalización de los pesos restantes — cuando en esa ventana no se decidió ningún pull request de un contribuyente primerizo. Solo aparece en informes producidos bajo la metodología 2.1.0 o posterior (véase versiones de la metodología). Los percentiles de latencia — con qué rapidez se deciden los issues y pull requests — permanecen en la hoja de ruta publicada.

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 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.
• La aceptación de PR de nuevos contribuyentes lee ese mismo resultado para autores sin ningún pull request fusionado previamente en el repositorio. Un proyecto puede ser rápido y generoso con sus contribuyentes habituales y no fusionar nada procedente de fuera de ese círculo; ambas proporciones divergen con suficiente frecuencia como para que solo esta describa lo que puede esperar quien contribuye por primera vez.

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.
• Una ventana sin nuevos contribuyentes no es una puntuación baja. Que nadie llame a la puerta no es el mismo hecho que no dejar entrar a nadie, y solo el segundo es obra del propio proyecto, de modo que el componente se excluye en lugar de puntuarse como cero. El denominador son los pull requests decididos de los nuevos contribuyentes, no su proporción sobre el total de fusiones: un proyecto maduro en el que los habituales aportan la mayor parte del trabajo no se penaliza por tener contribuyentes habituales.
• Los repositorios con los issues desactivados y sin historial de PR son null aquí, 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