Cerré los Pull Requests y los Issues, y ahora soy más feliz

Desde hace un tiempo empecé a migrar mis proyectos de GitHub, GitLab y Codeberg a mi propia instancia de Gitea. Hacerlo requiere valor, porque te independizas de unas redes sociales de programadores con una gran visibilidad, interacciones y accesibilidad. Olvídate de estrellas, followers, forks, trendings y demás. Solo te queda el código, y tal vez la gente que dejes entrar. Y sin embargo, ahora soy más feliz que antes. Gracias a la fricción, la calidad de las contribuciones ha subido y es relativamente más fácil gestionar los proyectos.

Leer contribute ya no es opcional

Ahora ya no puedes pulsar un botón para abrir un Pull Request/Merge Request o Issue. Todos mis proyectos comparten la misma guía de contribución. Una serie de pasos que se resumen en:

1. Clona el repositorio.
2. Crea una rama.
3. Haz tus cambios.
4. Genera un parche con git format-patch.
5. Envíamelo a mi correo usando git send-email preferiblemente, y utilizando una plantilla para el asunto y el cuerpo del mensaje.
6. Espera a que lo lea y te conteste.

Ahora mi correo es la única vía de comunicación.

Además incluyo algunas buenas prácticas que son básicas pero no viene mal recordar:

• Un parche = un cambio lógico.
• Prueba antes de enviar.
• Escribe mensajes de commit claros.
• Ten paciencia con quien mantiene.
• Acepta el feedback con buena disposición.

¡La fricción es enorme! Te pido que leas una guía, que te manejes medianamente bien con Git, y que además lo tengas configurado para enviar correos. El último paso parece un capricho de viejo cascarrabias, pero tiene una razón técnica. git send-email habla directamente con el servidor SMTP y coloca el parche como cuerpo del correo en texto plano, con la codificación correcta. Un webmail (Gmail y compañía) suele reescribir los saltos de línea, convertir los tabuladores en espacios o cambiar la codificación. El parche me llega byte a byte como lo generó el autor.

Pero, ¿qué ventajas traen todos esos pasos extra? Dan ganas de ignorar el proyecto.

La fricción no es un bug, es una feature

Durante décadas hubo una barrera natural en el software libre. Para mandar un parche tenías que entender el código, clonarlo, hacer el cambio, leer documentación, probarlo y saber explicarlo. Quien pasa por todo ello demuestra un interés real en el proyecto: su issue de verdad molesta y su parche vale la pena revisarlo línea por línea.

Por otro lado recompensa al contribuidor de una forma enorme. Después de intercambiar varios correos, ajustar tu parche, ajustar el código a las normas del proyecto, refinando el parche con el feedback del mantenedor, y... al final es aceptado: no sientes que has arreglado un bug en un proyecto de otro, sientes que eres parte de él. Que tu esfuerzo ha sido valorado y que tu tiempo ha merecido la pena. Tal vez incluso sigas contribuyendo, ya no por necesidad, sino por placer. Se ha creado un vínculo entre el proyecto y tú.

Recuerdo con mucho cariño algunos parches que se dilataron meses, y que al final fueron aceptados. De hecho uno de ellos se va a aprobar en unos días después de casi ¡8 meses! Y lo mejor de todo, es que he hecho un amigo en el proceso. Y eso es lo que hace grande al software libre: la gente que hay detrás.

Todo ello no se logra apretando un botón y cambiando un par de líneas sin salir de la interfaz web. De hecho acabas sintiendo un sentimiento egoísta de ¡que te deben algo a ti!

Un relajante para los mantenedores

Los mantenedores de proyectos enormes están sufriendo el tsunami de Pull Requests y Issues generados por IA:

• curl llegó a cerrar su programa de recompensas por fallos. A mitad de 2025, solo un 5% de los reportes eran vulnerabilidades reales y cerca de un 20% parecía generado por IA. Daniel Stenberg lo describió como un "DDoS" contra los mantenedores.
• GitHub habla ya de un "septiembre eterno" del código abierto y ha empezado a poner límites al número de Pull Requests para bajar el ruido. Están construyendo funciones para archivar y esconder contribuciones de baja calidad.
• Según CodeRabbit, los Pull Requests generados por IA traen 1,7 veces más problemas que los escritos por humanos. Y llegan en mucho mayor volumen.

La IA aceleró generar código, pero no creó más revisores seniors. El trabajo cognitivo de leer, entender y decidir sigue recayendo en una persona. Yo no digo que no se use la IA para generar código, buscar bugs o entender el código, no nos engañemos, es una herramienta excelente, pero sí que detrás exista un responsable humano experimentado que gestione la contribución. Si no puedes explicar el parche, no lo envíes. Si no puedes explicar el bug, no lo reportes. Si no puedes explicar el cambio, no lo propongas. Si no, el mantenedor se dará cuenta en el primer correo.

Estás espantando al principiante

Sí, es verdad. El Pull Request de GitHub se inventó en 2008 precisamente para bajar la barrera a gente desconocida, y funcionó: multiplicó la participación. Y hay una larga literatura académica sobre cómo esa barrera técnica hace que mucha gente abandone su primera contribución. Ese "drive-by" casual es valioso y necesario.

Pero yo no mantengo el kernel de Linux, sino proyectos pequeños, solo, con poco tiempo.

Cuando eres un equipo de una persona, tu recurso más escaso es dedicar atención a quien quiere contribuir.

Cada issue vacío, cada parche que no compila, cada "esto no funciona" sin contexto, me cuesta un rato que le quito a escribir código, a la familia o al descanso. El triaje soy yo. Proteger mi tiempo es proteger la calidad de mis proyectos. Sin embargo no me escondo en una cueva, hay una puerta a la que llamar. Hay un documento con unos sencillos pasos que cualquiera puede seguir para contribuir. Pero requiere de tu atención y de tu tiempo.

Conclusión

Ya no tengo que seguir y empujar Issues de los que el autor se desentendió nada más abrirlos. Ya no tengo que leer un Pull Request en el que cambiaron un par de líneas mientras tomaban un café y no probaron. Tengo 2 o 3 parches a la semana, todos ellos con un contexto, explicados y probados. Y si necesito más información, tengo el correo del autor para preguntarle.

Ahora todo es más personal y humano.

Fuentes

• La avalancha de reportes generados por IA en curl (5% reales, ~20% slop) y el cierre de su bug bounty: AI Slopageddon and the OSS Maintainers (RedMonk).
• Por qué la revisión de contribuciones de IA quema a quien mantiene, con el dato de 1,7 veces más problemas: AI is burning out the people who keep open source alive (CodeRabbit).
• El "septiembre eterno" del código abierto y los planes de GitHub para los mantenedores: Welcome to the Eternal September of open source (GitHub Blog).
• Los límites al número de Pull Requests para bajar el ruido: How pull request limits are cutting down the noise (GitHub Blog); contexto en GitHub eyes restrictions on pull requests (InfoWorld).
• Mi guía práctica para enviar parches por correo: Enviando parches vía Email con Git.