More formatting fixes

translation/gl/patterns/30-day-warranty.md

@@ -4,35 +4,35 @@ Garantía de 30 días
 
 ## Patlet
 
-Cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos equipos e fará que sexa máis probable que se acepten as contribucións. 
+Cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos equipos e fará que sexa máis probable que se acepten as contribucións.
 
 ## Problema
 
-Un equipo desenvolve un compoñente que se emprega na organización e resístese a aceptar ou directamente rexeita as contribucións (*feature requests*). Este comportamento bloquea o progreso e xera frecuentes interrupcións a causa das escaladas. 
+Un equipo desenvolve un compoñente que se emprega na organización e resístese a aceptar ou directamente rexeita as contribucións (*feature requests*). Este comportamento bloquea o progreso e xera frecuentes interrupcións a causa das escaladas.
 
 ## Contexto
 
 - Os equipos dependen de que outro equipo acepte as súas contribucións para que o compoñente producido polo equipo receptor poida ser empregado polo equipo contribuidor.
-- O equipo receptor non dispón dos recursos, dos coñecementos, dos permisos ou da disposición necesaria para escribir, por si mesmo, o compoñente/funcionalidade aportado/a. 
+- O equipo receptor non dispón dos recursos, dos coñecementos, dos permisos ou da disposición necesaria para escribir, por si mesmo, o compoñente/funcionalidade aportado/a.
 
 ## Aspectos que mellorar
 
-- Desconfíase das contribucións a causa dun pasado de enganos: os equipos enviaban contribucións que non estaban rematadas e, posteriormente, presentaban peticións de correccións que as deixaban listas para o seu uso en produción. 
-- Se se aporta código externo, o equipo receptor pode albergar a sospeita natural de que o outro equipo non saiba escribir un código que satisfaga as súas expectativas. 
-- Cada equipo tenta axudar primeiro a que os/as seus/súas propios/as líderes acaden as súas propias metas. Esta lealdade cara a directiva pode complicar a resolución deste problema. 
-- Naturalmente, existe un rexeitamento a responsabilizarse do código que non foi escrito por un/unha mesmo/a. 
+- Desconfíase das contribucións a causa dun pasado de enganos: os equipos enviaban contribucións que non estaban rematadas e, posteriormente, presentaban peticións de correccións que as deixaban listas para o seu uso en produción.
+- Se se aporta código externo, o equipo receptor pode albergar a sospeita natural de que o outro equipo non saiba escribir un código que satisfaga as súas expectativas.
+- Cada equipo tenta axudar primeiro a que os/as seus/súas propios/as líderes acaden as súas propias metas. Esta lealdade cara a directiva pode complicar a resolución deste problema.
+- Naturalmente, existe un rexeitamento a responsabilizarse do código que non foi escrito por un/unha mesmo/a.
 - As contribucións de código deben reescribirse a fondo antes de ser aceptadas na base de código.
-- Témese que os/as contribuidores/as non estean dispoñibles para recibir asistencia coa corrección de erros unha vez transcorrido o tempo da contribución. 
-- Os equipos temen que as contribucións de código xeren custos de mantemento elevados, pero non saben como controlalo. 
-- Os equipos receptores poden temer que, ensinar a outras persoas a contribuír co código, expoña unha débeda técnica no seu sistema e que a visibilidade poida ser prexudicial. 
-- É posible que os equipos receptores non crean que obterán un código aceptable por moito asesoramento que brinden. 
-- Calquera dos equipos pode sentirse inseguro á hora de medir os riscos ou certificar que están mitigados nunha contribución; o sistema en si é algo fráxil (pode que non haxa maneiras de probalo completamente e detectar tódolos problemas). 
+- Témese que os/as contribuidores/as non estean dispoñibles para recibir asistencia coa corrección de erros unha vez transcorrido o tempo da contribución.
+- Os equipos temen que as contribucións de código xeren custos de mantemento elevados, pero non saben como controlalo.
+- Os equipos receptores poden temer que, ensinar a outras persoas a contribuír co código, expoña unha débeda técnica no seu sistema e que a visibilidade poida ser prexudicial.
+- É posible que os equipos receptores non crean que obterán un código aceptable por moito asesoramento que brinden.
+- Calquera dos equipos pode sentirse inseguro á hora de medir os riscos ou certificar que están mitigados nunha contribución; o sistema en si é algo fráxil (pode que non haxa maneiras de probalo completamente e detectar tódolos problemas).
 
 ## Solución
 
 Aborde os temores dos equipos receptores e contribuidores establecendo un período de garantía de 30 días, a partir do momento no que a contribución de código entra na fase de produción. Durante este período de garantía, o equipo contribuidor comprométese a proporcionar correccións de erros ao equipo receptor.
 
-Teña en conta que o período de garantía tamén pode chegar a ser de 45, 60 ou 100 días. A duración pode variar en función das limitacións do proxecto, o ciclo de vida do software do proxecto ou os compromisos cos/coas clientes/as, entre outros factores. 
+Teña en conta que o período de garantía tamén pode chegar a ser de 45, 60 ou 100 días. A duración pode variar en función das limitacións do proxecto, o ciclo de vida do software do proxecto ou os compromisos cos/coas clientes/as, entre outros factores.
 
 Ademais, axuda a proporcionar [directrices de contribución](./base-documentation.md) claras, concretando as expectativas do equipo receptor e o equipo contribuidor.
 
@@ -42,13 +42,13 @@ Ademais, axuda a proporcionar [directrices de contribución](./base-documentatio
 
 - O equipo receptor está disposto a aceptar contribucións e pode compartir a carga de traballo das adaptacións/reparacións iniciais.
 - Maior transparencia e equidade.
-- Evita que as escaladas se volvan demasiado pesadas. 
+- Evita que as escaladas se volvan demasiado pesadas.
 
 ## Exemplos coñecidos
 
 - Isto foi probado con éxito en PayPal.
-- GitHub emprega internamente este modelo cun prazo de garantía modificado de 6 semanas. 
-- Microsoft recomenda este modelo coma un principio: os equipos establecen o seu propio obxectivo temporal específico en función das súas necesidades e confianza. 
+- GitHub emprega internamente este modelo cun prazo de garantía modificado de 6 semanas.
+- Microsoft recomenda este modelo coma un principio: os equipos establecen o seu propio obxectivo temporal específico en función das súas necesidades e confianza.
 
 ## Autoría
 
@@ -64,7 +64,7 @@ Ademais, axuda a proporcionar [directrices de contribución](./base-documentatio
 ## Estado
 
 * Estruturado
-* Redactado no Cume InnerSource de primavera de 2017; revisado o 18 de xuño de 2017. 
+* Redactado no Cume InnerSource de primavera de 2017; revisado o 18 de xuño de 2017.
 
 ## Variantes
 
@@ -73,4 +73,4 @@ Ademais, axuda a proporcionar [directrices de contribución](./base-documentatio
 ## Tradución
 
 - Leticia Gómez Cadahía
-- María Lucía González Castro
+- María Lucía González Castro