Merge branch 'update-docs' into 'master'

Update non pendings development rules files

See merge request !1

.vscode/settings.json

 {
     "editor.formatOnSave": true,
     "editor.wordWrap": "on",
+    "cSpell.language": "en,es-ES",
 }

docs/development-rules/README.md

@@ -17,3 +17,6 @@
 - [Registro de eventos (logs)](sections/logs.md) 🪵 - ¡Registra los eventos importantes para facilitar la depuración y el monitoreo!
 - [Desarrollo seguro](sections/security.md) 🛡️ - ¡Protege tu aplicación contra vulnerabilidades y ataques!
 - [Bases de datos relacionales](sections/relational-dbs.md) 📊 - ¡Asegúrate de que tus bases de datos sean ordenadas, eficientes y seguras!
+
+---
+* volver al [inicio](/README.md)

docs/development-rules/sections/code-versioning.md

 # Versionamiento de código fuente
 
-Para el sistema de versionamiento de software se deberán cumplirán las siguientes reglas:
+Para el sistema de versionamiento de software se deberán cumplir las siguientes reglas:
 
 * Todos los proyectos nuevos deberán funcionar con el sistema de control de versiones *[Git](https://en.wikipedia.org/wiki/Git)*.
 * No se deberán versionar archivos de más de 5 MB.
@@ -8,7 +8,7 @@ Para el sistema de versionamiento de software se deberán cumplirán las siguien
 
 ## Repositorios
 
-Todos los repositorios asociados a herramientas, plataformas, procesos y demás temas relacionados deben pertenecer a la organización [Dirección de Conocimiento](https://github.com/PEM-Humboldt). La creación de repositorios está restringida a los propietarios de la organización. En caso de que a un desarrollador se le asigne la creación de un repositorio, obtendrá permisos temporales y deberá tener en cuenta lo siguiente:
+Todos los repositorios asociados a herramientas, plataformas, procesos y demás temas relacionados deben pertenecer a la organización [Dirección de Conocimiento](https://github.com/PEM-Humboldt). La creación de repositorios está restringida a los propietarios de la organización. En caso de que a un investigador se le asigne la creación de un repositorio, obtendrá permisos temporales y deberá tener en cuenta lo siguiente:
 
 * Asignar el repositorio a un [equipo de trabajo](https://github.com/orgs/PEM-Humboldt/teams). El equipo le será indicado en la tarea.
 * Añadir los siguientes archivos al repositorio:
@@ -25,7 +25,9 @@ Todos los repositorios asociados a herramientas, plataformas, procesos y demás
 
 **NOTA:** Puede construir fácilmente archivos *gitignore* y *gitattributes* con las herramientas web [*gitignore.io*](http://gitignore.io) y [*gitattributes.io*](http://gitattributes.io).
 
-## Commits
+## *Git flow*
+
+### Commits
 
 Se recomienda realizar commits con pocos cambios y con nombres cortos y concretos. Todos los commits deberán escribirse en Inglés.
 
@@ -37,17 +39,23 @@ Condiciones en los commits:
 * 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* y *Merge Requests* (*PRs* y *MRs*)
 
-* 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*) o *MR* (*Merge Requests*), 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).
 
-* 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*)
+* Al crear un *PR*, se debe seleccionar la rama que se trabajó el destino dependerá del tipo de desarrollo que se esté realizando (*feature*, *release* o *hotfix*). Recuerde que el orden de estas ramas está invertido en GitLab (para los *MR*)
 * En caso de haber conflictos, el desarrollador que crea el *PR* debe resolverlos.
 * Siempre se deben asignar revisores al *PR*.
+* Al crear un PR/MR en la sección *Associated issues* de la plantilla debe enlazar la tarea correspondiente usando las palabras mágicas (nunca a través del título). Puede ver las instrucciones para [GitLab](https://linear.app/docs/gitlab#use-a-magic-word) y para [GitHub](https://linear.app/docs/github#link-through-pull-requests)
+
+#### Consideraciones
+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 es determinada por la sensibilidad de la tarea.
+* Si un revisor solicita cambios, esa misma persona debe aprobar después.
+* Más de un revisor puede solicitar cambios. Luego, se deberá tener la aprobación de todos los que hayan solicitado cambios.
 
 ### Revisores
 
@@ -57,43 +65,34 @@ Los revisores deben verificar en cada *PR* los siguientes puntos:
 * 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.
 * No debe haber código comentado.
 * 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  
+* 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 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  
+  * Para el caso de JavaScript e implementaciones asíncronas 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.
 
-
-## *Git Flow*
-
-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.  
-* Más de un revisor puede solicitar cambios. Luego, se deberá tener la aprobación de todos los que hayan solicitado cambios.
-
 ### Ramas
 
-El nombre de una rama debe tener el nombre del usuario del instituto, un símbolo de barra o *slash* (“/”) y el número de la tarea a resolver. Por ejemplo: *pperez/LIB-01*, *pgonzalez/LIB-042*
+El nombre de una rama debe tener el nombre del usuario del instituto, un símbolo de barra o *slash* (“/”) y el identificador de la tarea a resolver. Por ejemplo: *pperez/LIB-01*, *pgonzalez/LIB-042*
 
 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á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.
+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 y actualizar la documentación en otras ubicaciones.
 
 #### 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)
+![Manejo de ramas tipo "feature"](/resources/diagrams/git-flow/branches-feature.drawio.png)
 
 #### 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)
+![Manejo de ramas tipo "release"](/resources/diagrams/git-flow/branches-release.drawio.png)
 
 #### Rama *Hotfix*
 
@@ -113,3 +112,7 @@ Al crear un lanzamiento, se debe tener en cuenta lo siguiente:
 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
+
+---
+* volver al [inicio](/README.md)
+* volver a las [normas de desarrollo](/docs/development-rules/README.md)

docs/development-rules/sections/docs.md

@@ -2,10 +2,16 @@
 
 ## Documentación técnica
 
-Para la documentación técnica se utilizarán archivos con formato [Markdown](https://en.wikipedia.org/wiki/Markdown) en el repositorio con una descripción breve del proyecto e instrucciones detalladas de instalación. La documentación deberá ser escrita en Inglés.
+La documentación técnica será escrita en archivos con formato [Markdown](https://en.wikipedia.org/wiki/Markdown), la mayoría de los proyectos tendrá dos partes:
+1. El README del repositorio, donde se encontrará una descripción breve del proyecto e instrucciones detalladas de instalación. La documentación deberá ser escrita en Inglés para los repositorios en GitHub.
+1. Repositorio en el GitLab interno con instrucciones y consideraciones específicas de despliegue
 
 ## Diagramas
 
-Para diagramas complejos o que requieren mucho formato, se recomienda utilizar [draw.io](https://www.drawio.com/).
+Para diagramas complejos o que requieren mucho formato, se recomienda utilizar [draw.io](https://www.drawio.com/). En este sitio puede cargar los archivos `.drawio.png` que se encuentran en repositorios como este para realizar las ediciones necesarias.
 
-Para diagramas técnicos (por ejemplo, `diagramas de flujo` o `Entidad-Relación`), se deberá utilizar [MermaidJS](https://mermaid.js.org/intro/) en un repositorio local.
+Para diagramas técnicos (por ejemplo, `diagramas de flujo` o `Entidad-Relación`), se deberá utilizar [MermaidJS](https://mermaid.js.org/intro/) en el repositorio correspondiente.
\ No newline at end of file
+
+---
+* volver al [inicio](/README.md)
+* volver a las [normas de desarrollo](/docs/development-rules/README.md)

docs/development-rules/sections/semantic-versioning.md

 # Versionamiento semántico
 
-Para el versionamiento de proyectos de software, se recomienda el uso de las especificaciones del [Versionamiento Semántico](https://semver.org).
+Esta sección es de vital importancia cuando corresponde hacer un deploy de alguna de las plataformas desarrolladas por el equipo.
+
+Para el versionamiento de proyectos de software, seguimos las especificaciones del [Versionamiento Semántico](https://semver.org).
 
 ##  Especificación
 
 * Un número de versión deberá tener el formato **X.Y.Z** en donde **X**, **Y** y **Z** son números enteros no negativos y no deben ser precedidos de ceros.
 * Cada elemento debe incrementarse numéricamente.
 * En el formato **X.Y.Z**:
-    * El número **X** indicará un número de versión mayor (por ejemplo, un cambio completo de una API)
-    * 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.  
+    * El número **X** indicará un número de versión mayor, corresponde a cambios que no tienen compatibilidad con versiones anteriores (por ejemplo, un cambio completo de una API)
+    * El número **Y** indicará un número de versión menor, indica cambios compatible con versiones anteriores (por ejemplo, nuevas características o ajustes de bugs no prioritarios)
+    * El número **Z** indicará un número de parche, lo que se denomina un `hotfix` en inglés.
 * 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](code-versioning.md)*), el título deberá ser el número del lanzamiento (por ejemplo, *1.2.0*)  
+* Al realizar un lanzamiento nuevo en *GitHub* (*[Release](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)*), 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.
+
+---
+* volver al [inicio](/README.md)
+* volver a las [normas de desarrollo](/docs/development-rules/README.md)

docs/development-rules/sections/team-framework.md

 # Marco de trabajo
 
-En la línea de desarrollo se aplicará una versión de *[SCRUM](https://en.wikipedia.org/wiki/Scrum_(software_development))* adaptada a las necesidades del equipo. 
+En la línea de informática de la biodiversidad aplicamos una versión de *[SCRUM](https://en.wikipedia.org/wiki/Scrum_(software_development))* 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*".
 
-**Nota:** Un día es representado por 6 horas.
+**Nota:** Un día es representado por 6 horas efectivas de trabajo.
 
 | Puntos | Tiempo |
 | :---: | :---: |
@@ -21,11 +21,11 @@ La estimación de tareas se realiza con "*story points*", para lo cual se tiene
 
 ### 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* duran 2 semanas, iniciando los miércoles. El día de inicio 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. Durante la ceremonia cada persona presentará las tareas asignadas, resolverá dudas y participará en las presentaciones de los demás miembros.
 
 ### 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](https://app.dailybot.com/checkins/bfe64453-2b94-4ea5-b811-eb70b8ea1181/daily-report/2025-06-25)* por medio de un bot en el chat del *Workspace* de *Google*. Es responsabilidad de cada persona 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
 
@@ -34,16 +34,31 @@ Durante el *planning* se realizan las siguientes actividades:
 1. Se revisa la priorización de las tareas. De acuerdo a las consideraciones que tengan los demás miembros del equipo se pueden reorganizar.
 2. Por cada tarea:
    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.  
+   2. Si la persona que tiene la tarea asignada tiene dudas, 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.
 
-   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.
+
+   1. Se pasa la tarea de la columna *Sprint Backlog* a *Todo*
+
+El tablero debe siempre estar organizado por prioridad, la cual es asignada por el líder técnico o encargado del proyecto
+
+Previo al espacio para el planning se van creando las tareas para revisión en el pipeline *Sprint Backlog*. En caso de que se tengan dudas o comentarios acerca de las tareas o sus estimaciones, se podrán comentar en el chat del grupo (*BioDev*).
+
+En el pipeline *Sprint Backlog* también se dejan las tareas "bonus" del sprint (tareas con prioridad baja que se pueden trabajar si se acaba con la carga del sprint)
+
+**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.
 
 ### Retrospectiva
 
 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 *In Review* se agregan al siguiente *sprint*, no se modifica la estimación.
\ No newline at end of file
+
+
+---
+* volver al [inicio](/README.md)
+* volver a las [normas de desarrollo](/docs/development-rules/README.md)

docs/development-rules/sections/tickets.md

 # Tareas (*tickets*)
+Se tendrán tareas para todas las actividades que involucren una de las siguientes consideraciones:
+- Corresponde al diagnóstico o corrección de un error en una de las plataformas
+- Corresponde a una investigación (*[spike]*) o a una prueba (*[POC]*) relacionada a algún compromiso de la línea
+- Es una responsabilidad que tiene un resultado concreto (por ejemplo un PR, MR o un documento)
 
-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.
+Ejemplos de actividades que no se manejan con tareas en el tablero del equipo:
+- Apoyo en un proceso de selección (por ejemplo revisión de pruebas, hojas de vida o entrevistas)
+- Apoyo en algún proceso o problema que tengan en otra línea (por ejemplo revisión de algún código, una consulta rápida en base de datos)
+- Levantar un servicio caído
+- Asistir a reuniones de futuros proyectos o convenios
+- Tareas que surgen a partir de la supervisión de un contrato (a menos que sean actividades técnicas que tenemos que resolver, como dar acceso a alguien a un servidor o servicio)
+
+Cabe aclarar que sí se debe crear una tarea si alguna de las actividades mencionadas en el punto anterior se extiende o complejiza.
 
 ## Creación
 
-Todos los miembros del equipo podrán crear tareas cuando sea necesario, las cuales se deberán crear en el repositorio correspondiente. 
+Normalmente será el líder técnico o encargado del proyecto quien cree las tareas, pero todos los miembros del equipo podrán hacerlo cuando sea necesario.
 
 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*”.
+1. Cuando se trata de un *bug* reportado por algún investigador, se discute con ellos la prioridad y se agrega o al *Backlog* o al *Sprint Backlog* con la prioridad discutida.
+1. Cuando se trata de una mejora, deberá ir al *Backlog*.
+1. 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 *Todo* o en “*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.
-
-Al crear las tareas, se deben asignar las siguientes etiquetas:
-
-* **Prioridad**: Etiquetas diseñadas para enfatizar la prioridad de las tareas: `prio:high` \- `prio:medium` \- `prio:low`  
-* **Tipo**: Determinan el impacto de la tarea dentro de la plataforma:  
-  `type:bug` \- `type:enhancement` \- `type:feature` \- `type:documentation`
+1. Debe arrancar con un contexto que de claridad del por qué es necesaria esta tarea.
+1. 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.
+1. 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.
 
-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*).
-
-**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.
+Al crear las tareas, se deben asignar la etiquetas correspondientes al proyecto y tipo de producto al que pertenece, si hay dudas consultar con el líder técnico o encargado del proyecto.
 
 ## Desarrollo y cierre
 
-* 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 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.
+* 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 “*Todo*”.
+* Cuando no es necesario realizar una tarea (empezar o terminar), se debe cambiar su estado a *Canceled*.
+* Al crear un *PR* se debe asociar la tarea correspondiente. Esto automáticamente pasará la tarea al *pipeline* “*In Review”. De este estado solo vuelve a “*In Progress*” si los cambios solicitados son grandes.
+* Tener en cuenta que al cerrar un PR asociado a una tarea, esta se marca automáticamente como completada (Estado *Done*), en algunos casos se deberá mantener abierta hasta finalizar otras cosas (por ejemplo documentación)
+* 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.
\ No newline at end of file
+
+---
+* volver al [inicio](/README.md)
+* volver a las [normas de desarrollo](/docs/development-rules/README.md)

docs/development-rules/sections/tools-and-frameworks.md

 # Herramientas y frameworks
 
+El uso de diferentes herramientas y frameworks será determinado para cada proyecto, en conjunto con los miembros del equipo, a continuación se presentan algunas recomendaciones generales.
+
+### Recomendaciones generales
+* Tener compatibilidad total con el sistema operativo *GNU/Linux* (para facilitar su contenerización y orquestación).
+
 ## Back end
 
 Un proyecto de back end debe:
 
-* Tener compatibilidad total con el sistema operativo *GNU/Linux* (para facilitar su contenerización y orquestación).  
 * Utilizar transacciones en servicios que almacenen datos en 2 o más tablas de una base de datos *SQL* de manera simultánea.
 
 ## Front end
 
-Para el desarrollo de front ends se deberán utilizar automatizadores de tareas (por ejemplo, *Gulp* o *Webpack*). Los desarrollos podrán utilizar bibliotecas como *Bootstrap*, *JQuery* u otros, pero se debe evitar el uso injustificado y redundante de dependencias de *JavaScript* y *CSS*.
+Para el desarrollo de front end se debe
+* Utilizar automatizadores de tareas (por ejemplo, *Gulp* o *Webpack*)
+* Los desarrollos podrán utilizar bibliotecas como *Bootstrap*, *JQuery* u otros, pero se debe evitar el uso injustificado y redundante de dependencias de *JavaScript* y *CSS*.
 
 ## Contenedores
 
-Además de seguir las buenas prácticas recomendadas por [*Docker*](https://docs.docker.com/build/building/best-practices/), también es recomendable realizar las siguientes tareas:
+Además de seguir las buenas prácticas recomendadas por [*Docker*](https://docs.docker.com/build/building/best-practices/), también están las siguientes recomendaciones:
 
 * Utilizar imágenes basadas en *Alpine Linux* (Para obtener imágenes de menor tamaño).
 * Al crear imágenes, configurar usuarios sin permisos de administrador.
 * Configurar datos sensibles por medio de variables de entorno o archivos externos protegidos.
+
+---
+* volver al [inicio](/README.md)
+* volver a las [normas de desarrollo](/docs/development-rules/README.md)