viernes, 17 de mayo de 2024 From rOpenSci (https://ropensci.org/es/blog/2024/05/17/communication-tips-oss-project/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
¿Mantienes un proyecto de código abierto, como un paquete R o una colección de ellos, te preguntas cómo utilizar mejor los distintos canales de comunicación para informar a tu comunidad de usuarios y comprometerte con ella? Pues hemos hecho una lista con consejos. Algunos de ellos son obligatorios en nuestra opinión, otros son simplemente agradables de tener.
Puesto que estás desarrollando un producto, el primer acto de comunicación es escribir notas de publicación informativas.
Las notas de publicación suelen describir actualizaciones y cambios, normalmente en un archivo llamado NEWS.md. Estos archivos suelen tener una cabecera por versión, con subcabeceras utilizadas para agrupar los cambios en categorías significativas.
Entre los recursos para empezar con las notas de publicación se incluyen:
usethis::use_news_md() crear el NEWS.md archivo.Puedes automatizar parcialmente las notas de publicación a partir de los mensajes de confirmación utilizando, por ejemplo, la función paquete fledge (bastante potente si se combina con el paquete Convención de commits convencionales).
Las notas de publicación pueden informar directamente a los usuarios, que pueden leerlas
NEWS.md los archivos en una página llamada Changelog.También serán útiles como materia prima para otras notas de publicación, como entradas de blog sobre las versiones.
No sólo tus repositorios deben tener rastreadores de incidencias/tickets, sino que también debes asegurarte de que suficientes miembros del equipo los vigilan o revisan los nuevos tickets o comentarios al menos de vez en cuando. Mantener y responder a las incidencias es una parte importante del mantenimiento de una comunidad de usuarios.
El uso de incidencias en tu proyecto puede anunciarse a través de una incidencia anclada; incluso podrías limitar temporalmente las interacciones. Estas condiciones y enlaces son para GitHub, pero existen ideas y características similares para otras plataformas de código.
Todo software de código abierto tiene un perfil, potencialmente repartido por muchos lugares, como organizaciones de GitHub o cuentas de Mastodon. Un logotipo puede ser un identificador clave de tu perfil, y debe aparecer de forma coherente en todos tus perfiles. También es importante incluir descripciones informativas, y verificar todas las URL (docs para GitHub, docs para Mastodon).
Para una organización de GitHub, puedes preguntar a sus miembros si desean que su organización GitHub sea pública lo que podría dar una imagen más colaborativa incluso antes de que nadie se sumerja en la actividad de commit.
Pulir el perfil no tiene por qué llevar mucho tiempo, y puede mejorar la imagen de tu proyecto.
Para cualquier plataforma que requiera inicios de sesión o algún tipo de derechos de acceso, asegúrate de que todos los que necesiten acceso lo tengan, y de que se elimine el acceso a cualquiera que ya no lo necesite.
Quizá te convenga buscar sistemas de gestión de contraseñas como 1Contraseña.
Como la composición de un equipo de desarrollo cambia con el tiempo, puede ser conveniente revisar el acceso con regularidad, y hacer que esa revisión forme parte de algún tipo de lista de control de incorporación/desincorporación.
Aunque el desarrollo de código abierto exige que ocurran muchas cosas en abierto también es importante cultivar un espacio seguro donde los miembros del equipo puedan desahogarse, discutir asuntos delicados o compartir fotos de sus mascotas. Esto puede adoptar formas como un espacio de trabajo Slack, Discord, Matrix o un servidor Element, u opciones vanguardistas como plano o CQ2.
Lo ideal sería que el espacio te perteneciera, a menos que puedas confiar en un socio externo (¿un financiador? ¿una cohalición mayor de proyectos?) para que te lo siga proporcionando.
Para un proyecto pequeño, los gestores de incidencias pueden ser todo lo que necesitas para gestionar los informes de errores, las peticiones de características y las preguntas y respuestas generales. Sin embargo, los proyectos más grandes podrían beneficiarse de la creación y gestión de un foro de debate dedicado.
Puedes utilizar un Discurso o Debates en GitHub.
En comparación con las notas de la versión, las entradas del blog sobre las nuevas versiones ofrecen más narrativa, por lo que pueden ser más fáciles de leer. También pueden remitir a los usuarios a las notas de la versión para obtener más información.
El blog de un proyecto de código abierto también puede contener otro tipo de publicaciones, como un análisis en profundidad de una función, el anuncio de financiación o la solicitud de contribuciones o ayudas económicas.
Cuando elijas un creador de sitios web, intenta elegir uno que sea gratuito y que resulte familiar para el equipo de tu proyecto o lo suficientemente fácil para familiarizarse con él. Las entradas de blog basadas en Markdown son más fáciles de escribir a partir de notas de publicación. Asegúrate también de que publicar una nueva entrada de blog no sea un proceso complicado de 100 pasos, o nadie querrá escribir una. Puedes optar por utilizar GitHub para un proceso de revisión y previsualización de las entradas del blog.
Si creas un blog, asegúrate de crear también un canal RSS para él. En la mayoría de los generadores de sitios web estáticos, esto viene por defecto o está disponible activando una opción (documentación de Quarto).
Una vez que tu blog tenga un canal RSS, regístralo en ¿agregadores? relevantes como R Semanal en el mundo de R.
Si decides abrir comentarios en las entradas de tu blog, asegúrate de integrar los comentarios en el foro de tu proyecto.
Esto es muy fácil con un foro Discourse (que utilizamos en este mismo blog), y con Debates en GitHub a través de Giscus (que también son fáciles de integrar con Quarto entre otros).
Integrar los comentarios con tu foro significa que sólo tienes que vigilar un espacio, y también ayuda a conectar a los lectores de las entradas de tu blog con el foro.
Las redes sociales pueden ser útiles para dar a conocer tu proyecto y sus actualizaciones, y para interactuar con los usuarios. Puedes optar por hacer que tus redes sociales sean de “sólo lectura”, indicando claramente que no dispones de recursos para responder a preguntas allí.
Lo ideal es que concentres tu uso de las redes sociales en plataformas agradables y plataformas en las que es probable que se junten los usuarios y la comunidad de tus proyectos.
En este post, compartimos algunos consejos para la comunicación de tu proyecto de código abierto. Utiliza canales de comunicación acordes con los objetivos y recursos de tu proyecto. Puede que también te interese nuestra anterior convocatoria comunitaria Configura tu paquete para fomentar una comunidad.
