Cómo contribuir a open source en GitHub: guía práctica para tu primer PR

Tabla de contenido

1. ¿Por qué contribuir?
2. Encontrar el proyecto adecuado
3. Antes del código
4. Forkear y clonar
5. Hacer los cambios
6. Abrir el Pull Request
7. Después del PR
8. Buenas prácticas
9. Más allá del código

---

1. ¿Por qué contribuir? {#por-que}

Contribuir a open source no es solo para developers seniors:

Beneficio	Por qué importa
Portafolio real	Tus PRs son visibles para reclutadores
Aprender código real	Leer código de proyectos grandes enseña más que cualquier tutorial
Networking	Conoces maintainers y contributors de todo el mundo
Confianza	Perder el miedo a PRs y code reviews
Reconocimiento	Tu perfil de GitHub muestra tu actividad pública

2. Encontrar el proyecto adecuado {#encontrar}

Filtros de búsqueda en GitHub

is:issue is:open label:"good first issue"
is:issue is:open label:"help wanted"
is:issue is:open label:"beginner friendly"

Exploradores de proyectos

Sitio	Descripción
goodfirstissue.dev	Issues para beginners por lenguaje
up-for-grabs.net	Proyectos buscando contribuidores
firsttimersonly.com	Recursos para primer PR
codetriage.com	Issues por repositorio

Criterios para elegir proyecto

1. Usas la tecnología — Si usas React, contribuye a librerías React
2. Comunidad activa — Último commit < 1 mes, issues respondidos
3. Buenas prácticas — Tiene CONTRIBUTING.md, tests, CI
4. Tamaño manejable — Empieza con proyectos pequeños (< 5k stars)

3. Antes del código {#antes-codigo}

Lee el CONTRIBUTING.md

Todo proyecto serio tiene este archivo. Te dice cómo:

- Configurar el entorno de desarrollo
- Estilo de código que esperan
- Cómo nombrar ramas y commits
- Cómo pasar los tests
- Template de PR

Revisa issues existentes

# Busca issues abiertos
is:issue is:open

# Busca issues con label específico
is:issue is:open label:"good first issue"

# Comenta en el issue que quieres trabajarlo
# Así el maintainer sabe que alguien lo está haciendo

Únete al canal de comunicación

La mayoría de proyectos tienen:

• Slack / Discord
• Mailing list
• GitHub Discussions

No temas preguntar “¿por dónde empiezo?“.

4. Forkear y clonar {#fork}

# Fork desde la UI de GitHub (botón Fork ⬆️)

# Clonar tu fork
git clone https://github.com/tu-usuario/proyecto.git
cd proyecto

# Agregar upstream (el repo original)
git remote add upstream https://github.com/original/proyecto.git

# Verificar remotes
git remote -v
# origin    → tu fork
# upstream  → repo original

# Crear rama para tu cambio
git switch -c feat/mi-primer-cambio

5. Hacer los cambios {#cambios}

# Siempre sincronizar con upstream primero
git fetch upstream
git rebase upstream/main

# Hacer cambios
# ... editar archivos ...

# Ver qué cambió
git diff

# Commit con mensaje descriptivo
git commit -m "feat: add validation for email input"

# Push a tu fork
git push origin feat/mi-primer-cambio

Reglas para commits:

✅ feat: add form validation
✅ fix: correct pagination offset
✅ docs: update README with API examples
✅ refactor: extract user service

❌ update
❌ fix bug
❌ changes
❌ asdfghjk

6. Abrir el Pull Request {#pr}

Desde GitHub, verás un banner para abrir PR. Si no:

# O usa GitHub CLI
gh pr create --title "feat: add email validation" \
  --body "Closes #42" \
  --base main

Template de PR

## Descripción
<!-- Explica qué hace este PR -->

## Cambios
- [x] Nueva validación de email
- [x] Tests unitarios
- [x] Documentación actualizada

## Closes
Closes #42

## Screenshots
<!-- Si aplica, capturas del cambio -->

## Tipo de cambio
- [ ] Bug fix
- [x] Nueva feature
- [ ] Documentación
- [ ] Refactor

7. Después del PR {#despues}

El maintainer puede pedir cambios:

# Hacer cambios solicitados
git add .
git commit -m "fix: address review feedback"
git push origin feat/mi-primer-cambio

Cosas que pasarán:

Escenario	Qué hacer
Solicitan cambios	Haz los cambios, push a la misma rama
EL CI falla	Lee los logs, corrige, push de nuevo
No responden	Espera 1-2 semanas, menciona amablemente
Aprueban 🎉	El maintainer hace merge, ya contribuiste

8. Buenas prácticas {#buenas-practicas}

Haz

• PR pequeños — Un cambio por PR
• Descriptivo — Explica el qué y el por qué
• Sigue el estilo — Usa el linter/config del proyecto
• Prueba — Verifica que todo funciona
• Sé paciente — Maintainers son voluntarios

NO hagas

• PRs gigantes — 500 archivos en un PR
• Cambios sin preguntar — Comenta en el issue primero
• Push force a ramas compartidas — A menos que sepas lo que haces
• Exigir merge — Sé amable, todos aprendemos

9. Más allá del código {#mas-alla}

No todo en open source es código:

Contribución	Lo que necesitas
Documentación	Saber escribir claro
Traducciones	Saber otro idioma
Reportar bugs	Saber usar el proyecto
Diseño	UI/UX skills
Community	Responder issues/dudas
Testing	Probar features nuevas

---

Tu primer PR puede ser tan simple como corregir un typo en el README. Todos empiezan por ahí.

Artículos relacionados: Pull Request, Fork, guía definitiva de Git y GitHub 2026.