martes, 19 de septiembre de 2023 From rOpenSci (https://ropensci.org/es/blog/2023/09/19/help-wanted/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
Mantener un paquete puede ser una actividad solitaria, lo que a veces supone un problema si prefieres el trabajo en equipo o si te encuentras con un problema muy duro para ti. Además de pertenecer a una comunidad solidaria de mantenedores (como rOpenSci 😉), ¡para obtener ayuda y compasión colaborativa puedes intentar crear una comunidad de colaboradores en torno a tu paquete! En este post, exploraremos una herramienta que te ayudará a conseguir ese objetivo: los issues de “se busca ayuda”, ¡con los que tu repositorio podría atraer y retener a nuevos desarrolladores! Hablaremos de qué son estos issues de “se busca ayuda”, sobre cuatro pasos para solicitar ayuda externa y te recordaremos que puede ser un proceso beneficioso, aunque no acabes consiguiendo ayuda.
Ten en cuenta que este post utiliza terminología específica de GitHub, como issues y etiquetas (labels). Si utilizas GitLab u otra plataforma git, probablemente exista un equivalente. :cara_ligeramente_sonriente:
Los issues “Se busca ayuda” son issues para los que necesitarías o aceptarías contribuciones externas.
Se etiquetan con la etiqueta estándar de la comunidad “se busca ayuda” (ejemplo; opcionalmente con un emoji, si ejecutaste usethis::use_tidy_github_labels()).
Para algunos de ellos, si no están demasiado implicados, o si son una buena rampa de acceso a tu base de código, también puedes utilizar la función “etiqueta “buena primera edición.
A continuación veremos cuatro pasos para solicitar ayuda externa.
A veces se avecina un obstáculo que no sabes cómo superarlo en el camino hacia tu próximo hito de desarrollo. En esta fase puedes:
Por ejemplo, al trabajar en el paquete tinkr, Maëlle abrió un issue muy específico que acabó recibiendo una ayuda externa milagrosa.
También puedes añadir la etiqueta “se necesita ayuda” a un informe de error o a una solicitud de función que alguien haya abierto en tu paquete. Con un poco de suerte, el propio creador del problema podrá participar.
Ahora bien, a veces hay algunas ideas de mantenimiento o mejora que tienes para tu paquete para las que no tienes tiempo ahora mismo, o que no son urgentes. Por ejemplo actualizar la infraestructura de pruebas para probar esa tercera edición o añadir soporte a un paquete espacial. Incluyéndolos en tu gestor de issues,
Una vez que tengas un tema en mente, haz que el título del issue y el texto sean lo más claros posible. Aunque al final seas tú quien solucione el problema, en el futuro te alegrarás de no haber anotado un comentario indescifrable. Enlaza a los recursos que sean necesarios, y asegúrate de incluir el contexto. Aborda la redacción de un problema en tu propio repositorio del mismo modo que lo harías en uno que no es tuyo: descripción del reto, resultado deseado, compensaciones, etc.
Más allá de los esfuerzos en el issue individual, es crucial tener un guía de contribución que subraye todo lo que conviene saber sobre la contribución a tu paquete: herramientas utilizadas, preferencias de estilo y diseño. 1 No dupliques los recursos externos, mejor apunta a ellos. Intenta ser un poco flexible para no sobrecargar o asustar a los colaboradores con requisitos demasiado estrictos: probablemente puedas terminar tú mismo los PR, o enseñarles poco a poco.
En primer lugar, para los paquetes rOpenSci, los issues de “se busca ayuda” se difunden a la comunidad a través de la sección sitio web y en las redes sociales.
Puedes compartirlo en tus propias redes: el espacio de trabajo de slack de rOpenSci, tus redes sociales, un canal de comunicación local del Grupo de Usuarios de R, etc.
También puedes considerar la posibilidad de aprovechar eventos hack-a-thon como Hacktoberfest por ejemplo (si añades el “hacktoberfest” a tu repositorio), pero con eventos realmente grandes como éste no puedes contar necesariamente con que alguien descubra tu pequeño problema en ese mar de problemas.
Si alguien responde en el issue o abre un PR, intenta ser algo receptivo. Comprueba que tu configuración te permite recibir notificaciones de los comentarios de los issues y de los PR, puede que necesites mirar las notificaciones en tu repositorio.
¡Agradece las contribuciones generosamente!
Aunque hayas escrito un issue excelente, puede que nadie lo tome. En ese caso, plantéate volver a difundirlo, pide consejos generales a tus compañeros mantenedores y considera la posibilidad de solicitar financiación (que puede comprar tiempo de trabajo, ya sea tuyo o el de un contratista externo) para tus esfuerzos de mantenimiento. Por ejemplo el R Consortium tiene dos convocatorias anuales de propuestas para subsidios.
Aunque al final nadie aborde la cuestión, pasar por este proceso puede ser útil, ya que te da la oportunidad de pensar en el tema en detalle y de considerar posibles resoluciones, lo que puede ayudarte a resolver tu problema por ti mismo. Además, un issue bien documentado es una forma estupenda de dejar documentadas tus decisiones sobre tu software de forma transparente y puede ayudar a futuros usuarios y colaboradores a entender las razones de tus elecciones.
Abrir issues de “se busca ayuda” puede ser una forma de hacer crecer la comunidad de colaboradores de tu paquete. Puede ser una mejor puerta a la contribución de temas menos específicos con una lista de tareas necesarias, ya que son menos abrumadores. Es posible que los colaboradores solucionen un problema de “ayuda solicitada” y luego se marchen, o que sigan adelante y solucionen más de ellos. A veces una conversación en los comentarios puede ayudarte a encontrar una solución aunque un colaborador no envíe un PR.
Como colaborador, ¡comenta siempre un problema antes de abordarlo, para asegurarte de que sigue actualizado y de que nadie más está preparando un PR duplicado en este momento! Qué fastidioso sería trabajar para nada.
Para más ideas sobre cómo fomentar una comunidad en torno a tu paquete, quizá te guste la grabación y los materiales de nuestra pasada “conversaciones con la comunidad” sobre el tema.
Puede que encuentreshttps://contributing.streamlit.app/ útil, pero otra forma de mejorar tu guía de colaboradores es ir modificándola en función de tu experiencia con los nuevos colaboradores. ↩︎
