docs: added text format and fixed issues

docs/sections/code-versioning.md

@@ -2,7 +2,7 @@
 
 Para el sistema de versionamiento de software se deberán cumplirán las siguientes reglas:
 
-* Todos los proyectos nuevos deberán funcionar con el sistema de control de versiones GIT.  
+* Todos los proyectos nuevos deberán funcionar con el sistema de control de versiones **[Git](https://es.wikipedia.org/wiki/Git)**.  
 * No se deberán versionar archivos de más de 5 MB.  
 * Evitar versionar archivos binarios.
 
@@ -18,8 +18,8 @@ Todos los repositorios asociados a herramientas, plataformas, procesos y demás
   * **.gitattributes:** Usar una plantilla para el lenguaje que se vaya a utilizar. Si se desconoce, dejar el archivo en blanco.  
 * Crear la rama *develop* a partir de la rama *main*.  
 * Proteger ambas ramas:  
-  * No permitir push forzados  
-  * Requerir revisiones sobre los PR  
+  * No permitir *push* forzados  
+  * Requerir revisiones sobre los *PR*  
   * Aplicar las reglas para los administradores también  
 * Poner la rama *develop* como rama por defecto
 
@@ -31,27 +31,27 @@ Se recomienda realizar commits con pocos cambios y con nombres cortos y concreto
 
 Condiciones en los commits:
 
-* Cada commit debe ser funcional, es decir, al hacer checkout a un commit específico la aplicación debe funcionar sin errores de código.   
+* Cada commit debe ser funcional. Es decir, al hacer checkout a un commit específico la aplicación debe funcionar sin errores de código.   
 * Dejar al final, o incluso en una rama aparte optimizaciones y otros ajustes que se encuentren necesarios durante el desarrollo de la tarea.  
-* Cuando se genera la documentación en el mismo repositorio, por ejemplo con *APIDoc*, se debe generar en una rama aparte, cuyo PR irá a la rama principal de la tarea.  
+* Cuando se genera la documentación en el mismo repositorio, por ejemplo con *APIDoc*, se debe generar en una rama aparte, cuyo *PR* irá a la rama principal de la tarea.  
 * Deben ser escritos de tal forma que complementen la frase: *If applied, this commit will*…  
 * Cuando un mensaje sea muy grande, debe dividirse en varias líneas y la primera debe ser el “asunto” del commit, debe separarse por una línea en blanco del resto del commit, y el resto del commit puede ser una descripción o una lista de puntos para explicar más detalles.
 
 ## Revisión de código (code review)
 
-### Pull Requests (PRs)
+### *Pull Requests* (*PRs*)
 
-* Antes de crear un PR (*Pull Request*), se debe comprobar la funcionalidad del proyecto y los posibles eventos o errores que se hayan ejecutado en la plataforma de desarrollo (*GitHub*, *GitLab*) al ejecutar el comando *push*. En caso de existir errores, se deben solucionar antes de crear el PR.
+* Antes de crear un *PR* (*Pull Request*), se debe comprobar la funcionalidad del proyecto y los posibles eventos o errores que se hayan ejecutado en la plataforma de desarrollo (*GitHub*, *GitLab*) al ejecutar el comando *push*. En caso de existir errores, se deben solucionar antes de crear el *PR*.
 
-  **Nota:** Para el caso de GitHub, se recomienda ejecutar las acciones de github actions de manera local. Para eso puede usar [act](https://github.com/nektos/act) (vea [aquí](https://medium.com/@debasishkumardas5/running-github-actions-locally-a-complete-guide-for-windows-mac-and-linux-users-34c45999c7cd) un instructivo).
+  **Nota:** Para el caso de *GitHub*, se recomienda ejecutar las acciones de *github actions* de manera local. Para eso puede usar [act](https://github.com/nektos/act) (vea [aquí](https://medium.com/@debasishkumardas5/running-github-actions-locally-a-complete-guide-for-windows-mac-and-linux-users-34c45999c7cd) un instructivo).
 
-* Al crear un PR, se debe seleccionar la rama a subir y el destino, dependiendo del tipo de desarrollo que se esté realizando (*feature*, *release* o *hotfix*)
-* En caso de haber conflictos, el desarrollador que crea el PR debe resolverlos.  
-* Siempre se deben asignar revisores al PR.
+* Al crear un *PR*, se debe seleccionar la rama a subir y el destino, dependiendo del tipo de desarrollo que se esté realizando (*feature*, *release* o *hotfix*)
+* En caso de haber conflictos, el desarrollador que crea el *PR* debe resolverlos.  
+* Siempre se deben asignar revisores al *PR*.
 
 ### Revisores
 
-Los revisores deben verificar en cada PR los siguientes puntos:
+Los revisores deben verificar en cada *PR* los siguientes puntos:
 
 * Un correcto funcionamiento del proyecto  
 * Que la tarea, los criterios de aceptación y consideraciones se estén cumpliendo. Este paso se puede evitar en algunos casos, pero eso será mencionado en la tarea.  
@@ -59,17 +59,17 @@ Los revisores deben verificar en cada PR los siguientes puntos:
 * No debe haber impresiones a consola (ejemplo: *console.log*, *print*, *p*, *system.out.println*)  
 * El archivo *readme* debe estar actualizado en caso de ser necesario. Por ejemplo, si se introducen o cambian variables de configuración. (Como regla general, el archivo *readme* siempre debe estar al día)  
 * El código ha sido documentado de acuerdo a las prácticas del repositorio / proyecto  
-* Los nombres de las funciones y variables es claro de acuerdo a su uso.  
+* Los nombres de las funciones y variables son claros de acuerdo a su uso.  
 * No hay código sin usar (variables, funciones, clases, sentencias sueltas, etc).  
 * El código en general es entendible y lo suficientemente óptimo.  
   * Se debe buscar un balance entre optimización (entiéndase como evitar redundancias, repeticiones, estructuras de datos adecuadas, etc) y legibilidad del código.  
   * Prestar especial atención a las condiciones de carrera  
-* Si el PR incluye una nueva dependencia en el proyecto, hacer una breve investigación sobre la dependencia para verificar que no tenga problemas de seguridad, que la actualicen con cierta frecuencia y que efectivamente sea necesaria.
+* Si el *PR* incluye una nueva dependencia en el proyecto, hacer una breve investigación sobre la dependencia para verificar que no tenga problemas de seguridad, que la actualicen con cierta frecuencia y que efectivamente sea necesaria.
 
 
-## Git Flow
+## *Git Flow*
 
-En caso de haber más de 2 revisores en el PR, se debe tener en cuenta:
+En caso de haber más de 2 revisores en el *PR*, se debe tener en cuenta:
 
 * En casi todos los repositorios es suficiente con que uno lo apruebe. Pero la cantidad de aprobaciones necesarias la determina cada repositorio.  
 * Si un revisor solicita cambios, esa misma persona debe aprobar después.  
@@ -81,21 +81,21 @@ El nombre de una rama debe tener el nombre del usuario del instituto, un símbol
 
 Una tarea puede ser de tipo *feature*, lo cual implica que se lleva a desarrollo (rama *develop*) o de tipo *hotfix*, la cual se lleva tanto a producción (rama *master* o *main*) como a desarrollo (rama *develop*). El flujo de trabajo con estas ramas tienen cosas en común, pero también sus diferencias.
 
-Adicionalmente está las ramas *release*, que por lo regular tendrá una tarea asociada, pero es principalmente para marcar la dedicación en un sprint determinado.
+Adicionalmente están las ramas *release*, que por lo regular tendrán una tarea asociada, pero es principalmente para marcar la dedicación en un sprint determinado.
 
-#### Rama feature
+#### Rama *Feature*
 
 A continuación se presenta una guía del flujo de una rama tipo *feature*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer la tarea, como para los revisores.
 
 ![Manejo de ramas tipo "feature"](../../resources/diagrams/git-flow/branches-feature.drawio.svg)
 
-#### Rama release
+#### Rama *Release*
 
 A continuación se presenta una guía del flujo de una rama tipo *release*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el lanzamiento, como para los revisores.  
 
 ![Manejo de ramas tipo "release"](../../resources/diagrams/git-flow/branches-release.drawio.svg)
 
-#### Rama Hotfix
+#### Rama *Hotfix*
 
 Las tareas de estas ramas son para corregir algo urgente que no da tiempo de esperar a un lanzamiento.
 
@@ -105,11 +105,11 @@ A continuación se presenta una guía del flujo de una rama tipo *hotfix*. Aquí
 
 ### Lanzamientos y etiquetas (Releases, tags)
 
-Al crear un lanzamiento, se deben tener en cuenta lo siguiente:
+Al crear un lanzamiento, se debe tener en cuenta lo siguiente:
 
 1. Seleccionar la rama *main*/*master* para crear el lanzamiento  
-2. Asignar la etiqueta de la forma: \<\#1\>.\<\#2\>.\<\#3\>  
-3. Asignar el título de la versión de la forma: \<\#1\>.\<\#2\>.\<\#3\>  
+2. Asignar la etiqueta de la forma: **\<\#1\>.\<\#2\>.\<\#3\>** (ver [Versionamiento semántico](semantic-versioning.md))  
+3. Asignar el título de la versión de la forma: **\<\#1\>.\<\#2\>.\<\#3\>**  
 4. En la descripción del lanzamiento, redactar los cambios de la nueva versión teniendo en cuenta los siguiente:  
    1. No especificar cada commit ni cada tarea, solo los cambios en funcionalidades completas.  
    2. No detallar cambios técnicos. Por ejemplo, solo “*dependency update*” en lugar de listar todas las dependencias que se cambiaron
\ No newline at end of file

docs/sections/logs.md

 # Registro de eventos (logs)
 
-Para sistemas web, se recomienda implementar un sistema de registro de eventos (logs) con textos en Inglés. Es recomendable que se almacenen en una base de datos no relacional (por ejemplo, MongoDB).
+Para sistemas web, se recomienda implementar un sistema de registro de eventos (logs) con textos en Inglés. Es recomendable que se almacenen en una base de datos no relacional (por ejemplo, *MongoDB*).
 
 Los datos que debería tener un log son:
 

docs/sections/relational-dbs.md

@@ -62,7 +62,7 @@ Tareas del administrador de bases de datos (*DBA*):
 
 * Evitar el uso de vistas y procedimientos almacenados.  
 * Evitar la creación y el uso de columnas con datos binarios.  
-* En caso de tener columnas con datos binarios deben estar en tablas separadas referenciadas con la PK, con el fin de mejorar el tiempo en las búsquedas y las copias de seguridad.  
+* En caso de tener columnas con datos binarios deben estar en tablas separadas referenciadas con la llave primaria, con el fin de mejorar el tiempo en las búsquedas y las copias de seguridad.  
 * Evitar usar el asterisco (\*) en las sentencias *SELECT*.  
 * Si se van a realizar muchas inserciones o actualizaciones en una tabla, se deben utilizar [tareas por lotes](https://learn.microsoft.com/en-us/sql/odbc/reference/develop-app/batches-of-sql-statements?view=sql-server-ver16).  
 * En caso de necesitar una consulta que involucre muchas columnas y/o conversiones de las mismas, se recomienda crear un [campo computado](https://learn.microsoft.com/en-us/sql/relational-databases/tables/specify-computed-columns-in-a-table?view=sql-server-ver16).
\ No newline at end of file

docs/sections/security.md

-# Seguridad
+# Desarrollo seguro
 
 ## Recomendaciones generales
 
@@ -11,16 +11,16 @@
 ## Recomendaciones (Web)
 
 * Todos los sistemas de información deberán implementar un sistema de [registro de eventos (logs)](logs.md).
-* Todas las conexiones y manejo de credenciales y datos sensibles deben ser responsabilidad del back end. Bajo ninguna circunstancia el front end debe manejar directamente este tipo de datos.  
+* Todas las conexiones y manejo de credenciales y datos sensibles deben ser responsabilidad del *back end*. Bajo ninguna circunstancia el *front end* debe manejar directamente este tipo de datos.  
 * Los sistemas de autenticación deberán implementar protecciones ante ataques de [fuerza bruta](https://en.wikipedia.org/wiki/Brute-force_attack).  
 * Es recomendable que los sistemas de autenticación implementen un sistema de detección de robots del lado del servidor.  
 * Es recomendable habilitar sistemas de doble verificación (por ejemplo, [TOTP](https://en.wikipedia.org/wiki/Time-based_one-time_password)) en los sistemas de autenticación.  
 * Las restricciones y permisos de los roles de usuario en el sistema deberán funcionar en el front end y en el back end por igual.  
 * Los desarrollos web tendrán que estar preparados para ataques [XSS](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting), [CSRF](https://developer.mozilla.org/en-US/docs/Glossary/CSRF) y [SQL Injection](https://developer.mozilla.org/en-US/docs/Glossary/SQL_Injection).  
-* Todas las plataformas web del ambiente de producción tendrán que implementar protocolos de comunicación cifrados (Por ejemplo, HTTPS).
+* Todas las plataformas web del ambiente de producción tendrán que implementar protocolos de comunicación cifrados (Por ejemplo, *HTTPS*).
 
 ## Recomendaciones (Redes y conexiones)
 
-* Las conexiones a servidores Linux en producción deberán realizarse con claves privadas.  
-* Se recomienda que la conexión a sistemas privados y servicios de pruebas se realicen con una conexión por VPN.  
+* Las conexiones a servidores *Linux* en producción deberán realizarse con claves privadas.  
+* Se recomienda que la conexión a sistemas privados y servicios de pruebas se realicen con una conexión por *VPN*.  
 * Se recomienda que las conexiones a los servidores sean restringidas por IP pública, en caso de que los servidores pertenezcan a un servicio en la nube privado.
\ No newline at end of file

docs/sections/semantic-versioning.md

@@ -11,5 +11,5 @@ Para el versionamiento de proyectos de software, se recomienda el uso de las esp
     * El número **Y** indicará un número de versión menor (compatible con versiones anteriores)
     * El número **Z** indicará un número de parche.  
 * Nunca se deberá modificar el contenido de una versión existente. En caso necesario se debe crear una nueva versión.  
-* Al realizar un lanzamiento nuevo en Git (Release), el título deberá ser el número del lanzamiento (por ejemplo, 1.2.0)  
+* Al realizar un lanzamiento nuevo en *Git* (*[Release](code-versioning.md)*), el título deberá ser el número del lanzamiento (por ejemplo, *1.2.0*)  
 * Todo lanzamiento de una nueva versión deberá tener una descripción detallada de los cambios en la misma.
\ No newline at end of file

docs/sections/team-framework.md

 # Marco de trabajo
 
-En la línea de desarrollo se aplicará una versión de *SCRUM* (AÑADIR REFERENCIA AQUÍ) adaptada a las necesidades del equipo. 
+En la línea de desarrollo se aplicará una versión de *[SCRUM](https://es.wikipedia.org/wiki/Scrum_(desarrollo_de_software))* adaptada a las necesidades del equipo. 
 
 ## Estimación de tareas
 
-La estimación de tareas se realiza con “story points”, para lo cual se tiene una equivalencia entre rangos de tiempo y “story points”.
+La estimación de tareas se realiza con "*story points*", para lo cual se tiene una equivalencia entre rangos de tiempo y "*story points*".
 
 **Nota:** Un día es representado por 6 horas.
 
@@ -21,11 +21,11 @@ La estimación de tareas se realiza con “story points”, para lo cual se tien
 
 ### Cierre y planeación de sprint
 
-Los sprints serán semanales. Los miércoles de cada semana se realizará, en el mismo espacio el cierre y la planeación. El líder técnico es quien se encarga de priorizar y organizar las tareas para cada sprint previo a la ceremonia, cada miembro del equipo revisará las tareas asignadas y durante el la ceremonia las presentará y resolverá dudas.
+Los *sprints* serán semanales. Los miércoles de cada semana se realizará, en el mismo espacio el cierre y la planeación. El líder técnico es quien se encarga de priorizar y organizar las tareas para cada *sprint* previo a la ceremonia, cada miembro del equipo revisará las tareas asignadas y durante el la ceremonia las presentará y resolverá dudas.
 
 ### Daily
 
-El *daily meeting* se realizará de forma asíncrona en la plataforma *DailyBot* por medio de un bot en el chat del *Workspace* de *Google*. Es responsabilidad de cada desarrollador informar en las primeras horas de la mañana las tareas que haya realizado el anterior día laboral y las tareas que vaya a realizar en el día actual, el bot cuenta con un recordatorio y se espera que esto se haga antes de las 9:30 de la mañana. 
+El *daily meeting* se realizará de forma asíncrona en la plataforma *DailyBot* por medio de un bot en el chat del *Workspace* de *Google*. Es responsabilidad de cada desarrollador informar en las primeras horas de la mañana las tareas que haya realizado el anterior día laboral y las tareas que vaya a realizar en el día actual. El bot cuenta con un recordatorio y se espera que esto se haga antes de las 9:30 de la mañana. 
 
 ### Planning
 
@@ -36,14 +36,14 @@ Durante el *planning* se realizan las siguientes actividades:
    1. Se aclaran dudas que no se hayan podido resolver antes de la reunión.  
    2. Si la estimación no fue uniforme, se mencionan los puntos de vista de cada miembro y se llega a un consenso sobre la estimación.  
    3. Si no se ha asignado un responsable, se asigna.  
-      **Nota:** algunas tareas, especialmente las \[spike\] o \[poc\] pueden tener 2 responsables para atacar más de un enfoque en el mismo sprint.
+      **Nota:** algunas tareas, especialmente las *\[spike\]* o *\[poc\]* pueden tener 2 responsables para atacar más de un enfoque en el mismo sprint.
 
-   4. Si la tarea es un \[spike\] o un \[poc\] se programa una reunión de seguimiento con al menos otro miembro del equipo (normalmente será el líder técnico y/o alguien que tenga más clara la visión del objetivo de la tarea) a mitad del sprint para socializar los avances en la tarea y recibir retroalimentación y orientación  
-3. Adicional al orden en el que están las tareas en el pipeline de Sprint Backlog, algunas tareas pueden tener etiquetas para reforzar la prioridad que tienen.
+   4. Si la tarea es un *\[spike\]* o un *\[poc\]*, se programa una reunión de seguimiento con al menos otro miembro del equipo (normalmente será el líder técnico y/o alguien que tenga más clara la visión del objetivo de la tarea) a mitad del *sprint* para socializar los avances en la tarea y recibir retroalimentación y orientación  
+3. Adicional al orden en el que están las tareas en el *pipeline* de *Sprint Backlog*, algunas tareas pueden tener etiquetas para reforzar la prioridad que tienen.
 
 ### Retrospectiva
 
-Esta ceremonia se realizará en el mismo espacio del planning, justo antes de planear las tareas del siguiente sprint.
+Esta ceremonia se realizará en el mismo espacio del *planning*, justo antes de planear las tareas del siguiente sprint.
 
 * Se revisan las tareas que finalizaron. Los responsables explican resumidamente lo que se hizo en la tarea y mencionan cosas que deseen resaltar.  
-* Las tareas que no se terminaron, es decir, quedaron en estado *In Progress* o los cambios solicitados en *Review* son medianos o grandes, se vuelven a estimar (el esfuerzo que les falta) y se agregan al siguiente sprint. 
+* Las tareas que no se terminaron, es decir, quedaron en estado *In Progress* o los cambios solicitados en *Review* son medianos o grandes, se vuelven a estimar (el esfuerzo que les falta) y se agregan al siguiente *sprint*. 
\ No newline at end of file

docs/sections/tickets.md

-# Tareas (tickets)
+# Tareas (*tickets*)
 
-Todo nuevo requerimiento o error de un sistema debe ser debidamente documentado en un sistema de tickets y estar asignado a un integrante del equipo de desarrollo.
+Todo nuevo requerimiento o error de un sistema debe ser debidamente documentado en un sistema de *tickets* y estar asignado a un integrante del equipo de desarrollo.
 
 ## Creación
 
 Todos los miembros del equipo podrán crear tareas cuando sea necesario, las cuales se deberán crear en el repositorio correspondiente. 
 
-A continuación se presenta una guía para determinar en qué pipeline se debería crear:
+A continuación se presenta una guía para determinar en qué *pipeline* se debería crear:
 
 1. Primero se debe identificar el repositorio adecuado para crear la tarea. Por lo regular, si está relacionada con código, va a haber un repositorio dedicado para el proyecto o producto correspondiente.   
-2. Si el ticket es un bug reportado por algún investigador, se agrega al *backlog* con la máxima prioridad.  
-3. Si el ticket es una mejora, deberá ir en la sección “*New Issues / Icebox”* con la máxima prioridad.  
-4. Si se debe acortar el alcance de una tarea, se agrega en el backlog con la máxima prioridad.  
-5. Si es una actividad en la que se tuvo que trabajar sin previo aviso, pero del cuál se debe agregar registro (por ejemplo para poder asociar un PR), se debe agregar en el *sprint backlog* o en la sección “*In Progress*”.
+2. Si el *ticket* es un *bug* reportado por algún investigador, se agrega al *backlog* con la máxima prioridad.  
+3. Si el *ticket* es una mejora, deberá ir en la sección “*New Issues / Icebox”* con la máxima prioridad.  
+4. Si se debe acortar el alcance de una tarea, se agrega en el *backlog* con la máxima prioridad.  
+5. Si es una actividad en la que se tuvo que trabajar sin previo aviso, pero del cuál se debe agregar registro (por ejemplo para poder asociar un *PR*), se debe agregar en el *sprint backlog* o en la sección “*In Progress*”.
 
 En cuanto al contenido de la tarea, se debe tener en cuenta lo siguiente para su creación:
 
 * Debe tener una descripción que detalle el resultado esperado y las condiciones relacionadas a dicho resultado, esto puede estar acompañado de una lista de puntos para describir todo más fácilmente.  
-* Cuando sea necesario, debe haber una sección de “Consideraciones” en donde se deben describir cosas a tener en cuenta para la tarea. Por ejemplo: archivos de prueba, consultas a otros investigadores, ayudas a TI.
+* Cuando sea necesario, debe haber una sección de "Consideraciones" en donde se deben describir cosas a tener en cuenta para la tarea. Por ejemplo: archivos de prueba, consultas a otros investigadores, ayudas a TI.
 
 Al crear las tareas, se deben asignar las siguientes etiquetas:
 
@@ -25,9 +25,9 @@ Al crear las tareas, se deben asignar las siguientes etiquetas:
 * **Tipo**: Determinan el impacto de la tarea dentro de la plataforma:  
   `type:bug` \- `type:enhancement` \- `type:feature` \- `type:documentation`
 
-Las tareas asociadas al desarrollo normal de los compromisos de la línea son creadas por el líder técnico. Esto lo hará los últimos días del sprint anterior, de manera que los demás miembros del equipo puedan revisar, entender y dar una estimación inicial a las tareas antes de la reunión de planeación. 
+Las tareas asociadas al desarrollo normal de los compromisos de la línea son creadas por el líder técnico. Esto lo hará los últimos días del *sprint* anterior, de manera que los demás miembros del equipo puedan revisar, entender y dar una estimación inicial a las tareas antes de la reunión de planeación. 
 
-En caso de que se tengan dudas o comentarios acerca de las estimaciones de las tareas, se podrán comentar en el chat del grupo (BioDev).
+En caso de que se tengan dudas o comentarios acerca de las estimaciones de las tareas, se podrán comentar en el chat del grupo (*BioDev*).
 
 **Nota:** Cuando el líder técnico no logra preparar las tareas la semana anterior, es necesario dedicar tiempo al análisis de las tareas en la planeación misma.
 
@@ -35,6 +35,6 @@ En caso de que se tengan dudas o comentarios acerca de las estimaciones de las t
 
 * Al empezar a trabajar en una tarea, se debe pasar al pipeline “*In Progress*”. La tarea se mantendrá ahí a menos que por diferentes razones no se pueda seguir trabajando en ella, en cuyo caso pasará de nuevo a “*Sprint Backlog*”.   
 * Cuando no es necesario realizar una tarea (empezar o terminar), se debe añadir la etiqueta *wontfix*, agregar un comentario describiendo el por qué y cerrarla.  
-* Al crear un PR se debe asociar la tarea correspondiente. Esto automáticamente pasará la tarea al pipeline “*Review Q/A*”. De este estado solo vuelve a “*In Progress*” si los cambios solicitados son grandes.  
-* Antes de cerrar una tarea se deben dejar comentarios que sean relevantes en el futuro. Por ejemplo, si se tomaron decisiones durante el desarrollo de la misma, discusiones que se hayan tenido, fuentes de información relevantes, modificaciones de alcance, entre otros. No se espera un detalle técnico, a menos que no haya código relacionado en el repositorio (normalmente a través de un PR)  
-* Para cerrar una tarea, debe pasar por la aprobación y merge del PR. Si la tarea tiene solo un revisor asociado, debe tener el visto bueno por chat o en reunión por al menos otro miembro del equipo.
+* Al crear un *PR* se debe asociar la tarea correspondiente. Esto automáticamente pasará la tarea al *pipeline* “*Review Q/A*”. De este estado solo vuelve a “*In Progress*” si los cambios solicitados son grandes.  
+* Antes de cerrar una tarea se deben dejar comentarios que sean relevantes en el futuro. Por ejemplo, si se tomaron decisiones durante el desarrollo de la misma, discusiones que se hayan tenido, fuentes de información relevantes, modificaciones de alcance, entre otros. No se espera un detalle técnico, a menos que no haya código relacionado en el repositorio (normalmente a través de un *PR*)  
+* Para cerrar una tarea, debe pasar por la aprobación y mezcla (*merge*) del *PR*. Si la tarea tiene solo un revisor asociado, debe tener el visto bueno por chat o en reunión por al menos otro miembro del equipo.
\ No newline at end of file