Community health files
Community health files
GitHub reconoce un conjunto de archivos que definen cómo la comunidad interactúa con tu proyecto. No configuran build ni automatización: son metadata que GitHub renderiza en la UI (botones, banners, la pestaña Community) para guiar a contribuidores y patrocinadores.
Los archivos
| Archivo | Para qué sirve |
|---|---|
CONTRIBUTING.md | Guía para contribuidores: cómo levantar el proyecto, convenciones de commits, cómo abrir PRs |
CODE_OF_CONDUCT.md | Código de conducta de la comunidad |
SUPPORT.md | Dónde pedir ayuda (Discord, Discussions, Stack Overflow) sin abrir una issue |
FUNDING.yml | Plataformas de sponsorship; hace aparecer el botón Sponsor en el repo |
CONTRIBUTING.md
GitHub muestra un enlace a este archivo cuando alguien abre una issue o un PR (“please review our contributing guidelines”). Ahí documentás requisitos de entorno, estilo de commits y el flujo de PR esperado.
CODE_OF_CONDUCT.md
Al crearlo desde la UI de GitHub podés partir de plantillas estándar como el Contributor Covenant, muy usado en proyectos open source. Solo completás los datos de contacto.
SUPPORT.md
Redirige las preguntas de soporte fuera de las issues. Si tu repo recibe muchas dudas de uso, este archivo mantiene el issue tracker enfocado en bugs y features.
FUNDING.yml
Define las plataformas donde te pueden patrocinar. Campos típicos:
github: [usuario]
patreon: usuario
open_collective: proyecto
ko_fi: usuario
tidelift: npm/paquete
community_bridge: proyecto
liberapay: usuario
issuehunt: usuario
otechie: usuario
custom: ["https://tu-sitio.com/donar"]Con este archivo presente, GitHub muestra el botón Sponsor en la cabecera del repo.
Dónde ubicarlos
GitHub busca estos archivos en ubicaciones específicas, por orden de preferencia:
.github/- La raíz del repositorio
docs/
La ubicación recomendada es .github/ porque no ensucia la raíz del proyecto. No cambies este orden: GitHub toma la primera coincidencia que encuentra siguiendo esa prioridad.
El repositorio .github de la organización
Podés definir versiones por defecto de estos archivos para toda una organización creando un repositorio con el nombre literal .github dentro de esa org. Requisitos:
- El repo debe llamarse exactamente
.github. - Debe ser público para que el fallback aplique.
Los community health files que pongas ahí (en .github/ o en la raíz de ese repo especial) se usan automáticamente en cualquier repo de la organización que no tenga su propia versión del archivo.
flowchart TD
PR["Repo miembro-app<br/>¿tiene CONTRIBUTING.md propio?"]
PR -->|Sí| USA["Usa el CONTRIBUTING.md del repo"]
PR -->|No| ORG["Busca en el repo especial<br/>tu-org/.github (público)"]
ORG -->|Existe| FALLBACK["Aplica el CONTRIBUTING.md de la org"]
ORG -->|No existe| NADA["Sin archivo"]Esto te evita copiar el mismo CODE_OF_CONDUCT.md en cada repo: lo ponés una vez en tu-org/.github y aplica a todos.
Verificar la salud del repo
En Insights → Community GitHub muestra un checklist visual que chequea la presencia de estos archivos (más LICENSE y templates). Es la forma rápida de ver qué le falta a tu repo para considerarse “sano” según los criterios de la plataforma.
Anterior → Capítulo 6: Seguridad en Actions · Siguiente → Capítulo 8: CODEOWNERS