diff --git a/translation/gl/patterns/base-documentation.md b/translation/gl/patterns/base-documentation.md
index ffd514a02..1edbe00ce 100644
--- a/translation/gl/patterns/base-documentation.md
+++ b/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
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/common-requirements.md b/translation/gl/patterns/common-requirements.md
index c34117343..ab9d7d435 100644
--- a/translation/gl/patterns/common-requirements.md
+++ b/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
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/communication-tooling.md b/translation/gl/patterns/communication-tooling.md
index f20e2343c..92e80e4f3 100644
--- a/translation/gl/patterns/communication-tooling.md
+++ b/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
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/contracted-contributor.md b/translation/gl/patterns/contracted-contributor.md
index 971bd3f5c..e3ae04824 100644
--- a/translation/gl/patterns/contracted-contributor.md
+++ b/translation/gl/patterns/contracted-contributor.md
@@ -8,51 +8,51 @@ Os/As socios/as que desexen contribuír a InnerSource son disuadidos/as de facel
 
 ## Problema
 
-Sen o apoio dos/as responsables de área, é probable que o número total de contribuidores/as e, en consecuencia, a cantidade de contribucións realizadas, así como o calidade xerada pola iniciativa InnerSource, sexa inferior á das expectativas dos altos cargos. Probablemente esta situación se vexa agravada se non se financia adecuadamente aos/ás [líderes da comunidade expertos/as en InnerSource](./dedicated-community-leader.md) e se lles capacita correctamente. Córrese o risco de que a dirección decida non seguir adiante coa inicitiva InnerSource. 
+Sen o apoio dos/as responsables de área, é probable que o número total de contribuidores/as e, en consecuencia, a cantidade de contribucións realizadas, así como o calidade xerada pola iniciativa InnerSource, sexa inferior á das expectativas dos altos cargos. Probablemente esta situación se vexa agravada se non se financia adecuadamente aos/ás [líderes da comunidade expertos/as en InnerSource](./dedicated-community-leader.md) e se lles capacita correctamente. Córrese o risco de que a dirección decida non seguir adiante coa inicitiva InnerSource.
 
 ## Contexto
 
-Unha gran corporación puxo en marcha unha iniciativa InnerSource. Os principais obxectivos da iniciativa son aumentar a eficiencia do desenvolvemento do software distribuído e fomentar a innovación permitindo que tódolos/as traballadores/as contribúan voluntariamente nos proxectos InnerSource, independentemente do tema e da unidade de negocio. 
+Unha gran corporación puxo en marcha unha iniciativa InnerSource. Os principais obxectivos da iniciativa son aumentar a eficiencia do desenvolvemento do software distribuído e fomentar a innovación permitindo que tódolos/as traballadores/as contribúan voluntariamente nos proxectos InnerSource, independentemente do tema e da unidade de negocio.
 
-Os altos cargos apoian a iniciativa InnerSource. Para eles/as, é só unha das moitas iniciativas para fomentar a innovación e a eficacia. Financian InnerSource con diñeiro e capacitación para os/as *líderes da comunidade*, ademais de dotalos/as de autonomía para o gasto do presuposto. Tamén limitan a amplitude e a duración da iniciativa e participan en revisións periódicas ata que haxa probas de que da os resultados esperados (vexa [Comité de revisión](./review-committee.md)). Os/As directivos/as anunciaron o seu apoio á iniciativa InnerSource en varias reunións internas de empresa. 
+Os altos cargos apoian a iniciativa InnerSource. Para eles/as, é só unha das moitas iniciativas para fomentar a innovación e a eficacia. Financian InnerSource con diñeiro e capacitación para os/as *líderes da comunidade*, ademais de dotalos/as de autonomía para o gasto do presuposto. Tamén limitan a amplitude e a duración da iniciativa e participan en revisións periódicas ata que haxa probas de que da os resultados esperados (vexa [Comité de revisión](./review-committee.md)). Os/As directivos/as anunciaron o seu apoio á iniciativa InnerSource en varias reunións internas de empresa.
 
-Con todo, aínda non capacitaron ou incentivaron aos/ás responsables de área para que permitan, ou incluso motiven, aos/ás seus/súas traballadores/as a participar en actividades InnerSource interdivisionais. Ademais, a capacidade de cada socio/a adoita asignarse a proxectos alleos a InnerSource durante toda a súa xornada de traballo. A colaboración entre organizacións aínda non é a norma e os cargos superiores non adoitan ter obxectivos fóra da súa propia compañía. Espérase que as contribucións aos proxectos InnerSource teñan lugar durante o horario laboral, non durante o tempo libre. 
+Con todo, aínda non capacitaron ou incentivaron aos/ás responsables de área para que permitan, ou incluso motiven, aos/ás seus/súas traballadores/as a participar en actividades InnerSource interdivisionais. Ademais, a capacidade de cada socio/a adoita asignarse a proxectos alleos a InnerSource durante toda a súa xornada de traballo. A colaboración entre organizacións aínda non é a norma e os cargos superiores non adoitan ter obxectivos fóra da súa propia compañía. Espérase que as contribucións aos proxectos InnerSource teñan lugar durante o horario laboral, non durante o tempo libre.
 
 ## Aspectos que mellorar
 
-- O persoal directivo é responsable dos resultados das súas unidades de negocio. Permitir que o seu persoal participe en actividades InnerSource nas que poderían perder tempo facendo contribucións fóra da súa área empresarial, reduce eficazmente a capacidade da súa unidade. É probable que isto dificulte que o persoal directivo alcance ou supere os seus obxectivos. 
+- O persoal directivo é responsable dos resultados das súas unidades de negocio. Permitir que o seu persoal participe en actividades InnerSource nas que poderían perder tempo facendo contribucións fóra da súa área empresarial, reduce eficazmente a capacidade da súa unidade. É probable que isto dificulte que o persoal directivo alcance ou supere os seus obxectivos.
 - Os/As responsables de área e RR HH xulgarán, por defecto, o rendemento dos/as seus/súas subordinados/as en función dos obxectivos das súas unidades de negocio, que poderían non estar aliñados cos obxectivos da comunidade InnerSource.
-- Canto menor sexa o apoio executivo percibido polo/a superior/a inmediato/a, menos probable será que permita que o seu persoal participe en actividades InnerSource que contribúan a outra unidade de negocio. 
-- Canta menor transparencia e control teña o/a superior/a do traballo realizado por un/unha dos/das seus/súas subordinados/as, menos probable será que lles permita facer contribucións. 
+- Canto menor sexa o apoio executivo percibido polo/a superior/a inmediato/a, menos probable será que permita que o seu persoal participe en actividades InnerSource que contribúan a outra unidade de negocio.
+- Canta menor transparencia e control teña o/a superior/a do traballo realizado por un/unha dos/das seus/súas subordinados/as, menos probable será que lles permita facer contribucións.
 - Canto menos formal sexa a xestión e organización do traballo en InnerSource, menos probable será que un cargo superior acostumado aos procesos oficiais autorice a un/unha dos/as seus/súas traballadores/as a contribuír en InnerSource.
-- Canto máis tempo dedique un/unha socio/a a contribuír a un proxecto InnerSource que non beneficie ao seu propio traballo diario, máis aumentará a carga de traballo para os/as seus/súas compañeiros/as de equipo na súa unidade de negocio. 
-- É probable que os/as contribuidores/as individuais consideren participar en InnerSource para ter a oportunidade de mellorar a súa rede profesional dentro da empresa e adquirir coñecementos e experiencia na área técnica das súas contribucións. 
+- Canto máis tempo dedique un/unha socio/a a contribuír a un proxecto InnerSource que non beneficie ao seu propio traballo diario, máis aumentará a carga de traballo para os/as seus/súas compañeiros/as de equipo na súa unidade de negocio.
+- É probable que os/as contribuidores/as individuais consideren participar en InnerSource para ter a oportunidade de mellorar a súa rede profesional dentro da empresa e adquirir coñecementos e experiencia na área técnica das súas contribucións.
 
 ## Solución
 
-Estableza un sistema de contratación formal entre o/a contribuidor/a, o/a seu/súa superior/a e unha oficina de gobernación InnerSource (ISGO), financiada e dirixida de maneira centralizada. Faga que a ISGO reembolse ás unidades de negocio que contrataron a contribuidores/as polo tempo contratado. 
+Estableza un sistema de contratación formal entre o/a contribuidor/a, o/a seu/súa superior/a e unha oficina de gobernación InnerSource (ISGO), financiada e dirixida de maneira centralizada. Faga que a ISGO reembolse ás unidades de negocio que contrataron a contribuidores/as polo tempo contratado.
 
-- A contratación especifica unha porcentaxe máxima de tempo de traballo dos/as socios/as en InnerSource. 
+- A contratación especifica unha porcentaxe máxima de tempo de traballo dos/as socios/as en InnerSource.
 - A contratación establece, claramente, que o traballo na unidade de negocio do/a contribuidor/a ten prioridade sobre o traballo en InnerSource.
-- A contratación establece que non é obrigatorio traballar en InnerSource durante a porcentaxe máxima especificada no contrato. 
-- A contratación está firmada polo/a contribuidor/a, o/a seu/súa superior/a inmediato/a, a oficina de gobernación e o/a [líder da comunidade experto/a en InnerSource](./dedicated-community-leader.md) coa que vaia colaborar o/a contribuidor/a. 
-- A oficina de gobernación ofrécese a mediar entre o/a contribuidor/a e o/a seu/súa superior/a en caso de conflito acerca do horario das contribucións. 
-- O/A [líder da comunidade experto/a en InnerSource](./dedicated-community-leader.md) participa nas revisións do rendemento dos/as contribuidores/as contratados/as por máis dun 20% ou realiza aportacións ás mesmas. 
+- A contratación establece que non é obrigatorio traballar en InnerSource durante a porcentaxe máxima especificada no contrato.
+- A contratación está firmada polo/a contribuidor/a, o/a seu/súa superior/a inmediato/a, a oficina de gobernación e o/a [líder da comunidade experto/a en InnerSource](./dedicated-community-leader.md) coa que vaia colaborar o/a contribuidor/a.
+- A oficina de gobernación ofrécese a mediar entre o/a contribuidor/a e o/a seu/súa superior/a en caso de conflito acerca do horario das contribucións.
+- O/A [líder da comunidade experto/a en InnerSource](./dedicated-community-leader.md) participa nas revisións do rendemento dos/as contribuidores/as contratados/as por máis dun 20% ou realiza aportacións ás mesmas.
 
 ![*Contracted contributor*](../../../assets/img/contracted-contributor.png)
 
 ## Contexto resultante
 
-A contratación formal e os reembolsos financiados de xeito centralizado comunican de forma convincente o apoio da organización á iniciativa InnerSource, capacitando así aos mandos intermedios para que aproben a devandita iniciativa: 
+A contratación formal e os reembolsos financiados de xeito centralizado comunican de forma convincente o apoio da organización á iniciativa InnerSource, capacitando así aos mandos intermedios para que aproben a devandita iniciativa:
 
-- A asignación dos fondos corporativos das unidades de negocio para o reembolso da capacidade de desenvolvemento indícalles aos/ás responsables de área que InnerSource aporta valor á organización, que conta con apoio executivo e que se espera que tamén eles/as a apoien. 
-- A contratación formal indica que o traballo mediante InnerSource se xestiona de xeito profesional e inspira confianza. 
-- Unha contratación formal aumenta a transparencia e proporciona unha mellor visión de conxunto sobre a capacidade dispoñible do/a socio/a para a súa unidade de negocio e sobre os seus proxectos InnerSource, reducindo así o risco de planificar en exceso a capacidade de produción. 
+- A asignación dos fondos corporativos das unidades de negocio para o reembolso da capacidade de desenvolvemento indícalles aos/ás responsables de área que InnerSource aporta valor á organización, que conta con apoio executivo e que se espera que tamén eles/as a apoien.
+- A contratación formal indica que o traballo mediante InnerSource se xestiona de xeito profesional e inspira confianza.
+- Unha contratación formal aumenta a transparencia e proporciona unha mellor visión de conxunto sobre a capacidade dispoñible do/a socio/a para a súa unidade de negocio e sobre os seus proxectos InnerSource, reducindo así o risco de planificar en exceso a capacidade de produción.
 
-A contratación formal tamén é beneficiosa para os/as contribuidores/as e as comunidades: 
+A contratación formal tamén é beneficiosa para os/as contribuidores/as e as comunidades:
 
 - Cun grupo estable de contribuidores/as, é moito máis probable que algúns/algunhas deles/as rematen acadando o status de  [*Trusted committer*](./trusted-committer.md)
-- Unha contratación formal proporciona un marco para resolver conflitos vencellados á participación nas actividades InnerSource. Teña en conta que probablemente a mediación só sexa frutífera para as compañías que teñan unha cultura que o propicie. 
+- Unha contratación formal proporciona un marco para resolver conflitos vencellados á participación nas actividades InnerSource. Teña en conta que probablemente a mediación só sexa frutífera para as compañías que teñan unha cultura que o propicie.
 
 ## Exemplos coñecidos
 
@@ -88,4 +88,4 @@ A contratación formal tamén é beneficiosa para os/as contribuidores/as e as c
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/core-team.md b/translation/gl/patterns/core-team.md
index c9e442788..80b65c711 100644
--- a/translation/gl/patterns/core-team.md
+++ b/translation/gl/patterns/core-team.md
@@ -4,41 +4,41 @@
 
 ## Patlet
 
-Incluso cando se necesita moito un proxecto InnerSource, as colaboracións e o seu uso poden verse obstaculizados porque é difícil traballar co proxecto. Estableza un *core team* que se dedique a coidar dos elementos fundamentais do proxecto. O traballo do *core team* permite aos/ás contribuidores/as engadir e empregar as funcionalidades que aportan valor aos seus escenarios. 
+Incluso cando se necesita moito un proxecto InnerSource, as colaboracións e o seu uso poden verse obstaculizados porque é difícil traballar co proxecto. Estableza un *core team* que se dedique a coidar dos elementos fundamentais do proxecto. O traballo do *core team* permite aos/ás contribuidores/as engadir e empregar as funcionalidades que aportan valor aos seus escenarios.
 
 ## Problema
 
-- É difícil contribuír ao proxecto. Isto podería deberse a aspectos como: 
+- É difícil contribuír ao proxecto. Isto podería deberse a aspectos como:
   - Non se pode executar o proxecto de maneira local.
   - Documentación deficiente.
   - Código intrincado.
   - Probas inadecuadas.
-- É difícil usar o proxecto. Algunhas causas posibles son: 
+- É difícil usar o proxecto. Algunhas causas posibles son:
   - Documentación deficiente (unha vez máis).
   - Erros frecuentes.
   - Configuración pouco intuitiva.
 
 ## Historia
 
-Hai un proxecto central do que todos/as dependen. Gran candidato para InnerSource! Desafortunadamente, o proxecto creceu de maneira orgánica e con varias contribucións e adicións fortuítas. Agora trátase dunha maraña de código desordenado e denso que ninguén entende e no que todo o mundo ten medo a somerxerse. Está claro que necesita unha revisión (por exemplo, refactorización, probas, documentación etc.), pero aínda que todos/as necesitan e queren que se leve a cabo a tarefa, ninguén emprega tempo en facelo. 
+Hai un proxecto central do que todos/as dependen. Gran candidato para InnerSource! Desafortunadamente, o proxecto creceu de maneira orgánica e con varias contribucións e adicións fortuítas. Agora trátase dunha maraña de código desordenado e denso que ninguén entende e no que todo o mundo ten medo a somerxerse. Está claro que necesita unha revisión (por exemplo, refactorización, probas, documentación etc.), pero aínda que todos/as necesitan e queren que se leve a cabo a tarefa, ninguén emprega tempo en facelo.
 
 ## Contexto
 
 - Moitos equipos necesitan o proxecto.
-- O proxecto ten unha débeda tecnolóxica significativa. 
+- O proxecto ten unha débeda tecnolóxica significativa.
 - A adopción e iteración do proxecto é lenta.
 - Non hai un/unha propietario/a ou encargado/a do mantemento que asuma a responsabilidade do proxecto e o ecosistema de contribución no seu conxunto.
 
 ## Aspectos que mellorar
 
-- Tódolos equipos contribuidores están ocupados e, por tanto, priorizan o traballo que supón unha recompensa inmediata para eles mesmos. 
-- A medida que o proxecto crece, a tendencia natural é que se volva máis difícil de empregar e modificar. 
+- Tódolos equipos contribuidores están ocupados e, por tanto, priorizan o traballo que supón unha recompensa inmediata para eles mesmos.
+- A medida que o proxecto crece, a tendencia natural é que se volva máis difícil de empregar e modificar.
 
 ## Solución
 
-Forme un *core team* cuxo traballo sexa manter este proxecto nun estado no que outros/as poidan incorporarse e contribuír facilmente. Este equipo leva a cabo o traballo necesario para crear un ecosistema saudable de uso e de contribución. Este traballo crítico a miúdo non se prioriza tanto como a contribución. As categorías deste tipo de traballo inclúen a comunicación, un entorno local e unha infraestrutura DevOps. 
+Forme un *core team* cuxo traballo sexa manter este proxecto nun estado no que outros/as poidan incorporarse e contribuír facilmente. Este equipo leva a cabo o traballo necesario para crear un ecosistema saudable de uso e de contribución. Este traballo crítico a miúdo non se prioriza tanto como a contribución. As categorías deste tipo de traballo inclúen a comunicación, un entorno local e unha infraestrutura DevOps.
 
-Velaquí algúns exemplos específicos: 
+Velaquí algúns exemplos específicos:
 
 - Erros de produción.
 - Documentación.
@@ -50,34 +50,34 @@ Velaquí algúns exemplos específicos:
 - Monitorización.
 - Clases/categorías de funcionalidades pioneiras.
 
-Cada un destes elementos é moi importante para un ecosistema de produtos saudable, pero é pouco probable que se lle dea tanta prioridade como á contribución. 
+Cada un destes elementos é moi importante para un ecosistema de produtos saudable, pero é pouco probable que se lle dea tanta prioridade como á contribución.
 
-O *core team* pode estar composto por un pequeno número de persoas a tempo completo ou parcial. A elección depende da cantidade de traballo necesario, a dispoñibilidade de recursos e a cultura da organización. A consideración máis importante é formar ao equipo de maneira que permita á organización capacitalos e responsabilizalos da mesma maneira que a outro equipo calquera. 
+O *core team* pode estar composto por un pequeno número de persoas a tempo completo ou parcial. A elección depende da cantidade de traballo necesario, a dispoñibilidade de recursos e a cultura da organización. A consideración máis importante é formar ao equipo de maneira que permita á organización capacitalos e responsabilizalos da mesma maneira que a outro equipo calquera.
 
-Por mor do seu rol central, os membros do *core team* case sempre deben desempeñar tamén o rol de ***trusted committers*** (para obter máis información acerca deste concepto, consulte [Learning Path](https://innersourcecommons.org/learn/learning-path/trusted-committer/) ou *Ruta de aprendizaxe* e o [modelo](./trusted-committer.md)). Se ben o rol de *trusted committer* se centra principalmente en facilitar a contribución e o uso do proxecto por parte doutros/as, un membro do *core team* tamén contribúe regularmente ao proxecto. O *core team* non ten unha axenda propia que determine as súas contribucións. Estes deciden en que traballar en función daquilo que máis axudará aos/ás demais a empregar e contribuír ao proxecto. 
+Por mor do seu rol central, os membros do *core team* case sempre deben desempeñar tamén o rol de ***trusted committers*** (para obter máis información acerca deste concepto, consulte [Learning Path](https://innersourcecommons.org/learn/learning-path/trusted-committer/) ou *Ruta de aprendizaxe* e o [modelo](./trusted-committer.md)). Se ben o rol de *trusted committer* se centra principalmente en facilitar a contribución e o uso do proxecto por parte doutros/as, un membro do *core team* tamén contribúe regularmente ao proxecto. O *core team* non ten unha axenda propia que determine as súas contribucións. Estes deciden en que traballar en función daquilo que máis axudará aos/ás demais a empregar e contribuír ao proxecto.
 
-Unha boa maneira de recordarlles constantemente ao equipo central este obxectivo é facer que estes proporcionen información regularmente sobre: 
+Unha boa maneira de recordarlles constantemente ao equipo central este obxectivo é facer que estes proporcionen información regularmente sobre:
 
 - O número de equipos activos que emprega o proxecto.
 - O número de contribucións externas ao equipo.
 
-Centrarse de xeito continuo nestas métricas, naturalmente, impulsará ao *core team* a priorizar, en xeral, o traballo axeitado co fin de crear un ecosistema InnerSource próspero arredor do proxecto. 
+Centrarse de xeito continuo nestas métricas, naturalmente, impulsará ao *core team* a priorizar, en xeral, o traballo axeitado co fin de crear un ecosistema InnerSource próspero arredor do proxecto.
 
-![Responsabilidades do *core team* e dos/as contribuidores/as de InnerSource](../../../assets/img/gl/core-team.png) 
+![Responsabilidades do *core team* e dos/as contribuidores/as de InnerSource](../../../assets/img/gl/core-team.png)
 
 ## Contexto resultante
 
-- É doado de empregar e contribuír ao proxecto. 
-- Moitos equipos empregan e contribúen ao proxecto. 
-- O éxito do *core team* defínese nos termos da interacción dos/as demais e a resposta ao seu proxecto. 
+- É doado de empregar e contribuír ao proxecto.
+- Moitos equipos empregan e contribúen ao proxecto.
+- O éxito do *core team* defínese nos termos da interacción dos/as demais e a resposta ao seu proxecto.
 
 ## Fundamento
 
-Separar a un *core team* e asignarlle tarefas axuda a encher os baleiros que necesita un proxecto frutífero e que, porén, exclúe aos/ás contribuíntes que só se preocupan dos seus propios obxectivos. O *core team* enche eses baleiros e engraxa as rodas para que o ecosistema de contribución se manteña saudable. 
+Separar a un *core team* e asignarlle tarefas axuda a encher os baleiros que necesita un proxecto frutífero e que, porén, exclúe aos/ás contribuíntes que só se preocupan dos seus propios obxectivos. O *core team* enche eses baleiros e engraxa as rodas para que o ecosistema de contribución se manteña saudable.
 
 ## Exemplos coñecidos
 
-- **Nike** aplicou este modelo para xestionar o esforzo InnerSource arredor das súas planificacións non reutilizables de CI/CD. 
+- **Nike** aplicou este modelo para xestionar o esforzo InnerSource arredor das súas planificacións non reutilizables de CI/CD.
 - **WellSky** estableceu un *core team* para un proxecto chave. Isto permitiulles escalar as súas contribucións InnerSource a ese proxecto de xeito significativo; vexa [*Wide-Scaled InnerSource with a Core Team*](https://www.youtube.com/watch?v=kgxexjYdhIc) [InnerSource de grande escala cun *core team]*.
 - **BBVA AI Factory** aplicou este modelo como parte dunha estratexia InnerSource para fomentar a contribución e a reutilización do código de ciencia de datos; vexa [*Mercury: Scaling Data Science reusability at BBVA*](https://www.bbvaaifactory.com/mercury-acelerando-la-reutilizacion-en-ciencia-de-datos-dentro-de-bbva/) [Mercury: Acelerando a reutilización da ciencia de datos en BBVA].
 
diff --git a/translation/gl/patterns/crossteam-project-valuation.md b/translation/gl/patterns/crossteam-project-valuation.md
index 2cc425827..0f8f6e862 100644
--- a/translation/gl/patterns/crossteam-project-valuation.md
+++ b/translation/gl/patterns/crossteam-project-valuation.md
@@ -8,43 +8,43 @@ Valoración de proxectos entre equipos
 
 ## Contexto
 
-- Vostede é responsable da colaboración entre equipos que serve de plataforma para outros/as traballadores/as da empresa. 
-- O proxecto de colaboración entre equipos non aporta ningún valor directo aos ingresos da empresa. 
+- Vostede é responsable da colaboración entre equipos que serve de plataforma para outros/as traballadores/as da empresa.
+- O proxecto de colaboración entre equipos non aporta ningún valor directo aos ingresos da empresa.
 
 ## Problema
 
-Os proxectos de colaboración entre equipos poden ter un grande impacto na empresa, pero son difíciles de representar mediante datos. En consecuencia, é doado e habitual seguir adiante con proxectos que non aportan valor real ou non inverter suficiente diñeiro, o que, en caso contrario, si aportaría un gran valor. 
+Os proxectos de colaboración entre equipos poden ter un grande impacto na empresa, pero son difíciles de representar mediante datos. En consecuencia, é doado e habitual seguir adiante con proxectos que non aportan valor real ou non inverter suficiente diñeiro, o que, en caso contrario, si aportaría un gran valor.
 
 ## Aspectos que mellorar
 
-- Os proxectos deben amosar valor (obxectivo ou subxectivo) ao liderado da empresa para que se poidan financiar. 
+- Os proxectos deben amosar valor (obxectivo ou subxectivo) ao liderado da empresa para que se poidan financiar.
 - O valor do proxecto de colaboración entre equipos distribúese entre múltiples unidades comerciais afíns.
-- Por mor desta dispersión, o valor do proxecto de colaboración entre equipos é difícil de medir de xeito directo. 
+- Por mor desta dispersión, o valor do proxecto de colaboración entre equipos é difícil de medir de xeito directo.
 
 ## Solución
 
-Estableza un modelo e unha fórmula para avaliar os proxectos de colaboración entre equipos. Estes modelos bríndannos a ferramenta que necesitamos para centrar e amplificar a colaboración de gran valor para a empresa. 
+Estableza un modelo e unha fórmula para avaliar os proxectos de colaboración entre equipos. Estes modelos bríndannos a ferramenta que necesitamos para centrar e amplificar a colaboración de gran valor para a empresa.
 
-O núcleo do valor de todo proxecto de colaboración entre equipos é a idea de que podemos facer máis cousas xuntos/as que separados/as. Atribuírlle valor ao esforzo de colaboración entre equipos é un exercicio para cuantificar *canto máis* se está avanzando xuntos/as. O *delta* exacto de produtividade variará segundo o ámbito e o proxecto. Existe un proceso común, mediante o cal pode crear unha fórmula para calculalo. 
+O núcleo do valor de todo proxecto de colaboración entre equipos é a idea de que podemos facer máis cousas xuntos/as que separados/as. Atribuírlle valor ao esforzo de colaboración entre equipos é un exercicio para cuantificar *canto máis* se está avanzando xuntos/as. O *delta* exacto de produtividade variará segundo o ámbito e o proxecto. Existe un proceso común, mediante o cal pode crear unha fórmula para calculalo.
 
 ### Explicación
 
-Reúna a un pequeno equipo de expertos/as na materia do seu ámbito. Empregando ese equipo de expertos/as, estime catro aspectos sobre cada consumidor/a da produción do seu proxecto: 
+Reúna a un pequeno equipo de expertos/as na materia do seu ámbito. Empregando ese equipo de expertos/as, estime catro aspectos sobre cada consumidor/a da produción do seu proxecto:
 
 - Canto tempo lles leva consumir a produción do seu proxecto?
-- Canto tempo lles levaría, pola contra, calcular o valor da produción do seu proxecto por si mesmos/as? 
+- Canto tempo lles levaría, pola contra, calcular o valor da produción do seu proxecto por si mesmos/as?
 - Que porcentaxe da produción do seu proxecto é realmente útil para eles/as?
-- Canto tempo (por uso óptimo) dedicarían a empregar unha solución caseira? 
+- Canto tempo (por uso óptimo) dedicarían a empregar unha solución caseira?
 
-Á hora de facer estas estimacións, é imposible saber con gran precisión canto tempo leva cada actividade. Ese non é o seu obxectivo. En lugar da exactitude, debe esforzarse en _**establecer un límite para delimitar o peor escenario posible**_ destas estimacións.
+Á hora de facer estas estimacións, é imposible saber con gran precisión canto tempo leva cada actividade. Ese non é o seu obxectivo. En lugar da exactitude, debe esforzarse en ***establecer un límite para delimitar o peor escenario posible*** destas estimacións.
 
-A idea é que o grupo de expertos/as poida dicirse uns/unhas a outros/as: «Non sabemos exactamente canto tempo nos levaría, pero todos/as estamos de acordo en que, *polo menos*, levaríanos este tempo.». Concretamente, debe estimar un tempo *máximo* razoable e tempos *mínimos* razoables para que os/as consumidores/as poidan, por outra parte, improvisar e aplicar as súas propias solucións. 
+A idea é que o grupo de expertos/as poida dicirse uns/unhas a outros/as: «Non sabemos exactamente canto tempo nos levaría, pero todos/as estamos de acordo en que, *polo menos*, levaríanos este tempo.». Concretamente, debe estimar un tempo *máximo* razoable e tempos *mínimos* razoables para que os/as consumidores/as poidan, por outra parte, improvisar e aplicar as súas propias solucións.
 
-Un apunte sobre o custo de idear unha «solución caseira propia»; o custo de pór en marcha unha solución caseira NON é necesariamente (de feito, é moi pouco probable) o mesmo que o de crear unha solución común. A miúdo, para a mesma funcionalidade, a modularidade e a calidade involucradas na creación dunha solución mediante a colaboración entre equipos, fai que sexa unha inversión notablemente maior que unha aplicación rápida e codificada que se emprega só unha vez. 
+Un apunte sobre o custo de idear unha «solución caseira propia»; o custo de pór en marcha unha solución caseira NON é necesariamente (de feito, é moi pouco probable) o mesmo que o de crear unha solución común. A miúdo, para a mesma funcionalidade, a modularidade e a calidade involucradas na creación dunha solución mediante a colaboración entre equipos, fai que sexa unha inversión notablemente maior que unha aplicación rápida e codificada que se emprega só unha vez.
 
 ### Fórmula
 
-Unha vez que teña os límites do peor escenario posible, pode valorar o resultado do seu proxecto de colaboración entre equipos durante un período de tempo concreto a través da sinxela fórmula: 
+Unha vez que teña os límites do peor escenario posible, pode valorar o resultado do seu proxecto de colaboración entre equipos durante un período de tempo concreto a través da sinxela fórmula:
 
 ```
 [Time Saved] - [Time Invested]
@@ -56,27 +56,27 @@ Unha vez que teña os límites do peor escenario posible, pode valorar o resulta
 
 ### Comentario
 
-A pesar do seu rigor, este proceso non produce unha forma exacta para medir o resultado nun proxecto de colaboración entre equipos. Na práctica, con todo, brinda un marco mediante o cal pode tomar unha decisión acertada para financiar este traballo. Tras dispor de datos fiables e razoables, de acordo coa explicación anterior, debe financiar as horas de desenvolvemento dedicadas a executar o proxecto ata, **polo menos**, chegar ao nivel máis baixo destes tres niveis seguintes: 
+A pesar do seu rigor, este proceso non produce unha forma exacta para medir o resultado nun proxecto de colaboración entre equipos. Na práctica, con todo, brinda un marco mediante o cal pode tomar unha decisión acertada para financiar este traballo. Tras dispor de datos fiables e razoables, de acordo coa explicación anterior, debe financiar as horas de desenvolvemento dedicadas a executar o proxecto ata, **polo menos**, chegar ao nivel máis baixo destes tres niveis seguintes:
 
-1. As horas brutas que se aforraron mediante a fórmula anterior. Posto que todos/as estamos seguros/as de que a fórmula devolveranos unha cifra inferior ao número real de horas aforradas, pode estar seguro/a de que financiar o proxecto é unha vitoria asegurada. 
+1. As horas brutas que se aforraron mediante a fórmula anterior. Posto que todos/as estamos seguros/as de que a fórmula devolveranos unha cifra inferior ao número real de horas aforradas, pode estar seguro/a de que financiar o proxecto é unha vitoria asegurada.
 2. A cantidade de tempo que se necesita para apoiar as contribucións InnerSource a proxectos de colaboración entre equipos. Posto que o/a contribuidor/a probablemente tería feito o traballo de tódolos xeitos puntualmente, merece a pena financiar o tempo que se necesita para facilitar que o seu traballo pase a estar nunha arquitectura de información compartida.
-3. O que a vostede lle pareza mellor. Un efecto secundario intencionado de dispor dunha fórmula de valoración é que, naturalmente, obriga a medir puntos chave que aportan valor aos/ás consumidores/as. 
+3. O que a vostede lle pareza mellor. Un efecto secundario intencionado de dispor dunha fórmula de valoración é que, naturalmente, obriga a medir puntos chave que aportan valor aos/ás consumidores/as.
 
-Esas medicións poden entenderse e consumirse na súa forma bruta para que vostede poida intuír a valía deste proxecto: 
+Esas medicións poden entenderse e consumirse na súa forma bruta para que vostede poida intuír a valía deste proxecto:
 
-Pode que a algúns/algunhas lles preocupe a falta de precisión deste método de valoración. Está ben que este proceso non teña un resultado de medición exacta. Só ten que ser o suficientemente preciso para cumprimentar dous obxectivos: 
+Pode que a algúns/algunhas lles preocupe a falta de precisión deste método de valoración. Está ben que este proceso non teña un resultado de medición exacta. Só ten que ser o suficientemente preciso para cumprimentar dous obxectivos:
 
-1. Ofrecer un medio para representar o valor do que está acontecendo a quen organiza e financia o esforzo dos equipos. 
-2. Axudar aos/ás implicados/as a saber que áreas dos esforzos entre os equipos son máis prioritarias en función do seu valor. 
+1. Ofrecer un medio para representar o valor do que está acontecendo a quen organiza e financia o esforzo dos equipos.
+2. Axudar aos/ás implicados/as a saber que áreas dos esforzos entre os equipos son máis prioritarias en función do seu valor.
 
-Na práctica, sempre que estas valoracións se atopen dentro dunha orde de magnitude da realidade e entre si, son suficientemente precisas para cumprimentar con estes fins. Mellorarán con creces os resultados obtidos respecto das valoracións *ad hoc* (e dos efectos resultantes) descritas na sección **Problema** ao comezo deste documento. 
+Na práctica, sempre que estas valoracións se atopen dentro dunha orde de magnitude da realidade e entre si, son suficientemente precisas para cumprimentar con estes fins. Mellorarán con creces os resultados obtidos respecto das valoracións *ad hoc* (e dos efectos resultantes) descritas na sección **Problema** ao comezo deste documento.
 
 ## Contexto resultante
 
 - Medios baseados en datos para debater o valor e a financiación do proxecto de colaboración entre equipos mediante o liderado.
 - Métricas clave arredor do proxecto de colaboración entre equipos instrumentados en bruto.
 - Definir a forma na que o proxecto de colaboración entre equipos aporta valor e como iso adoita producir un maior valor para a empresa.
-- Éxito xeral do proxecto e axitación ao seu redor. 
+- Éxito xeral do proxecto e axitación ao seu redor.
 
 ## Exemplos coñecidos
 
@@ -93,9 +93,9 @@ Na práctica, sempre que estas valoracións se atopen dentro dunha orde de magni
 
 ## Recoñecementos
 
-- Jeremiah Wright, por ensinarme a considerar os proxectos de colaboración entre equipos como un negocio interno no que a moeda é o tempo dos/as desenvolvedores/as. 
+- Jeremiah Wright, por ensinarme a considerar os proxectos de colaboración entre equipos como un negocio interno no que a moeda é o tempo dos/as desenvolvedores/as.
 
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/dedicated-community-leader.md b/translation/gl/patterns/dedicated-community-leader.md
index df4ae7671..67f4a20c9 100644
--- a/translation/gl/patterns/dedicated-community-leader.md
+++ b/translation/gl/patterns/dedicated-community-leader.md
@@ -10,7 +10,7 @@ Seleccione persoas con habilidades técnicas e de comunicación para liderar as
 
 Como asegura que a nova iniciativa InnerSource ten ao/á [líder da comunidade](http://www.artofcommunityonline.org/) axeitado/a para que o impacto poida ser maior?
 
-Ao seleccionar ás persoas coas habilidades erróneas e/ou non proporcionarlles a capacitación suficiente arríscase a desperdiciar esforzos e, en última instancia, a que a nova iniciativa InnerSource fracase. 
+Ao seleccionar ás persoas coas habilidades erróneas e/ou non proporcionarlles a capacitación suficiente arríscase a desperdiciar esforzos e, en última instancia, a que a nova iniciativa InnerSource fracase.
 
 ## Historia
 
@@ -18,47 +18,47 @@ Considere o seguinte escenario. Unha empresa quere comezar unha iniciativa Inner
 
 ## Contexto
 
-- A empresa é grande e antiga. Non ten experiencia previa en software libre ou outros modelos de traballo colaborativo. A cultura da empresa caracterízase por un estilo de xestión clásico de arriba cara abaixo: xeralmente está en desacordo coa cultura da comunidade. 
-- Aínda que hai paritarios/as e un/unha patrocinador/a no alto cargo, aos/ás responsables de área da empresa non lles entusiasma InnerSource. 
-- Non se conseguiu convencer á dirección para que aportase máis ca un presuposto limitado para financiar unicamente a un/unha líder da comunidade a tempo parcial. 
+- A empresa é grande e antiga. Non ten experiencia previa en software libre ou outros modelos de traballo colaborativo. A cultura da empresa caracterízase por un estilo de xestión clásico de arriba cara abaixo: xeralmente está en desacordo coa cultura da comunidade.
+- Aínda que hai paritarios/as e un/unha patrocinador/a no alto cargo, aos/ás responsables de área da empresa non lles entusiasma InnerSource.
+- Non se conseguiu convencer á dirección para que aportase máis ca un presuposto limitado para financiar unicamente a un/unha líder da comunidade a tempo parcial.
 - O/A líder da comunidade seleccionado/a inicialmente ten pouca ou ningunha experiencia previa co modelo de traballo de software libre.
-- O/A desenvolvedor/a seleccionado/a como líder da comunidade inicialmente non conta cunha ampla rede de contactos dentro da empresa. 
+- O/A desenvolvedor/a seleccionado/a como líder da comunidade inicialmente non conta cunha ampla rede de contactos dentro da empresa.
 
 ## Aspectos que mellorar
 
-Se unha empresa non inverte de xeito significativo na comunidade inicial de InnerSource en termos de presuposto e de capacitación, a credibilidade do seu compromiso coa iniciativa podería parecer cuestionable. O impulso común dunha empresa cunha cultura de xestión tradicional ante un proxecto ou iniciativa que non funciona como se esperaba, será a de substituír ao/á seu/súa líder. Facer isto sen involucrar á comunidade e sen seguir os principios meritocráticos, socavará aínda máis o compromiso da empresa con InnerSource ao pór de manifesto a fricción existente entre a cultura actual da empresa e a cultura obxectivo: a cultura comunitaria. 
+Se unha empresa non inverte de xeito significativo na comunidade inicial de InnerSource en termos de presuposto e de capacitación, a credibilidade do seu compromiso coa iniciativa podería parecer cuestionable. O impulso común dunha empresa cunha cultura de xestión tradicional ante un proxecto ou iniciativa que non funciona como se esperaba, será a de substituír ao/á seu/súa líder. Facer isto sen involucrar á comunidade e sen seguir os principios meritocráticos, socavará aínda máis o compromiso da empresa con InnerSource ao pór de manifesto a fricción existente entre a cultura actual da empresa e a cultura obxectivo: a cultura comunitaria.
 
-A aportación do valor dos proxectos InnerSource non resultará evidente para o persoal directivo que está inmerso nos métodos tradicionais de xestión de proxectos. É menos probable que o persoal directivo asigne a unha persoa de alto cargo, que xeralmente ten unha gran demanda de proxectos que non son InnerSource, a un proxecto InnerSource que ocuparía unha parte significativa da súa xornada de traballo. 
+A aportación do valor dos proxectos InnerSource non resultará evidente para o persoal directivo que está inmerso nos métodos tradicionais de xestión de proxectos. É menos probable que o persoal directivo asigne a unha persoa de alto cargo, que xeralmente ten unha gran demanda de proxectos que non son InnerSource, a un proxecto InnerSource que ocuparía unha parte significativa da súa xornada de traballo.
 
-A meirande parte do traballo diario dun/dunha líder da comunidade ocúpao na comunicación. Do mesmo xeito, é probable que tamén teña que encabezar un desenvolvemento inicial. Ante a capacidade limitada, os/as líderes sen experiencia tenderán a centrarse no desenvolvemento e descoidar a comunicación. A barreira para que os/as posibles contribuidores/as fagan a súa primeira contribución e se comprometan coa comunidade será moito maior se non é doado contactar co/coa líder da comunidade ou se tarda en dar retroalimentación e responder a preguntas por falta de tempo. Ademais, os/as líderes inexpertos/as no ámbito técnico probablemente terán máis dificultades para atraer e reter contribuidores/as con moita experiencia, das que tería un/unha líder cun alto desempeño e grao de visibilidade dentro da empresa. 
+A meirande parte do traballo diario dun/dunha líder da comunidade ocúpao na comunicación. Do mesmo xeito, é probable que tamén teña que encabezar un desenvolvemento inicial. Ante a capacidade limitada, os/as líderes sen experiencia tenderán a centrarse no desenvolvemento e descoidar a comunicación. A barreira para que os/as posibles contribuidores/as fagan a súa primeira contribución e se comprometan coa comunidade será moito maior se non é doado contactar co/coa líder da comunidade ou se tarda en dar retroalimentación e responder a preguntas por falta de tempo. Ademais, os/as líderes inexpertos/as no ámbito técnico probablemente terán máis dificultades para atraer e reter contribuidores/as con moita experiencia, das que tería un/unha líder cun alto desempeño e grao de visibilidade dentro da empresa.
 
-Se unha comunidade non pode crecer o suficientemente rápido e alcanzar a velocidade suficiente, é probable que non poida demostrar de maneira convincente o potencial de InnerSource. 
+Se unha comunidade non pode crecer o suficientemente rápido e alcanzar a velocidade suficiente, é probable que non poida demostrar de maneira convincente o potencial de InnerSource.
 
-Se a empresa selecciona a un/unha responsable de área con experiencia que está empapado/a dos métodos de xestión tradicionais para que sexa o/a líder da comunidade, é probable que este/a se centre en temas de xestión tradicionais como a asignación de recursos, a provisión dunha estrutura e as canles de información; na contra de liderar co exemplo a través de principios meritocráticos. Isto socavaría a credibilidade da iniciativa InnerSource aos ollos dos/as desenvolvedores/as. 
+Se a empresa selecciona a un/unha responsable de área con experiencia que está empapado/a dos métodos de xestión tradicionais para que sexa o/a líder da comunidade, é probable que este/a se centre en temas de xestión tradicionais como a asignación de recursos, a provisión dunha estrutura e as canles de información; na contra de liderar co exemplo a través de principios meritocráticos. Isto socavaría a credibilidade da iniciativa InnerSource aos ollos dos/as desenvolvedores/as.
 
 ## Solución
 
-Seleccione a un/unha líder da comunidade que: 
+Seleccione a un/unha líder da comunidade que:
 
 - Teña experiencia no modelo de traballo de software libre ou modelos de traballo baseados na comunidade que sexan similares.
 - Que teña habilidades brandas necesarias para actuar coma un/unha auténtico/a líder.
-- Que predique co exemplo e así xustifique a súa posición na meritocracia comunitaria. 
+- Que predique co exemplo e así xustifique a súa posición na meritocracia comunitaria.
 - Que sexa un/unha excelente *networker*.
 - Que inspire aos membros da comunidade.
-- Que poida comunicarse de maneira efectiva tanto coa xerencia executiva como cos/coas desenvolvedores/as. 
+- Que poida comunicarse de maneira efectiva tanto coa xerencia executiva como cos/coas desenvolvedores/as.
 - Que sexa capaz de xestionar aspectos administrativos do traballo colaborativo.
 
 Apoderar ao/á líder da comunidade para que dedique o 100 % do seu tempo ao traballo comunitario, incluíndo a comunicación e o desenvolvemento. Informar á xerencia sobre a necesidade de ter en conta os puntos de vista da comunidade ao xerar un cambio na xestión comunitaria. No mellor dos casos, apoderar á comunidade para que eles/as mesmos/as nomeen a un/unha líder da comunidade.
 
 ## Contexto resultante
 
-Un/Unha líder da comunidade coas prioridades descritas anteriormente dará a cara e encarnará o compromiso da empresa con InnerSource. Así será máis probable que outros/as socios/as da súa rede sigan o seu exemplo e contribúan a InnerSource. Co tempo, o/a líder da comunidade poderá crear un *core team* estable de desenvolvedores/as e, por tanto, aumentar as posibilidades de éxito do proxecto InnerSource. Ao convencer a un público o suficientemente amplo dentro da súa empresa do potencial de InnerSource, contribuirá a cambiar a cultura da empresa vixente por unha cultura comunitaria. 
+Un/Unha líder da comunidade coas prioridades descritas anteriormente dará a cara e encarnará o compromiso da empresa con InnerSource. Así será máis probable que outros/as socios/as da súa rede sigan o seu exemplo e contribúan a InnerSource. Co tempo, o/a líder da comunidade poderá crear un *core team* estable de desenvolvedores/as e, por tanto, aumentar as posibilidades de éxito do proxecto InnerSource. Ao convencer a un público o suficientemente amplo dentro da súa empresa do potencial de InnerSource, contribuirá a cambiar a cultura da empresa vixente por unha cultura comunitaria.
 
-Contar con excelentes líderes da comunidade especializados/as é unha condición previa para o éxito de InnerSource. Con todo, non é unha solución milagrosa. InnerSource abrangue moitos retos que superan o que un/unha líder da comunidade pode abordar, como son os retos presupostarios, xurídicos, fiscais e outros retos organizativos. 
+Contar con excelentes líderes da comunidade especializados/as é unha condición previa para o éxito de InnerSource. Con todo, non é unha solución milagrosa. InnerSource abrangue moitos retos que superan o que un/unha líder da comunidade pode abordar, como son os retos presupostarios, xurídicos, fiscais e outros retos organizativos.
 
 ## Exemplos coñecidos
 
-- BIOS en Robert Bosch GmbH: Teña en conta que InnerSource en Bosch estivo dirixido maioritariamente a aumentar a innovación de gran magnitude ao encargarse de produtos de revestimento interno. Actualmente, este modelo non se está a empregar en Bosch por mor da falta de financiación. 
+- BIOS en Robert Bosch GmbH: Teña en conta que InnerSource en Bosch estivo dirixido maioritariamente a aumentar a innovación de gran magnitude ao encargarse de produtos de revestimento interno. Actualmente, este modelo non se está a empregar en Bosch por mor da falta de financiación.
 
 ## Título alternativo
 
@@ -90,4 +90,4 @@ Coordinador/a da comunidade experto/a en InnerSource
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/document-your-guiding-principles.md b/translation/gl/patterns/document-your-guiding-principles.md
index 1791f231d..a322c78f0 100644
--- a/translation/gl/patterns/document-your-guiding-principles.md
+++ b/translation/gl/patterns/document-your-guiding-principles.md
@@ -8,11 +8,11 @@ A explicación habitual de InnerSource baseada en «aplicar as mellores práctic
 
 ## Problema
 
-A organización está intentando despregar InnerSource a grande escala. A iniciativa comezou cos/coas entusiastas do software libre e,agora, o obxectivo agora é conseguir a adhesión de persoas que carecen de experiencia no software libre. Para ese público, o típico slogan de «aplicar as mellores prácticas de software libre» non basta para transmitir a mensaxe do que supón InnerSource, os problemas que se poden resolver ou as ferramentas que se poden empregar para resolvelos. Como resultado, a adopción de InnerSource na organización relentízase. Os equipos desenvolven ideas diverxentes sobre os obxectivos de InnerSource e a mellor forma de aplicalo, o que xera confusión cando os/as contribuidores/as comezan a cruzar os límites dos equipos. 
+A organización está intentando despregar InnerSource a grande escala. A iniciativa comezou cos/coas entusiastas do software libre e,agora, o obxectivo agora é conseguir a adhesión de persoas que carecen de experiencia no software libre. Para ese público, o típico slogan de «aplicar as mellores prácticas de software libre» non basta para transmitir a mensaxe do que supón InnerSource, os problemas que se poden resolver ou as ferramentas que se poden empregar para resolvelos. Como resultado, a adopción de InnerSource na organización relentízase. Os equipos desenvolven ideas diverxentes sobre os obxectivos de InnerSource e a mellor forma de aplicalo, o que xera confusión cando os/as contribuidores/as comezan a cruzar os límites dos equipos.
 
 ## Historia
 
-Os primeiros experimentos levados a cabo nunha organización demostraron que as mellores prácticas de colaboración en software libre poden ser beneficiosas. O seguinte paso agora é trasladar a iniciativa aos equipos e persoal que carecen de formación en software libre. O obxectivo agora é comunicar claramente os obxectivos da iniciativa InnerSource, así como o camiño claro cara a consecución destes obxectivos. 
+Os primeiros experimentos levados a cabo nunha organización demostraron que as mellores prácticas de colaboración en software libre poden ser beneficiosas. O seguinte paso agora é trasladar a iniciativa aos equipos e persoal que carecen de formación en software libre. O obxectivo agora é comunicar claramente os obxectivos da iniciativa InnerSource, así como o camiño claro cara a consecución destes obxectivos.
 
 ## Contexto
 
@@ -21,80 +21,80 @@ Os primeiros experimentos levados a cabo nunha organización demostraron que as
 
 ## Aspectos que mellorar
 
-- Os equipos teñen dificultades á hora de comunicar de xeito exacto cales son os aspectos fundamentais de InnerSource. 
+- Os equipos teñen dificultades á hora de comunicar de xeito exacto cales son os aspectos fundamentais de InnerSource.
 - Quen carece de experiencia en software libre non entende o que significa implantar as mellores prácticas do software libre na empresa.
 - No día a día, os equipos que intentan seguir as mellores prácticas InnerSource teñen dificultades para decidir se o que están facendo se atopa aliñado cos valores xerais de InnerSource.
 
 ## Solución
 
-Quen impulsa a iniciativa InnerSource na organización debe axudar aos equipos e individuos que carecen dunha forte formación en software libre e, polo tanto, teñen unha comprensión menos intuitiva de InnerSource. 
+Quen impulsa a iniciativa InnerSource na organización debe axudar aos equipos e individuos que carecen dunha forte formación en software libre e, polo tanto, teñen unha comprensión menos intuitiva de InnerSource.
 
 Débese proporcionar claridade aos equipos e individuos documentando estas dúas áreas:
 
 1. **Propósito**: Por que quere adoptar InnerSource a organización?
 2. **Principios:** Que principios InnerSource axudarán a abordar estes retos?
 
-As seguintes seccións proporcionan máis detalles acerca destas áreas pensadas como posibles puntos de partida para documentalos para a súa organización. 
+As seguintes seccións proporcionan máis detalles acerca destas áreas pensadas como posibles puntos de partida para documentalos para a súa organización.
 
 ### Cal é o motivo polo que as organizacións queren adoptar InnerSource?
 
-No pasado, InnerSource amosou a súa eficacia na resolución de problemas habituais das organizacións. 
+No pasado, InnerSource amosou a súa eficacia na resolución de problemas habituais das organizacións.
 
 Con todo, que retos organizativos espera mellorar a súa organización cando emprega InnerSource?
 
-Na contra de facer xeneralizacións, intente identificar exactamente as solucións que se axustan aos retos da súa organización, preferiblemente coas persoas afectadas polo cambio que desexa aplicar. 
+Na contra de facer xeneralizacións, intente identificar exactamente as solucións que se axustan aos retos da súa organización, preferiblemente coas persoas afectadas polo cambio que desexa aplicar.
 
-Algúns retos que outras empresas abordaron seguindo as mellores prácticas InnerSource son: 
+Algúns retos que outras empresas abordaron seguindo as mellores prácticas InnerSource son:
 
-- Reducir o desenvolvemento de silos causados pola cultura da propiedade excesiva. 
-- Aumentar a velocidade da innovación reducindo o tempo dedicado a resolver problemas similares mediante o fomento da reutilización saudable do código. 
+- Reducir o desenvolvemento de silos causados pola cultura da propiedade excesiva.
+- Aumentar a velocidade da innovación reducindo o tempo dedicado a resolver problemas similares mediante o fomento da reutilización saudable do código.
 - Aumentar a velocidade de desenvolvemento mediante unha mellor colaboración entre equipos
-- Resolver as dependencias de proxecto/equipo máis aló da espera e das solucións provisionais, reducindo así os puntos de conxestión na enxeñaría. 
+- Resolver as dependencias de proxecto/equipo máis aló da espera e das solucións provisionais, reducindo así os puntos de conxestión na enxeñaría.
 - Aumentar a calidade.
-- Aumentar a felicidade dos/as traballadores/as. 
+- Aumentar a felicidade dos/as traballadores/as.
 - Aumentar o éxito das novas contratacións.
-- Crear documentación viable. 
+- Crear documentación viable.
 
 ### Que principios InnerSource axudarían a abordar estes retos?
 
-Unha vez que os equipos entendan que problemas lles axudarían a resolver InnerSource, o seguinte paso é explicar que principios axudan a afrontar estes retos. 
+Unha vez que os equipos entendan que problemas lles axudarían a resolver InnerSource, o seguinte paso é explicar que principios axudan a afrontar estes retos.
 
-Baseándonos nos principios básicos do desenvolvemento de software libre, as seguintes directrices amosaron a súa eficacia: 
+Baseándonos nos principios básicos do desenvolvemento de software libre, as seguintes directrices amosaron a súa eficacia:
 
 (1) O código debe aloxarse de maneira transparente na organización.
 
-O código fonte, a documentación e os datos relevantes para o desenvolvemento do proxecto deben estar dispoñibles e ser fáciles de atopar para calquera persoa da organización. 
+O código fonte, a documentación e os datos relevantes para o desenvolvemento do proxecto deben estar dispoñibles e ser fáciles de atopar para calquera persoa da organización.
 
 (2) As contribucións priman sobre as *feature requests*.
 
-Tódalas partes interesadas no proxecto actúan como posibles contribuidores/as e son tratados/as e apoiados/as como tal. As contribucións seguen sendo suxestións na contra de requisitos. A coordinación previa axuda a evitar esforzos inútiles. Os proxectos proporcionan directrices para evitar friccións. 
+Tódalas partes interesadas no proxecto actúan como posibles contribuidores/as e son tratados/as e apoiados/as como tal. As contribucións seguen sendo suxestións na contra de requisitos. A coordinación previa axuda a evitar esforzos inútiles. Os proxectos proporcionan directrices para evitar friccións.
 
 (3) Os erros son oportunidades para aprender.
 
-Cando o traballo é visible para toda a organización, calquera erro será tamén visible para todos/as. Deste xeito, debe establecerse unha cultura na que os erros sexan oportunidades de aprendizaxe na contra de fracasos que deben ser evitados a toda costa. 
+Cando o traballo é visible para toda a organización, calquera erro será tamén visible para todos/as. Deste xeito, debe establecerse unha cultura na que os erros sexan oportunidades de aprendizaxe na contra de fracasos que deben ser evitados a toda costa.
 
 (4) A comunicación escrita prima respecto da comunicación oral.
 
-Para os proxectos que abarcan varios equipos, con posibles calendarios de reunións diverxentes, ten que ser posible colaborar de maneira asíncrona. O obxectivo dos proxectos InnerSource é recrutar a novos/as contribuidores/as. Para iso, os/as posibles futuros/as contribuidores/as deben poder seguir o progreso do proxecto de maneira autónoma con poucas barreiras de acceso. Se a comunicación relevante do proxecto se produce a través da comunicación asíncrona, os razoamentos que se debatan deben facerse transparentes na canle escrita; as decisións unicamente poden finalizar nesa canle. Como efecto secundario, isto conduce a unha documentación de pasivos base moi valiosa para calquera novo/a colaborador/a do proxecto. 
+Para os proxectos que abarcan varios equipos, con posibles calendarios de reunións diverxentes, ten que ser posible colaborar de maneira asíncrona. O obxectivo dos proxectos InnerSource é recrutar a novos/as contribuidores/as. Para iso, os/as posibles futuros/as contribuidores/as deben poder seguir o progreso do proxecto de maneira autónoma con poucas barreiras de acceso. Se a comunicación relevante do proxecto se produce a través da comunicación asíncrona, os razoamentos que se debatan deben facerse transparentes na canle escrita; as decisións unicamente poden finalizar nesa canle. Como efecto secundario, isto conduce a unha documentación de pasivos base moi valiosa para calquera novo/a colaborador/a do proxecto.
 
-(5) Permita que o asesoramento escrito se acumule nun arquivo accesible no que se poidan realizar buscas. 
+(5) Permita que o asesoramento escrito se acumule nun arquivo accesible no que se poidan realizar buscas.
 
 Toda a comunicación do proxecto, en particular as decisión tomadas e os debates que conduciron a esas decisións, deben ser arquivados. Debe ser posible facer referencia á comunicación a través de URL estables. As conversacións previas deben poder almacenarse de maneira que se poidan atopar facilmente.
 
 Mais é necesario facer dúas advertencias:
 
-1. Isto non substitúe a unha documentación estruturada. Con todo, pode servir como punto de partida para recompilar a documentación estruturada. 
-2. Existen excepcións á regra de que todo debe estar por escrito e ser accesible para toda a organización: as conversacións relacionadas cos/coas traballadores/as, así como coa seguridade, son confidenciais e non deben facerse públicas. 
+1. Isto non substitúe a unha documentación estruturada. Con todo, pode servir como punto de partida para recompilar a documentación estruturada.
+2. Existen excepcións á regra de que todo debe estar por escrito e ser accesible para toda a organización: as conversacións relacionadas cos/coas traballadores/as, así como coa seguridade, son confidenciais e non deben facerse públicas.
 
 (6) Recompensa aos/ás *trusted committers*.
 
-Tódalas contribucións (por exemplo, de código fonte, de documentación, de informes de erros, de aportacións aos debates, de apoio aos/ás usuarios/as, de marketing) son benvidas e deben ser recompensadas. Aqueles/as que amosen o seu apoio ao proxecto serán invitados/as como [*trusted committers*](./trusted-committer.md), e tódolos/as *trusted committers* dun proxecto se publican. 
+Tódalas contribucións (por exemplo, de código fonte, de documentación, de informes de erros, de aportacións aos debates, de apoio aos/ás usuarios/as, de marketing) son benvidas e deben ser recompensadas. Aqueles/as que amosen o seu apoio ao proxecto serán invitados/as como [*trusted committers*](./trusted-committer.md), e tódolos/as *trusted committers* dun proxecto se publican.
 
 ## Contexto resultante
 
-- Os membros da organización comprenden que retos poden abordar aplicando as mellores prácticas InnerSource. 
-- Os membros da organización que carecen de experiencia previa no software libre comprenden os valores e os principios básicos dos proxectos InnerSource. 
-- Os membros da organización que carecen de experiencia previa en software libre son capaces de contrastar a súa actividade diaria cun conxunto de valores comúns establecidos. 
+- Os membros da organización comprenden que retos poden abordar aplicando as mellores prácticas InnerSource.
+- Os membros da organización que carecen de experiencia previa no software libre comprenden os valores e os principios básicos dos proxectos InnerSource.
+- Os membros da organización que carecen de experiencia previa en software libre son capaces de contrastar a súa actividade diaria cun conxunto de valores comúns establecidos.
 
 ## Exemplos coñecidos
 
@@ -104,37 +104,37 @@ Tódalas contribucións (por exemplo, de código fonte, de documentación, de in
 
 ### Europace AG
 
-Os principios de InnerSource enumerados na sección de **Solución** baséanse, na súa meirande parte, na experiencia de Europace. Ver [máis](https://tech.europace.de/post/europace-inner-source-prinzipien/) (en alemán). 
+Os principios de InnerSource enumerados na sección de **Solución** baséanse, na súa meirande parte, na experiencia de Europace. Ver [máis](https://tech.europace.de/post/europace-inner-source-prinzipien/) (en alemán).
 
 ### GitHub
 
 #### Finalidade
 
-A miúdo en GitHub traballamos cun modelo no que os equipos aportan funcionalidades a áreas que están fóra do seu ámbito de competencia. Algúns exemplos comúns inclúen a enxeñaría de ventas que aporta funcionalidades para desbloquear unha venta, os proxectos especiais que contribúen cando é estritamente necesario, as funcionalidades de grande impacto en todo o produto e un equipo de traballo en múltiples áreas para entregar unha funcionalidade. 
+A miúdo en GitHub traballamos cun modelo no que os equipos aportan funcionalidades a áreas que están fóra do seu ámbito de competencia. Algúns exemplos comúns inclúen a enxeñaría de ventas que aporta funcionalidades para desbloquear unha venta, os proxectos especiais que contribúen cando é estritamente necesario, as funcionalidades de grande impacto en todo o produto e un equipo de traballo en múltiples áreas para entregar unha funcionalidade.
 
 #### Principios
 
-Polo xeral, os principios descritos neste documento son evitar o aumento da débeda tecnolóxica e a carga para o equipo propietario. A miúdo, préstase axuda a un equipo que quedou atrás por mor dos costes de soporte e mantemento na súa área de competencia e non ten ancho de banda para contribuír á funcionalidade. Calquera nova funcionalidade realizada por outro equipo que aumente a carga de soporte ou a débeda técnica supón aínda menos tempo para que o equipo propietario traballe nas novas funcionalidades, polo que queremos asegurarnos de que se fai ben. 
+Polo xeral, os principios descritos neste documento son evitar o aumento da débeda tecnolóxica e a carga para o equipo propietario. A miúdo, préstase axuda a un equipo que quedou atrás por mor dos costes de soporte e mantemento na súa área de competencia e non ten ancho de banda para contribuír á funcionalidade. Calquera nova funcionalidade realizada por outro equipo que aumente a carga de soporte ou a débeda técnica supón aínda menos tempo para que o equipo propietario traballe nas novas funcionalidades, polo que queremos asegurarnos de que se fai ben.
 
-Do mesmo xeito, esforzámonos por ser unha empresa na que os/as enxeñeiros/as traballen libremente máis aló das fronteiras e as prioridades empresariais que, a miúdo, esixen que contribuamos en áreas alleas ás nosas principais áreas de especialidade. 
+Do mesmo xeito, esforzámonos por ser unha empresa na que os/as enxeñeiros/as traballen libremente máis aló das fronteiras e as prioridades empresariais que, a miúdo, esixen que contribuamos en áreas alleas ás nosas principais áreas de especialidade.
 
-Un bo resumo dos principios é deixar a área en tan bo estado ou nun estado aínda mellor do que a atopou. 
+Un bo resumo dos principios é deixar a área en tan bo estado ou nun estado aínda mellor do que a atopou.
 
-Tendo isto en conta, velaquí os principios nos que estamos de acordo: 
+Tendo isto en conta, velaquí os principios nos que estamos de acordo:
 
-- Evite os produtos menos viables (MVP, polas súas siglas en inglés, Produto-Viable-Mínimo) que acumulan débeda de funcionalidades. Está ben lanzar un MVP para obter *retroalimentación* dos/as clientes/as, pero o equipo que contribúe debe comprometerse a rematar o conxunto de funcionalidades. Algúns exemplos son: 
-  - Compromiso de ir máis aló do MVP para chegar a unha solución que satisfaga á maioría dos/as clientes/as. 
-  - Soporte completo para a administración das novas funcionalidades (por exemplo, soporte na interface de usuario/a (IU)). 
-  - Presentar as funcionalidades tanto na IU como na API (polas súas siglas en inglés, Interface de Programación de Aplicacións). 
-  - Garantir que as funcionalidades responden en ambientes de servidores locais e na nube. 
-- Apoie o traballo das funcionalidades ata o seu despregamento para a produción e tras esta. 
+- Evite os produtos menos viables (MVP, polas súas siglas en inglés, Produto-Viable-Mínimo) que acumulan débeda de funcionalidades. Está ben lanzar un MVP para obter *retroalimentación* dos/as clientes/as, pero o equipo que contribúe debe comprometerse a rematar o conxunto de funcionalidades. Algúns exemplos son:
+  - Compromiso de ir máis aló do MVP para chegar a unha solución que satisfaga á maioría dos/as clientes/as.
+  - Soporte completo para a administración das novas funcionalidades (por exemplo, soporte na interface de usuario/a (IU)).
+  - Presentar as funcionalidades tanto na IU como na API (polas súas siglas en inglés, Interface de Programación de Aplicacións).
+  - Garantir que as funcionalidades responden en ambientes de servidores locais e na nube.
+- Apoie o traballo das funcionalidades ata o seu despregamento para a produción e tras esta.
   - Xestionar o despregamento progresivo.
   - Xestionar os tíckets de asistencia.
   - Planificar o tempo para responder aos comentarios dos/as clientes/as (funcionalidades e erros).
 - Crear funcionalidades do xeito correcto (sen acumular débeda tecnolóxica).
-  - Acordar os requisitos e a solución cos equipos de produto e de enxeñaría. 
+  - Acordar os requisitos e a solución cos equipos de produto e de enxeñaría.
   - Arquitectura e deseño axeitados.
-  - Asegúrese de que os datos se almacenan correctamente para evitar posteriores migracións de datos. 
+  - Asegúrese de que os datos se almacenan correctamente para evitar posteriores migracións de datos.
   - Implantar telemetría apropiada.
   - Soporte en ambientes de produción locais e na nube (incluídos a instalación, configuración e copia de seguridade/restauración, migracións etc.).
   - Erros reparados.
@@ -142,33 +142,33 @@ Tendo isto en conta, velaquí os principios nos que estamos de acordo:
 
 #### Compromiso
 
-Empregamos un modelo de compromiso porque nos gusta establecer que pasos concretos pode dar un equipo cando contribúe con funcionalidades a áreas fóra do seu ámbito de responsabilidade. 
+Empregamos un modelo de compromiso porque nos gusta establecer que pasos concretos pode dar un equipo cando contribúe con funcionalidades a áreas fóra do seu ámbito de responsabilidade.
 
-Un modelo de compromiso típico de GitHub é o seguinte: 
+Un modelo de compromiso típico de GitHub é o seguinte:
 
-- Obter a aprobación do conxunto de características e do plan de despregamento do/a *product owner*. 
+- Obter a aprobación do conxunto de características e do plan de despregamento do/a *product owner*.
 - Obter a aprobación do deseño da enxeñaría, incluído o cumprimento dos requisitos non funcionais (telemetría, cobertura de probas, ensaios e asistencia multiambientais) do/a propietario/a de enxeñaría (normalmente o/a enxeñeiro/a xefe/a e o/a director/a).
-- Facer revisións do código ao longo do proceso, así como revisión de requisitos novos ou modificados. 
+- Facer revisións do código ao longo do proceso, así como revisión de requisitos novos ou modificados.
 
 ### Robert Bosch GmbH
 
 #### Finalidade
 
-O principal obxectivo da iniciativa InnerSource de Bosch (BIOS) é fomentar a colaboración, a aprendizaxe e a innovación. 
+O principal obxectivo da iniciativa InnerSource de Bosch (BIOS) é fomentar a colaboración, a aprendizaxe e a innovación.
 
 #### Principios
 
-Para isto, Bosch aplica os seguintes principios: 
+Para isto, Bosch aplica os seguintes principios:
 
-- **Apertura:** Reducimos ao máximo as barreiras de entrada ás comunidades BIOS. 
-- **Transparencia:** Somos radicalmente transparentes, compartimos o traballo realizado e comunicámonos na toma de decisións tendo en conta a tódolos/as socios/as da empresa. 
-- **Carácter voluntario:** A decisión de unirse e contribuír a unha comunidade BIOS corresponde a cada socio/a. Os/As socios/as deben traballar na BIOS por mor da súa motivación intrínseca, non porque o persoal directivo llo pedise. 
-- **Autodeterminación:** As comunidades BIOS son libres de elixir en que traballar, cando traballar e que ferramentas e procesos empregar. 
-- **Meritocracia:** O poder conferido aos membros do proxecto BIOS vén dado en función dos seus méritos, é dicir, en función da calidade e da cantidade de contribucións. 
+- **Apertura:** Reducimos ao máximo as barreiras de entrada ás comunidades BIOS.
+- **Transparencia:** Somos radicalmente transparentes, compartimos o traballo realizado e comunicámonos na toma de decisións tendo en conta a tódolos/as socios/as da empresa.
+- **Carácter voluntario:** A decisión de unirse e contribuír a unha comunidade BIOS corresponde a cada socio/a. Os/As socios/as deben traballar na BIOS por mor da súa motivación intrínseca, non porque o persoal directivo llo pedise.
+- **Autodeterminación:** As comunidades BIOS son libres de elixir en que traballar, cando traballar e que ferramentas e procesos empregar.
+- **Meritocracia:** O poder conferido aos membros do proxecto BIOS vén dado en función dos seus méritos, é dicir, en función da calidade e da cantidade de contribucións.
 
 ![Os principios BIOS](../../../assets/img/gl/bios-principles.png)
 
-Os principios de *apertura*, *transparencia* e *carácter voluntario* axudaron a crear comunidades diversas de traballadores/as cunha motivación intrínseca. A *meritocracia* amosou ser unha motivación eficaz para realizar grandes contribucións. E a *autodeterminación* permitiu ás comunidades empregar o seu tempo limitado para facer contribucións dunha maneira máis eficaz e eficiente. 
+Os principios de *apertura*, *transparencia* e *carácter voluntario* axudaron a crear comunidades diversas de traballadores/as cunha motivación intrínseca. A *meritocracia* amosou ser unha motivación eficaz para realizar grandes contribucións. E a *autodeterminación* permitiu ás comunidades empregar o seu tempo limitado para facer contribucións dunha maneira máis eficaz e eficiente.
 
 ## Estado
 
@@ -181,7 +181,7 @@ Os principios de *apertura*, *transparencia* e *carácter voluntario* axudaron a
 
 ## Recoñecementos
 
-- Zack Koppert, por compartir o enfoque de GitHub nos exemplos coñecidos. 
+- Zack Koppert, por compartir o enfoque de GitHub nos exemplos coñecidos.
 
 ## Título alternativo
 
@@ -190,4 +190,4 @@ Principios explícitos InnerSource
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/extensions-for-sustainable-growth.md b/translation/gl/patterns/extensions-for-sustainable-growth.md
index 5efe16e87..bb6c7180f 100644
--- a/translation/gl/patterns/extensions-for-sustainable-growth.md
+++ b/translation/gl/patterns/extensions-for-sustainable-growth.md
@@ -38,7 +38,7 @@ Dedícase moito tempo a madurar cada nova funcionalidade engadida, antes de que
 - A organización inverte considerablemente no fortalecemento das contribucións de novas funcionalidades para manter os estándares de calidade, mesmo antes de que esas ideas sexan exploradas pola comunidade.
 - O modelo aplícase en calquera escenario:
   - Os/As mantedores/as teñen que rexeitar ideas de novas funcionalidades para limitar o alcance do proxecto. Isto está a dificultar a innovación na comunidade e a restrinxir unha expansión maior.
-  - Para reducir as acumulacións, lánzanse novas funcionalidades sen documentación, fortalecemento ou probas exhaustivas; o que xera unha experiencia de usuario/a deficiente. Ademais, isto está a aumentar o tamaño da base de código, un grande engadido no gráfico de dependencia que dificulta o seu mantemento. 
+  - Para reducir as acumulacións, lánzanse novas funcionalidades sen documentación, fortalecemento ou probas exhaustivas; o que xera unha experiencia de usuario/a deficiente. Ademais, isto está a aumentar o tamaño da base de código, un grande engadido no gráfico de dependencia que dificulta o seu mantemento.
 
 ## Aspectos que mellorar
 
@@ -67,7 +67,7 @@ Para que o modelo de extensións teña éxito, haberá que ter en conta algunhas
    - **Probar a extensión en combinación co repositorio primario:** Os/As desenvolvedores/as de extensións teñen un método ben establecido para probar a súa extensión fronte a versións específicas do repositorio primario sen a implicación dos/as mantedores/as do devandito repositorio.
    - **Probar a extensión en combinación con outras extensións:** Proporcionar un marco de proba para este escenario podería resultar excesivo, especialmente se hai un gran número de extensións que aínda están explorando os/as usuarios/as e é improbable que se empreguen todas de xeito combinado. Se un/unha usuario/a se atopa con conflitos ao usar extensións combinadas (o que debería ser improbable cunha baixa dependencia), pode informar dunha incidencia aos/ás respectivos/as *extension owners* para que o resolvan. A medida que unha extensión acade as derradeiras fases do seu ciclo de vida e se integre co repositorio primario, pasará probas combinadas co resto da libraría e calquera incidencia posible resolveríase nese intre.
 5. **Dispoñibilidade e utilización:**
-   - É necesario que os/as usuarios/as que crearon as extensións as mostren nunha páxina de publicación, co fin de compartilas de maneira sinxela para o seu uso. 
+   - É necesario que os/as usuarios/as que crearon as extensións as mostren nunha páxina de publicación, co fin de compartilas de maneira sinxela para o seu uso.
    - Será preciso permitir o rexistro de extensións co proxecto primario, para que os/as usuarios/as poidan valerse das extensións xunto co proxecto orixinal, mantendo así a mesma experiencia de usuario/a.
 6. **Ciclo de vida das extensións e o seu mantemento:** Débese establecer o ciclo de vida das extensións desde a súa creación ata a súa portabilidade á base de código primario, xunto con directrices de propiedade claras.
    - Os/As creadores/as de extensións teñen que continuar o seu mantemento, proporcionar asistencia e corrixir as fallas. Calquera extensión sen mantemento será eliminada da páxina de publicación.
@@ -114,4 +114,4 @@ Extensións para xestionar contribucións a escala
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/gig-marketplace.md b/translation/gl/patterns/gig-marketplace.md
index 5634bc211..c50a15a3b 100644
--- a/translation/gl/patterns/gig-marketplace.md
+++ b/translation/gl/patterns/gig-marketplace.md
@@ -75,4 +75,4 @@ Cando se usa en combinación co modelo do portal InnerSource, o *Gig marketplace
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/group-support.md b/translation/gl/patterns/group-support.md
index 3d802b228..7b5e3bde7 100644
--- a/translation/gl/patterns/group-support.md
+++ b/translation/gl/patterns/group-support.md
@@ -34,10 +34,10 @@ Convocar voluntarios/as interesados/as de calquera sector da compañía para for
 
 Ao formarse, este grupo debería identificar ou constituír unha [documentación base estándar](./base-documentation.md) e [ferramentas de comunicación](.communication-tooling.md).
 
-O grupo fará o posible para xestionar estes aspectos do proxecto: 
+O grupo fará o posible para xestionar estes aspectos do proxecto:
 
 * **Mantemento**. Se o proxecto está totalmente roto para o caso de uso estándar, haberá que arranxalo. É preciso manter o proxecto actualizado a medida que as dependencias e os marcos que usa seguen a desenvolverse.
-* **Incorporación**. Se alguén ten unha pregunta sobre como empregar o proxecto, haberá que asegurarse de que obtén unha resposta razoable. 
+* **Incorporación**. Se alguén ten unha pregunta sobre como empregar o proxecto, haberá que asegurarse de que obtén unha resposta razoable.
 * **Actualizacións**. Se alguén quere engadir novas funcionalidades ao proxecto, proporcionaráselle o deseño e soporte técnico precisos para a súa contribución, de xeito que sexa tanto bo para eles/as como para o proxecto. As *pull requests* entrantes revisaranse de maneira oportuna.
 
 Posto que o grupo está formado por voluntarios/as, é importante comunicar que o soporte é só o seu «mellor esforzo». E, en consecuencia, este modelo de soporte non é adecuado para proxectos de produción críticos en tempo de execución como as *live* API. Será máis axeitado para proxectos que se consomen no tempo de compilación, como librarías/paquetes/módulos. Non se espera que o grupo introduza ningunha funcionalidade nova para outros.
@@ -66,4 +66,4 @@ A xente xeralmente estará disposta a axudar. Se alguén quere converterse en [*
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/innersource-license.md b/translation/gl/patterns/innersource-license.md
index ea2f426a7..2e49e6f75 100644
--- a/translation/gl/patterns/innersource-license.md
+++ b/translation/gl/patterns/innersource-license.md
@@ -90,4 +90,4 @@ Paga a pena mencionar que, ata agora, o software compartido baixo esta licenza I
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/issue-tracker.md b/translation/gl/patterns/issue-tracker.md
index 2ad703047..f605d6b23 100644
--- a/translation/gl/patterns/issue-tracker.md
+++ b/translation/gl/patterns/issue-tracker.md
@@ -54,4 +54,4 @@ Adopte a filosofía «o escrito prevalece sobre a palabra», non só para o dese
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/maturity-model.md b/translation/gl/patterns/maturity-model.md
index e356b3895..420cc3423 100644
--- a/translation/gl/patterns/maturity-model.md
+++ b/translation/gl/patterns/maturity-model.md
@@ -34,7 +34,7 @@ O proxecto InnerSource benefíciase de que a planificación sexa transparente en
 
 * PP-0: Os individuos e os equipos non divulgan regularmente os seus plans ou produtos a múltiples partes interesadas. Non existen accións formais na organización.
 * PP-1: Os individuos e equipos dan visibilidade aos seus plans ou produtos a múltiples partes interesadas antes de comezar. Folla de ruta compartida.
-* PP-2: Xa hai follas de ruta compartidas con directrices claras e regras de contribución nas que os/as interesados/as poden aportar retroalimentación. Non obstante, isto non está estandarizado en toda a organización e non tódolos proxectos proporcionan esta información. 
+* PP-2: Xa hai follas de ruta compartidas con directrices claras e regras de contribución nas que os/as interesados/as poden aportar retroalimentación. Non obstante, isto non está estandarizado en toda a organización e non tódolos proxectos proporcionan esta información.
 * PP-3: As follas de ruta compártense por defecto e hai un proceso estándar e unha forma homoxénea de facelo en toda a organización a nivel de cada proxecto InnerSource. Esta contén regras claras para contribuír e influír na folla de ruta.
 
 **Proceso de desenvolvemento e ferramentas**
@@ -44,7 +44,7 @@ Os proxectos InnerSource prosperan cando os/as contribuidores/as se volven activ
 * DP-0: Cada equipo segue o seu propio proceso de desenvolvemento e ferramentas. Non están definidos para compartir coñecementos e dispositivos fóra do equipo de desenvolvemento. Equipos de desenvolvemento en silos.
 * DP-1: Os equipos de desenvolvemento usan repositorios de código compartido internamente. Algúns equipos desenvolven o seu propio proceso de CI, utilizando ferramentas de CI non corporativas ou estándar. Non hai un proceso de revisión de código definido, aínda que algúns equipos de proxectos fano internamente.
 * DP-2: A organización patrocina e promove un repositorio compartido para o coñecemento colectivo. Algúns equipos desenvolven o seu propio proceso de CI, usando ferramentas de CI corporativas. Hai ambientes CI, así como un proceso de revisión do código definido que se emprega nalgúns proxectos. Ás veces, a revisión do código é realizada por membros externos do equipo.
-* DP-3: A meirande parte dos equipos desenvolven o seu propio proceso de CI, utilizando ferramentas de CI corporativas. Existen ambientes CI, así como un proceso de revisión do código definido e utilizado. A revisión do código realízana os membros do equipo interno e externo. 
+* DP-3: A meirande parte dos equipos desenvolven o seu propio proceso de CI, utilizando ferramentas de CI corporativas. Existen ambientes CI, así como un proceso de revisión do código definido e utilizado. A revisión do código realízana os membros do equipo interno e externo.
 
 **Decisións**
 
@@ -60,7 +60,7 @@ Para motivar aos/ás compañeiros/as a contribuír ao traballo fóra do seu *cor
 Para atraer contribuidores/as, o material útil de soporte debe ser facilmente accesible.
 
 * RS-0: Individuos e equipos non contribúen nin recorren a un repositorio de coñecemento compartido.
-* RS-1: Individuos e equipos liberan materiais do proxecto para a súa revisión interna, despois de rematar o seu traballo. Individuos e equipos comparten recursos, pero en sistemas ou repositorios desconectados, fragmentados ou individualizados/en silos. Individuos e equipos comparten recursos, pero non existe unha comprensión común ou compartida dos criterios utilizados para determinar se a información é sensible ou non. 
+* RS-1: Individuos e equipos liberan materiais do proxecto para a súa revisión interna, despois de rematar o seu traballo. Individuos e equipos comparten recursos, pero en sistemas ou repositorios desconectados, fragmentados ou individualizados/en silos. Individuos e equipos comparten recursos, pero non existe unha comprensión común ou compartida dos criterios utilizados para determinar se a información é sensible ou non.
 * RS-2: Individuos e equipos fan que os materiais relacionados co proxecto sexan accesibles a algúns membros dos equipos do proxecto segundo formatos e/ou protocolos compartidos claramente definidos. Individuos e equipos manteñen datos e recursos confidenciais e proporcionan detalles, contexto e alcance limitados.
 * RS-3: Individuos e equipos fan que os materiais relacionados co proxecto sexan amplamente accesibles para a organización e, posiblemente, tamén fóra dela, segundo formatos e/ou protocolos claramente definidos e compartidos. Os individuos e equipos que deben reter datos e recursos confidenciais teñen claro o que non están a compartir, e outros entenden por que eses materiais non están dispoñibles para eles/as.
 
@@ -131,7 +131,7 @@ Unha das posibles razóns para introducir InnerSource nas organizacións pode se
 * PA-0: Baixo grao de compromiso, sen colaboración a xente non se sente cómoda compartindo cos/coas demais.
 * PA-1: Os membros da organización séntense cómodos compartindo as súas opinións sen medo a represalias, pero só en ámbitos coñecidos. A xente entende que as mellores ideas gañan e as responsabilidades de liderado recaen en persoas cun historial de contribución e compromiso.
 * PA-2: Os membros da organización séntense cómodos compartindo os seus pensamentos e opinións sen medo a represalias. Os/As líderes demostran dedicación aos valores compartidos da organización.
-* PA-3: A empresa é proactiva á hora de facerlles saber aos membros que se beneficia das súas contribucións; como tal, os membros amosan ter unha conciencia compartida e unha execución apoderada, e senten un sentido de responsabilidade coa comunidade. Os/As líderes entenden que crecen axudando a outros/as a crecer e son mentores/as dos membros máis novos da organización. 
+* PA-3: A empresa é proactiva á hora de facerlles saber aos membros que se beneficia das súas contribucións; como tal, os membros amosan ter unha conciencia compartida e unha execución apoderada, e senten un sentido de responsabilidade coa comunidade. Os/As líderes entenden que crecen axudando a outros/as a crecer e son mentores/as dos membros máis novos da organización.
 
 ### Gobernación
 
diff --git a/translation/gl/patterns/praise-participants.md b/translation/gl/patterns/praise-participants.md
index ec023ba70..e4fa3046c 100644
--- a/translation/gl/patterns/praise-participants.md
+++ b/translation/gl/patterns/praise-participants.md
@@ -69,4 +69,4 @@ Como advertencia: é necesario mantelo crible. Asegúrese de que as súas palabr
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/repository-activity-score.md b/translation/gl/patterns/repository-activity-score.md
index 33f6ff4fe..97775291f 100644
--- a/translation/gl/patterns/repository-activity-score.md
+++ b/translation/gl/patterns/repository-activity-score.md
@@ -124,7 +124,7 @@ A cualificación da actividade do repositorio é un cálculo sinxelo baseado na
 
 ## Recoñecementos
 
-Grazas á comunidade InnerSource Commons polos consellos rápidos como un lóstrego e moitas aportacións útiles para alimentar este modelo. Especialmente: 
+Grazas á comunidade InnerSource Commons polos consellos rápidos como un lóstrego e moitas aportacións útiles para alimentar este modelo. Especialmente:
 
 * Johannes Tigges
 * Sebastian Spier
@@ -134,4 +134,4 @@ Grazas á comunidade InnerSource Commons polos consellos rápidos como un lóstr
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/review-committee.md b/translation/gl/patterns/review-committee.md
index 94bdc7218..993978f6e 100644
--- a/translation/gl/patterns/review-committee.md
+++ b/translation/gl/patterns/review-committee.md
@@ -59,4 +59,4 @@ A empresa A quere presentar a súa primeira iniciativa InnerSource. A meirande p
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/service-vs-library.md b/translation/gl/patterns/service-vs-library.md
index 20fecbd31..a9d27ad05 100644
--- a/translation/gl/patterns/service-vs-library.md
+++ b/translation/gl/patterns/service-vs-library.md
@@ -54,7 +54,7 @@ Este modelo está relacionado co de [garantía de 30 días](./30-day-warranty.md
 ## Exemplos coñecidos
 
 - Europace AG
-- Flutter Entertainment: A[ aplicación Flutter InnerSource ](https://innersource.flutter.com/docs/)ten un repositorio de «servizo» de código compartido para as contribucións entre equipos e o fluxo de traballo da CI co fin de crear e publicar un dispositivo de lanzamento compartido. Cada equipo ten un repositorio de «configuración de uso» que define a súa propia implantación. Isto débese a requisitos normativos cambiantes que impulsaron diferentes requisitos normativos, prácticas de xestión de servizos e incidencias e conxuntos de habilidades de infraestrutura en diferentes áreas de negocio. 
+- Flutter Entertainment: A[aplicación Flutter InnerSource](https://innersource.flutter.com/docs/)ten un repositorio de «servizo» de código compartido para as contribucións entre equipos e o fluxo de traballo da CI co fin de crear e publicar un dispositivo de lanzamento compartido. Cada equipo ten un repositorio de «configuración de uso» que define a súa propia implantación. Isto débese a requisitos normativos cambiantes que impulsaron diferentes requisitos normativos, prácticas de xestión de servizos e incidencias e conxuntos de habilidades de infraestrutura en diferentes áreas de negocio.
 
 ## Estado
 
diff --git a/translation/gl/patterns/start-as-experiment.md b/translation/gl/patterns/start-as-experiment.md
index 6fa0055b3..5a69accf0 100644
--- a/translation/gl/patterns/start-as-experiment.md
+++ b/translation/gl/patterns/start-as-experiment.md
@@ -76,4 +76,4 @@ Finalmente, comezar cunha práctica a modo experimento, fai que sexa moito máis
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md b/translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md
index 8da27c4ff..c9cea0d6f 100644
--- a/translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md
+++ b/translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md
@@ -93,7 +93,7 @@ Por outra banda, en canto á toma de decisións fóra das puras decisións de de
 
 ## Exemplos coñecidos
 
-- **BBC iPlayer & Sounds**: Tal como se presentou no cume de outono de 2020 de ISC, [*Using Internal RFCs to Enhance Collaboration*](https://www.youtube.com/watch?v=U6zlghE0HcE) [O uso de RFC para promover a colaboración]. 
+- **BBC iPlayer & Sounds**: Tal como se presentou no cume de outono de 2020 de ISC, [*Using Internal RFCs to Enhance Collaboration*](https://www.youtube.com/watch?v=U6zlghE0HcE) [O uso de RFC para promover a colaboración].
 - **Europace:** Como se describe en Open Organization: [*Setting cross-team standards and best practices in the open*](https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm-remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open) [Establecemento de estándares entre equipos e mellores prácticas no marco de decisións aberto].
 - **Uber:** Segundo esta publicación de blog de Gergely Orosz: [*Scaling Engineering Teams via RFCs: Writing Things Down*](https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/) [A escalada dos equipos de enxeñaría mediante RFC].
 - **Google Design Docs:** Como se describe na publicación de blog de Malte Ubl: [Design Docs at Google](https://www.industrialempathy.com/posts/design-docs-at-google/)[](https://www.industrialempathy.com/posts/design-docs-at-google/).
@@ -116,4 +116,4 @@ Por outra banda, en canto á toma de decisións fóra das puras decisións de de
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/patterns/trusted-committer.md b/translation/gl/patterns/trusted-committer.md
index 3c99f3e5e..61aea9b64 100644
--- a/translation/gl/patterns/trusted-committer.md
+++ b/translation/gl/patterns/trusted-committer.md
@@ -9,7 +9,7 @@ Nestas situacións, as persoas encargadas do mantemento do proxecto buscan forma
 
 ## Problema
 
-- As persoas encargadas do mantemento de proxectos queren atopar xeitos de incrementar a súa capacidade para brindar apoio a un proxecto. 
+- As persoas encargadas do mantemento de proxectos queren atopar xeitos de incrementar a súa capacidade para brindar apoio a un proxecto.
 - As persoas encargadas do mantemento de proxectos queren atopar xeitos de prolongar o valor que aportou o proxecto.
 - As persoas encargadas do mantemento de proxectos queren recompensar visiblemente aos/ás contribuidores/as frecuentes e capacitalos/as para que melloren o valor das contribucións.
 - Falla de mecanismos e linguaxe para recoñecer as contribucións que levaban a cabo os equipos dunha organización.
@@ -125,4 +125,4 @@ Esta iniciativa foi levada a cabo con éxito en:
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
\ No newline at end of file
+- María Lucía González Castro
diff --git a/translation/gl/templates/CONTRIBUTING-template.md b/translation/gl/templates/CONTRIBUTING-template.md
index 567dc1e05..50b1daaab 100644
--- a/translation/gl/templates/CONTRIBUTING-template.md
+++ b/translation/gl/templates/CONTRIBUTING-template.md
@@ -2,7 +2,7 @@
 
 ## Tipos de contribucións
 
-Nesta sección proporcione información sobre o tipo de contribucións que está a procurar o seu proxecto. Por exemplo, poden ser informes de erros, axuda para responder preguntas dos/as usuarios/as, melloras da documentación, corrixir erros e a posta en marcha de funcionalidades. 
+Nesta sección proporcione información sobre o tipo de contribucións que está a procurar o seu proxecto. Por exemplo, poden ser informes de erros, axuda para responder preguntas dos/as usuarios/as, melloras da documentación, corrixir erros e a posta en marcha de funcionalidades.
 
 ## Informes de erros
 
diff --git a/translation/gl/templates/README-template.md b/translation/gl/templates/README-template.md
index 284c47c9d..2bc1da0d6 100644
--- a/translation/gl/templates/README-template.md
+++ b/translation/gl/templates/README-template.md
@@ -25,7 +25,7 @@ Esta sección debe conter unha breve documentación sobre a maneira de obter axu
 
 ## Familiarización
 
-Esta sección debe incluír información breve sobre como entrar en contacto co proxecto; polo xeral, este apartado contén as ligazóns ás canles de comunicación arquivadas e de busca. 
+Esta sección debe incluír información breve sobre como entrar en contacto co proxecto; polo xeral, este apartado contén as ligazóns ás canles de comunicación arquivadas e de busca.
 
 ## Quen somos
 
@@ -38,7 +38,7 @@ Tamén é a sección na que incluír información sobre o que significa ser un/u
 Nesta sección debe documentar (ou incluír unha ligazón á documentación) aqueles aspectos que calquera novo/a contribuidor/a precisa saber para comezar. Polo xeral, non se cubrirán tódolos temas seguintes. Céntrese naquilo que difire no seu proxecto respecto da configuración estándar, así como naquilo que lles resultou difícil de entender aos/ás contribuidores/as anteriores.
 
 - Atopar o código fonte.
-- Atopar unha listaxe de incidencias coas que o seu proxecto precisa axuda que pode ser técnica ou non. Polo xeral, os/as contribuidores/as poden acceder a través dun sistema de seguimento de incidencias. 
+- Atopar unha listaxe de incidencias coas que o seu proxecto precisa axuda que pode ser técnica ou non. Polo xeral, os/as contribuidores/as poden acceder a través dun sistema de seguimento de incidencias.
 - Ligazóns á documentación adicional, por exemplo, sobre a arquitectura do proxecto, convencións xerais de codificación, convencións de proba...
 - Para contribucións técnicas: Facer cambios, construír o proxecto e probar os cambios.
 - Enviar os cambios ao proxecto.