# Garantía de 30 días ### Title 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 os 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. ### 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. ### 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. * 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). ### 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. Ademais, axuda a proporcionar [directrices de contribución](/gl/p/base-documentation.md) claras, concretando as expectativas do equipo receptor e o equipo contribuidor. ![Garantía de 30 días](/files/JShsaLhtz246W19d6FCB) ### Contexto resultante * 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. ### 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. ### Autoría * Cedric Willians ### Recoñecementos * Dirk-Willem van Gulik * Padma Sudarsan * Klaas-Jan Stol * Georg Grütter ### Estado * Estruturado * Redactado no Cume InnerSource de primavera de 2017; revisado o 18 de xuño de 2017. ### Variantes * Garanta a cooperación dos equipos dependentes, converténdoos nunha comunidade mediante a responsabilidade de máis dun/dunha [*trusted commiter*](/gl/p/trusted-committer.md) (TC), designados/as por meritocracia. ### Tradución * Leticia Gómez Cadahía * María Lucía González Castro --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://patterns.innersourcecommons.org/gl/p/30-day-warranty.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.