Update non pendings development rules files

.vscode/settings.json

 {
     "editor.formatOnSave": true,
     "editor.wordWrap": "on",
-}
+    "cSpell.language": "en,es-ES",
\ No newline at end of file
+}

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 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, seeguimos 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.  
+* 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.  
-* 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*)  
-* Todo lanzamiento de una nueva versión deberá tener una descripción detallada de los cambios en la misma.
+    * 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 denomita 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 *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.
\ 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/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 |
 | :---: | :---: |
@@ -17,33 +17,48 @@ La estimación de tareas se realiza con "*story points*", para lo cual se tiene
 | 8 | Hasta tres días |
 | (\*) Más de 8  | Se deberá dividir la tarea |
 
-## Ceremonias 
+## Ceremonias
 
 ### 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
 
 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.  
-   3. Si no se ha asignado un responsable, se asigna.  
+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 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*. 
+* 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 *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 tarea para todas las actividades que involucren una de las siguientes consideracioens:
+- Corresponde al diagnístico o corrección de un error en una de las plataformas
+- Corresponde a una investicación (*[spipke]*) 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
+
+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 automaticamnnte 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.
+
 ## 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).  
+* 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.
 
-* 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)
\ No newline at end of file