docs: added some docs files

README.md

+# Normas del equipo de desarrollo
+
+En este repositorio se mencionan las normas y recomendaciones de todos los desarrollos de software que se realicen en la línea de informática de la biodiversidad.
+
+## Documentos 📚
+
+1. [Normas de desarrollo](docs/development-rules.md) - ¡Este es el documento principal! Te explicará todo lo que necesitas saber para desarrollar software de manera correcta y eficiente.
\ No newline at end of file

docs/development-rules.md

+# Normas de desarrollo
+
+¡Este es el corazón de cómo hacemos las cosas! 💖 Aquí tienes una lista de los temas clave que cubrimos para asegurar un desarrollo de software de alta calidad. ¡Vamos a explorarlos! 🚀
+
+- [Estilo del código](sections/code-style.md) 🎨 - ¡Asegúrate de que tu código sea legible y consistente! 🤓 Este documento te dará las pautas para escribir código limpio y fácil de entender.
+- [Versionamiento semántico](sections/semantic-versioning.md) 🔢 - ¡Entiende cómo versionamos nuestro software! 📈 Este documento te explicará el sistema de versionamiento semántico para que puedas seguir los cambios y las mejoras.
+- [Herramientas y frameworks](sections/tools-and-frameworks.md)  🛠️ - ¡Descubre las herramientas y frameworks que utilizamos! 🤩 Este documento te mostrará las herramientas que te ayudarán a ser más productivo y a escribir código de alta calidad.
+- [Marco de trabajo](sections/team-framework.md) 🤝 - ¡Conoce cómo organizamos nuestro trabajo en equipo! 🗓️ Este documento te explicará cómo colaboramos y nos coordinamos para lograr nuestros objetivos.
+- [Tareas (tickets)](sections/tickets.md) 🎫 - ¡Aprende cómo gestionamos nuestras tareas! 📝 Este documento te mostrará cómo utilizamos los tickets para organizar y priorizar nuestro trabajo.
+- [Versionamiento de código fuente](sections/code-versioning.md) 💾 - ¡Domina el control de versiones! 💪 Este documento te enseñará cómo versionamos nuestro código fuente para mantener un historial de cambios y colaborar de manera segura.
\ No newline at end of file

docs/sections/code-style.md

+# Estilo del código
+
+## Convención de nombres (Naming conventions)
+
+Dependiendo del lenguaje, se deberá utilizar la convención de nombres por defecto del mismo. Algunos ejemplos son:
+
+| Lenguaje | Convención de nombres |
+| ----- | ----- |
+| Javascript, Typescript, Java | [camelCase](https://en.wikipedia.org/wiki/Camel_case) |
+| Python | snake\_case y camelCase ([ver](https://peps.python.org/pep-0008/#naming-conventions)) |
+| Ruby | snake\_case y camelCase (ver guía de ruby y guía de RoR)  |
+| SQL | [snake\_case](https://en.wikipedia.org/wiki/Snake_case) |
+| MongoDB | camelCase con [variaciones](https://www.mongodb.com/docs/manual/reference/limits/#naming-restrictions) |
+
+## Lenguaje de marcado para comentarios
+
+Dependiendo del lenguaje, se deberá documentar el código con el formato por defecto del mismo. Algunos ejemplos son:
+
+| Lenguaje | Convención de nombres |
+| ----- | ----- |
+| Javascript, Typescript | [JSDoc](https://jsdoc.app) |
+| Java | [Javadoc](https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javadoc.html) |
+| Python | [Docstring](https://peps.python.org/pep-0008/#documentation-strings) |
+| Ruby | [RDoc](https://github.com/ruby/rdoc) |
\ No newline at end of file

docs/sections/code-versioning.md

+# Versionamiento de código fuente
+
+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.  
+* No se deberán versionar archivos de más de 5 MB.  
+* Evitar versionar archivos binarios.
+
+## 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:
+
+* 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:  
+  * **LICENSE:** Usar la licencia MIT, a menos que se le indique otra.  
+  * **README.md:** Añadir información del proyecto. Si se desconoce, dejar el archivo en blanco  
+  * **.gitignore:** Usar una plantilla para el lenguaje que se vaya a utilizar. Si se desconoce, dejar el archivo en blanco.  
+  * **.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  
+  * Aplicar las reglas para los administradores también  
+* Poner la rama *develop* como rama por defecto
+
+**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
+
+Se recomienda realizar commits con pocos cambios y con nombres cortos y concretos. Todos los commits deberán escribirse en Inglés.
+
+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.   
+* 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.  
+* 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)
+
+* 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).
+
+* 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*) (AGREGAR ENLACE DE DOCUMENTACIÓN DE RAMAS AQUÍ)  
+* 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:
+
+* 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.  
+* 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  
+* Los nombres de las funciones y variables es claro 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.
+
+
+## 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*
+
+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.
+
+#### 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.
+
+![][image1]
+
+#### 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.  
+![][image2]
+
+#### Rama Hotfix
+
+Las tareas de estas ramas son para corregir algo urgente que no da tiempo de esperar a un lanzamiento.
+
+A continuación se presenta una guía del flujo de una rama tipo *hotfix*. Aquí se consideran tanto los pasos y recomendaciones para el encargado de hacer el ajuste, como para los revisores.
+
+![][image3]
+
+### Lanzamientos y etiquetas (Releases, tags)
+
+Al crear un lanzamiento, se deben 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\>  
+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/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).
+
+##  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) y 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)  
+* 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. 
+
+## 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.
+
+| Puntos | Tiempo |
+| :---: | :---: |
+| 1 | Hasta medio día |
+| 2 | Hasta un día |
+| 3 | Hasta día y medio |
+| 5 | Hasta dos días |
+| 8 | Hasta tres días |
+| (\*) Más de 8  | Se deberá dividir la tarea |
+
+## 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.
+
+### 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. 
+
+### 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.  
+      **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.
+
+### 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. 
\ No newline at end of file

docs/sections/tickets.md

+# 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.
+
+## 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:
+
+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*”.
+
+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
+
+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.
+
+## 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 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

docs/sections/tools-and-frameworks.md

+# Herramientas y frameworks
+
+## 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*.
+
+## 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:
+
+* 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.
\ No newline at end of file