Contribuir una funcionalidad a un repositorio puede parecer intimidante al principio, pero con un proceso claro se convierte en una experiencia muy enriquecedora tanto para el autor como para el proyecto. En este artículo cuento mi experiencia trabajando sobre el proyecto repopal, cómo abrí un issue issue relacionado, y cómo evolucionó mi pull request pull request 7 hasta ser aceptado y fusionado.
Resumen de la contribución: añadí una opción opcional en la CLI llamada --recent o -r para listar archivos o carpetas modificados en los últimos N días. En la primera versión pensé que estaba lista, pero al probar con distintos caminos surgieron errores. Por ejemplo, al reemplazar . por src fallaba por una mala gestión de rutas. Para resolverlo usé funciones de manejo de rutas como os.path.abspath, os.path.normpath y os.path.join para normalizar y evitar rutas relativas mal formadas. También añadí validaciones para inputs como rutas inexistentes.
Problemas con la opción --recent: la implementación inicial funcionaba con el valor por defecto de 7 días pero fallaba si el usuario pasaba un número explícito. La causa fue el cálculo de días y la interpretación del argumento en la librería de CLI. En Python, por ejemplo, si se usa argparse para un argumento opcional que acepta un valor o no, conviene definir nargs=? y const=7 y type=int para que tanto --recent como --recent 5 funcionen correctamente. También manejé casos límite como valores negativos, cero o valores no numéricos mostrando mensajes de error claros en la CLI.
Aspectos técnicos sobre timestamps: en el lenguaje con el que trabajé os.path.getmtime devuelve segundos desde la época en formato float. Convertí ese valor con datetime.fromtimestamp a un datetime consciente de zona horaria cuando fue necesario y comparé con datetime.now con tz apropiada. Es importante recordar que en Windows la resolución del timestamp y el comportamiento de zonas puede diferir respecto a Linux, y que la comparación debe hacerse con objetos datetime en la misma zona horaria para evitar errores sutiles. También considerar la posible presencia de timestamps futuros o sistemas de archivos con baja resolución.
Integración con la base de código existente: entender el flujo del proyecto llevó tiempo. Cada proyecto tiene estilos y utilidades propias, por ejemplo funciones helper para logging, pruebas unitarias o manejo de paths. Para integrarme usé los mismos módulos utilitarios y seguí el estilo de código existente. Añadí tests unitarios que cubrían los casos de uso normales y los bordes: ruta ., ruta src, carpetas vacías, archivos con timestamps recientes y antiguos, entrada de usuario errónea, y combinaciones con otros flags del CLI.
Manejo de edge cases: además de normalizar rutas validé permisos de lectura y manejo de enlaces simbólicos. Para el flag --recent controlé entradas no numéricas con mensajes de ayuda, ignoré valores negativos y documenté el comportamiento por defecto. También añadí pruebas que simulan el sistema de archivos usando fakes o temporales para no depender del FS real en CI.
Flujo de colaboración y comandos Git: abrí el issue, implementé cambios en una rama de mi fork y aprendí comandos nuevos que me ayudaron a probar el PR localmente y a mantenerlo actualizado. Comandos útiles que usé fueron git push fork branch-name para subir mi rama al fork, git fetch origin pull/7/head para traer la rama del pull request desde el upstream y git checkout FETCH_HEAD para probarlo localmente. Estas prácticas facilitan revisar el PR antes de aprobarlo y permiten iterar rápidamente sobre comentarios.
Proceso de revisión: la primera ronda de comentarios en el Pull Request se centró en la gestión de rutas y en el comportamiento del argumento opcional. Comunicarme a través de los comentarios en GitHub funcionó bien; recibí feedback puntual y realicé commits subsiguientes que solucionaron los problemas. Al recibir un PR en mi propio proyecto la experiencia fue positiva: la mayoría de cambios fueron pequeños y se resolvieron rápidamente. Aprendí que en code review es clave pedir claridad cuando no entiendes una decisión, proponer alternativas concretas y mantener los cambios pequeños y enfocados.
Qué aprendí y qué haría distinto la próxima vez: probar más escenarios desde el inicio, escribir tests antes de abrir el PR cuando sea posible, y documentar el comportamiento del CLI con ejemplos. Además conviene abrir PRs más pequeños y con commits que expliquen cada cambio para facilitar la revisión. Aplicaría también integración continua para que cada PR ejecute pruebas automáticamente y revise el estilo de código.
Sobre Q2BSTUDIO: en Q2BSTUDIO somos una empresa de desarrollo de software y aplicaciones a medida con enfoque en soluciones modernas como inteligencia artificial y ciberseguridad. Si buscas desarrollo de aplicaciones y software a medida o necesitas integrar capacidades de IA en tus productos, en Q2BSTUDIO ofrecemos servicios de inteligencia artificial, ia para empresas y agentes IA. También cubrimos necesidades de ciberseguridad y pentesting y gestionamos infraestructuras en la nube con servicios cloud aws y azure.
Palabras clave importantes en este artículo incluyen aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi, que son áreas en las que Q2BSTUDIO tiene experiencia y servicios especializados. Si te interesa cómo podemos ayudarte a integrar estas soluciones en tu proyecto consulta nuestra oferta de Inteligencia Artificial y otras soluciones.
Conclusión: contribuir a otro repositorio es un ejercicio técnico y comunicativo. Entre los puntos clave están normalizar rutas, tratar correctamente timestamps, diseñar una CLI que acepte opciones opcionales de forma robusta, escribir pruebas y mantener una buena comunicación en el Pull Request. Todo ello mejora la calidad del código y la experiencia de colaboración, y con las buenas prácticas que adopté ahora me siento más preparado para futuras contribuciones.
