wiki migration

.github/workflows/deploy-action.yml

@@ -0,0 +1,45 @@
+# Thanks to ayaka-notes
+
+name: DeployPage
+
+on:
+  ####################################################################
+  # Allows you to run this workflow manually from the Actions tab
+  #
+  # 允许你在 Actions 页面手动运行这个工作流
+  workflow_dispatch:
+    inputs:
+      unconditional-invoking:
+        description: 'Deploy Manually'
+        type: boolean
+        required: true
+        default: true
+  push:
+    branches: ['main']
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: 'pages'
+  cancel-in-progress: false
+
+jobs:
+  # Single deploy job since we're just deploying
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+      - name: Docusaurus Cache
+        uses: docuactions/[email protected]
+      - name: DeployPage
+        uses: ayaka-notes/[email protected]

.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

docs/FAQs.md

@@ -0,0 +1,75 @@
+# FAQs Wiki
+
+En esta sección encontrarás las preguntas más frecuentes sobre el uso de la wiki.
+
+<details>
+<summary>**1. ¿Cómo subo una nueva página?**</summary>
+
+1. Ubicar la carpeta “docs” dentro del repositorio.
+2. Dentro de la carpeta “docs”, ubicar la carpeta en la cual queremos añadir una página.
+3. Una vez dentro de dicha carpeta, dar click a “add files” ubicado arriba a la derecha.
+4. El nombre del archivo debe ser definido de la siguiente manera: **nombre-de-página.md**.
+5. Recuerda agregar el .md
+6. Escribe tu página en MarkDown.
+7. Cuando hayas finalizado, da click a “commit changes” ubicado arriba a la derecha.
+8. Espera 1 minuta para que tu cambio se vea reflejado en la página.
+</details>
+
+<details>
+<summary>**2. ¿Cómo subo una nueva carpeta?**</summary>
+
+1. Ubicar la carpeta “docs” dentro del repositorio.
+2. Dentro de la carpeta “docs”, dar click a “add files” ubicado arriba a la derecha.
+3. El nombre de la carpeta debe ser definido de la siguiente manera: **nombre-de-carpeta/nombre-de-página.md**
+4. El primer nombre hace referencia a cómo se llamará la carpeta mientras que el nombre después del “/“ se refiere al nombre de una página dentro de la nueva carpeta.
+5. Agrega un archivo \_category\_.json. Este archivo contiene información para la configuración de la carpeta.
+6. Cuando hayas finalizado, da click a “commit changes” ubicado arriba a la derecha.
+
+```
+{
+  "label": “Nombre de la carpeta”,
+  "position": num,  //posición de la carpeta en la lista (asegúrate de no escribir un número ya existente)
+  "link": {
+    "type": "generated-index"
+  }
+}
+```
+
+</details>
+
+<details>
+<summary>**3. Me marca error cuando uso `<br>` ¿qué hago?**</summary>
+
+Si estamos utilizando lo siguiente:
+`<br>`
+Es necesario especificar que es una etiqueta de cierre, por lo que debe de quedar así:
+`<br />`
+
+</details>
+
+<details>
+<summary>**4. No se suben mis cambios ¿qué hago?**</summary>
+
+Puedes verificar el estatus de tu código en la sección de “**Actions**” que se encuentra al lado del botón “Pull Request”, ahí podrás identificar si tus cambios están en proceso, si ya se desplegaron o si los cambios fueron rechazados por un error.
+
+</details>
+
+<details>
+<summary>**5. ¿Cómo cambio el orden el que aparecen las páginas en la barra lateral?**</summary>
+
+Para esto tienes que agregar una sección de metadata al inicio del archivo .md de la siguiente manera:
+
+```
+---
+sidebar_position: 1
+---
+
+...resto del contenido...
+```
+
+- Los 3 guiones al inicio y al final son necesarios para que el archivo sea reconocido como una página de documentación.
+- El número que se encuentra después de `sidebar_position` indica la posición en la que aparecerá la página en la barra lateral. Mientras más pequeño sea el número, más arriba aparecerá la página.
+
+**Procura que no existan dos páginas con el mismo sidebar_position dentro de una sección**.
+
+</details>

docs/comunicacion/_category_.json

@@ -0,0 +1,7 @@
+{
+  "label": "Plan de Comunicación",
+  "position": 6,
+  "link": {
+    "type": "generated-index"
+  }
+}

docs/comunicacion/comunicacion-cr.md

@@ -0,0 +1,30 @@
+# Plan de comunicación con CR Organizacional
+
+## Objetivo
+
+Mantener una comunicación continua, respetuosa y efectiva con los socios formadores representantes de CR Organizacional.
+
+## Comunicación responsable
+
+En nuestro departamento, reconocemos la importancia de una comunicación responsable y respetuosa con nuestros profesores. Es fundamental que se sigan los [valores](https://github.com/Black-Dot-2024/docs/wiki/Misión,-Visión,-Valores-y-Objetivos:) y el [Código de ética](www.blackdot/codigoEtica) del departamento.
+
+## Medios
+
+El canal de comunicación principal será el grupo de WhatsApp de CR Organizacional, donde se encuentran tanto los socios formadores como los representantes de Black Dot (Team Leader, Architecture Owner y Product Owner). Aquí, organizamos las reuniones, resolvemos dudas y compartimos los puntos de vista tanto de los socios como del equipo.
+
+El canal de comunicación secundario será el correo electrónico.
+
+Para las comunicaciones formales, utilizaremos la [plantilla de comunicación](https://docs.google.com/document/d/1eO7YG_qw98ETbj0fJPgfsT9RfVy2-64SvPJLLYbAQnA/edit?usp=sharing). Esta plantilla está membretada con los colores del equipo (Blue Dot), e incluye el logo de Black Dot y el logo del Tecnológico de Monterrey.
+
+## Reuniones
+
+No se cuenta con un horario fijo para las reuniones, estas se llevarán a cabo cuando sea necesario y se acordará con los socios formadores y los representantes de Black Dot.
+
+## Control de cambios
+
+| Versión | Cambio                                                                                             | Autor del cambio | Aprobado por    | Fecha de cambio |
+| ------- | -------------------------------------------------------------------------------------------------- | ---------------- | --------------- | --------------- |
+| v 1.0   | Creación del plan                                                                                  | Diego Sandoval   | David Langarica | 29/02/2024      |
+| v 2.0   | <ul> <li>Actualización de versionamiento.</li> <li>Revisión y corrección de ortografía.</li> </ul> | David Langarica  |                 | 03/03/2024      |
+| v 3.0   | <ul> <li>Actualización de medios.</li> <li>Revisión y corrección de ortografía.</li> </ul>         | Mike Tena        | David Langarica | 04/03/2024      |
+| v 3.1   | Revisión y corrección de ortografía                                                                | Mike Tena        | David Langarica | 04/03/2024      |

docs/comunicacion/comunicacion-profesores.md

@@ -0,0 +1,35 @@
+# Comunicación con profesores
+
+## Objetivo
+
+Mantener una comunicación continua, respetuosa y efectiva con los profesores responsables de la Unidad de Formación.
+
+## Comunicación responsable
+
+En nuestro departamento, reconocemos la importancia de una comunicación responsable y respetuosa con nuestros profesores. Es fundamental que se sigan los [valores](https://github.com/Black-Dot-2024/docs/wiki/Misión,-Visión,-Valores-y-Objetivos:) y el [Código de ética](www.blackdot/codigoEtica) del departamento.
+
+## Medios
+
+Los canales de comunicación principales con los profesores será mediante el correo institucional y por el canal de Discord de la UF (Unidad de Formación), en caso de requerir asesoría o de necesitar una comunicación directa por otros medios se presenta la especialización de cada profesor en la siguiente tabla:
+
+|       Nombre del profesor        | Especialidad                                                                                                                                           |
+| :------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------- |
+|   Eduardo Daniel Juárez Pineda   | Profesor de los módulos "Procesos para el desarrollo de software comercial" y "Administración inicial de proyectos"                                          |
+| Lilia Carolina Rodríguez Galván  | Maestra de ética, en administración y consultora de negocios                                                                                           |
+| Denisse Lizbeth Maldonado Flores | Desarrolladora de software, diseñadora UX/UI, móviles, consejos prácticos                                                                                         |
+|  José Manuel Velázquez Hurtado   | Ingeniero y maestro en literatura quien nos apoya en procesos de comunicación oral y escrita                                                           |
+|        Araham Sotelo Nava        | Profesor del módulo "Administración Inicial del Proyecto"                                                                                                |
+|          Claud Robinson          | Profesor de los módulos "Requerimientos de software" y "Calidad del software en etapas iniciales", siendo el experto en DAD, en revisiones y en pruebas      |
+|   Alejandro Fernández Vilchis    | Desarrollador de software, móviles, base de datos avanzadas, consejos prácticos                                                                       |
+|      Raymundo Romero Arenas      | Amplia experiencia y dominio de las auditorías; mejor guía para clarificar los conceptos teóricos en la práctica; CMMI                                 |
+| Carlos Leonardo Sánchez Higuera  | Auditor y consultor, certificado en TICs y gestión de calidad. Profesor del módulo Visión de estándares internacionales para el desarrollo de software |
+|     Karel Gutiérrez González     | Comunicóloga con maestría en responsabilidad social, y consultora de empresas                                                                         |
+|       Raquel Ortiz Ledesma       | Internacionalista con maestría en Estudias Humanísticos y doctora en Derechos Humanos                                                                  |
+
+## Control de cambios
+
+| Versión | Cambio                        | Autor del cambio | Aprobado por   | Fecha de cambio |
+| ------- | ----------------------------- | ---------------- | -------------- | --------------- |
+| v 1.0 | Creación del plan             | Diego Sandoval   | Yuna Chung     | 28/02/2024      |
+| v 2.0 | Se agrega tabla de profesores | Yuna Chung       | Diego Sandoval | 29/02/2024      |
+| v 3.0 | <ul> <li>Actualización de versionamiento.</li> <li>Revisión y corrección de ortografía.</li> </ul> | David Langarica    |             | 03/03/2024      |

docs/comunicacion/comunicacion-zg.md

@@ -0,0 +1,41 @@
+# Plan de comunicación con ZeitGeist
+
+## Objetivo
+
+Mantener una comunicación continua, respetuosa y efectiva tanto con los miembros del equipo como con las socias formadoras de ZeitGeist.
+
+## Comunicación responsable
+
+En nuestro departamento reconocemos la importancia de una comunicación responsable y respetuosa con todos los que formen parte tanto del departamento como de los proyectos.
+
+Es importante seguir fielmente los valores y Código de ética del departamento en todas nuestras interacciones.
+
+
+## Medios
+
+El canal principal de comunicación será a través de correo electrónico entre las socias formadoras y el Product Owner.
+
+Las llamadas telefónicas servirán como canal secundario de comunicación, de igual manera, entre las socias formadoras y el Producto Owner.
+
+Para comunicación entre socias formadoras y el equipo de desarrollo, se estableció Google Meet como canal general de comunicación.
+
+Finalmente, la comunicación entre el equipo de desarrollo, es por Discord.
+
+
+
+## Reuniones
+
+No se cuenta con horario fijo de reuniones, sin embargo, estas tomarán lugar cuando la agenda de las socias esté disponible y cuando el equipo de desarrollo determine la necesidad de una reunión. 
+
+Antes de cada reunión, se debe acordar la hora, fecha y agenda a abordar.
+
+## Días de comunicación
+
+Respetando los días hábiles y horario de oficina, se establece que la comunicación será únicamente de lunes a viernes.
+
+
+## Control de cambios
+| Versión | Cambio | Autor del cambio | Aprobado por | Fecha de cambio |
+|---------|--------|------------------|--------------|-----------------|
+| v 1.0 | Creación del plan |Denisse Dominguez |  | 01/03/2024 |
+| v 2.0 | <ul> <li>Actualización de versionamiento.</li> <li>Revisión y corrección de ortografía.</li> </ul> | David Langarica    |             | 03/03/2024      |

docs/estandares/_category_.json

@@ -0,0 +1,7 @@
+{
+  "label": "Estándares",
+  "position": 6,
+  "link": {
+    "type": "generated-index"
+  }
+}

docs/estandares/est-bdt-001.md

@@ -0,0 +1,53 @@
+# EST-BDT-001 Redacción para Documentos
+
+v 1.0.1
+
+## Propósito
+
+El propósito de este documento es establecer los estándares que se deberán seguir para redactar cualquier documento departamental.
+
+## Notas introductorias
+
+La importancia de este documento es mantener un estándar e identidad para todos los documentos del departamento y definir de qué manera serán redactados y estilizados.
+
+## Estándares
+
+### Estilos
+
+1. La tipografía para títulos es Nunito número 14 en negritas.
+2. La tipografía para subtítulos es Nunito número 12 en negritas.
+3. La tipografía para el cuerpo del documento es Open Sans número 10.
+4. El interlineado es de 1.15.
+
+### Redacción
+
+1. Los verbos se escriben en infinitivo (terminaciones ar, er, ir).
+2. Se referirá a la Organización Socio Formadora como Cliente.
+3. El nombre de una fase debe ser conciso y comenzar con alguna de las siguientes sugerencias:
+   1. **Inicio / Análisis**: Esta fase está fuertemente ligada al entendimiento de las entradas del proceso y representa el punto de partida para dar paso a su ejecución.
+   2. **Desarrollo**: En esta fase el propósito del proceso se ve reflejado en sus actividades porque se enfocan en la transformación de sus entradas a sus salidas.
+   3. **Verificación**: Con las actividades de esta fase se busca retroalimentar el contenido del proceso hasta el momento y se especifica a qué fase deben regresar en caso de necesitar cambios.
+   4. **Seguimiento**: Una fase perteneciente a esta categoría engloba actividades relacionadas al monitoreo y seguimiento de las salidas del proceso.
+   5. **Notificación**
+   7. **Documentación**: En esta fase se consideran las actividades relacionadas al registro de información de las salidas del proceso en un documento oficial para que todo el departamento tenga acceso.
+   8. **Solicitud**
+
+### Versiones
+
+1. Las versiones se escriben conforme al estándar _[Semantic Versioning 2.0.0](https://semver.org/)_.
+2. Las versiones se escribirán con una _v_ antes del número de la versión.
+
+### Diagramas
+
+1. Los diagramas de proceso son opcionales, a menos que se indique lo contrario, y deben estar en escala de grises y lenguaje UML bajo los [estándares de diagramas UML](https://github.com/Black-Dot-2024/docs/wiki/EST%E2%80%90BDT%E2%80%90002-Diagramas-UML).
+
+### Fechas
+
+1. El formato de las fechas es dd/mm/aaaa.
+
+## Control de cambios
+
+| Versión | Cambio                                       | Autor del cambio                                                | Aprobado por | Fecha de cambio |
+| ------- | -------------------------------------------- | --------------------------------------------------------------- | ------------ | --------------- |
+| v 1.0 | Creación del documento                       | Sergio Garnica González                                         |              | 26/02/2024      |
+| v 1.0 | Estándares para el nombramiento de las fases | Sergio Garnica González <br/> Ramona Najera <br/> Armando Rosas |              | 26/02/2024      |

docs/estandares/est-bdt-002.md

@@ -0,0 +1,34 @@
+# EST-BDT-002 Diagramas UML
+
+## Propósito
+
+El propósito de este documento es establecer los estándares que se deberán seguir para diseñar cualquier tipo de diagrama UML.
+
+## Notas introductorias
+
+La importancia de este documento es mantener un estándar e identidad para todos los diagramas UML que se han de realizar por el departamento, definiendo los colores, figuras y herramientas para desarrollarlos.
+
+## Estándares
+
+### Estilos
+
+1. Los colores a utilizar serán escala de grises.
+
+### Redacción
+
+1. Los verbos se escriben en infinitivo (terminaciones ar, er, ir).
+2. Los actores se escribirán en singular.
+
+### Herramientas
+
+1. Las herramienta a utilizar para diseñar los diagramas será [draw.io](https://app.diagrams.net/).
+
+### Figuras
+
+1. Usar las figuras presentadas en [este diagrama](https://lucid.app/lucidchart/661beab2-311a-4255-b153-dd8a5799374b/edit?invitationId=inv_4e4282af-3e5d-49a2-9e7a-bc3ded660366&page=wBzdocGomGPM#).
+
+## Control de cambios
+
+| Versión | Cambio                 | Autor del cambio | Aprobado por | Fecha de cambio |
+| ------- | ---------------------- | ---------------- | ------------ | --------------- |
+| v 1.0 | Creación del documento | Sergio Garnica   |              | 26/02/2024      |

docs/estandares/est-bdt-003.md

@@ -0,0 +1,31 @@
+# EST-BDT-003 Estandar de versionamiento
+
+## Propósito
+
+El propósito de este documento es establecer un estándar simplificado para el versionamiento de archivos dentro del proyecto, facilitando así la gestión y el seguimiento de cambios a lo largo del tiempo.
+
+## Notas introductorias
+
+Este estándar busca reemplazar los métodos de versionamiento complejos o detallados por un sistema más directo y fácil de seguir, permitiendo a los miembros del equipo identificar rápidamente la secuencia de cambios y la versión actual de un archivo o documento.
+
+## Estándares
+
+### Estilos de Versionamiento
+
+1. **Vesiones principales:** Se utilizará un sistema de numeración secuencial simple para identificar cada nueva versión mayor de un archivo. Estas versiones representan cambios significativos, revisiones completas, o el lanzamiento de nuevas funcionalidades importantes.
+
+Ejemplo: `v 1`, `v 2`, `v 3`, etc.
+
+1. **Notas de versión:** Junto con cada versión, se debe proporcionar una breve descripción de los cambios realizados. Esto ayudará a los miembros del equipo a entender el alcance de las modificaciones y la razón detrás de la nueva versión.
+
+### Documentación y Registro
+
+1. **Control de Cambios:** Mantener un registro actualizado en un lugar accesible por todos los miembros del equipo, donde se documenten las versiones junto con sus notas de versión correspondientes.
+
+
+## Control de cambios
+
+| Versión | Cambio                 | Autor del cambio | Aprobado por | Fecha de cambio |
+| ------- | ---------------------- | ---------------- | ------------ | --------------- |
+| v 1.0 | Creación del documento | Daniel Hurtado    |  Frida Bailleres           | 01/03/2024      |
+| v 1.1 | Correción ortográfica | Olimpia García    |  Diego Llaca           | 04/03/2024      |