9  Gestión editorial

Guía para gestionar el equipo editorial y cómo gestionar la publicación de una nueva versión de la guía de desarrollo.

9.1 Reclutar nuevas personas para la edición

Reclutar nuevas personas y mantener un equipo editorial funcional y equilibrado es responsabilidad de quien Lidere la Revisión de Software con el apoyo y asesoramiento del comité editorial.

Estos son los pasos a seguir:

  • Crea un canal privado para discutir la invitación; de este modo, el historial de conversación no queda disponible en el canal al que luego se unirán los nuevos miembros del equipo, lo que podría ser incómodo.

  • Haz un ping a las personas del equipo editorial para asegurarte de que reciban una notificación, ya que se trata de un tema importante.

  • Espera a que la mayoría de del equipo intervenga antes de realizar la invitación. Dales una semana para que respondan.

9.2 Invitar a una nueva persona al equipo

Nos gustaría invitarte a formar parte del consejo editorial de rOpenSci como miembro en pleno derecho. [RAZONES ESPECÍFICAS PARA LA INVITACIÓN (MENCIONA LAS CONTRIBUCIONES A ROPENSCI)]. 
Creemos que serías una magnífica incorporación al equipo.

[SI REALIZÓ EDICIÓN DE FORMA INVITADA: Ya conoces el rol de edición ya que has sido editora/o invitada/o]. Nuestro objetivo es que los miembros del comité editorial se encarguen de cuatro paquetes al año ([SI REALIZÓ EDICIÓN DE FORMA INVITADA: ¡incluyendo el que acabas de terminar!]).  
Pedimos a los miembros del comité editorial que se comprometan de manera informal a prestar servicio durante dos años, y que reevalúen su participación luego de ese periodo.
A corto plazo, cualquier persona puede rechazar encargarse de un paquete o decir: "Tengo mi agenda completa, no puedo encargarme de un nuevo paquete hasta dentro de unas semanas".

Además de encargarse de los paquetes, los miembros del equipo editorial opinan sobre las decisiones editoriales del grupo, como por ejemplo si un paquete está dentro de nuestro alcance, y determinan las actualizaciones de nuestras políticas. 
Generalmente usamos Slack, donde esperamos que los miembros del equipo participen regularmente. 
Tenemos reuniones anuales del equipo editorial.  
También rotamos las responsabilidades de Lider Editorial (quien toma decisiones de alcance en primera instancia y asigna personas para editar envíos) entre el equipo aproximadamente cada trimestre. 
Tendrás la oportunidad de entrar en esta rotación cuando lleves un tiempo en el equipo, normalmente al menos seis meses. 
Algunos mimebros del equipo también asumimos proyectos más grandes para mejorar el proceso de revisión por pares, aunque esto es totalmente opcional. 

¡Esperamos que te unas al equipo!  
Es un momento emocionante para la revisión por pares en rOpenSci.

Por favor, reflexiónalo, pregúntanos cualquier duda que tengas y haznos saber si puedes unirte.

Te deseamos lo mejor,
[NOMBRE], en nombre del equipo editorial de rOpenSci.

9.3 Incorporar un nuevo miembro al equipo

  • Añadir al archivo “team.json” del sitio web las propiedades "editor": true y para editores/as de paquetes estadísticos, también "stats": true. Eso añadirá automáticamente a las nuevas personas al equipo editorial que se muestra en la página del sitio web de rOpenSci.

  • Informa a quien gestiona la comunidad de rOpenSci para que pueda preparar un artículo introductorio para el blog y realice los anuncios en redes sociales.

  • Solicita a la nueva persona que active la autenticación de dos factores (2FA) en GitHub si aún no lo han hecho.

  • Invita a esta persona a la organización rOpenSci en GitHub como integrante, tanto del equipo editors como del equipo editorial de paquetes estadísticos stats-editors. Esto le dará los permisos adecuados y garantizará que aparezcan en el panel editorial.

  • Envíale una invitación a la base de datos de Airtable de revisión de software (enlazada en la descripción del canal sólo para editores en Slack). Asegúrate de que la invitación es “Sólo lectura”.

  • Dale acceso al canal privado “editors-only” del espacio de trabajo Slack de rOpenSci (y al espacio de trabajo Slack en general si aún no están allí).

  • Una vez que esté en el canal “editors-only”, envía un mensaje de bienvenida con un ping a todas las personas editoras.

9.4 Dar de baja a un integrante del equipo editorial

  • Agradece su trabajo.

  • Informa a quien maneja la comunidad de rOpenSci o a algún otro miembro del personal para anunciarlo en nuestro newsletter mensual y agradecerle.

  • Remueve a esta persona del canal “editors-only” y del equipo Slack de personas editoras.

  • Remueve a la persona del equipo editors y del sub-equipo correspondiente en GitHub.

  • Actualiza “team.json” en el sitio web sustituyendo “roles” por “past_roles”, y añadiendo un nuevo campo, alumnus: "true".

  • Remueve su acceso al espacio de trabajo de AirTable.

    • Desde la vista “interfaz”, despliega el menú principal en la parte superior izquierda y entra en “View Data (ver datos)”
    • Haz clic en el botón “Share (compartir)” de la parte superior derecha, y luego en “People with access (personas con acceso)”
    • Haz clic en la casilla de la izquierda de la persona que quieras remover y luego en “Remove 1 collaborator (remover 1 colaborador/a)”.

  • Las listas de integrantes del equipo editorial, tanto en el capítulo de introducción a la revisión del software en la guía como en el README del repo de revisión de software, se completan automáticamente a partir de los datos de AirTable. Las actualizaciones se ejecutan diariamente, así que compruébalo un día después de actualizar AirTable para asegurarte de que ambos se hayan actualizado.

9.5 Poner el sistema en pausa

Si quieres poner el sistema en pausa, por ejemplo durante las vacaciones, antes de irte:

  • Añade un mensaje de vacaciones al about de las plantillas de issues. PR de ejemplo.
  • Añade un mensaje de vacaciones a la respuesta de bienvenida estándar del bot. PR de ejemplo.

Al reanudar las actividades:

  • Elimina el mensaje de vacaciones de las plantillas de issues. PR de ejemplo.
  • Elimina el mensaje de vacaciones de la respuesta de bienvenida estándar del bot. PR de Ejemplo.

9.6 Gestión de la publicación de la guía de desarrollo

Si te encargas de gestionar una versión de este mismo libro que estás leyendo, utiliza la guía para la publicación de libros como plantilla de issue para publicar en el gestor de issues de la guía de desarrollo y no dudes en hacer preguntas al resto del equipo de edición.

9.6.1 Gobernanza de la guía de desarrollo

Para modificaciones muy pequeñas de la guía de desarrollo, no es necesaria la revisión del PR. Para enmiendas mayores, solicita la revisión de al menos varios miembros del equipo de edición (si ninguno participó en la discusión relacionada con la enmienda, solicita una revisión de todos en GitHub, y en ausencia de cualquier reacción aprueba el PR después de una semana).

Dos semanas antes del lanzamiento de una nueva versión de la guía de desarrollo, una vez que el PR de dev a master y la publicación en el blog estén listos para su revisión, todos los miembros del equipo de edición deben recibir una notificación de GitHub (“solicitud de revisión” en el PR de dev a main) y Slack, pero no es necesario que todos aprueben explícitamente la publicación.

9.6.2 Artículo de blog sobre una publicación

El artículo del blog sobre una nueva edición será revisado por el equipo de edición y por alguien de @ropensci/blog-editors.

9.6.2.1 Contenido

Consulta la guía general para blogs rOpenSci y las orientaciones más específicas a continuación.

Primer ejemplo de un artículo de este tipo; segundo ejemplo.

El artículo del blog debe mencionar todos los elementos importantes del registro de cambios organizados en (sub)secciones: por ejemplo, una sección sobre el gran cambio A, otra sobre el gran cambio B, y otra sobre cambios menores agrupados. Menciona primero los cambios más importantes.

Por cada cambio realizado por una persona que colabora de manera externa, agradéceselo explícitamente utilizando la información del registro de cambios. Por ejemplo [Matt Fidler](https://github.com/mattfidler/) arregló nuestra sección sobre mensajes en la Consola [ropensci/dev_guide#178](https://github.com/ropensci/dev_guide/pull/178)..

Al final del post, menciona los próximos cambios enlazando a los issues abiertos en el repositorio, e invita a quienes leen a contribuir a la guía de desarrollo abriendo issues y participando en los debates abiertos. Plantilla de conclusiones:

En este post resumimos los cambios incorporados a nuestro libro ["rOpenSci Packages: Development, Maintenance, and Peer Review"](https://devguide.ropensci.org/) en los últimos X meses.
Agradecemos todas las personas cuyas contribuciones han hecho posible esta versión.
Ya estamos trabajando en actualizaciones para nuestra próxima versión, como *ISSUE1*, *ISSUE2.*
Echa un vistazo a [la lista de *issues*](https://github.com/ropensci/dev_guide/issues/) si quieres contribuir.

9.6.2.2 Autoría

Quien escribe el post lidera la lista de autoría, el resto del equipo de edición aparecen en orden alfabético.