|
| 1 | +== Tornando-se um Contribuidor InnerSource |
| 2 | +Os contribuidores de InnerSource operam fora dos limites regulares da equipe, eles são os elos 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 iniciar a 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? |
| 12 | +=== Benefícios de 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 Open Source, pode permitir que sua equipe construa algo maior do que você poderia ter realizado sozinho. |
| 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 | +Sempre faltavam um aspecto ou outro nesses componentes - 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 anfitriã 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 então faça a alteração 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 fazer um fork (bifurcar) do 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 anfitriã 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 decidir confortavelmente quando faz sentido técnico e comercial 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 de InnerSource. |
| 38 | +=== Escopo das contribuições InnerSource |
| 39 | +Então __InnerSource__ é apenas sobre __Código Fonte__? |
| 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 de InnerSource, você pode ajudar a equipe anfitriã de várias maneiras: |
| 43 | +Relatar problemas que você encontra 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 podem ser contribuições valiosas. |
| 47 | +Melhorar os builds é outro exemplo de contribuição valiosa. |
| 48 | +Resumindo, nenhuma contribuição é muito pequena para contribuir. |
| 49 | +Aqui está uma 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 | +Vimos a mentalidade de compartilhamento. |
| 54 | +Mergulhamos profundamente nos benefícios do compartilhamento de soluções. |
| 55 | +Finalmente, demos uma olhada em como normalmente é o escopo das contribuições do InnerSource. |
0 commit comments