Comment on page
Garantia de 30 dias
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.
Garantia de 30 dias
- 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.
Last modified 1mo ago