|
| 1 | +== Tornando-se um Contribuidor InnerSource |
| 2 | +Os contribuidores do InnerSource operam fora dos limites regulares da equipe, eles são os links que cruzam os silos organizacionais |
| 3 | +Como tal, eles precisam estar cientes de algumas práticas comuns que tornam este trabalho mais eficaz. |
| 4 | +== = Mindset de Compartilhamento |
| 5 | +Então, você está implementando um novo recurso para o produto da sua equipe.. |
| 6 | +Você precisa de alguma funcionalidade para que esse recurso funcione.. |
| 7 | +Em vez de entrar na implementação, desacelere um pouco: essa funcionalidade reflete um problema geral? |
| 8 | +É algo que outras equipes em sua organização enfrentam também devido ao domínio de negócios compartilhado? |
| 9 | +Esta funcionalidade é ortogonal ao domínio do seu projeto? |
| 10 | +Se isso se aplicar, comece a olhar além da sua própria equipe: existe uma solução compartilhada que você pode usar ou melhorar para atender às suas necessidades? |
| 11 | +Deveria haver um? |
| 12 | +== = Benefícios para compartilhar soluções |
| 13 | +Há um provérbio africano afirmando que " Se você quer ir rápido, vá sozinho. |
| 14 | +Se você quer ir longe, vá junto. ` " O mesmo é verdade para as equipes de desenvolvimento de software: |
| 15 | +Se você quiser se mover rapidamente, é uma ótima ideia quebrar dependências. |
| 16 | +A desvantagem para isso pode ser esforço duplicado. |
| 17 | +Em particular, ao reimplementar a lógica central, existe um risco muito real de que o custo da duplicação seja superior ao benefício da independência. |
| 18 | +Colaborar com outras equipes permite compartilhar o custo de desenvolvimento. |
| 19 | +Assim como em projetos de código aberto, ele pode permitir que sua equipe construa algo maior do que você sozinho poderia ter realizado. |
| 20 | +Mas cada equipe tem um roteiro diferente! |
| 21 | +Eu tentei usar componentes compartilhados antes-eles sempre levaram mais tempo para se integrar do que eu teria levado para reimplementá-los. |
| 22 | +Esses componentes sempre faltaram em algum aspecto ou outro-e minhas solicitações de recursos nunca tiveram prioridade no roteiro da outra equipe! |
| 23 | +Em contraste com um projeto tradicional, os projetos InnerSource vêm com o papel de um Contribuidor. |
| 24 | +Sim, haverá momentos em que você deseja que a solução compartilhada tenha um novo recurso. |
| 25 | +Como um Contribuidor, você tem a liberdade de verificar o código-fonte do componente, fazer modificações nele e usar a versão melhorada resultante. |
| 26 | +Sim, haverá momentos em que você precisará urgentemente de uma correção de bug em sua linha do tempo que não tenha a mesma prioridade na equipe anfitriã.. |
| 27 | +Tornar-se um Contribuidor permite que você aja e suporte a equipe de host com a correção desse bug. |
| 28 | +Essa maneira de trabalhar requer uma mudança de mentalidade para muitos: em vez de esperar que recursos sejam implementados ou bugs corrigidos, em vez de trabalhar em torno de problemas, agora há uma terceira solução. |
| 29 | +Gaste seu tempo e energia para verificar novamente com o projeto InnerSource quais são suas necessidades-e, em seguida, faça a mudança diretamente no projeto compartilhado. |
| 30 | +Portanto, além de suas habilidades de codificação, você precisa de habilidades de comunicação para ter sucesso em um projeto InnerSource-para articular claramente suas necessidades e chegar a uma solução que funcione tanto para sua equipe quanto para a equipe anfitriã. |
| 31 | +"Mas eu poderia simplesmente ir e bifurcar o projeto, fazer minhas mudanças lá e me salvar de toda essa coordenação!". |
| 32 | +Com certeza, bifurcar o projeto é uma maneira de fazer seu trabalho. |
| 33 | +Exceto no longo prazo, isso significa que você deve manter essa versão bifurcada para sua equipe-e levar suas mudanças adiante para qualquer nova versão que a equipe do host fizer. |
| 34 | +Contribuir com suas mudanças para a equipe anfitriã também significa que você se beneficiará de seu conhecimento mais profundo do componente. |
| 35 | +Eles podem detectar problemas em seu patch que de outra forma só teriam se tornado óbvios na produção. |
| 36 | +Um bom Contribuidor pode confortavelmente fazer uma chamada para quando faz sentido técnico e de negócios introduzir uma dependência e reutilizar um componente em vez de duplicar o trabalho. |
| 37 | +Eles podem conversar com a gerência para explicar os benefícios das contribuições do InnerSource. |
| 38 | +== = Escopo das contribuições InnerSource |
| 39 | +Então é Inner__Source__ apenas sobre __Source__Code? |
| 40 | +Claro que não. |
| 41 | +Se o negócio da sua equipe depende de um componente externo, você quer ter certeza de que ele está bem mantido e bem executado.. |
| 42 | +Como um Contribuidor do InnerSource, você pode ajudar a equipe do host de várias maneiras: |
| 43 | +Relatar problemas que você vê ao usar o componente é uma contribuição valiosa. |
| 44 | +Criar ou corrigir casos de teste que mostram que o código não está funcionando conforme o esperado é valioso. |
| 45 | +Assim como melhorar a documentação, outros gastam menos tempo usando-a e contribuindo para ela. |
| 46 | +Apoiando outros usuários, ajudar com a triagem de bugs pode ser contribuições valiosas. |
| 47 | +Melhorar as construções é outro exemplo de uma contribuição valiosa. |
| 48 | +Resumindo, nenhuma contribuição é muito pequena para contribuir. |
| 49 | +Aqui está um que eu fiz para https://github.com/tensorflow/models/pull/4784 [tensorflow/models]. |
| 50 | +Uma mudança de rótulo simples em um gráfico |
| 51 | +== = Resumo deste artigo |
| 52 | +Neste artigo você aprendeu sobre o que é preciso para se tornar um Contribuidor. |
| 53 | +Nós olhamos para a mentalidade de partilha. |
| 54 | +Nós mergulhamos profundamente nos benefícios das soluções de compartilhamento. |
| 55 | +Finalmente, tivemos uma olhada em como o escopo para contribuições do InnerSource normalmente se parece. |
0 commit comments