Revisar estas fuentes

\[fuente: \[Go\]\(https://github\.com/golang/go/blob/master/CONTRIBUTING\.md\#filing\-issues\)\] \*\*Necesitas más inspiración?\*\* \[1\] \[Celery\]\(https://github\.com/celery/celery/blob/master/CONTRIBUTING\.rst\#other\-bugs \) \[2\] \[Atom\]\(https://github\.com/atom/atom/blob/master/CONTRIBUTING\.md\#reporting\-bugs\) \(incluye plantilla\)

https://github.com/ucudal/PFG_Metodologia/blob/91adfb261ce2bab5dba9f15960f926f9a126e375/CONTRIBUTING.md#L125

```markdown

# Contribuyendo

## Introducción

Antes que nada, gracias por considerar contribuir con esta iniciativa. Son las
personas como tú las que hacen que sea una herramienta útil para estudiantes,
profesores y tutores.

Esta guía está basada [en esta](https://github.com/nayafia/contributing-template)
y [esta otra](https://github.com/valerybriz/contributing-template).

Al seguir estas guías estás comunicando que tú respetas el tiempo de las y los
que estamos involucrados en esta iniciativa. A cambio, ellas y ellos deberían de
forma recíproca resolver tus *issues*, revisar los cambios y ayudarte a finalizar
tus *pull requests*.

¡Mantén la mente abierta! Mejorar la documentación sugiriendo nuevas entradas o
reportar los errores que encuentres son ejemplos de contribuciones que ayudan a
mejorar esta iniciativa.

## Reglas de base

Esperamos que quienes quieran contribuir asuman las siguientes responsabilidades:

* Asegurar la compatibilidad entre plataformas para cada cambio aceptado:
Windows, Mac, Linux.
* Crea *issues* para cualquier cambio mayor y mejora que desearías hacer. Discute
las cosas de manera transparente y obtén los comentarios de la comunidad.
* No agregues nuevos archivos a menos de que sea completamente necesario.
* Mantén el versionamiento de las cosas que agregues tan cortos como sea posible.
* Sé amable con las y los recién llegados y apoya la diversidad de nuevas y nuevos

contribuidores de todo tipo de antecedente. Revisa el [código de conducta de la
comunidad Python](https://www.python.org/psf/codeofconduct/).

## Tu primera contribución

¿Aún no sabes como empezar a contribuir? Puedes empezar revisando los

*issues* con etiquetas `good first issue` ‑principiante‑ y `help wanted`

* Etiqueta `good first issue`: los *issues* con esta etiqueta deberían ser
triviales de resolver, por ejemplo, un error ortográfico, o un error de formato.
* Etiqueta `help wanted`: Estos son *issues* que pueden ser un poco más
complicados que los anteriores.

Ambas listas de issues están ordenadas por la cantidad de comentarios que
tienen. Aunque no es perfecto, la cantidad de comentarios es un proxy razonable
para saber el impacto que tendrá el cambio.

No seas tímido. Tus comentarios y aportes son siempre bienvenidos. Puedes
equivocarte, todos podemos equivocarnos, lo que no podemos hacer es dejar de
aprender de nuestros errores, o ser negligentes; pero por lo demás, te alentamos
a que pruebes.



![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)

> [!TIP]
> ¿Estás por hacer tu primer *pull request*? Aprende cómo hacerlo en esta
> serie *gratuita* [How to Contribute to an Open Source Project on
> GitHub](https://kcd.im/pull-request)

En este punto, ¡ya estás preparada o preparado para hacer cambios! Siéntete
libre de pedir ayuda; todos fuimos principiantes una vez :smile_cat:

> [!IMPORTANT]
> Si un colaborador te pide que hagas un *rebase* al *pull request*, se refiere
> a que muchísimo código ha cambiado y deberías actualizar la rama para que sea
> más fácil unirla al resto del código.

## Empezando

Asumimos que si tienes acceso al repo puedes hacer todo lo que estás autorizado
a hacer según los permisos de tu rol.

La rama `main` está configurada con una regla de protección de requiere:

* Que haya un *pull request* para hacer un *merge*.
* Que haya al menos una aprobación del *pull request*.
* Que uno de los revisores sea *code owner*.

> [!TIP]
> Para obtener más información sobre las reglas de protección de
> las ramas mira [este link](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-pull-request-reviews-before-merging).
>
> Para obtener más información sobre los *code owners* mira [este
> link](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)


Para cualquier cosa que sea mayor a una o dos líneas para corregir:

1. Crea tu propio *fork* del código
2. Haz los cambios en tu *fork*
3. Cuando creas que los cambios ameritan ser incorporados en el repo:
 * Asegúrate de haber seguido el estilo de código del proyecto.
 * Envía un *pull request* solicitando que tus cambios sean incorporados.



## Cómo reportar un bug

Cuando completes un *issue* para
[reportar](https://github.com/ucudal/ANDIS_Conceptos/issues/new/choose) un
error, asegúrate de responder estas tres preguntas:

1. ¿En qué página estabas navegando? Incluye la URL que muestra el navegador
2. ¿Qué viste que consideras incorrecto?
3. ¿Qué esperabas ver que consideras correcto?

Preguntas generales sobre el contenido deben ser planteadas a través de los
canales de comunicación que proponen los profesores en los cursos o proyectos en
los que se consume este contenido.



## Cómo sugerir algo nuevo

En caso de que lo que quieras reportar no sea un error en un contenido existente
sino la sugerencia de agregar un nuevo contenido, puedes hacerlo también a través
de un *issue*.

> [!IMPORTANT]
> Cuando consideres que falta algo, probablemente no estés solo.
> [Busca](https://github.com/ucudal/ANDIS_Conceptos/issues?q=is%3Aissue+is%3Aopen)
> en la lista de *issues* si ya no existe uno similar al que estás considerando
> agregar; si no lo encuentras, [crea uno
> nuevo](https://github.com/ucudal/ANDIS_Conceptos/issues/new/choose).

Al crear un *issue* para pedir que se agregue el contenido que te gustaría ver,
asegúrate de que incluya las respuesta a las siguientes preguntas:

1. ¿Qué contenido está faltando? Incluye referencias a libros, sitios web, u
otros recursos útiles para encontrar lo que estás sugiriendo
2. ¿Por qué es necesario?
3. ¿Cómo deberíamos agregarlo?







## Convenciones

La documentación en este repo está creada utilizando el lenguaje
[Markdown](https://en.wikipedia.org/wiki/Markdown). Es un lenguaje que permite
crear texto con formato utilizando un editor de texto plano.

Mira los siguientes recursos para conocer más sobre este lenguaje:

* [Escritura y formato básico](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax).
Lee esta guía primero para conocer lo básico que se necesita al editar
documentos en Markdown.
* [Edición avanzada](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting).
Lee esta otra guía para ver cómo crear tablas, bloques de código, diagramas,
etc.
* [Guía básica](https://markdownguide.offshoot.io/basic-syntax/). Una guía
 básica de lo que se puede hacer con Markdown.
* [Guía avanzada](https://markdownguide.offshoot.io/extended-syntax/). Una guía
 avanzada para usuarios de Markdown.
* [Markdown](https://daringfireball.net/projects/markdown/). Sitio de John
Grubber, uno de los creadores
* [Edición de Markdown en Visual Studio Code](https://code.visualstudio.com/docs/languages/markdown).
 Funcionalidades de Visual Studio Code para la edición de Markdown.

### Edición

Usamos [Visual Studio Code](https://code.visualstudio.com/download) para editar
los archivos de este repo. Aunque puedes usar cualquier editor de texto, este
documento asume que usas ese editor de código.

> [!TIP]
> Como probablemente uses el editor en otros proyectos, considera crear un
> perfil antes de agregar estas extensiones que te sugerimos a continuación.
> Consulta [este link](https://code.visualstudio.com/docs/editor/profiles) para
> obtener más información sobre los perfiles en Visual Studio Code.

Instala las siguientes extensiones que son útiles para facilitar la edición:

* [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker):
 Corrector ortográfico para el texto.
* [Code Spell Checker - Spanish](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker-spanish):
 Corrector ortográfico para idioma español.
* [Markdown Checkboxes](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-checkbox):
 Agrega compatibilidad con casillas de verificación a la vista previa de
 Markdown.
* [Markdown Emoji](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-emoji):
 Agrega compatibilidad con la sintaxis de emoji a la vista previa de Markdown.
* [Markdown Footnotes](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-footnotes):
 agrega compatibilidad con la sintaxis de ^notas al pie a la vista previa de
 Markdown.
* [Markdown Preview GitHub Styling](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-preview-github-styles):
 Utiliza el estilo de GitHub en la vista previa de Markdown.
* [Markdown Preview Mermaid Support](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-mermaid):
 Agrega soporte para diagramas en Mermaid.
* [Markdown yaml Preamble](https://marketplace.visualstudio.com/items?itemName=bierner.markdown-mermaid):
 Aunque no usamos actualmente las *front matters* de YAML, podríamos usarlas en
 el futuro y esta extensión es recomendada.
* [markdownlint](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint):
 *Linting* de Markdown y controles de estilo.

Otras extensiones útiles:

* [Path Intellisense](https://marketplace.visualstudio.com/items?itemName=christian-kohler.path-intellisense):
 Para auto-completar de nombres de archivos.
* [Rewrap](https://marketplace.visualstudio.com/items?itemName=stkb.rewrap):
 Para formatear el ancho del archivo a cierto número de columnas, que en
 nuestro caso es 80.
* [Numbered Bookmarks](https://marketplace.visualstudio.com/items?itemName=alefragnani.numbered-bookmarks):
 Para navegar fácilmente dentro de un archivo mediante marcadores.
* [Print](https://marketplace.visualstudio.com/items?itemName=pdconsec.vscode-print):
 Permite imprimir archivos Markdown.

Además, esta es la configuración sugerida del editor y sus extensiones:

```json
{
 "files.autoSave": "afterDelay",
 "git.enableSmartCommit": true,
 "window.commandCenter": true,
 "cSpell.language": "en,es-ES",
 "editor.renderWhitespace": "selection",
 "editor.wordWrapColumn": 120,
 "markdown.validate.enabled": true,
 "markdown.updateLinksOnFileMove.enabled": "prompt",
 "rewrap.wrappingColumn": 80,
 "rewrap.autoWrap.enabled": true,
 "workbench.editor.untitled.hint": "hidden",
 "markdown.validate.enabled": true,
 "markdown.updateLinksOnFileMove.enabled": "prompt",
 "workbench.startupEditor": "none",
}
```

Para verificar los links usamos la herramienta Linkspector disponible
[aquí](https://github.com/UmbrellaDocs/linkspector). La puedes ejecutar a
demanda con el comando `linkspector check`.

Usamos cSpell como corrector ortográfico tanto en inglés como en español. Las
palabras que cSpell no reconoce podemos ignorarlas si y sólo sí:

* Son nombres propios o apellidos de autores

* Son palabras que existen en el idioma. En este caso agregamos a la directiva
 para ignorar la palabra el link a la definición en la [RAE](https://rae.es) u
 otro diccionario confiable.

Por ejemplo:

```markdown

```

### Organización del contenido

El contenido está organizado en estas carpetas:

1. Entregable proyecto
2. Técnicas y herramientas
3. Plantillas
4. Conceptos
5. Unidades temáticas

Cada carpeta tiene un archivo Markdown ‑con extensión `.md`‑ cuyo nombre
coincide con el de la carpeta y sirve como tabla de contenido de la carpeta
‑excepto que usa dos guiones bajos `__` en lugar de uno para separar el número
del resto de nombre; esto para que quede ordenado antes de los demás archivos‑:
por ejemplo, la carpeta `4_Conceptos` tiene un archivo `4__Conceptos.md`.

> [!IMPORTANT]
> Mira la sección [Nombres de archivos](#nombres-de-archivos), más adelante en
> este documento, para conocer más detalles sobre las convenciones sobre los
> nombres de archivos y carpetas.

En algunas carpetas el contenido está organizado de manera jerárquica, pero no
utilizamos sub carpetas, sino que agregamos niveles a los nombres de archivos:
por ejemplo, el tema `5. Unidades temáticas` tiene algunos de los siguientes
niveles:

* 5. Unidades temáticas
 * 5.1
 * 5.1.1
 * 5.1.2
 * 5.2
 * 5.2.1

Los nombres de los archivos en la carpeta `5_Unidades_tematicas` comienzan con:

`5_Unidades_tematicas`

`5__Unidades_tematicas.md`

`5_1__⋯.md`

`5_1_1⋯.md`

`5_1_2⋯.md`

`5_2__⋯.md`

`5_2_1⋯.md`

### Referencias a las fuentes

Respetamos la propiedad intelectual dando atribución al origen del contenido
incluido en los documentos.

Cuando el contenido de un documento fue tomado de una fuente, incluimos el texto
"Tomado de", seguido de una notas al pie, al final de la primera frase del
documento.

#### Ejemplo

> Esta es la plantilla para un requerimiento funcional o no funcional. Tomado de
> [^1].

[^1]: Robertson, S. & Robertson, J. (2012). Mastering the Requirements Process:
Getting Requirements Right, 3rd Edition. Addison-Wesley Professional.

#### Fuente

``` markdown
Esta es la plantilla para un requerimiento funcional o no funcional. Tomado de [^1].

[^1]: Robertson, S. & Robertson, J. (2012). Mastering the Requirements Process:
Getting Requirements Right, 3rd Edition. Addison-Wesley Professional.
```

> [!NOTE]
> Aunque las notas al pie aparecen al final del documento, en el documento en
> Markdown ponemos la referencia inmediatamente después de donde de usa, y no al
> final para que sea más fácil editar el documento.

En el caso de una imagen, el texto "Tomado de" va al final del pie de foto,
seguido de una nota al pie.

> [!TIP]
> Mira [este link](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#footnotes)
> para tener más información sobre cómo crear notas al pie en Markdown.

Cuando usamos tablas en HTML no es posible agregar notas al pie. En ese caso
las referencias las agregamos así:

#### Ejemplo

<table>
 <tr>
 <td>
 Ver debajo <a href="#ref_1">↓</a>
 </td>
 </tr>
</table>

-----

Robertson, S. & Robertson, J. (2012). Mastering the
Requirements Process: Getting Requirements Right, 3rd Edition.
Addison-Wesley Professional.<a href="#back_ref_1" title="Volver...">↩︎</a>

#### Fuente

```html
<table>
 <tr>
 <td>
 Ver debajo <a href="#ref_1">↓</a>
 </td>
 </tr>
</table>

-----

Robertson, S. & Robertson, J. (2012). Mastering the
Requirements Process: Getting Requirements Right, 3rd Edition.
Addison-Wesley Professional.<a href="#back_ref_1" title="Volver...">↩︎</a>
```

### Leyendas de figuras

Al incluir figuras en un documento las acompañamos de una pequeña leyenda debajo
que explica o describe brevemente la figura. Esa descripción se utiliza también
como como texto alternativo al embeber la imagen. Lo mismo hacemos con las
tablas cuando resulta necesario o conveniente.

Estas leyendas las incluimos en itálica, asegurándonos de asociarles un número
según la cantidad de figuras presentes hasta el momento en el documento,
empezando por uno ‑1‑. Si hay figuras y tablas en un mismo documento, las
contamos por separado, por lo que puede haber una *Tabla 1* y una *Figura 1* en
un mismo documento. `Figura` o `Tabla` se separa del resto de la leyenda por `:`
‑dos puntos‑.

Antes de la imagen agregamos un elemento HTML `anchor` cuyo identificar `id` es
`figura` o `tabla`, según corresponda, seguido del número respectivo. Esto
permite hacer referencia a esa figura con `[Figura N](#figura-n)` como se
muestra más abajo.

Al incluir las leyendas de las figuras y tablas de esta forma, podemos
crear referencias desde dentro y fuera del documento.

#### Ejemplo



![El ciclo de vida DAD](/diagrams/DAD_Lifecycle.svg)

*Figura 1: El ciclo de vida DAD.*

§

Ver [Figura 1](#figura-1).

#### Fuente

```markdown


![El ciclo de vida DAD](/diagrams/DAD_Lifecycle.svg)

*Figura 1: El ciclo de vida DAD.*

§

Ver [Figura 1](#figura-1).
```

> [!NOTE]
> Hay configurado un *snippet* `figura` para insertar el código necesario para
> incluir una figura.

### Viñetas

Usamos el símbolo `*` para las viñetas; no usamos `-`.

### Incisos

Cuando queremos incluir en una frase un texto en forma de aclaración o
explicación ‑lo que en gramática se conoce como
[inciso](https://www.rae.es/drae2001/inciso#)‑, usamos `‑` que corresponde con
la [raya](https://www.rae.es/dpd/raya) o `EM DASH`, código Unicode `U+2014` o
UTF-8 `E28094`; no usamos `-` o guión; una [Github
Action](https://github.com/marketplace/actions/find-and-replace) reemplaza ese
carácter por `NON-BREAKING HYPHEN`, código Unicode `U+2011` o UTF-8 `E28091`.

Puedes generar una raya:

* En Windows: con <kbd>Ctrl</kbd> + <kbd>Alt</kbd> + <kbd>-</kbd>
* En Mac: con <kbd>Option</kbd> + <kbd>Shift</kbd> + <kbd>-</kbd>

### Palabras en inglés u otros idiomas

Cuando no existe una traducción ampliamente aceptada de una palabra en inglés
u otro idioma al español, preferimos usar la palabra original; esa palabra la
escribimos *en cursiva*.

También ponemos tanto la palabra en español como en inglés cuando existe más de
una posible traducción.

### Colores

Usamos un único color para resaltar texto y para las líneas en los diagramas:

This color

Que se obtiene con este código:

```markdown
This color
```

El único texto resaltado es en las plantillas el texto que debe quedar como
parte de la plantilla, para diferenciarlo del texto que debe ser reemplazado en
la plantilla.

### Notas, consejos, avisos, etcétera

Incluimos notas ‑*notes*‑, consejos ‑*tips*‑, avisos ‑*warnings*‑, etc. usando
la notación de citas en bloque según se describe
[aquí](https://github.com/orgs/community/discussions/16925).

#### Ejemplo

> [!NOTE]
> Destaca información que los usuarios deben tener en cuenta, incluso cuando hojean.

> [!TIP]
> Información opcional para ayudar al usuario a tener más éxito.

> [!IMPORTANT]
> Información crucial necesaria para que los usuarios tengan éxito.

> [!WARNING]
> Contenido crítico que exige atención inmediata del usuario debido a riesgos potenciales.

> [!CAUTION]
> Consecuencias potenciales negativas de una acción.


#### Fuente

```text
> [!NOTE]
> Destaca información que los usuarios deben tener en cuenta, incluso cuando hojean.

> [!TIP]
> Información opcional para ayudar al usuario a tener más éxito.

> [!IMPORTANT]
> Información crucial necesaria para que los usuarios tengan éxito.

> [!WARNING]
> Contenido crítico que exige atención inmediata del usuario debido a riesgos potenciales.

> [!CAUTION]
> Consecuencias potenciales negativas de una acción.
```

### Nombres de archivos

No usamos caracteres especiales o letras con tilde en los nombres de archivos.

Tampoco usamos espacios, separamos las palabras que componen el nombre con guión
bajo `_`.

El nombre comienza con mayúscula.



## TODOs

Para manejar la lista de TODO usamos la [extensión Todo
Tree](https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.todo-tree)
que permite ver los TODO directamente en el editor.

También usamos la [*GitHub action* TODO to
Issue](https://github.com/marketplace/actions/todo-to-issue) para convertir los
nuevos TODO en *issues*.



> [!NOTE]
> La línea que ves debajo y el texto que le sigue son la nota al pie que
> mostramos en la sección de [referencias](./CONTRIBUTING.md#fuente).

```

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Revisar estas fuentes #3

Organización del contenido

Referencias a las fuentes

Ejemplo

Fuente

Ejemplo

Fuente

Leyendas de figuras

Ejemplo

Fuente

Viñetas

Incisos

Palabras en inglés u otros idiomas

Colores

Notas, consejos, avisos, etcétera

Ejemplo

Fuente

Nombres de archivos

TODOs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Revisar estas fuentes #3

Description

Organización del contenido

Referencias a las fuentes

Ejemplo

Fuente

Ejemplo

Fuente

Leyendas de figuras

Ejemplo

Fuente

Viñetas

Incisos

Palabras en inglés u otros idiomas

Colores

Notas, consejos, avisos, etcétera

Ejemplo

Fuente

Nombres de archivos

TODOs

Footnotes

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions