La organización del Flujo de Documentos
Esta guía presenta miembros Docs y contribuidores aspirantes con el listado de etiquetas y categorías asociadas con Incidencias y Unión de Solicitudes en el repositorio de GitLab Docs.
El equipo de Documentos de Fedora agradecen la organización del flujo de trabajo, la cual converge en las dos páginas centrales:
Tablero de incidencias y etiquetas
Hay cuatro etiquetas que clasifican el estado de un ticket de incidencia.
-
Triage: la incidencia está etiquetada, pero todavía ninguna ha sido asignada. ¿Quiere tomarla? Siéntase libre de asignarse y emitir la incidencia a “En progreso”.
-
En progreso: alguno ha sido asignado a esta incidencia y está en progreso.
-
Soporte necesario: algo ya fue realizado, pero alguien tiene que apoyar al cesionario actual o hacerse cargo de la tarea.
-
Aprobación necesaria: esto es un cambio mayor y necesita una aprobación desde alguno más que el apoderado. Siéntase libre para tomar el control de aprobación tal que el asignante pueda fusionarse después.
«Abrir Solicitudes de Unión» no contiene una pizarra. Puede ver todas las etiquetas asignadas de una Solicitud de Unión abierta en el primer caso cuando abra la página «Abrir Solicitudes de Unión».
Adicionalmente, hay tres etiquetas que clasifican el tipo de un ticket de incidencia.
-
Cambio mayor: esto es un cambio mayor con página(s) de Docs. Necesita un Merge Request y tiene que ser aprobado por alguien más que el asignado antes que puedea ser unido.
-
Cambio menor: esto solo es un cambio menor en página(s) de Docs. No necesita una aprobación, y puede ser realizada directamente (una Solicitud de Unión no es obligatoria).
-
Tarea interna: esto es una tarea interna de Fedora Docs que no es un cambio, reparación o actualización de una página de Docs page/content. (Ejemplo: preparar un encuentro o evaluar una consulta).
Cada ticket de incidencia y cada Merge Request abierto tiene que estar etiquetado adicionalmente con una de estas tres etiquetas. El tipo de etiquetas no cambia durante el flujo de trabajo.
Además de una etiqueta de estado y una etiqueta de tipo, los tickets de incidencia y las solicitudes de fusión pueden etiquetarse como «primera incidencia buena». ¿Quieres contribuir a la documentación de Fedora? Esta es tu oportunidad. No dudes en comentar en una de estas incidencias que quiera auto-asignar.
Además, existe una etiqueta adicional para las solicitudes de fusión que podrían afectar a más de una rama, lo que significa que requieren solicitudes de fusión posteriores o selecciones selectivas. La etiqueta múltiples solicitudes de fusión probablemente garantiza que se identifiquen y actualicen todas las ramas afectadas, y que las solicitudes de fusión no se fusionen sin la revisión de la solicitud de fusión.
Como se crean los ticket de incidencia y Solicitud de Unión.
Hay dos maneras de etiquetas de incidencias y Solicitudes de Unión que pueden ser creados: externamente e internamente.
-
Si se crean externamente, son creados por personas ajenas al equipo de Fedora Docs, quienes los abrieron en GitLab o mediante los botones «Reportar una incidencia» (crea los ticket de incidencia) o «Editar esta página» (crea Solicitudes de Fusión) en cualquier página de Fedora Docs (los botones se encuentran en la esquina superior derecha). Los ticket aparecerán en el listado «Abiertos» del panel sin etiquetas. Las solicitudes de fusión aparecerán en la página «Solicitudes de fusión abiertas» sin etiquetas.
-
Si se creó internamente, un miembro del equipo de documentación lo abrió. En el mejor de los casos, este miembro ya asigna una etiqueta de tipo y coloca los tickets de incidencia en la lista "Triaje", donde pueden esperar a que un asignado los tome. Lo mismo ocurre con las solicitudes de fusión, aunque no tienen listas de arrastrar y soltar y la etiqueta "Triaje" debe configurarse manualmente, al igual que la etiqueta de tipo. Como alternativa, el miembro creador puede asignar un asignado al ticket de incidencia/solicitud de fusión y luego colocarlo (arrastrando y soltando) en la lista "En curso" (esto implica agregar la etiqueta "En curso") en el panel, o agregar manualmente la etiqueta de incidencia «En curso» si se trata de una solicitud de fusión.
En el panel, los ticket de incidencia se pueden mover por las listas arrastrando y soltando. Las etiquetas de estado cambian según corresponda. Si un ticket se mueve de "Triage" a "En progreso" arrastrando y soltando, la etiqueta de estado cambia de «Triage» a «En progreso». Por lo tanto, solo las etiquetas de tipo persistente deben configurarse manualmente una vez cuando el ticket es nuevo. Esto no aplica a las solicitudes de fusión en la página "Abrir solicitud de fusión". Al crear un ticket de incidencia en el panel, se le preguntará dónde crearlo. Si no está seguro de dónde crearlo, créelo en Fedora / Documentos de Fedora / Sitio web de documentos / Páginas de documentos de Fedora. Lo verá en el listado «Proyectos» («Seleccionar un proyecto») que se muestra al hacer clic para crear un ticket de incidencia. Posteriormente, se mostrará como "fedora/docs/docs-website/pages".
El flujo de trabajo
Cambio menor
Si lo realizan miembros de Docs y se trata claramente de un «cambio menor», se puede realizar mediante una confirmación directa, sin necesidad de una solicitud de fusión ni un ticket de incidencia. Si los miembros externos realizan una solicitud de fusión como "cambio menor", los miembros de Docs la fusionan inmediatamente tras asignarse a sí mismos y revisarla. Sin embargo, siempre verifique si un cambio aplica a varias ramas.
Si varias ramas se ven afectadas por un "Cambio menor", solo podrá fusionar/confirmar directamente si realiza la fusión/confirmación y la selección selectiva de todas las ramas afectadas a la vez. Si tiene dudas, añada la etiqueta "múltiples MR probables" a la etiqueta "Cambio menor" y mantenga la solicitud de fusión abierta para su discusión.
Dependiendo de la siguiente discusión, la etiqueta "múltiples MR probables" se eliminará si no hay otras ramas afectadas y entonces se podrá realizar la fusión o confirmación. Si hay otras ramas afectadas, se podrá realizar la fusión o confirmación y se seleccionarán todas las ramas afectadas de inmediato. El objetivo es que una solicitud de fusión no desaparezca de la página "Abrir solicitud de fusión" hasta que se complete la actualización de todas las ramas afectadas.
Si la discusión se lleva a cabo dentro de un ticket de incidencia (usando confirmaciones en lugar de solicitudes de fusión, o usando múltiples solicitudes de fusión que convergen dentro de un ticket) y no dentro de una solicitud de fusión, la confirmación y las selecciones se pueden realizar por separado.
El flujo de trabajo para un cambio menor es el siguiente:
-
Si solo se trata de una confirmación que claramente es un «cambio menor», simplemente hágalo. Si sabe qué ramas se ven afectadas y puede realizar la confirmación y todas las selecciones pertinentes, adelante. Si no tiene tiempo suficiente para completar la tarea, proceda de la siguiente manera:
-
Determine el tipo y asigne la etiqueta correspondiente («Cambio menor», «Cambio mayor», «Tarea interna». Aquí: Cambio menor) a la solicitud de fusión o al ticket de incidencia existente. Si aún no existe ninguno, ¡cree uno! Si no está seguro de qué crear, cree un ticket de incidencia.
-
Mueva las incidencias nuevas al listado «Triage» (que, como se explicó anteriormente, asigna automáticamente la etiqueta de estado «Triage») o agregue la etiqueta «Triage» manualmente si se trata de una solicitud de fusión.
-
El ticket de incidencia o la solicitud de fusión se puede asignar a un miembro que asume el control. Una vez asignado, el ticket debe pasarse a «En proceso» (el cambio a «En proceso» debe hacerse manualmente para las solicitudes de fusión).
-
Hay unas pocas opciones.
-
El cesionario finaliza el ticket/MR de incidencia y, en consecuencia, lo cambia de su estado actual a "Cerrado". Si se deben cambiar varias sucursales y el caso se gestiona dentro de una MR, todas las ramificaciones deben modificarse a la vez.
-
Como alternativa, si el asignado necesita apoyo u opiniones adicionales: el ticket/MR simplemente se mueve a "Se necesita apoyo" para identificar a los que apoyan (quienes pueden, aunque no necesariamente, ser asignados como asignados adicionales si es necesario). Una vez identificados suficientes, se mueve/pone de nuevo en "En curso". Use "Se necesita apoyo" para fomentar una discusión en el ticket/MR y obtener opiniones adicionales. Una vez finalizado todo el trabajo, el ticket/MR puede moverse/poner en "Cerrado". Si se deben cambiar varias ramas y el caso se gestiona dentro de una rama, todas las ramas deben cambiarse a la vez. Los miembros pueden reasignar la incidencia (por ejemplo, si alguien tiene más experiencia con la tarea o puede dedicar más tiempo).
-
Si el cesionario ya no puede brindar soporte para la incidencia, este cambia la etiqueta de la incidencia a «Se necesita soporte» y busca un nuevo cesionario, o hace un comentario sobre el trabajo completado y el trabajo restante, elimina al asignante y cambia el estado a «Triaje».
-
Cambio mayor
«Probablemente haya varios MR» se puede transferir a «Cambios importantes», que necesitan un ticket de incidencia o una Solicitud de Fusión.
El flujo de trabajo para un cambio importante es el siguiente:
-
Determine el tipo y vuelva a etiquetar la solicitud de fusión o el ticket de incidencia como Cambio mayor.
-
Mueva las incidencias nuevas al listado «Triage» o agregue manualmente la etiqueta «Triage» si se trata de una Solicitud de Fusión.
-
El ticket de incidencia o la Solicitud de Unión se pueden reasignar a otros miembros. Una vez que se ha asignado a alguien, el ticket pasa a «En curso» (el cambio a «En curso» se realiza manualmente para las Solicitudes de Unión).
-
Hay unas pocas opciones.
-
El asignado finaliza el trabajo activo* en el ticket de incidencia/MR, y lo mueve/coloca desde la etiqueta de estado actual a «Se necesita aprobación».
-
Alternativamente, el asignado necesita apoyo u opiniones adicionales. El ticket/MR se mueve a "Se necesita apoyo" para identificar a los que apoyan. Una vez que suficientes voluntarios se ofrezcan, la incidencia vuelve a "En curso". "Se necesita apoyo" también puede usarse para fomentar una discusión en el ticket/MR y obtener opiniones adicionales. Una vez completado, el ticket/MR se puede mover a "Se necesita aprobación". Cambie el asignado responsable a alguien con más experiencia en la siguiente tarea o que pueda dedicar más tiempo.
-
Si varias ramas se ven afectadas, agregue la etiqueta «probables múltiples MR». Si se asigna esta etiqueta, la discusión dentro del ticket/MR debe identificar todas las ramas afectadas. Finalmente, la solicitud de fusión debe transferirse a todas las ramas afectadas mediante la selección de cambios. Si es necesario modificar varias ramas, todos los cambios deben realizarse a la vez.
| No uses la rama "stg" para el contenido. Trabaja en bifurcaciones y ramas dedicadas a la incidencia específica en el que estás trabajando. |
El papel de la reunión semanal
La reunión semanal de Documentos ayuda a identificar y abordar incidencias y tareas inusuales o que no ocurren con regularidad. Por otro lado, la organización del flujo de trabajo está diseñada para gestionar las operaciones diarias estandarizadas de Fedora Docs.
Los ticket de incidencia actual y Solicitud de Unión de organización de flujo de trabajo pueden convertirse en temas usuales en los encuentros semanales.
-
Compruebe si hay algún desarrollado imprevisto en el flujo de trabajo que necesita una discusión.
-
Identificar y asignar los ticket de incidencias y MR que permanecen sin asignar durante más de dos semanas, y analizar aquellos que permanecen abiertos un mes después de haber sido asignados.
-
Utilice la etiqueta Meeting para incidencias o MR para ser discutidas en el encuentro de Docs.
Want to help? Learn how to contribute to Fedora Docs ›