Contenido
Mientras daba los toques finales a la primera versión funcional de bulletty, noté que Hacktoberfest—el evento anual organizado por DigitalOcean donde los participantes ganan camisetas al completar con éxito seis pull requests (PR) durante octubre—se acercaba. Pensé que podría ser una gran oportunidad para involucrar a la comunidad, mejorar el lector de feeds y aumentar la visibilidad del proyecto. Para prepararme, organicé la sección de Issues en GitHub, creando un issue por cada característica del roadmap y para errores, añadiendo descripciones detalladas e imágenes. Luego los etiqueté adecuadamente con etiquetas como “Mejoras,” “Errores,” “Buen primer issue,” y “Hacktoberfest.” Se redactó un archivo CONTRIBUTING genérico, que describía los procedimientos para enviar cambios, reportar errores y abrir PRs.\n\nUnos días antes de octubre, promocioné el proyecto en mis cuentas personales en X, Bluesky y Mastodon, y también publiqué en el subreddit /r/hacktoberfest. Al descubrir el servidor oficial de Discord de Hacktoberfest, también publiqué allí para reclutar colaboradores. Incluso probé Hacker News, aunque generó el menor compromiso. En pocos días, la cantidad de estrellas en GitHub subió a casi cien, y recibí numerosas respuestas en varias plataformas, lo que consideré un fuerte éxito inicial.\n\nSin embargo, una vez que comenzó octubre, rápidamente recibí numerosas solicitudes de colaboradores pidiendo que se les asignaran issues sin ninguna discusión previa. Este enfoque me pareció prematuro y arriesgado, ya que asignar issues sin entender el plan del proponente podría bloquear a otros de contribuir. Por lo tanto, actualicé el archivo CONTRIBUTING con pautas claras que enfatizan que los colaboradores deben primero participar en una discusión sobre su implementación prevista. Solo después de un diálogo suficiente asignaría issues. Para correcciones de errores, permití enviar PRs sin discusión previa siempre que los colaboradores explicaran sus cambios a fondo.\n\nUna interacción particular destacó cuando un usuario que solicitaba asignación mencionó un “conocimiento,” lo que me llevó a sospechar la participación de algún flujo de trabajo asistido por IA o “vibe-coding.” Tras confirmarlo, revisé aún más las pautas de CONTRIBUTING para abordar el código generado por IA. Declaré que no prohibiría la IA por completo, pero que no se aceptarían PRs generados puramente por IA. Los colaboradores deben revelar el uso de IA, asumir la responsabilidad de sus envíos y estar preparados para revisiones exhaustivas del código. El uso no revelado de IA se consideraría deshonesto y llevaría al cierre del PR. Compartí mi opinión de que, aunque yo mismo uso herramientas de IA, delegar implementaciones enteras a la IA sin comprensión genuina es problemático.\n\nEsta sospecha se reforzó cuando el usuario envió un PR que no compilaba, carecía de formato adecuado a pesar de instrucciones explícitas, contenía commits con títulos pobres e inconsistencias como cambiar el nombre de un método sin actualizar su definición en el trait. Estas señales apuntaban a un intento automatizado de generación de código. Cerré el PR y pedí contribuciones más reflexivas. Además, algunos issues recibieron “planes de ataque” vagos que parecían generados por IA y sin sentido, destacando un desafío para filtrar entradas de baja calidad.\n\nReflexionando sobre comentarios de otros mantenedores, parece que Hacktoberfest a menudo atrae PRs spam centrados en cambios triviales, como correcciones de errores tipográficos o simples modificaciones de comentarios. Con el auge de modelos avanzados de IA capaces de reescribir grandes secciones de código, mantener proyectos de código abierto se vuelve más complejo. Aunque la IA puede manejar bien tareas simples, grandes refactorizaciones impulsadas por IA corren el riesgo de introducir errores difíciles de detectar y semánticas de código oscuras. A diferencia de los desarrolladores humanos, la IA carece de la comprensión conceptual del software como “construcción teórica,” una noción enfatizada por Peter Naur. Además, la comunidad tiene dificultades para acordar qué constituye trabajo generado por IA versus humano, complicando la moderación.\n\nA pesar de estos desafíos, hubo contribuciones valiosas durante Hacktoberfest. Tras el flujo inicial de PRs cuestionables, colaboradores más comprometidos enviaron mejoras significativas. Un ejemplo notable fue la adición de navegación siguiente y anterior en el lector, una función crítica que antes faltaba. La implementación también me enseñó sobre el uso de Rc en Rust para conteo de referencias, enriqueciendo mi comprensión.\n\nEn general, Hacktoberfest trajo tanto oportunidades como obstáculos. Catalizó la participación comunitaria y aceleró el desarrollo de funciones, pero también introdujo complejidades relacionadas con la calidad de las contribuciones, especialmente con la codificación asistida por IA. La comunicación clara, pautas estrictas y procesos de revisión vigilantes demostraron ser esenciales para mantener la integridad del proyecto durante todo el evento.
