Clarify documentation and fix markdown issues

Author: CesarF

_config.yml

@@ -1,6 +1,6 @@
 title: Lineamientos de desarrollo
 logo: /assets/img/logo.png
-description: Lineamientos para del desarrollo de aplicaciones sobre el repositorio de la Dirección de Información y Tecnologías DSIT de la Universidad de Los Andes. Versión 1.1.1
+description: Lineamientos para del desarrollo de aplicaciones sobre el repositorio de la Dirección de Información y Tecnologías DSIT de la Universidad de Los Andes. Versión 1.1.2
 show_downloads: false
 google_analytics:
 theme: jekyll-theme-minimal

style/COMMITS_DOCUMENTATION.md

@@ -26,7 +26,7 @@ Los lineamientos de estilo son los siguientes:
     * :arrow_up: `:arrow_up:` cuando actualice dependencias
     * :arrow_down: `:arrow_down:` cuando desactualice dependencias
     * :shirt: `:shirt:` cuando elimine advertencias del linter
-* Continue por el código de la historia de usuario o issue al cual está aportando el desarrollo. El formato es de la forma <HU/IS>-<ID FASE PROYECTO>-<NÚMERO HISTORIA> Por ejemplo:
+* Continue por el código de la historia de usuario o issue al cual está aportando el desarrollo. El formato es de la forma `<HU/IS>-<ID FASE PROYECTO>-<NÚMERO HISTORIA>` Por ejemplo:
 	* HU-S1-001
 * Haga uso del _present tense_ (_"Add feature"_, no _"Added feature"_)
 * Haga uso del _imperative mood_ (_"Move cursor to..."_, no _"Moves cursor to..."_)
@@ -56,8 +56,12 @@ Todo código en este repositorio debe ser documentado a dos niveles.
 		* Refiérase a los métodos de clase con `{ClassName.methodName}`
 	* Use la wiki para documentar todo aquello adicional que otros desarrolladores deben saber del desarrollo para poder ejecutarlo y continuar con el.
 
-Si se considera necesario, la documentación autogenerada de código (dependiendo el framework) puede ser presentada en el repositorio. Para esto usted debe solicitar la aprobación de dejar pública la documentación, si se considera necesario usted debe:
+Si se considera necesario, la documentación autogenerada de código (dependiendo el framework) puede ser presentada en el repositorio, para esto usted debe:
 
-* Crear una rama que tendrá solo la documentación. Esta rama debe ser protegida para que no sea mezclada con las demás. 
+* Crear una rama que tendrá solo la documentación. Esta rama debe ser protegida para que no sea mezclada con las demás.
+* Agregar en la wiki el link a la rama en la cual se encuentra la documentación.
+
+En caso que se considere dejar pública la documentación. Se debe solicitar la aprobación del CedEx que gestiona el repositorio de código, si la DSIT considera que es viable su publicación usted debe:
+
 * Crear una página web haciendo uso de la característica de github para este fin, y apuntando a la rama de documentación.
-* Seleccione la plantilla y modifíquela para que integre la documentación autogenerada o los archivos .md que usted requiera para documentar su código.
+* Seleccione la plantilla y modifíquela para que integre la documentación autogenerada y/o los archivos .md que usted requiera para documentar su código. Tome el ejemplo de la forma en que está creada esta documentación.

versioning/PULL_REQUESTS.md

@@ -15,9 +15,10 @@ Todo cambio entre ramas debe seguir el manejo de pull requests como se indica en
 * Termine todos los archivos con un newline.
 
 **NOTA:** Todo Pull Request en sus comentarios debe contener:
-* un link al documento o fuente de información donde está alojado el listado con descripción de todas las historias de usuario por las que se está haciendo el desarrollo.
-* el listado paso a paso de la configuración que es necesaria en la aplicación para que los cambios surtan efecto. Este paso es opcional
-* una certificación de las pruebas realizadas por parte del QA (Tester)
+* Un link al documento o fuente de información donde está alojado el listado con descripción de todas las historias de usuario por las que se está haciendo el desarrollo.
+* En el caso de un incidente (issue) debe contener en el cuerpo el identificador del issue que se está cerrando y si es posible el link del mismo
+* El listado paso a paso de la configuración que es necesaria en la aplicación para que los cambios surtan efecto. Este paso es opcional
+* Una certificación de las pruebas realizadas por parte del QA (Tester)
 
 ![Git Workflow](../assets/img/git-flow-infographics.png)