Use Patlet as section title in the Spanish translations. Required for the toc generation. Also regenerate the toc for Spanish.

spier · spier · commit cb325f2e4d60 · 2025-03-07T07:12:02.000+01:00
diff --git a/book/es/toc.md b/book/es/toc.md
diff --git a/translation/es/patterns/30-day-warranty.md b/translation/es/patterns/30-day-warranty.md
@@ -2,7 +2,7 @@
 
 Garantía de 30 Días
 
-## Resumen
+## Patlet
 
 Al aceptar contribuciones de fuera de tu propio equipo, existe una aversión natural a asumir la responsabilidad del código no escrito por el equipo mismo. A través de la Garantía de 30 Días, el equipo contribuyente se compromete a proporcionar correcciones de errores al equipo receptor, lo que aumentará el nivel de confianza entre ambos equipos y hace más probable que se acepten las contribuciones.
 
diff --git a/translation/es/patterns/base-documentation.md b/translation/es/patterns/base-documentation.md
@@ -2,7 +2,7 @@
 
 Documentación Base Estándar
 
-## Resumen
+## Patlet
 
 Los nuevos contribuidores a un proyecto InnerSource tienen dificultades para identificar quién
 mantiene el proyecto, en qué trabajar y cómo contribuir. Proporcionar
diff --git a/translation/es/patterns/common-requirements.md b/translation/es/patterns/common-requirements.md
@@ -2,7 +2,7 @@
 
 Requerimientos Comunes
 
-## Resumen
+## Patlet
 
 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.
 
diff --git a/translation/es/patterns/communication-tooling.md b/translation/es/patterns/communication-tooling.md
@@ -2,7 +2,7 @@
 
 Herramientas de Comunicación
 
-## Resumen
+## Patlet
 
 Los usuarios de un proyecto InnerSource tienen dificultades para obtener ayuda y contactar con el equipo anfitrión.
 Mediante el uso consistente de herramientas de comunicación asincrónica, el proyecto hace que las discusiones sean visibles, archivadas y buscables, lo que conduce a un mejor nivel de soporte para los usuarios.
diff --git a/translation/es/patterns/contracted-contributor.md b/translation/es/patterns/contracted-contributor.md
@@ -2,7 +2,7 @@
 
 Colaborador Contratado
 
-## Resumen
+## Patlet
 
 Los colaboradores que desean contribuir a InnerSource son desalentados por su gerencia directa. La solución se proporciona mediante contratos y acuerdos formales.
 
diff --git a/translation/es/patterns/core-team.md b/translation/es/patterns/core-team.md
@@ -2,7 +2,7 @@
 
 Equipo Central (Core Team)
 
-## Resumen
+## Patlet
 
 Incluso cuando un proyecto InnerSource es ampliamente necesario, las contribuciones y el uso pueden verse obstaculizados porque el proyecto es difícil de trabajar.
 Establece un equipo central dedicado a ocuparse de los elementos fundamentales del proyecto.
diff --git a/translation/es/patterns/crossteam-project-valuation.md b/translation/es/patterns/crossteam-project-valuation.md
@@ -2,7 +2,7 @@
 
 Valoración de Proyectos Cross-Team
 
-## Resumen
+## Patlet
 
 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.
diff --git a/translation/es/patterns/dedicated-community-leader.md b/translation/es/patterns/dedicated-community-leader.md
@@ -2,7 +2,7 @@
 
 Líder de Comunidad Dedicado
 
-## Resumen
+## Patlet
 
 Selecciona personas con habilidades tanto de comunicación como técnicas para liderar las comunidades y asegurar el éxito al iniciar una iniciativa InnerSource.
 
diff --git a/translation/es/patterns/document-your-guiding-principles.md b/translation/es/patterns/document-your-guiding-principles.md
@@ -2,7 +2,7 @@
 
 Documenta tus Principios Rectores
 
-## Resumen
+## Patlet
 
 La explicación habitual de InnerSource como "aplicación de mejores prácticas de open source dentro de una organización" no funciona bien con personas que carecen de experiencia en open source.
 Como solución, los principios más importantes de InnerSource se documentan y publican ampliamente.
diff --git a/translation/es/patterns/extensions-for-sustainable-growth.md b/translation/es/patterns/extensions-for-sustainable-growth.md
@@ -2,7 +2,7 @@
 
 Extensiones para un Crecimiento Sostenible
 
-## Resumen
+## Patlet
 
 Un proyecto InnerSource está recibiendo demasiadas contribuciones, haciendo difícil su mantenimiento. Al ofrecer un mecanismo de extensiones fuera del proyecto principal, los mantenedores permiten escalar las capacidades del proyecto con un costo y mantenimiento mínimos.
 
diff --git a/translation/es/patterns/gig-marketplace.md b/translation/es/patterns/gig-marketplace.md
@@ -2,7 +2,7 @@
 
 Mercado de Gigs
 
-## Resumen
+## Patlet
 
 Establece un mercado creando un sitio web interno que liste necesidades específicas de proyectos InnerSource como "Gigs" con requisitos explícitos de tiempo y habilidades. Esto permitirá a los gerentes comprender mejor el compromiso de tiempo de sus empleados y los beneficios profesionales, aumentando así la probabilidad de obtener aprobación para realizar contribuciones InnerSource.
 
diff --git a/translation/es/patterns/group-support.md b/translation/es/patterns/group-support.md
@@ -2,7 +2,7 @@
 
 Soporte Grupal
 
-## Resumen
+## Patlet
 
 ¿Qué sucede si un equipo o individuo deja de mantener un proyecto InnerSource?
 Mantén el proyecto activo formando un grupo de personas interesadas.
diff --git a/translation/es/patterns/innersource-license.md b/translation/es/patterns/innersource-license.md
@@ -2,7 +2,7 @@
 
 Licencia InnerSource
 
-## Resumen
+## Patlet
 
 Dos entidades legales que pertenecen a la misma organización quieren compartir código fuente entre sí pero están preocupadas por las implicaciones en términos de responsabilidades legales o contabilidad entre empresas.
 Una **Licencia InnerSource** proporciona un marco legal reutilizable para compartir código fuente dentro de la organización. Esto abre nuevas opciones de colaboración y hace explícitos los derechos y obligaciones de las entidades legales involucradas.
diff --git a/translation/es/patterns/innersource-portal.md b/translation/es/patterns/innersource-portal.md
@@ -2,7 +2,7 @@
 
 Portal InnerSource
 
-## Resumen
+## Patlet
 
 Los contribuidores potenciales no pueden descubrir fácilmente proyectos InnerSource que les interesen. Al crear un sitio web en la intranet que indexe toda la información disponible de proyectos InnerSource, permitirás que los contribuidores aprendan sobre proyectos que podrían interesarles y que los propietarios de proyectos InnerSource atraigan una audiencia externa.
 
diff --git a/translation/es/patterns/issue-tracker.md b/translation/es/patterns/issue-tracker.md
@@ -2,7 +2,7 @@
 
 Casos de Uso del Issue Tracker
 
-## Resumen
+## Patlet
 
 El equipo anfitrión de InnerSource no logra hacer transparentes no solo los planes y el progreso sino también el contexto de los cambios. Esto se resuelve aumentando los casos de uso del issue tracker del proyecto para también servir en lluvia de ideas, discusión de implementación y diseño de funcionalidades.
 
diff --git a/translation/es/patterns/maturity-model.md b/translation/es/patterns/maturity-model.md
@@ -2,7 +2,7 @@
 
 Modelo de Madurez
 
-## Resumen
+## Patlet
 
 Los equipos han comenzado a adoptar InnerSource. La práctica se está extendiendo a múltiples
 departamentos. Sin embargo, la comprensión de lo que constituye un proyecto InnerSource
diff --git a/translation/es/patterns/praise-participants.md b/translation/es/patterns/praise-participants.md
@@ -2,7 +2,7 @@
 
 Reconocimiento a los Participantes
 
-## Resumen
+## Patlet
 
 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.
diff --git a/translation/es/patterns/release-process.md b/translation/es/patterns/release-process.md
@@ -2,7 +2,7 @@
 
 Proceso Estándar de Liberación
 
-## Resumen
+## Patlet
 
 Los equipos pueden dudar en adoptar un proyecto InnerSource si no están seguros de su madurez. Para abordar esto, las notas de versión consistentes y los artefactos publicados son cruciales. Estas prácticas demuestran una fuerte dedicación al proyecto, generando confianza y asegurando a los usuarios un compromiso continuo con un software sostenible y bien gestionado.
 
diff --git a/translation/es/patterns/repository-activity-score.md b/translation/es/patterns/repository-activity-score.md
@@ -2,7 +2,7 @@
 
 Puntuación de Actividad del Repositorio
 
-## Resumen
+## Patlet
 
 Los contribuidores potenciales quieren encontrar proyectos InnerSource activos que necesiten su ayuda. Al calcular una puntuación de actividad del repositorio para cada proyecto, se puede crear una lista clasificada de proyectos (por ejemplo, en el [Portal InnerSource](innersource-portal.md)), para que los contribuidores potenciales puedan determinar más fácilmente a qué proyecto quieren contribuir.
 
diff --git a/translation/es/patterns/review-committee.md b/translation/es/patterns/review-committee.md
@@ -2,7 +2,7 @@
 
 Comité de Revisión
 
-## Resumen
+## Patlet
 
 El modelo de trabajo InnerSource es un cambio radical respecto a los enfoques más tradicionales, tanto para desarrolladores como para gerentes. Al establecer un comité de revisión como interfaz entre la iniciativa InnerSource y todos los gerentes senior de las unidades de negocio participantes, es más probable que estos últimos se familiaricen con la iniciativa y la apoyen, ya que les proporciona cierto nivel de supervisión y control sin fomentar la microgestión.
 
diff --git a/translation/es/patterns/service-vs-library.md b/translation/es/patterns/service-vs-library.md
@@ -2,7 +2,7 @@
 
 Servicio vs Biblioteca
 
-## Resumen
+## Patlet
 
 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 biblioteca y colaborar en ella.
 
diff --git a/translation/es/patterns/start-as-experiment.md b/translation/es/patterns/start-as-experiment.md
@@ -2,7 +2,7 @@
 
 Comenzar como Experimento
 
-## Resumen
+## Patlet
 
 Inicia tu iniciativa InnerSource como un experimento con tiempo limitado para facilitar que los gerentes no familiarizados con InnerSource respalden y apoyen la iniciativa.
 
diff --git a/translation/es/patterns/transparent-cross-team-decision-making-using-rfcs.md b/translation/es/patterns/transparent-cross-team-decision-making-using-rfcs.md
@@ -2,7 +2,7 @@
 
 Toma de Decisiones Transparente Entre Equipos usando RFCs
 
-## Resumen
+## Patlet
 
 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.
 
diff --git a/translation/es/patterns/trusted-committer.md b/translation/es/patterns/trusted-committer.md
@@ -2,7 +2,7 @@
 
 Trusted Committer
 
-## Resumen
+## Patlet
 
 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.
 
