Add Spanish templates for README and CONTRIBUTING documentation

Author: Oscar Lobaton

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

@@ -0,0 +1,77 @@
+## Title
+
+Garantía de 30 Días
+
+## Resumen
+
+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.
+
+## Problema
+
+Un equipo desarrolla un componente que se utiliza en toda una organización. Este equipo se resiste a aceptar o directamente rechaza contribuciones (solicitudes de funcionalidades). Este comportamiento bloquea el progreso y conduce a interrupciones frecuentes por escalamientos.
+
+## Contexto
+
+- Los equipos dependen de que otro equipo acepte sus contribuciones para que un componente producido por el equipo receptor pueda ser utilizado por el equipo contribuyente.
+- El equipo receptor no tiene los recursos, conocimientos, permisos y/o inclinación para escribir el componente/funcionalidad contribuido por sí mismos.
+
+## Fuerzas
+
+- Existe desconfianza hacia las contribuciones debido a un historial de engaños: los equipos enviaron contribuciones a medio terminar y posteriormente presentaron solicitudes de correcciones para hacerlas listas para su uso en producción.
+- Si el código es contribuido desde fuera del equipo, el equipo tiene la sospecha natural de que el otro equipo no sabe cómo escribir código que cumpla con las expectativas del equipo receptor.
+- Cada equipo busca primero ayudar a sus propios líderes a alcanzar sus objetivos. Esta dirección de lealtad puede complicar la resolución de este problema.
+- Existe una aversión natural a asumir la responsabilidad del código no escrito por uno mismo.
+- El código contribuido necesita ser reescrito considerablemente antes de ser aceptado en la base de código.
+- Existe el temor de que los contribuyentes no estén disponibles para el soporte en la corrección de errores después del momento de la contribución.
+- Los equipos temen que el código contribuido lleve a costos de mantenimiento más altos pero no saben cómo controlarlo.
+- Los equipos receptores pueden temer que enseñar a otros cómo contribuir código expondrá deuda técnica en su sistema y que esa visibilidad pueda ser dañina.
+- Los equipos receptores pueden no creer que recibirán código aceptable sin importar cuánta tutoría proporcionen.
+- Cualquiera de los equipos puede no sentirse seguro al medir riesgos o certificar que están mitigados en una contribución; el sistema en sí es algo frágil (puede no haber formas de probar completamente y detectar todos los problemas).
+
+## Solución
+
+Aborda los temores de ambos equipos, tanto el receptor como el contribuyente, estableciendo un **período de garantía de 30 días** que comienza cuando el código contribuido entra en producción. Durante este período de garantía, el equipo contribuyente acepta proporcionar correcciones de errores al equipo receptor.
+
+Ten en cuenta que el período de garantía podría ser de 45, 60 o 100 días también. La duración puede variar según las restricciones del proyecto, el ciclo de vida del software del proyecto, los compromisos con los clientes y otros factores.
+
+Además, ayuda proporcionar [directrices de contribución](./base-documentation.md) claras, detallando las expectativas tanto del equipo receptor como del equipo contribuyente.
+
+![Garantía de 30 Días](../../../assets/img/thirtydaywarranty.jpg)
+
+## Contexto Resultante
+
+- El equipo receptor está dispuesto a aceptar contribuciones y puede compartir la carga de trabajo de adaptaciones/correcciones iniciales.
+- Mayor transparencia y equidad.
+- Evita que los escalamientos se vuelvan demasiado pesados.
+
+## Instancias Conocidas
+
+- Esto fue probado y demostrado exitoso en PayPal.
+- GitHub internamente usa este patrón con un período de garantía modificado de 6 semanas.
+- Microsoft recomienda este patrón como principio - los equipos establecen su propio objetivo de tiempo específico que coincida con sus necesidades y confianza.
+- SAP aprovecha este patrón en su proyecto Everest basado en InnerSource para transformar la colaboración, asegurando que las contribuciones no solo sean aceptadas sino también apoyadas, mejorando la confianza e impulsando la cultura de responsabilidad compartida e innovación. Ver: [InnerSource: Primera Contribución Explorada](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
+
+## Autores
+
+- Cedric Williams
+
+## Agradecimientos
+
+- Dirk-Willem van Gulik
+- Padma Sudarsan
+- Klaas-Jan Stol
+- Georg Grütter
+
+## Estado
+
+* Estructurado
+* Redactado en la Cumbre InnerSource de Primavera 2017; revisado el 18 de julio de 2017.
+
+## Variantes
+
+- Asegurar la cooperación de equipos dependientes convirtiéndolos en una comunidad al tener más de un "[Trusted Committer](./trusted-committer.md)" (TC) designado meritocráticamente que asuma la responsabilidad.
+
+
+## Histórico de Traducciones
+
+- **2025-04-03** - Tradución [Oscar Lobaton S.](https://github.com/ovas04)

translation/es/patterns/base-documentation.md

@@ -0,0 +1,156 @@
+## Title
+
+Documentación Base Estándar
+
+## Resumen
+
+Los nuevos contribuidores a un proyecto InnerSource tienen dificultades para identificar quién
+mantiene el proyecto, en qué trabajar y cómo contribuir. Proporcionar
+documentación en archivos estándar como `README.md`/`CONTRIBUTING.md`/`COMMUNICATION.md` permite un
+proceso de autoservicio para nuevos contribuidores, permitiéndoles encontrar respuestas a
+las preguntas más comunes por sí mismos.
+
+## Problema
+
+Un equipo desea compartir un proyecto, ya sea nuevo o existente, con
+la organización y recibir contribuciones. Los potenciales contribuidores
+frecuentemente se sienten perdidos: No logran identificar los canales de comunicación
+preferidos del equipo. Tienen dificultades para determinar rápidamente si una nueva
+funcionalidad tiene sentido o no. Les cuesta entender exactamente
+quiénes son los colegas que actualmente mantienen el proyecto.
+
+## Contexto
+
+Un proyecto se compartirá con otros como proyecto InnerSource. Para que
+otros puedan entender de qué trata el proyecto y cómo
+contribuir, el proyecto necesita proporcionar documentación básica. Hasta ahora,
+el proyecto carece de toda la documentación o algunos aspectos necesarios para que los usuarios
+lo prueben de manera autónoma y para que los contribuidores puedan ponerse al día
+rápidamente.
+
+## Fuerzas
+
+- El proyecto se convirtió en un proyecto InnerSource recientemente. Antes, los usuarios eran internos o recibían capacitación presencial. De igual manera, las personas que trabajaban en el proyecto pasaban por sesiones de incorporación presencial que no son escalables con el crecimiento de contribuidores o contribuidores remotos. Como resultado, falta documentación de autoservicio.
+- El proyecto fue creado como un proyecto InnerSource, pero el equipo anfitrión carece de experiencia con InnerSource. Como resultado, necesitan orientación sobre qué información incluir en su documentación, dónde ubicarla para que otros la encuentren y qué tipos de lectores considerar.
+- El proyecto se convirtió en un proyecto InnerSource recientemente, y el equipo anfitrión tiene experiencia limitada con InnerSource. Como resultado, la documentación existente aborda aspectos técnicos pero no cubre comunicación, coordinación e información necesaria para facilitar la planificación transparente.
+- El proyecto se convirtió en un proyecto InnerSource recientemente. Como resultado, mucho conocimiento implícito del equipo no está documentado ni es obvio para los contribuidores.
+- La falta de documentación hace que los potenciales contribuidores tarden mucho en configurar y comenzar. Producir documentación (y mantenerla actualizada) requiere inversión de tiempo. Incluso si el equipo anfitrión cuenta con contribuidores para ayudar con la documentación faltante, esas contribuciones necesitan tiempo de revisión.
+- Los miembros del proyecto dedican mucho tiempo a responder preguntas iniciales. Mantener una base de datos completa de preguntas de soporte requiere mucho tiempo y esfuerzo.
+- Diferentes equipos dentro de la organización tienen estándares divergentes sobre cómo formatear código y qué patrones de software usar. Como resultado, las contribuciones a menudo terminan siendo reescritas en gran parte o completamente. Estandarizar todo esto requeriría mucho tiempo y trabajo.
+- El trabajo adicional por explicaciones repetidas y reescrituras disminuye la utilidad del enfoque InnerSource.
+- Las escalaciones frecuentes debido al trabajo extra y los retrasos por reescrituras llevan a una situación de cuello de botella.
+
+## Solución
+
+Abordar la necesidad de una documentación más clara para nuevos contribuidores. El objetivo al
+crear esta documentación debe ser hacer que el proceso de inicio sea lo más autoservicio posible, con preguntas frecuentes respondidas en un formato de documentación estándar.
+
+### README.md
+
+Si aún no existe, crea un `README.md` para tu proyecto. Debe contener:
+
+* La [misión del proyecto](https://producingoss.com/en/producingoss.html#mission-statement) en un formato lo más conciso posible. Debe responder cuál es el propósito del proyecto y permitir a los contribuidores hacer una buena suposición inicial sobre si una funcionalidad sugerida probablemente estará dentro del alcance del proyecto o no.
+* Una sección de "Primeros pasos" para los usuarios del proyecto. Debe explicar cómo configurar/integrar los artefactos del proyecto, así como una explicación de algunos de los primeros pasos típicos para los usuarios primerizos.
+* Documentación más profunda para los usuarios del proyecto, o un enlace a ella.
+* Documentación necesaria para hacer modificaciones al proyecto, o un enlace a ella.
+* Documentación sobre cómo contribuir al proyecto, o un enlace a ella.
+* Una sección de "Participar" que explique qué canales de comunicación públicos, archivados y enlazables utiliza el proyecto. Esto debe incluir un enlace al rastreador de problemas del proyecto, pero también a cualquier otro medio de discusión utilizado.
+* Una sección de "Quiénes somos" que explique quiénes son los [Trusted Committers](trusted-committer.md) detrás del proyecto, con una explicación de que en lugar de contactar a estas personas en privado, se deben utilizar los canales de comunicación públicos mencionados anteriormente.
+* Una explicación de cuáles son los criterios para que el proyecto convierta a los contribuidores en Trusted Committers, si ese camino existe.
+
+![README.md](../../../assets/img/standard-base-documentation/README-for-users.png)
+
+### CONTRIBUTING.md
+
+Si la explicación de los pasos para hacer una contribución es demasiado detallada, crea
+un documento `CONTRIBUTING.md` separado. Este documento debe responder preguntas frecuentes que los contribuidores hayan hecho en el pasado. No es necesario proporcionar un libro completo desde el principio. Más bien, comparte información que haya demostrado ser necesaria para los contribuidores. Probablemente tocará uno o más de los siguientes temas:
+
+* Cómo obtener el código fuente del proyecto desde el control de versiones.
+* Cómo hacer modificaciones al proyecto (potencialmente incluyendo información sobre las pautas de codificación).
+* Cómo construir el proyecto.
+* Cómo ejecutar pruebas para asegurarse de que las modificaciones anteriores no introduzcan nuevos errores.
+* Cómo enviar tus modificaciones de vuelta al proyecto.
+* Alguna información sobre el tiempo de respuesta esperado para las modificaciones realizadas.
+
+![CONTRIBUTING.md](../../../assets/img/standard-base-documentation/CONTRIBUTING-for-contributors.png)
+
+
+### COMMUNICATION.md
+
+Crea un documento `COMMUNICATION.md` separado. Enlaza este documento a tu `README.md` para que se pueda proporcionar información de contacto completa sin ocupar espacio adicional en tu README. Este documento debe responder preguntas frecuentes sobre cómo comunicarse con tu equipo que los contribuidores necesitan saber. El objetivo es agilizar las comunicaciones para que los usuarios y contribuidores se comuniquen con la persona correcta a través de un solo canal. Esto reduce distracciones innecesarias para los miembros del equipo y organiza las comunicaciones para que no se pierdan.
+
+Las secciones en el `COMMUNICATION.md` incluyen puntos de contacto para comunicaciones entrantes e información sobre comunicaciones salientes del equipo de propiedad del proyecto. A continuación, algunos ejemplos.
+
+Puntos de contacto para la comunicación entrante y cómo contactar a esos usuarios:
+
+* Reportar un error
+* Dar seguimiento a un PR
+* Solicitudes de funcionalidades
+* Preguntas sobre documentación
+* Escalaciones
+
+Cómo y cuándo el equipo se comunica con los usuarios y cómo ser agregado a esas comunicaciones:
+
+* Interrupciones planificadas y no planificadas
+* Lanzamientos de funcionalidades
+* Congelaciones de código
+* Cambios importantes
+
+Hay muchos buenos ejemplos de cómo escribir un `README.md` y qué tipo
+de información incluir en un archivo `CONTRIBUTING.md` en varios proyectos de código abierto.
+Páginas como [cómo escribir un readme que destaque](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a),
+[Guía de Código Abierto de GitHub](https://opensource.guide/) así como
+el libro [Producing Open Source](https://producingoss.com/en/producingoss.html)
+tienen información valiosa sobre qué tipo de información proporcionar. Aunque
+Producing Open Source no tiene un capítulo sobre cómo escribir un buen README per se,
+el [capítulo de Primeros Pasos](https://producingoss.com/en/producingoss.html#starting-from-what-you-have)
+proporciona una lista bastante extensa de cosas que los miembros del equipo anfitrión,
+usuarios y contribuidores necesitarán. Los proyectos InnerSource probablemente no cubrirán todos
+esos aspectos desde el principio, pero la lista en sí es útil para
+inspiración sobre qué se podría cubrir.
+
+Además de eso, este patrón viene con tres plantillas muy básicas para que
+puedas comenzar de inmediato: [README-template.md](templates/README-template.md),
+[CONTRIBUTING-template.md](templates/CONTRIBUTING-template.md) y [COMMUNICATION-template.md](templates/COMMUNICATION-template.md).
+
+## Contexto Resultante
+
+* El tiempo para que los contribuidores se pongan al día se reduce significativamente.
+* El tiempo dedicado a responder preguntas iniciales para los [Trusted Committers](trusted-committer.md) se reduce significativamente, dejándoles más tiempo para trabajar en otras tareas.
+* Las escalaciones debido a malentendidos y desalineaciones se reducen significativamente.
+
+## Instancias Conocidas
+
+* Europace AG - Ver publicación en el blog [InnerSource: Adding base documentation](https://tech.europace.de/post/innersource-base-documentation/)
+* Paypal Inc.
+* Mercado Libre - crear un sitio de documentación que contenga cómo comenzar con InnerSource y también definir los artefactos básicos que un repositorio debe tener para ser InnerSource (README, CONTRIBUTING, CODING_GUIDELINES, etc).
+* Analog Devices Inc.
+* Airbus
+
+## Autores
+
+* Isabel Drost-Fromm
+* Katie Schueths - agregó el concepto de `COMMUNICATION.md`
+
+## Alias
+
+Proporcionar documentación base estándar a través de un README
+
+## Estado
+
+* Estructurado
+* Borrador en diciembre de 2019.
+
+## Referencias
+
+* [README-template.md](templates/README-template.md)
+* [CONTRIBUTING-template.md](templates/CONTRIBUTING-template.md)
+* [COMMUNICATION-template.md](templates/COMMUNICATION-template.md)
+
+## Créditos
+
+Ilustraciones de [Web](https://storyset.com/web) y [People](https://storyset.com/people) por Storyset
+
+## Histórico de Traducciones
+
+- **2025-04-03** - Tradución [Oscar Lobaton S.](https://github.com/ovas04)