Auto-correcting various issues reported by markdownlint

translation/gl/patterns/base-documentation.md

@@ -99,4 +99,4 @@ Ilustracións de [xente](https://storyset.com/people) e [web](https://storyset.c
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
+- María Lucía González Castro

translation/gl/patterns/common-requirements.md

@@ -12,49 +12,49 @@ O código común do repositorio compartido non satisfai as necesidades de tódol
 
 ## Contexto
 
-* Moitos proxectos están tentando empregar un código común. Tódolos proxectos teñen acceso a un repositorio compartido. 
-* Alguén (ou algún proxecto) escribe o código desde o principio e apórtao ao repositorio. 
-* O código común é unha pequena porcentaxe da entrega global de calquera dos proxectos. 
-* Cada proxecto ten o seu propio calendario de entrega, o seu propio conxunto de entregables e os/as seus/súas propios/as clientes/as. 
-* Este modelo aplícase en calquera destas situacións: 
-  * Existe un/unha **propietario/a do código sólido**; de modo que tódolos cambios no repositorio compartido deben ser aprobados por el/ela. 
-  * A **propiedade do código é débil**, polo que ninguén é o/a propietario/a do código realmente. 
-  * Non hai **un/unha patrocinador/a benévolo/a**, polo que ningunha organización ou executivo/a proporciona recursos para organizar o código común á maneira InnerSource. 
+* Moitos proxectos están tentando empregar un código común. Tódolos proxectos teñen acceso a un repositorio compartido.
+* Alguén (ou algún proxecto) escribe o código desde o principio e apórtao ao repositorio.
+* O código común é unha pequena porcentaxe da entrega global de calquera dos proxectos.
+* Cada proxecto ten o seu propio calendario de entrega, o seu propio conxunto de entregables e os/as seus/súas propios/as clientes/as.
+* Este modelo aplícase en calquera destas situacións:
+  * Existe un/unha **propietario/a do código sólido**; de modo que tódolos cambios no repositorio compartido deben ser aprobados por el/ela.
+  * A **propiedade do código é débil**, polo que ninguén é o/a propietario/a do código realmente.
+  * Non hai **un/unha patrocinador/a benévolo/a**, polo que ningunha organización ou executivo/a proporciona recursos para organizar o código común á maneira InnerSource.
 
 ## Aspectos que mellorar
 
-O proxecto que fixo que o código estivera dispoñible ten certas necesidades, similares ás de parte da organización receptora, pero non exactamente as mesmas. Os requisitos do código han de derivarse das necesidades reais do/a cliente/a. 
+O proxecto que fixo que o código estivera dispoñible ten certas necesidades, similares ás de parte da organización receptora, pero non exactamente as mesmas. Os requisitos do código han de derivarse das necesidades reais do/a cliente/a.
 
-As necesidades dos/as distintos/as clientes/as adoitan ser bastante similares; con todo, poden expresarse de maneira diferente ou ponderarse de distinto xeito entre uns/unhas clientes/as e outros/as. Un exemplo podería ser que algúns/algunhas clientes/as queren que un resultado se presente dunha maneira, mentres que outros/as queren que se presente na orde contraria. É sinxelo facer a tradución entre eles/as, pero require codificación adicional para un dos casos e, como resultado, o compoñente que computa o resultado non pode ser reempregado para ambos/as clientes/as. 
+As necesidades dos/as distintos/as clientes/as adoitan ser bastante similares; con todo, poden expresarse de maneira diferente ou ponderarse de distinto xeito entre uns/unhas clientes/as e outros/as. Un exemplo podería ser que algúns/algunhas clientes/as queren que un resultado se presente dunha maneira, mentres que outros/as queren que se presente na orde contraria. É sinxelo facer a tradución entre eles/as, pero require codificación adicional para un dos casos e, como resultado, o compoñente que computa o resultado non pode ser reempregado para ambos/as clientes/as.
 
-Moitos/as clientes/as queren que o/a provedor/a lles axude no que precisan. A empresa ten moitos/as enxeñeiros/as de sistemas que redactan os requisitos para os produtos. Suponse que estes requisitos foron extraídos das necesidades do/a cliente/a para guiar o desenvolvemento do produto. Reempregar o código é un obxectivo importante para aforrarlle tempo e diñeiro á empresa. 
+Moitos/as clientes/as queren que o/a provedor/a lles axude no que precisan. A empresa ten moitos/as enxeñeiros/as de sistemas que redactan os requisitos para os produtos. Suponse que estes requisitos foron extraídos das necesidades do/a cliente/a para guiar o desenvolvemento do produto. Reempregar o código é un obxectivo importante para aforrarlle tempo e diñeiro á empresa.
 
 ## Solución
 
-Hai dous aspectos que deben facerse en paralelo para resolver este problema: 
+Hai dous aspectos que deben facerse en paralelo para resolver este problema:
 
-1. Aliñar os requisitos dos proxectos para que o código que cumpra os requisitos dun proxecto tamén cumpra as necesidades dos demais proxectos. 
-2. Refactorizar o código en fragmentos máis pequenos para que os numerosos proxectos que o empregan poidan poñerse de acordo acerca dos requisitos. 
+1. Aliñar os requisitos dos proxectos para que o código que cumpra os requisitos dun proxecto tamén cumpra as necesidades dos demais proxectos.
+2. Refactorizar o código en fragmentos máis pequenos para que os numerosos proxectos que o empregan poidan poñerse de acordo acerca dos requisitos.
 
-Ademais, aproveite que os/as clientes/as esperan que o/a provedor/a axude a dilucidar os requisitos. Consiga a aliñación dos requisitos durante as negociacións cos/coas clientes/as e inflúa nos requisitos do/a cliente/a na contra de cambiar o compoñente. 
+Ademais, aproveite que os/as clientes/as esperan que o/a provedor/a axude a dilucidar os requisitos. Consiga a aliñación dos requisitos durante as negociacións cos/coas clientes/as e inflúa nos requisitos do/a cliente/a na contra de cambiar o compoñente.
 
-No exemplo presentado anteriormente, o/a provedor/a axuda a ambos/as clientes/as a darse conta de que queren o mesmo e aforraralles esforzo (e diñeiro) a todos/as se se poñen de acordo á hora de elixir o resultado no mesmo formato. 
+No exemplo presentado anteriormente, o/a provedor/a axuda a ambos/as clientes/as a darse conta de que queren o mesmo e aforraralles esforzo (e diñeiro) a todos/as se se poñen de acordo á hora de elixir o resultado no mesmo formato.
 
 ![Requisitos comúns](../../../assets/img/CommonReqtsv2.jpg)
 
 ## Contexto resultante
 
-Para isto podería ser necesario negociar os cambios nos requisitos co/coa cliente/a. Os cambios tamén poden requirir a participación dos equipos de ventas e dos/as xefes/as de produtos para conseguir a aliñación cos requisitos. O/A cliente/a pode necesitar incentivos, como descontos, para aceptar os cambios. 
+Para isto podería ser necesario negociar os cambios nos requisitos co/coa cliente/a. Os cambios tamén poden requirir a participación dos equipos de ventas e dos/as xefes/as de produtos para conseguir a aliñación cos requisitos. O/A cliente/a pode necesitar incentivos, como descontos, para aceptar os cambios.
 
-Un reto relacionado (e un posible modelo novo) é un exercicio circular de redacción de historias de usuario/a do que se informa nunha empresa que emprega InnerSource. En poucas palabras: 
+Un reto relacionado (e un posible modelo novo) é un exercicio circular de redacción de historias de usuario/a do que se informa nunha empresa que emprega InnerSource. En poucas palabras:
 
-* Os/As desenvolvedores/as escriben unha historia de usuario/a para resolver un problema dunha maneira. 
-* Os/As directivos/as do programa reescriben a historia de usuario/a para expresar mellor as súas necesidades, mantendo a mesma esencia. No momento no que regresa ás mans dos/as desenvolvedores/as, estes/as non recoñecen o que querían facer nun primeiro lugar e, por tanto, resístense a poñelo en práctica. 
-* A solución a este modelo é contar con máis asentos arredor da mesa de planificación para que as modificacións da historia de usuario/a se entendan en todo o proxecto, non só no grupo dos/as desenvolvedores/as ou directivos/as de programas. 
+* Os/As desenvolvedores/as escriben unha historia de usuario/a para resolver un problema dunha maneira.
+* Os/As directivos/as do programa reescriben a historia de usuario/a para expresar mellor as súas necesidades, mantendo a mesma esencia. No momento no que regresa ás mans dos/as desenvolvedores/as, estes/as non recoñecen o que querían facer nun primeiro lugar e, por tanto, resístense a poñelo en práctica.
+* A solución a este modelo é contar con máis asentos arredor da mesa de planificación para que as modificacións da historia de usuario/a se entendan en todo o proxecto, non só no grupo dos/as desenvolvedores/as ou directivos/as de programas.
 
 ## Exemplos coñecidos
 
-* Gran provedor/a de telecomunicacións 
+* Gran provedor/a de telecomunicacións
 
 ## Estado
 
@@ -74,4 +74,4 @@ Un reto relacionado (e un posible modelo novo) é un exercicio circular de redac
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
+- María Lucía González Castro

translation/gl/patterns/communication-tooling.md

@@ -8,56 +8,56 @@ Os/As usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e p
 
 ## Problema
 
-Un equipo está aberto a recibir contribucións de usuarios/as intermedios/as do seu compoñente. A coordinación e a comunicación prodúcense de maneira *ad hoc*, o que causa que se comparta información incoherente, que se reciban respostas con atraso ou que os/as contribuidores/as fagan *ping* a varios membros do *host team* antes de recibir unha resposta definitiva. 
+Un equipo está aberto a recibir contribucións de usuarios/as intermedios/as do seu compoñente. A coordinación e a comunicación prodúcense de maneira *ad hoc*, o que causa que se comparta información incoherente, que se reciban respostas con atraso ou que os/as contribuidores/as fagan *ping* a varios membros do *host team* antes de recibir unha resposta definitiva.
 
 ## Contexto
 
 - Hai un equipo dependente do compoñente do outro equipo.
-- Hai un equipo ao que lle gustaría facer contribucións a ese compoñente. 
-- Incluso cando isto ocorre por escrito, a comunicación ten lugar de maneira individual. 
+- Hai un equipo ao que lle gustaría facer contribucións a ese compoñente.
+- Incluso cando isto ocorre por escrito, a comunicación ten lugar de maneira individual.
 
 ## Aspectos que mellorar
 
-- O equipo anfitrión está interesado en recibir contribucións e disposto a asesorar aos/ás contribuidores/as. 
-- Os equipos teñen unha cultura sólida baseada na comunicación verbal e non teñen experiencia na configuración de canles de comunicación asíncrona específicas do proxecto. 
-- As canles de comunicación poden estar aliñadas cos grupos específicos aos que se debe chegar, pero non por un propósito comunicativo. 
+- O equipo anfitrión está interesado en recibir contribucións e disposto a asesorar aos/ás contribuidores/as.
+- Os equipos teñen unha cultura sólida baseada na comunicación verbal e non teñen experiencia na configuración de canles de comunicación asíncrona específicas do proxecto.
+- As canles de comunicación poden estar aliñadas cos grupos específicos aos que se debe chegar, pero non por un propósito comunicativo.
 
 ## Solución
 
-O *host team* debe proporcionar canles de comunicación públicas, arquivadas, con capacidade de busca e vinculables ás que poida subscribirse calquera persoa da empresa; posto que o apoio ás canles abertas de comunicación escrita aporta beneficios medibles. 
+O *host team* debe proporcionar canles de comunicación públicas, arquivadas, con capacidade de busca e vinculables ás que poida subscribirse calquera persoa da empresa; posto que o apoio ás canles abertas de comunicación escrita aporta beneficios medibles.
 
-O obxectivo ao optimizar as canles de comunicación para os proxectos InnerSource debe ser aliñar a comunicación arredor de temas, non arredor de certos grupos de persoas. 
+O obxectivo ao optimizar as canles de comunicación para os proxectos InnerSource debe ser aliñar a comunicación arredor de temas, non arredor de certos grupos de persoas.
 
 Un proxecto debe establecer as seguintes ferramentas de comunicación:
 
-1. **Un sistema especializado de seguimento de incidencias** co que avaliar o progreso que estruture a comunicación e a toma de decisións de xeito transparente para tódolos membros do equipo anfitrión, pero tamén para os/as futuros/as usuarios/as intermedios/as e contribuidores/as. Para coñecer máis aplicacións deste sistema, consulte [Casos de uso cun sistema de seguimento de incidencias](./issue-tracker.md). 
-2. **Canles conversacionais públicas** cunha estrutura menos ríxida. Polo xeral, trátase de listaxes de correo, foros en liña, sistemas *Q&A* ou, incluso, canles de chat arquivadas. Normalmente, abonda con comezar cunha soa canle para o proxecto. Se o tráfico aumenta demasiado, é útil separar as conversacións sobre o uso do proxecto das outras acerca do desenvolvemento do proxecto. 
-3. **Unha canle privada na que poida ter lugar** a comunicación entre os/as [*trusted committers*](./trusted-committer.md) sobre os temas máis sensibles; como, por exemplo, incorporar a máis *trusted comitters* ao *host team*. Esta canle debe empregarse con sumo coidado, de xeito que a comunicación sexa aberta por defecto e só se manteña privada en circunstancias moi excepcionais. 
+1. **Un sistema especializado de seguimento de incidencias** co que avaliar o progreso que estruture a comunicación e a toma de decisións de xeito transparente para tódolos membros do equipo anfitrión, pero tamén para os/as futuros/as usuarios/as intermedios/as e contribuidores/as. Para coñecer máis aplicacións deste sistema, consulte [Casos de uso cun sistema de seguimento de incidencias](./issue-tracker.md).
+2. **Canles conversacionais públicas** cunha estrutura menos ríxida. Polo xeral, trátase de listaxes de correo, foros en liña, sistemas *Q&A* ou, incluso, canles de chat arquivadas. Normalmente, abonda con comezar cunha soa canle para o proxecto. Se o tráfico aumenta demasiado, é útil separar as conversacións sobre o uso do proxecto das outras acerca do desenvolvemento do proxecto.
+3. **Unha canle privada na que poida ter lugar** a comunicación entre os/as [*trusted committers*](./trusted-committer.md) sobre os temas máis sensibles; como, por exemplo, incorporar a máis *trusted comitters* ao *host team*. Esta canle debe empregarse con sumo coidado, de xeito que a comunicación sexa aberta por defecto e só se manteña privada en circunstancias moi excepcionais.
 
-Mentres que a comunicación pode ter lugar fóra desas canles escritas, debería ser devolta ás canles asíncronas tanta información como sexa posible. 
+Mentres que a comunicación pode ter lugar fóra desas canles escritas, debería ser devolta ás canles asíncronas tanta información como sexa posible.
 
-Tódalas canles de comunicación deberían estar documentadas no proxecto README.md. Para obter máis información acerca do emprego deste arquivo vexa [Documentación base estándar](./base-documentation.md). 
+Tódalas canles de comunicación deberían estar documentadas no proxecto README.md. Para obter máis información acerca do emprego deste arquivo vexa [Documentación base estándar](./base-documentation.md).
 
-Os membros do *host team* necesitan facer o esforzo de dirixir as preguntas que reciban persoalmente (por exemplo, por medio do correo electrónico ou chats de mensaxería) de volta á comunicación nas canles oficiais. 
+Os membros do *host team* necesitan facer o esforzo de dirixir as preguntas que reciban persoalmente (por exemplo, por medio do correo electrónico ou chats de mensaxería) de volta á comunicación nas canles oficiais.
 
 ![Ferramentas de comunicación recomendadas para os proxectos InnerSource](../../../assets/img/gl/communication-tooling.png)
 
 ## Contexto resultante
 
-Establecer e empregar sistematicamente canles oficiais de comunicación asíncrona axuda a crear o nivel base da [documentación de pasivos](https://www.oreilly.com/library/view/understanding-the-innersource/9781491986899/ch04.html) que pode volver a consultarse cando xurdan preguntas similares. 
+Establecer e empregar sistematicamente canles oficiais de comunicación asíncrona axuda a crear o nivel base da [documentación de pasivos](https://www.oreilly.com/library/view/understanding-the-innersource/9781491986899/ch04.html) que pode volver a consultarse cando xurdan preguntas similares.
 
-Cando a comunicación é aberta, os/as demais poden seguir facilmente o progreso do proxecto e obter contribucións activas. O feito de que outros/as estean espreitando e poidan lelas reduce a barreira de participación e aumenta a probabilidade de recibir contribucións. 
+Cando a comunicación é aberta, os/as demais poden seguir facilmente o progreso do proxecto e obter contribucións activas. O feito de que outros/as estean espreitando e poidan lelas reduce a barreira de participación e aumenta a probabilidade de recibir contribucións.
 
-Se as preguntas se contestan en público, máis persoas poden aportar a súa opinión, o que conduce a ter unha visión xeral: Isto inclúe non só aos membros do *host team*, senón tamén aos/ás usuarios/as do proxecto. 
+Se as preguntas se contestan en público, máis persoas poden aportar a súa opinión, o que conduce a ter unha visión xeral: Isto inclúe non só aos membros do *host team*, senón tamén aos/ás usuarios/as do proxecto.
 
-Manter a comunicación en canles asíncronas permite que os/as participantes con horarios diferentes —xa sexa por mor das diferenzas horarias, por ter rutinas de traballo diferentes, diferentes calendarios de reunións ou rutinas de traballo en equipo— contribúan de xeito significativo ao proxecto. 
+Manter a comunicación en canles asíncronas permite que os/as participantes con horarios diferentes —xa sexa por mor das diferenzas horarias, por ter rutinas de traballo diferentes, diferentes calendarios de reunións ou rutinas de traballo en equipo— contribúan de xeito significativo ao proxecto.
 
-Responder ás preguntas nesas canles significa que non só outros membros do equipo poden escoitar e proporcionar información adicional, senón que tamén outros/as usuarios/as que teñan a mesma pregunta poden consultar (e máis tarde atopar) a resposta; o que reduce a necesidade de repetir as explicacións. 
+Responder ás preguntas nesas canles significa que non só outros membros do equipo poden escoitar e proporcionar información adicional, senón que tamén outros/as usuarios/as que teñan a mesma pregunta poden consultar (e máis tarde atopar) a resposta; o que reduce a necesidade de repetir as explicacións.
 
 ## Exemplos coñecidos
 
 * Europace AG
-* Paypal Inc. 
+* Paypal Inc.
 * Mercado Libre
 
 ## Autoría
@@ -80,4 +80,4 @@ Ilustracións de [xente](https://storyset.com/people) de StorySet.
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
+- María Lucía González Castro