fix translation inconsistencies and improve clarity in Spanish documentation

Author: ovas04

book/es/toc.md

@@ -39,7 +39,7 @@ Instead edit toc_template.md
 * [Reconocimiento a los Participantes](../../translation/es/patterns/praise-participants.md) - Cuando recibes una contribución InnerSource, es importante agradecer al contribuidor por su tiempo y esfuerzo. Extender tu gratitud no solo reconoce efectivamente la contribución sino que también genera mayor compromiso del contribuidor y otros. Reconocer las contribuciones positivas de los contribuidores a tu proyecto InnerSource motiva a estos contribuidores (y sus gerentes) a continuar invirtiendo en el esfuerzo.
 * [Requerimientos Comunes](../../translation/es/patterns/common-requirements.md) - El código común en un repositorio compartido no satisface las necesidades de todos los equipos de proyecto que desean utilizarlo; esto se resuelve mediante la alineación de requerimientos y la refactorización.
 * [Servicio vs Librería](../../translation/es/patterns/service-vs-library.md) - Los equipos en un entorno DevOps pueden mostrarse reacios a trabajar a través de los límites del equipo en bases de código comunes debido a la ambigüedad sobre quién será responsable de responder ante la interrupción del servicio. La solución es comprender que a menudo es posible implementar el mismo servicio en entornos independientes con cadenas de escalamiento separadas en caso de interrupciones del servicio, o bien extraer gran parte del código compartido en una librería y colaborar en ella.
-* [Soporte Grupal](../../translation/es/patterns/group-support.md) - ¿Qué sucede si un equipo o individuo deja de mantener un proyecto InnerSource? Mantén el proyecto activo formando un grupo de personas interesadas.
+* [Grupo de Soporte](../../translation/es/patterns/group-support.md) - ¿Qué sucede si un equipo o individuo deja de mantener un proyecto InnerSource? Mantén el proyecto activo formando un grupo de personas interesadas.
 * [Toma de Decisiones Transparente Entre Equipos usando RFCs](../../translation/es/patterns/transparent-cross-team-decision-making-using-rfcs.md) - Los proyectos InnerSource que buscan alcanzar altas tasas de participación y tomar las mejores decisiones posibles para todos los involucrados necesitan encontrar formas de crear sistemas participativos a lo largo de todo el ciclo de vida del software. La publicación de documentos internos de Solicitud de Comentarios (RFC) permite discusiones desde el inicio del proceso de diseño y aumenta las probabilidades de construir soluciones con un alto grado de compromiso de todas las partes involucradas.
 * [Trusted Committer](../../translation/es/patterns/trusted-committer.md) - Muchos proyectos InnerSource se encontrarán en una situación donde reciben constantemente retroalimentación, funcionalidades y correcciones de errores de los contribuidores. En estas situaciones, los mantenedores del proyecto buscan formas de reconocer y recompensar el trabajo del contribuidor más allá de las contribuciones individuales.
 * [Valoración de Proyectos Cross-Team](../../translation/es/patterns/crossteam-project-valuation.md) - Es difícil vender el valor de los proyectos InnerSource cross-team que no proporcionan un impacto directo en los ingresos de la empresa. Aquí hay una forma basada en datos para representar tu proyecto que articula y amplifica su valor.

translation/es/patterns/contracted-contributor.md

@@ -8,14 +8,14 @@ Los colaboradores que desean contribuir a InnerSource son desalentados por su ge
 
 ## Problema
 
-Sin el apoyo de la gerencia media, la cantidad de colaboradores y, en consecuencia, el número de contribuciones y el valor generado por la iniciativa InnerSource probablemente estarán por debajo de las expectativas de la alta dirección. Esto probablemente podría agravarse si no hay financiamiento adecuado y empoderamiento de los [Dedicated Community Leaders](dedicated-community-leader.md). Esto corre el riesgo de que la alta dirección abandone la idea de InnerSource.
+Sin el apoyo de la gerencia media, la cantidad de colaboradores y, en consecuencia, el número de contribuciones y el valor generado por la iniciativa InnerSource probablemente estarán por debajo de las expectativas de la alta dirección. Esto probablemente podría agravarse si no hay financiamiento adecuado y empoderamiento de los [Líder de Comunidad Dedicados](dedicated-community-leader.md). Esto corre el riesgo de que la alta dirección abandone la idea de InnerSource.
 
 ## Contexto
 
 Una gran corporación ha iniciado una iniciativa InnerSource. Los objetivos principales de la iniciativa son aumentar la eficiencia del desarrollo de software distribuido y fomentar la innovación permitiendo que cada colaborador contribuya voluntariamente a proyectos InnerSource, independientemente del tema y la unidad de negocio.
 
 La alta dirección está a bordo y apoyando la iniciativa InnerSource. Para ellos, la iniciativa InnerSource es solo una de las muchas iniciativas para fomentar la innovación y la eficiencia.
-Están financiando InnerSource con dinero y capacidad para líderes comunitarios y están dando gran autonomía en cuanto a cómo se gasta el presupuesto. También están limitando el alcance y la duración de la iniciativa y participan en revisiones periódicas hasta que haya pruebas de que produce los resultados esperados (ver [Review Committee](review-committee.md)).
+Están financiando InnerSource con dinero y capacidad para líderes comunitarios y están dando gran autonomía en cuanto a cómo se gasta el presupuesto. También están limitando el alcance y la duración de la iniciativa y participan en revisiones periódicas hasta que haya pruebas de que produce los resultados esperados (ver [Comité de Revisión](review-committee.md)).
 La alta dirección ha anunciado su apoyo a InnerSource en varias reuniones internas de la empresa.
 
 Sin embargo, la alta dirección aún no ha empoderado ni incentivado a los gerentes de nivel medio para permitir o incluso motivar a sus empleados a participar en actividades de InnerSource interdivisionales. Además de eso, la capacidad de cada colaborador generalmente se asigna a proyectos que no son de InnerSource para el 100 % de su tiempo de trabajo. La colaboración interorganizacional aún no es la norma y los gerentes de línea generalmente no tienen objetivos fuera de su propia organización. Se espera que las contribuciones a los proyectos de InnerSource se realicen durante el horario laboral, no durante el tiempo libre.
@@ -37,9 +37,9 @@ Establecer un contrato formal entre el colaborador, su gerente de línea y una o
 - El contrato especifica un porcentaje máximo del tiempo de trabajo del colaborador en InnerSource.
 - El contrato establece claramente que el trabajo en la unidad de negocio del colaborador tiene prioridad sobre el trabajo en InnerSource.
 - El contrato establece que no es obligatorio trabajar en InnerSource durante el porcentaje máximo especificado en el contrato.
-- El contrato es firmado por el colaborador, el gerente de línea del colaborador, la oficina de gobernanza y el [Dedicated Community Leader](dedicated-community-leader.md) de la comunidad a la que el colaborador contribuirá.
+- El contrato es firmado por el colaborador, el gerente de línea del colaborador, la oficina de gobernanza y el [Líder de Comunidad Dedicado](dedicated-community-leader.md) de la comunidad a la que el colaborador contribuirá.
 - La oficina de gobernanza ofrece mediar entre el colaborador y su gerente de línea en caso de conflicto respecto al tiempo para contribuciones.
-- El [Dedicated Community Leader](dedicated-community-leader.md) participa o proporciona información para las evaluaciones de desempeño de los colaboradores contratados por más del 20 %.
+- El [Líder de Comunidad Dedicado](dedicated-community-leader.md) participa o proporciona información para las evaluaciones de desempeño de los colaboradores contratados por más del 20 %.
 
 ![Contracted Contributor](../../../assets/img/contracted-contributor.png)
 

translation/es/patterns/crossteam-project-valuation.md

@@ -26,7 +26,7 @@ Como resultado, es fácil y común perseguir proyectos que no proporcionan valor
 ## Solución
 
 Establece un patrón y modelo sobre cómo valorar proyectos cross-team.
-Estos modelos nos proporcionan la herramienta necesaria para enfocar y amplificar la colaboración de alto valor para la empresa.
+Estos modelos nos proporcionan las herramientas necesaria para enfocar y amplificar la colaboración de alto valor para la empresa.
 
 El núcleo de todo el valor del proyecto cross-team es la idea de que podemos hacer más juntos que separados.
 Asignar valor a un esfuerzo cross-team es un ejercicio de cuantificar _cuánto más_ se está logrando juntos.
@@ -78,7 +78,7 @@ Esas mediciones pueden ser entendidas y consumidas en su forma bruta para propor
 Algunos pueden estar preocupados por la falta de precisión en este enfoque de valoración. Está bien que este proceso no proporcione una medición exacta. Solo necesita ser lo suficientemente preciso para cumplir 2 propósitos:
 
 1. Proporcionar un medio para representar el valor de lo que está sucediendo a aquellos que están organizando y financiando esfuerzos cross-team.
-1. Ayudar a los involucrados a saber qué áreas del esfuerzo cross-team son de mayor prioridad para perseguir según su valor.
+2. Ayudar a los involucrados a saber qué áreas del esfuerzo cross-team son de mayor prioridad para perseguir según su valor.
 
 En la práctica, siempre que estas valoraciones estén dentro de un orden de magnitud de la realidad y entre sí, son lo suficientemente precisas para cumplir estos propósitos.
 Proporcionarán una mejora notable en los resultados sobre el terreno en comparación con las valoraciones ad hoc (y los efectos resultantes) descritos en la sección **Problem** al comienzo de este documento.

translation/es/patterns/group-support.md

@@ -1,6 +1,6 @@
 ## Title
 
-Soporte Grupal
+Grupo de Soporte
 
 ## Patlet
 
@@ -59,7 +59,7 @@ No se espera que el grupo implemente ninguna funcionalidad nueva para otros.
 ## Contexto Resultante
 
 * Hay algún soporte frágil para el proyecto InnerSource.
-* A largo plazo, es probable que el soporte grupal se disuelva nuevamente en algún momento. Si el proyecto continúa a largo plazo, utiliza este período de soporte grupal estable para encontrar una forma de mantenerlo a largo plazo (por ejemplo, [Equipo Central][]).
+* A largo plazo, es probable que el grupo de soporte se disuelva nuevamente en algún momento. Si el proyecto continúa a largo plazo, utiliza este período de grupo de soporte estable para encontrar una forma de mantenerlo a largo plazo (por ejemplo, [Equipo Central][]).
 
 ## Razonamiento
 

translation/es/patterns/review-committee.md

@@ -32,7 +32,7 @@ La empresa A quiere introducir su primera iniciativa InnerSource. La mayoría de
 - El comité de revisión debe reunirse regularmente. Una cadencia de dos reuniones por año ha demostrado ser exitosa.
 - El comité de revisión puede volverse opcional si InnerSource ha sido ampliamente adoptado y comprendido por la organización.
 
-![Review Committee Sketch](../../../assets/img/review-committee-sketch.jpg)
+![Comité de Revisión Sketch](../../../assets/img/review-committee-sketch.jpg)
 
 ## Contexto Resultante
 
@@ -55,7 +55,7 @@ La empresa A quiere introducir su primera iniciativa InnerSource. La mayoría de
 
 ## Alias
 
-Interfaz de Queso
+Cheese Interface
 
 ## Histórico de Traducciones