La salud de la comunidad mide si un repositorio está preparado para recibir usuarios y contribuyentes: los archivos estándar que dicen a quien llega qué es el proyecto, en qué términos puede usarse y cómo participar. Estos archivos son la diferencia entre una base de código y una comunidad.
- Categoría: Comunidad y Adopción (35 % dentro de la categoría)
- Peso en el índice general: 6.3 %
- Clave de la métrica:
community_health
Cómo se calcula el valor
Una lista de verificación ponderada de los archivos estándar, cada uno presente o ausente (la fila de la licencia también puede obtener crédito parcial — véase más abajo):
| Componente | Peso |
|---|---|
| README | 22.5 |
| Licencia | 22.5 |
| Guía CONTRIBUTING | 18 |
| Código de conducta | 13.5 |
| Plantilla de issues | 7.2 |
| Plantilla de PR | 6.3 |
Cómo se detecta la licencia
La presencia de licencia se comprueba una sola vez, a partir de tres fuentes consideradas en conjunto: los metadatos de licencia del propio repositorio, el perfil comunitario de GitHub y la comprobación License publicada y neutral en cuanto a herramientas de OpenSSF Scorecard. Un archivo que vea cualquiera de las fuentes cuenta como presente — las fuentes discrepan en torno al 1 % de los repositorios, y un único punto de acceso no disponible no debe informar de una licencia como ausente.
El resultado es uno de tres estados:
| Estado | Significado | Crédito |
|---|---|---|
| Estándar | Una licencia reconocida, identificada por código SPDX | 22.5 |
| Personalizada | Existe un archivo de licencia, pero su texto no es una licencia reconocida | 16.9 |
| Ninguna | Ninguna fuente encontró un archivo de licencia | 0 |
Una licencia personalizada es una licencia real y obtiene la mayor parte del peso. No obtiene la totalidad: una licencia que las herramientas automatizadas no pueden identificar es un obstáculo genuino para la adopción, porque las herramientas de políticas, la revisión corporativa y los registros de paquetes se basan en identificadores reconocidos, y quien la lee no puede determinar qué está permitido hacer sin leer el texto por sí mismo. GitHub informa de este caso como NOASSERTION — una licencia que encontró pero no pudo clasificar, lo que no equivale a la ausencia de licencia.
El resultado de Scorecard sigue siendo un componente de la métrica de seguridad; aquí es una de las tres entradas, mostrada simplemente como License.
Por qué estos archivos tienen peso
- El README y la licencia soportan la carga. Un repositorio sin README es inadoptable; un repositorio sin licencia es legalmente inutilizable en la mayoría de las organizaciones — ningún equipo legal aguas abajo aprobará una dependencia cuyos términos están sin definir. Juntos suman la mitad de la métrica.
- CONTRIBUTING y un código de conducta convierten el interés pasajero en participación sostenida, lo que alimenta directamente la continuidad que mide la resiliencia de mantenedores.
- Las plantillas elevan la calidad de la señal de los issues y pull requests entrantes, reduciendo la carga de triaje de los mantenedores — un factor pequeño pero real en la capacidad de respuesta que un proyecto puede sostener.
Cómo leer el resultado
- La lista de verificación es independiente de la escala: un proyecto de una semana puede alcanzar 100 antes de su primera estrella, y un proyecto famoso sin licencia se lee visiblemente incompleto. Es intencionado — esta métrica mide preparación, no tracción.
- Lo que se verifica es la presencia, no la calidad de la prosa — véase la nota de honestidad de la medición en señales, no garantías.
Cómo mejorar el valor
Cada componente es directamente accionable en menos de una hora:
- Redactar un README que cubra qué hace el proyecto, la instalación y un ejemplo mínimo.
- Añadir un archivo
LICENSEcon una licencia SPDX reconocida. - Añadir
CONTRIBUTING.md, unCODE_OF_CONDUCT.mdy plantillas de issues/PR bajo.github/.
Esta suele ser la métrica más rápida de mover en toda la metodología.
Relacionado: Comunidad y Adopción · documentación