Garantia de 30 dias
Ao aceitar contribuições de fora da sua própria equipe, há uma aversão natural em assumir a responsabilidade pelo código que não foi escrito pela própria equipe. Através da Garantia de 30 dias, a equipe contribuinte concorda em fornecer correções de bugs para a equipe receptora, o que aumentará o nÃvel de confiança entre as duas equipes e torna mais provável que as contribuições sejam aceitas.
Uma equipe desenvolve um componente que é utilizado em toda a organização. Essa equipe resiste em aceitar ou rejeita completamente contribuições (pedidos de recursos). Esse comportamento bloqueia o progresso e leva a interrupções frequentes devido a escalonamentos.
As equipes dependem de outra equipe para aceitar suas contribuições para que um componente produzido pela equipe receptora possa ser utilizado pela equipe contribuinte.
A equipe receptora não possui os recursos, conhecimento, permissão e/ou inclinação para escrever o componente/pedido de recurso por si própria.
Existe desconfiança em relação às contribuições devido a um histórico de trapaças: equipes enviaram contribuições incompletas e posteriormente solicitaram correções para torná-las prontas para uso em produção.
Se o código é contribuÃdo por uma equipe externa, a equipe receptora tem a suspeita natural de que a outra equipe não sabe como escrever código que atenda à s expectativas da equipe receptora.
Cada equipe olha primeiro para ajudar seus próprios lÃderes a alcançar seus próprios objetivos. Essa direção de lealdade pode complicar a resolução desse problema.
Existe uma aversão natural em assumir a responsabilidade pelo código não escrito por si próprio.
O código contribuÃdo precisa ser amplamente reescrito antes de ser aceito na base de código.
Existe o medo de que os contribuintes não estejam disponÃveis para dar suporte na correção de bugs após o tempo da contribuição.
As equipes temem que o código contribuÃdo levará a custos de manutenção altos (ou mais altos), mas não sabem como controlar isso.
As equipes receptoras podem temer que ensinar outras pessoas a contribuir com o código irá expor dÃvida técnica em seu sistema e que essa visibilidade possa ser prejudicial.
As equipes receptoras podem não acreditar que receberão um código aceitável, não importa quanto mentoria seja fornecida.
Qualquer uma das equipes pode não se sentir confiante em medir riscos ou certificar que eles são mitigados em uma contribuição; o próprio sistema é um tanto frágil (pode não haver maneiras de testar completamente e detectar todos os problemas).
Aborde os medos tanto da equipe que recebe quanto da equipe que contribui, estabelecendo um perÃodo de garantia de 30 dias a partir do momento em que o código contribuÃdo entra em produção. Durante este perÃodo de garantia, a equipe contribuinte concorda em fornecer correções de bugs à equipe receptora.
Observe que o perÃodo de garantia também pode ser de 45, 60 ou 100 dias. A duração pode variar com base nas restrições do projeto, no ciclo de vida do software do projeto, nos compromissos com os clientes e em outros fatores.
Além disso, ajuda a fornecer diretrizes claras de contribuição, especificando as expectativas da equipe receptora e da equipe contribuinte.
A equipe receptora está disposta a aceitar contribuições e é capaz de compartilhar a carga de trabalho de adaptações/correções iniciais.
Aumenta a transparência e justiça.
Evita que as escalações se tornem muito pesadas.
Isso foi testado e comprovado com sucesso na PayPal.
O GitHub internamente usa esse padrão com um prazo de garantia modificado de 6 semanas.
A Microsoft recomenda esse padrão como um princÃpio - as equipes estabelecem seu próprio tempo especÃfico, correspondendo à s suas necessidades e confiança.
Cedric Williams
Dirk-Willem van Gulik
Padma Sudarsan
Klaas-Jan Stol
Georg Grütter
Structured
Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
Assegurar a cooperação das equipes dependentes, tornando-as numa comunidade, através da nomeação de mais do que um "Trusted Committers" (TCs) por mérito próprio.
2023-04-13 - Tradução Eneri Junior
2023-04-13 - Tradução Humberto Zilio