rOpenSci | Cómo sumar nuevas personas al mantenimiento de tu paquete

Cómo sumar nuevas personas al mantenimiento de tu paquete

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!). 1 ). 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:

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:

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!


  1. 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. ↩︎

  2. Esta puede ser una buena forma de descubrir si tu guía de contribución es lo suficientemente detallada. ↩︎