rOpenSci - herramientas abiertas para una ciencia abierta

rOpenSci Dev Guide 1.0.0: Trilingüe y mejorada

rOpenSci — Mon, 02 Mar 2026 00:00:00 +0000

Las orientaciones de rOpenSci para realizar la revisión de software por pares se recopilan en un libro en línea ¡que sigue mejorando! Este artículo resume las novedades de nuestra Guía de Desarrollo 1.0.0, incluyendo todos los cambios enumerados en la sección de registro de cambios.

Ahora disponible en portugués.

¡Nuestra guía es ahora trilingüe (inglés, Español, Portugués)!

Si quieres saber más sobre el impresionante proyecto de traducción al portugués, iniciado e impulsado por las personas lusófonas que integran nuestra comunidad, visita nuestro artículo sobre el tema.

El proyecto de traducción y mantenimiento multilingüe en curso utiliza nuestro paquete babelquarto para producir libros y sitios web Quarto multilingües. Recientemente revisado por pares por Ella Kaye y João Granja-Correia.

Estamos trabajando activamente en nuestro paquete babeldown para crear y actualizar traducciones utilizando la API DeepL.

En la guía de desarrollo también se mencionan herramientas útiles para internacionalizar paquetes: potools el paquete experimental rhelpi18n y la selección de un idioma para un sitio web pkgdown.

Actualizaciones de políticas

Hemos realizado algunos cambios en las políticas y el alcance de la revisión por pares:

Nueva categoría para Herramientas internas y de revisión por pares de rOpenSci.
Actualizaciones de la categoría de recuperación de datos.
Nueva regla explícita para presentar un paquete a la vez.
Nuevo requisito para no llamar a la rama por defecto “master”.
Eliminado el requisito de utilizar un codemeta.json ya obsoleto. Codemeta sigue siendo utilizado y desarrollado activamente pero hemos descubierto que es redundante con otros metadatos y Codemeta puede generar estos datos según sea necesario a partir de archivos DESCRIPTION.

Guía para equipos editorial, guía para revisión y guía para autores y autoras de paquetes

Las guías que viven en nuestra guía :smile
La guía para el equipo editorial se ha reestructurado para seguir el flujo típico de los envíos, y para explicar mejor cómo utilizar el panel de revisión de software. Hemos añadido una sección sobre retos y hemos documentado cómo poner el sistema en “modo vacaciones” (lo que solemos hacer durante el periodo de las fiestas de fin de año).

Asimismo, mejoramos la organización y el contenido del guía para autores y autoras (gracias a Alec Robitaille y Joan Maspons).

En la guía de revisión eliminamos el enlace a la guía de revisión de Mozilla (una de nuestras primeras fuentes de diseño para nuestro proceso) porque ya no se mantiene y enumeramos los elementos explícitamente.

Mejores prácticas de desarrollo de paquetes

En la guía de desarrollo de paquetes (¡otra guía dentro de la guía!), añadimos orientaciones para elegir conjuntos de datos de ejemplo. Además, agregamos una sección para paquetes que incluyen software externo. La sección sobre licencias exige ahora explícitamente que se mencione a las personas autoras del código incluido. Por último, pero no por ello menos importante, la sección sobre dependencias recomienda comprobar el estado de desarrollo de las dependencias.

Todo el libro ahora menciona el CLI de Air cada vez que menciona el paquete styler, ya que Air puede considerarse su sucesor.

En el capítulo sobre la evolución de los paquetes, añadimos orientaciones sobre la eliminación de datos y se explican los inconvenientes de renombrar un paquete muy utilizado.

Guía de pruebas

Hemos actualizado nuestras orientaciones sobre pruebas (test) con

una mención de tinytest como alternativa a testthat;
una nota sobre el mantenimiento de las pruebas escritas con testthat autocontenidas.

Documentación del paquete

Agradecimientos especiales a Alasdair Warwick hemos mejorado la documentación 😉 de nuestro sistema de creación de documentación, entre otras cosas:

Más detalles sobre aspectos técnicos de la creación de documentación para paquetes rOpenSci;
Actualización de la guía matemática tras la actualización de pkgdown.

También aclaramos diferentes estrategias para documentar funciones internas gracias a Claudiu Forgaci.

Metadatos e información del paquete

Hemos documentado más formas de reconocer a quienes colaboran:

en el capítulo sobre autoría agregando el ID del Registro de Organismos de Investigación (ROR);
en el capítulo sobre colaboración con el paquete allcontributors.

Conclusión

Este es un resumen de los cambios de la última versión de nuestro libro “Paquetes rOpenSci: Desarrollo, mantenimiento y revisión por pares”. Agradecemos todas las contribuciones que han dado lugar a esta publicación. Ya estamos trabajando en la próxima versión. No dudes en ayudarnos a darle forma abriendo un issue ¡!

Cómo sumar nuevas personas al mantenimiento de tu paquete

rOpenSci — Tue, 27 Jan 2026 00:00:00 +0000

Read it in: English.

Mantener un paquete de código abierto es un trabajo gratificante, pero también es mucho trabajo. La vida y las carreras cambian, los intereses cambian, y a veces simplemente no tienes tiempo o energía para seguir trabajando en tu paquete R (¡y no pasa nada!). ¹ ). Cuando eso ocurra, una de las cosas más responsables que puedes hacer por las personas que usuan tu paquete, y por ti mismo, es buscar proactivamente alguien más que pueda sumarse a mantener el paquete.

¿Cómo puedo encontrar a una persona que quiera mantener mi paquete? es una pregunta que oímos mucho en rOpenSci. A lo largo de los años, hemos apoyado a los autores y autoras de paquetes de rOpenSci en esta transición, ayudándoles a ponerse en contacto con posibles personas interesadas en mantener, a aclarar las expectativas en torno a la función y a hacer que los traspasos sean más fluidos y sostenibles.

En este post, compartimos consejos prácticos y estrategias para ayudarte a encontrar personas que puedan contribuir y, con el tiempo, hacerse cargo de tu paquete, basándonos en lo que hemos aprendido apoyando a quienes mantienen de paquetes que forman parte del conjunto de paquetes de rOpenSci.

Empieza pronto

El mejor momento para empezar a buscar nuevas personas que mantengan es mucho antes de que realmente la necesites, y el mejor lugar para buscar es entre las personas que ya colaboran y contribuyen a tu paquete. Por esta razón, es una buena idea que la planificación de la sucesión forme parte de tu estrategia de diseño y mantenimiento desde el principio.

Recomendamos contar con una “declaración del ciclo de vida” que describa la visión a mediano y largo plazo del mantenimiento y desarrollo del paquete. Pueden ser unas pocas frases en un CONTRIBUTING.md o en README.md que describa tus intenciones de desarrollo, incluido el tiempo que piensas mantener el paquete. Aunque el futuro sea incierto, esto ayuda a establecer expectativas claras, tanto a nivel personal como para posibles colaboraciones.

Haz que el paquete sea fácil de usar

Si quieres atraer colaboradores que puedan convertirse en mantenedores a corto o largo plazo, tu paquete tiene que ser accesible. Nuestra Guia de desarrollo tiene un capítulo entero sobre cómo hacer que los paquetes sean aptos para recibir colaboraciones y también tenemos la Conversaciones con la Comunidad “Configura tu paquete para fomentar una comunidad”. Esencialmente, estos son algunos puntos clave a tener en cuenta.

Pregúntate:

¿Podría una persona nueva entender cómo construir, probar y publicar este paquete solo a partir del repositorio?
¿Hay suficiente documentación para que contribuir sea claro y se sienta amigable?

Añadir o mejorar las directrices de contribución es una forma estupenda de reducir las barreras para que alguien empiece a realizar tareas de mantenimiento, incluso antes de que asuma oficialmente el papel. Una buena CONTRIBUTING.md puede abarcar:

Cómo configurar un entorno de desarrollo.
Preferencias de flujo de trabajo: ¿ Issue antes que Pull Request?
Cómo prefieres recibir los Pull Request (por ejemplo, una funcionalidad por Pull Request, debe incluir pruebas, etc.).
Pautas de estilo o formato del código.
Pruebas y cómo ejecutarlas.
Notas sobre el proceso de publicación, incluidos scripts, flujos de trabajo CI o pasos manuales que sigas para publicar una nueva versión.

Cuanto más claramente tengas documentados tus procesos, más fácil le resultará a alguien decir “sí” al mantenimiento.

Según el tiempo y la disponibilidad, también podés invertir activamente en acompañar el crecimiento de quienes colaboran, por ejemplo:

Acompañar a quienes colaboran por primera vez en su primera pull request² .
Organiza un “bug bash” o un “sprint de documentación” para fomentar las contribuciones. Nuestra guía sobre la organización de eventos para invitar nuevas contribuciones tiene recursos que te ayudarán a planificarlo.
Destaca las “Buen ‘primer issue’” y "Issues ‘se busca ayuda’". en tu gestor de issues.

Estas actividades ayudan a ampliar tu comunidad de personas que colaboran y que potencialmente pueden mantener en el futuro, pero serán más eficaces si empiezas mucho antes de decidir dejar de mantener el paquete, cuando aún tienes mucho tiempo y energía para invertir.

Aclara lo que estás dispuesto/a a hacer (y lo que no)

Quienes puedan sumarse al mantenimiento probablemente se pregunten:

¿Seguirás disponible para responder preguntas?
¿Mantendrás cierto nivel de control o lo cederás por completo? (es decir, ¿estás buscando acompañar el mantenimiento o hacer un traspaso total?)

Aclaralo de forma explícita. Por ejemplo:

“Puedo acompañar y estar disponible durante la transición, pero planeo retirarme por completo del mantenimiento una vez finalizada”.
“Me retiro por completo del mantenimiento, pero puedo responder algunas preguntas durante la transición”.
“Quiero hacer el traspaso completo y retirarme del mantenimiento lo antes posible”.

Establecer límites claros ayuda a otras personas a decidir si desean sumarse y evita malentendidos más adelante.

Abre un issue: “Se busca apoyo para el mantenimiento”

Una vez que hayas decidido buscar nuevas personas que colaboren o tomen por completo el mantenimiento y cómo piensas implicarte en el proyecto en el futuro, comunícalo claramente. Un primer paso visible es abrir un issue en tu repositorio dedicada a este tema.

Crea una incidencia con un título claro, como por ejemplo “Se busca apoyo para el mantenimiento”, “Se buscan nuevas personas para mantener el paquete”, “Buscamos sumar colaboraciones para mantener el paquete”.

En el cuerpo, puedes incluir:

Qué nivel de mantenimiento se necesita (sólo corrección de errores, desarrollo de funciones, documentación, etc.).
Lo que buscas en una nueva persona que colabore/mantenga:
- ¿Familiaridad con el lenguaje/ecosistema?
- ¿Experiencia con pruebas o CI?
- ¿Comodidad con la publicación de nuevas versiones?
Cómo expresar interés (comentar el tema, enviarte un correo electrónico, etc.).
Cualquier cronograma que tengas en mente para la transición.

Opcionalmente, también puedes explicar Por qué das un paso al costado (sin necesidad de mucho detalle: tiempo, interés, cambio de trabajo, etc.).

Este issue se convierte en el lugar central para debatir los cambios de propiedad y puede servir posteriormente como registro público de la transición.

El issue “Nuevo(s) mantenedor(es/as)” del paquete rentrez es un buen ejemplo de contenido, recursos y conversación de seguimiento.

Si tu repositorio está en GitHub puedes anclar este issue para que se muestre en la parte superior de la pestaña issues y gane visibilidad.

Actualiza tu README para reflejar el estado del paquete

El README es el otro lugar que verán muchas de las personas que usan tu paquete. Agrega una nota breve y bien visible cerca de la parte superior, por ejemplo:

⚠️ **Estado del proyecto:** se buscan personas que se sumen al mantenimiento.  
Si te interesa ayudar con el mantenimiento de este paquete,
revisá [este issue](link-to-issue) o 
escribí a tu_email@ejemplo.com.

Este mensaje:

Establece expectativas para los y las usuarias.
Invita a posibles personas interesadas directamente desde la portada de tu repositorio.
Reduce la posibilidad de que alguien asuma que el paquete está abandonado sin explicación (este artículo enumera las fuentes de información que aconsejamos comprobar para entender el estado de un paquete).

También puedes añadir un “Estado del proyecto” en el README que ofrezca un poco más de contexto (por ejemplo, “Modo: mantenimiento solamente”, “nuevas características improbables sin nuevas personas que mantengan”, etc.).

Acércate a las personas que ya colaboran y que son usuarias avanzadas

Los mejores candidatos y candidatas para sumar apoyo al mantenimiento uelen estar más cerca de lo que parece:

Personas que han enviado PRs.
Personas que han presentado cuestiones útiles y detalladas.
Personas que sabes que utilizan el paquete en su trabajo.

Tú puedes:

Enviar un correo electrónico o un mensaje breve y cortés a algunas personas que hayan sido especialmente activas. Aunque digan que no, puede que conozcan a alguien que encaje bien en el equipo.
Si no hay un correo electrónico u otra forma de contacto disponible, etiquetá directamente a estas personas activas en el issue “Se busca apoyo para el mantenimiento”, como se hizo en el repositorio del paquete rentrez.

Anúncialo donde estén las personas que usan tu paquete

Ahora que el repo de tu paquete tiene mensajes claros, un lugar donde expresar interés y una forma clara de comunicarse contigo, es buena idea correr la voz más allá de tu repositorio.

Considera la posibilidad de publicar un breve anuncio en lugares donde sea probable que tus usuarias/os o colaboradores/as lo vean:

Foros, listas de correo, canales de Slack/Discord relevantes para tu lenguaje de programación y-o disciplina.
Redes sociales (por ejemplo, Mastodon, Bluesky, LinkedIn) utilizando hashtags específicos como #RStats.

Por ejemplo, rOpenSci enumera los issues buscando nuevas personas para el mantenimiento de paquetes en nuestro sitio web los compartimos en nuestras redes sociales y en nuestro boletín de noticias.

Añadir un mensaje de inicio de paquete

En cierto momento, puedes plantearte añadir un mensaje de inicio que informe a las personas usuarias sobre la búsqueda de ayuda para mantener el paquete.

En este mensaje puedes enlazar con el issue “Se busca apoyo para el mantenimiento” y animar a quienes usan el paquete a que te consulten si tienen interés en ayudar.

Se trata de un movimiento agresivo y puede ser molesto, así que considéralo sólo si tu paquete es usado activamente por muchas personas y no has tenido mucha suerte encontrando alguien que tome responsabilidades de mantenimiento por otros canales.

Último recurso: archiva tu paquete

Si después de un tiempo razonable no has podido encontrar alguien que se sume a mantener tu paquete, puede que tengas que tomar la difícil decisión de archivarlo, en tu repositorio, por ejemplo GitHub – y en CRAN, si corresponde. Archivar el paquete pone fin, aunque sea tristemente, a tus esfuerzos de mantenimiento.

Antes de archivar tu paquete, tómate tu tiempo para añadir un comentario explicativo en todos los issues y PRs y para cerrarlos todos. Puedes crear un nuevo README para explicar el nuevo estado. Podrías añadir cómo ponerse en contacto contigo en caso de que alguien quisiera reactivar el repositorio y encargarse del mantenimiento.

Puede que tu software sea sustituido por otros paquetes, tal vez alguien acabe poniéndose en contacto contigo para pedirte que le transfieras el repositorio, tal vez alguien cree un sustituto con el mismo nombre (y con suerte con la autoría y licencia correctas si reutiliza tu código). En cualquier caso, habrás hecho todo lo posible y el destino del paquete ya no está en tus manos.

Está bien dar un paso al costado

Dejar de mantener un paquete es una parte normal del ciclo de vida del software de código abierto.

Al:

planificar la continuidad desde el inicio,
facilitar la colaboración en el paquete,
aclarar tus propios límites,
abrir un issue claro para buscar apoyo en el mantenimiento,
Actualizar el README,
contactar a quienes ya contribuyen,
difundir la búsqueda en los canales adecuados,
y, si es necesario, archivar el paquete,

le das a tu proyecto la mejor oportunidad de continuar, mientras también cuidás tu tiempo y energía.

¿Tienes algún otro consejo o idea? Por favor, compártelos. ¡Nos encantaría leerlos!

Si aparece la culpa, recordá que todo lo que construiste hasta ahora no se invalida por elegir dar un paso atrás más adelante. ↩︎
Esta puede ser una buena forma de descubrir si tu guía de contribución es lo suficientemente detallada. ↩︎

Software Libre de Investigación en América Latina, conversaciones con la comunidad de Campeon(a|e)s de rOpenSci

rOpenSci — Mon, 26 Jan 2026 00:00:00 +0000

En el marco del llamado abierto al Programa de Campeon(a|e)s de rOpenSci 2026 —cuarta cohorte global y segunda cohorte en español— realizamos una nueva edición de Conversaciones con la comunidad. En esta oportunidad, Yanina Bellini Saibene moderó un encuentro con Erik Navarro, Diana García y Luis Verde Arregoitia, quienes compartieron sus experiencias como campeon(a|e)s y mentor(a|e)s del programa, los aprendizajes obtenidos y las oportunidades que abre participar en una comunidad de software libre y ciencia abierta.

El objetivo del webinario fue contar desde la experiencia real cómo es formar parte del programa y responder preguntas de quienes están considerando postularse como campeon(a|e)s o mentor(a|e)s.

Yanina abrió la conversación presentando el programa y su propósito: fortalecer capacidades en desarrollo de software de investigación sostenible, con foco en ciencia abierta y comunidades colaborativas y luego dió la palabra a los invitados.

Erik Navarro - Campeón

El proyecto de Erick fue trabajar sobre un paquete existente y prepararlo para enviarlo al proceso de revision por pares de rOpenSci y recibir el feedback de expertos.

Su paquete de bioinformática, llamado RAMEN, tiene como objetivo facilitar el analisis y modelado de datos de metilación. Este paquete es un producto de su doctorado en la universidad de British Columbia, Canadá que tiene como objetivo entender cómo la genética y los factores ambientales modulan la expresión génica en poblaciones humanas

Experiencia en el programa

Erick valoro mucho los aprendizajes técnicos. Los talleres le permitieron mejorar sus conocimientos de programación pese a tener experiencia previa en desarrollo de software y aprendió mejores prácticas de programación y cómo hacer el código más robusto.

Aunque ya sabía programar, yo soy biologo y no tuve clases formales de programación. Los talleres me ayudaron a llenar huecos en mi conocimiento" - Erick

Estos conocimientos los pudo aplicar directamente en su paquete, por ejemplo implementando pruebas exhaustivas del código y asegurando compatibilidad con distintos sistemas operativos.

Sumado a los entrenamientos, Erick destacó la importancia de contar con una mentora (Pao Corrales) que lo guió durante el proceso de revisión y eso lo facilitó mucho. Le ayudo a dividir las tareas en partes manejables y resolver inconvenientes técnicos.

Es muy diferente tener una persona con quien hablar versus tener que leer un documento extenso solo, incluso si la documentacion es clara y completa." - Erick

Ademas, rescató que el proceso de revisión es muy util desde el minuto uno: su paquete mejoró significativamente solo con cumplir los estándares de revisión, incluso antes de recibir feedback de revisores y editores.

Erick también destaca que la experiencia del programa ayuda a ganar confianza para seguir participando en comunidades de código abierto y valoró que más allá de lo técnico, se construyen vínculos y redes profesionales valiosas y en especial para él, fue muy rico conocer personas de Latinoamérica, región poco representada en desarrollo de software libre.

Su mensaje final anima a las personas a aplicar al programa porque es una oportunidad única de aprendizaje y crecimiento profesional.

Diana García - Campeona

Diana participa del programa desarrollando un paquete nuevo para compartir datos de secuenciación de DNA y RNA de pacientes con cáncer de mama metastásico. Su motivación principal es hacer datos abiertos y fáciles de analizar para otros laboratorios, de esa manera espera permitir que otros investigadores hagan nuevas preguntas a los datos ya generados.

Experiencia en el programa

La primera aclaracion que Diana nos dejó es que el programa tiene una gran diversidad de temas, aunque los proyectos de Erick y el suyo son de bioinformática, otros campeon(a|e)s trabajan en áreas muy distintas:

Eso es algo que me gustó mucho del programa: en la cohorte hay paquetes para compartir datos de encuestas, en temas ambientables, otros enfocados en metodologías distintas… es decir, proyectos muy diversos conviviendo en un mismo espacio de aprendizaje." - Diana

Diana también destaca el valor de la mentoría personal, ella trabaja con Geraldine, una ingeniera de software con reuniones pogramadas cada dos semanas, lo que crea un compromiso positivo y constante para avanzar en el proyecto.

Tener una mentoría personal con alguien que ya tiene experiencia en el desarrollo de software es muy valioso. En lo personal, poder preguntar directamente a mi mentora hizo una gran diferencia en mi proceso de aprendizaje. Obviamente uno puede ver recursos en internet, preguntarle a ChatGPT y tratar de aprender por su cuenta, pero es muy diferente cuando tienes a una persona que ya vivió ese proceso y que te guía y con quien puedes conversar directamente tus dudas.

Finalmente, Diana menciona que el programa no solo enseña aspectos técnicos, como los que menciono Erick. También permite aprender las dimensiones humanas de construir comunidad, cosas que no se aprenden en otros espacios y que aquí se viven y se practican.

En su cierre, también anima a postular y compartir la oportunidad con otras personas.

Luis Verde Arregoitia - Mentor

Luis ha participado en dos cohortes consecutivas como mentor y rescata como un beneficio muy importante no solo el entrenamiento de mentores, pero también tener acceso a todos los entrenamientos disponibles para campeon(e|a)s.

El primer año no me perdí ninguna sesión. Los materiales del programa se actualizan constantemente así que siempre hay cosas nuevas que aprender. Incluso cuando me tocaba madrugar para conectarme, honestamente valió completamente la pena.” - Luis

Casos de mentoría

Luis acompañó dos proyectos muy distintos, lo que le permitió vivir de primera mano la diversidad de temas y dinámicas que Diana y Erick mencionaban.

En su primera mentoría trabajó junto a Andrea, cuyo proyecto consistía en desarrollar un paquete nuevo sobre censos y estadística demográfica de Argentina. Aunque el tema estaba fuera de su especialidad, ya que su formación es en biología, aun así pudo aportar acompañando el proceso general de desarrollo del paquete. Acompañó decisiones de organización, planificación y conexión con la comunidad. Coincidir en eventos presenciales con Andrea y otras personas de rOpenSci fortaleció el vínculo de trabajo. Como resultado del proceso, celebró que el paquete ya fue publicado.

En su segunda experiencia, Luis acompaña a Mónica, quien está trabajando en un paquete enfocado en estadística y econometría. En esta ocasión el trabajo fue más asincrónico, con intercambios principalmente a distancia. Su rol se centró especialmente en compartir recursos, herramientas y buenas prácticas que pudieran fortalecer el desarrollo del paquete.

Luis destacó que este tipo de acompañamiento flexible también es parte del valor del programa, aunque se capacita a mentores en qué se espera de ellos y cómo serlo efectivamente, se permite adaptar la mentoría a las necesidades y dinámicas de cada proyecto.

También cierra su participación invitando a postular para la nueva cohorte:

¿Por qué participar en el Programa? Porque aprendes muchísimo: de tu propio proyecto, de los proyectos de otras personas y de una comunidad increíble con la que haces conexiones que se quedan para toda la vida." — Luis

Una invitación abierta

Luego de la etapa de preguntas y respuesta, que puedes consultar en el documento compartido del evento, se cerró el encuentro con una invitación a postularse al próximo llamado 2026, ya sea como campeón/a o como mentor/a. La fecha límite para postular es el 20 de febrero de 2026.

El 5 de febrero tenemos una Clinica de Aplicación donde podes trabajar sobre tu postulación con apoyo de Yanina y también podes sacarte todas tus dudas

Como resaltó Yanina, fortalecer el software de investigación en América Latina requiere personas comprometidas, comunidades abiertas y espacios donde aprender colectivamente.

Si te interesa mejorar tu proyecto de software científico en R, aprender buenas prácticas de desarrollo abierto y conectar con una comunidad internacional, el Programade rOpenSci puede ser tu próximo paso.

Podes ver el video completo y todos los recursos compartidos en el evento en la página del webinario.

Software Libre de Investigacion en America Latina

rOpenSci — Wed, 21 Jan 2026 00:00:00 +0000

How to join this free online event with Diana Garcia Cortes, Erick Navarro Delgado, Luis D. Verde Arregoitia and Yanina Bellini Saibene.

Este 2026 el Programa de Campeon(a|e)s de rOpenSci abre el llamado a nuestra cuarta cohorte y la segunda en español.

Venite a conversar con Diana Garcia, Erick Navarro y Luis Verde Arregoitia sobre su experiencia como campeon(e|a)s y mentores de rOpenSci y como podes aplicar para cualquiera de los dos roles.

Destacaremos los beneficios de formar parte del programa para ti y para tu comunidad, qué tipo de aprendizaje, actividades y oportunidades ofrece un programa de una comunidad de código abierto y ciencia abierta.

Yani estara presente para contestar a todas sus preguntas sobre nuestro programa.

Consulta a continuación las biografías de las personas que exponen y los recursos del evento.

Speakers

Diana Garcia

Bióloga Computacional del Breast Oncology Program en el Dana Farber Cancer Institute, donde investiga las alteraciones del genoma asociadas a resistencia a terapias en cáncer de mama mestastático. Tiene un doctorado en Ciencias Biomédicas y una maestría en Ciencias de la Computación y experiencia desarrollando software tanto en la academia como en la industria. Disfruta mucho enseñar programación, fue profesora en CETYS Universidad, Campus Tijuana, y tallerista en la Escuela de Código Pilares en CDMX. Forma parte de R-Ladies Boston y del programa de campeones de rOpenSci, previamente participó en PyLadies CDMX y en Women Who Code CDMX.

Erick Navarro

Licenciado en biología por la Universidad Nacional Autónoma de México, y candidato a Doctor en Bioinformática por The University of British Columbia. Actual campeón del Programa de rOpenSci.

Luis Verde Arregoitia

Doctor en Biología con amplia experiencia en programación R para el análisis de datos, visualización y modelado estadístico. Autor de varios paquetes de R y mentor en dos cohortes del programa de rOpenSci, donde ha apoyado a desarrolladores de software en R de América Latina.

Resources

Materiales de los talleres del Programa, Recopilación de materiales de los talleres realizados en el marco del Programa de Campeon(a|e)s de rOpenSci en castellano.
Revisión de software en rOpenSci del proyecto de Erick Navarro, Issue donde se realiza la revision del proyecto de Erick
Sitio web del programa, Todos los detalles de los formularios y requisitos se encuentran en ese sitio web
Software Libre de Investigación en América Latina, conversaciones con la comunidad de Campeon(a|e)s de rOpenSci, Si preferis leer a ver videos, este blog post resume lo charlado en este evento
Collaborative notes

Join Us!

Who Everyone is welcome. No RSVP needed, simply connect and/or dial in at the time of the event.
When miércoles, 21 enero 2026 13:00 PST (miércoles, 21 enero 2026 21:00 UTC)
Find your timezone
Añadir al Calendario.
Cómo
Todas las personas son bienvenidas. No se necesita registro.

Chequea la configuración de tu Zoom https://zoom.us/test.

Unete a la reunión: https://numfocus-org.zoom.us/j/85368787555?pwd=LYHvGT1E1A87lnyFaXxVr6bVZfNLDf.1
ID de la reunión: 85368787555 Código de acceso: 934638
Encuentra tu número local para unirte por teléfono: https://zoom.us/u/adAyZGMYrE

Convocatoria abierta al Programa de Campeonas y Campeones de rOpenSci 2026

rOpenSci — Mon, 12 Jan 2026 00:00:00 +0000

Read it in: English.

Nos alegra anunciar la apertura de un nuevo llamado al Programa de Campeonas y Campeones de rOpenSci, que dará inicio en 2026. A partir del 12 de enero de 2026 y hasta el 20 de febrero de 2026, estaremos recibiendo postulaciones tanto para el rol de Campeon(a|e)s como de Mentor(a|e)s.

Al igual que en la cohorte anterior, el programa se desarrollará completamente en castellano y tendrá un foco regional en América Latina, con el objetivo de seguir fortaleciendo el ecosistema de software de investigación y ciencia abierta en la región.

Fechas clave del llamado 2026

Apertura de la convocatoria: Lunes 12 de enero de 2026
Conversación con la comunidad informativa: Miércoles 21 de enero de 2026
Clínicas de aplicación: Jueves 5 de febrero de 2026
Cierre de la convocatoria: Lunes 20 de febrero de 2026

La Conversación con la comunidad del 21 de enero contará con la participación de campeonas, campeones y mentores de cohortes anteriores, quienes compartirán sus experiencias y responderán preguntas sobre el programa. ¡Les invitamos a sumarse!. Pueden ver la grabación del evento del año pasado.

Durante febrero realizaremos una clínica de aplicación, espacio abierto donde podrán recibir ayuda para completar el formulario, resolver dudas y recibir orientación directa del equipo del programa.

¿Qué es el Programa de Campeonas y Campeones?

El Programa busca identificar, acompañar y reconocer a personas que ya están liderando, o que quieren dar un paso más, en la construcción de comunidades de ciencia abierta y software de investigación sostenible.

A lo largo de 12 meses, las personas seleccionadas participarán de:

Una capacitación inicial de 13 workshops de 2 horas basada en cohortes.
El desarrollo de un proyecto de software de investigación: creación de un paquete de R, participación en la revisión por pares de rOpenSci con un paquete de su autoria o como parte del equipo de revisores.
Mentoría 1 a 1 y espacios de intercambio grupal.
Actividades de construcción de comunidad, divulgación e intercambio de experiencias y fortalecimiento de redes regionales.

El programa ofrece además un estipendio para reconocer el tiempo y el trabajo de las personas participantes para aquellas personas que completen el programa y un certificado de participación.

¿A quiénes está dirigido?

Campeon(a|e)s

Buscamos personas que:

Sean orginarios o vivan y trabajen en América Latina.
Utilicen R y tengan experiencia previa en desarrollo de software, análisis reproducible o ciencia abierta.
Estén interesadas en desarrollar un proyecto de software de investigación abierto y en fortalecer sus comunidades locales o regionales.
Puedan comunicarse efectivamente en español (oral y escrito).
Acepten nuestro código de conducta y puedan comprometerse a participar en las actividades del programa organizadas para campeones y campeonas durante estos 12 meses.

Mentor(a|e)s

Invitamos a postularse como mentoras o mentores a personas que:

Tengan experiencia desarrollando, manteniendo o contribuyendo a paquetes de R (idealmente dentro de rOpenSci, aunque no es excluyente).
Hayan participado en procesos de revisión por pares de software.
Tengan experiencia relevante en mentoría.
Tengan interés en acompañar a otras personas, compartir experiencias y contribuir activamente al crecimiento del programa.
Puedan comunicarse efectivamente en español (oral y escrito).
Acepten nuestro código de conducta y puedan comprometerse a participar en las actividades del programa organizadas para mentores y mentoras durante estos 12 meses.

¿Por qué participar?

Ser parte del Programa de Campeonas y Campeones de rOpenSci significa:

Desarrollar o fortalecer un proyecto de software de investigación con acompañamiento experto.
Formar parte de una red regional de personas comprometidas con la ciencia abierta y el software libre.
Adquirir herramientas técnicas y habilidades de liderazgo comunitario.
Recibir apoyo para compartir tu trabajo y tus experiencias con tu comunidad o institución y en eventos regionales e internacionales.
Contribuir activamente a un ecosistema de software abierto más diverso, sostenible e inclusivo.

¿Cómo postularse?

Las postulaciones se realizarán a través de formularios en línea:

Estos formularios también están disponibles en el sitio web del programa.

Los formularios deberán completarse en castellano. En la web del programa también encontrarán el detalle de la información requerida para aplicar como campeon-a o como mentor-a para facilitar la preparación de las postulaciones y respuestas a las preguntas mas frecuentes.

Más información

En el sitio web podes encontrar el cronograma detallado de actividades y la información completa del programa, como también los proyectos realizados por las cohortes anteriores y los otros tipos de actividades llevadas adelante por las personas participantes.

Si tienen preguntas, los invitamos a participar de la Conversación con la comunidad de enero, sumarte a las clínicas de aplicación en febrero o enviar un mail a la directora del programa.

¡Esperamos sus postulaciones con mucho entusiasmo! Queremos seguir construyendo comunidad en América Latina junto a ustedes.