Trilha de aprendizagem: colaborador

A seção Contribuinte cobre o que significa ser um contribuidor InnerSource, os aspectos do comportamento que farão de você um contribuidor bem sucedido, mecânica de contribuição e os benefícios do InnerSource para sua equipe e organização.

Introdução

Você já foi bloqueado em sua próxima tarefa de codificação porque outra equipe não teve tempo de adicionar um recurso em seu sistema que você depende? Talvez depois de um tempo você tenha que fazer algum trabalho extra em seu projeto para contornar a característica desaparecida. Como seria bom nunca ser bloqueado assim?

Com projetos que incorporam princípios InnerSource, você nunca será bloqueado esperando por outra equipe para entregar algum recurso necessário. Se você não está recebendo o que precisa, você pode fazer a mudança que você precisa diretamente no repositório de código da outra equipe agindo como um contribuidor InnerSource.

O papel do contribuinte descreve uma pessoa que faz contribuições para os acordos de um projeto comunitário InnerSource. Essa pessoa pode ou não ser parte ou se ver como parte da comunidade. No entanto, para algumas pessoas há uma espécie de jornada que os contribuintes podem fazer de apenas saber sobre a comunidade para usar o produto da comunidade para interagir com membros da comunidade e finalmente começar a contribuir. Finalmente, alguns deles podem se tornar Trusted Committers.

Como contribuinte em uma comunidade InnerSource você vai interagir com as pessoas que desempenham outros papéis de InnerSource, como Trusted Committer ou responsável pelo produto e possivelmente com outros contribuintes. Às vezes, esses papéis podem ser desempenhados pela mesma pessoa, como Trusted Committer e responsável pelo produto em pequenos projetos de base.

Esta seção lhe dá uma breve visão geral dos outros dois papéis, mas gostaríamos de encorajá-lo a ler o Artigo introdutório do papel Trusted Committer, e recomendamos que você leia o Baixando as barreiras à entrada artigo, também, antes de aprofundar os detalhes do papel do contribuinte nesta seção. Você também pode assistir os vídeos (introdução, diminuindo as barreiras para a entrada) em vez de ler os artigos.

Um Trusted Committer será seu anfitrião para sua estadia na comunidade anfitriã. Eles são os guardiões do repositório de códigos do projeto, e vão aproximar sua contribuição da produção assim que aceitarem. É o papel deles te orientar em seu caminho para contribuir para a comunidade deles. Eles podem ajudá-lo diretamente ou fornecer informações para permitir que você se ajude. Esta informação poderia ser estabelecida regras de casa para revisões, modelos de proposta para mudanças maiores, ponteiros para documentação ou seções de código relevantes para sua contribuição.

Eles também precisam se preocupar com a qualidade do produto, sustentabilidade e evolução do projeto da perspectiva técnica, bem como geral, sobre reduzir a barreira para fazer contribuições para todos, bem como sobre cuidar de sua comunidade em geral. Cuidar da comunidade envolve mantê-la saudável, aprimorá-la e seus participantes, e defender suas necessidades em sua organização.

O papel do responsável pelo produto tem alguma semelhança com o papel de dono do produto do seu projeto médio. No entanto, há diferenças – dependendo do tamanho do projeto, este papel é muitas vezes preenchido pela mesma pessoa que age como comiter confiável. Em projetos maiores, ou em equipes que usam apenas parcialmente InnerSource como uma abordagem para preencher suas necessidades aceitando contribuições, este papel é provavelmente preenchido por uma pessoa separada de um committer confiável.

Sua interação com o papel de dono do produto provavelmente focará em trabalhar o ajuste de sua contribuição para o produto geral e seu roteiro. Você pode trabalhar com o papel de dono do produto para garantir que os aspectos gerais da documentação, ou consistência de UI/UX, sejam mantidos após a fusão de sua contribuição.

Por último, mas não menos importante, alguém agindo como dono do produto pode ter sido envolvido em trazer o projeto, seus benefícios e comunidade para sua atenção.

Se você quer aprender mais detalhadamente sobre o que são esses outros papéis, e nós encorajamos você a fazê-lo, nós preparamos seções separadas sobre o Trusted Committer e o responsável pelo produto.

Nos 5 segmentos seguintes você aprenderá mais em detalhes sobre os vários aspectos introduzidos aqui.

O próximo segmento detalharáMente e hábitoque criam oportunidades paratornar-se um contribuinte InnerSource.

No terceiro segmento vamos olhar para oEthos do Contribuidor– ou seja, aspectos decomportamentoIsso levará a um tempo agradável e produtivo para você e a equipe anfitriã, e pode gerar mais colaboração. A analogia do convidado em casa apresentada nos vídeos introdutórios servirá de exemplo vívido.

O quarto segmento descreve as coisas práticas a fazer para tornar sua contribuição um sucesso.mecânica de contribuir. Daremos dicas práticas para alavancar quando nos prepararmos para trabalhar em uma contribuição, durante o desenvolvimento, e também no pedido de retirada.

Depois de lidarmos com o pessoal, a interação focada, e os aspectos técnicos do papel do contribuinte, o quinto segmento apresenta os benefícios de fazer o esforço para contribuir. Mostraremos benefícios de várias perspectivas: a sua, a de sua equipe, e a perspectiva da empresa em geral.

O último segmento vai recapitular o que aprendemos sobre ser um contribuinte InnerSource. Vamos compartilhar como você pode continuar sua aprendizagem de InnerSource tanto com outros vídeos e artigos on-line, e através do envolvimento com a comunidade online InnerSource.

Tornando-se um contribuinte InnerSource

contribuidores InnerSource operam fora dos limites regulares da equipe, eles são as ligações que cruzam os silos organizacionais. Como tal, eles precisam estar cientes de algumas práticas comuns que tornam este trabalho mais eficaz.

Então – você está implementando uma nova característica para o produto da sua equipe. Você precisa de alguma funcionalidade para fazer esse recurso funcionar. Em vez de pular direto na implementação, diminua um pouco: essa funcionalidade reflete uma questão geral? É algo que outras equipes da sua organização também enfrentam devido ao domínio de negócios compartilhado? Esta funcionalidade é ortogonal para o domínio do seu projeto? Se isso se aplica, então comece a olhar além de sua própria equipe: existe uma solução compartilhada que você pode usar ou melhorar para atender às suas necessidades? Deveria haver um?

Há um provérbio africano dizendo que “Se você quer ir rápido, vá sozinho. Se você quer ir longe, vá junto.” O mesmo é verdade para equipes de desenvolvimento de software:

Se quiser ser rápido, é uma ótima ideia quebrar dependências. O lado negativo disso pode ser esforço duplicado. Em particular, ao reimplementar a lógica central, há um risco real de o custo da duplicação superar o benefício da independência.

Colaborar com outras equipes permite compartilhar custos de desenvolvimento. Assim como em projetos Open Source, isso pode permitir que sua equipe construa algo maior do que você poderia ter conseguido.

Mas cada equipe tem um roteiro diferente! Eu tentei usar componentes compartilhados antes – eles sempre levou mais tempo para integrar do que teria levado para reimplementá-los. Esses componentes estavam sempre faltando em algum aspecto ou outro – e meus pedidos de recursos nunca tiveram prioridade no roteiro da outra equipe!

Em contraste com um projeto tradicional, projetos InnerSource vêm com o papel de um contribuinte. Sim, haverá momentos em que desejaria que a solução compartilhada tivesse uma nova característica. Como contribuinte, você tem a liberdade de verificar o código fonte do componente, fazer modificações nele e usar a versão melhorada resultante.

Sim, haverá momentos em que você precisa urgentemente de uma correção de bug na sua linha do tempo que não tem a mesma prioridade na equipe anfitriã. Tornar-se um contribuinte permite que você aja sozinho e apoie a equipe anfitriã com consertar esse bug.

Este modo de trabalhar requer uma mudança de mentalidade para muitos: em vez de esperar por recursos a serem implementados ou corrigidos erros, em vez de trabalhar em torno de problemas, há agora uma terceira solução. Gaste seu tempo e energia para verificar com o projeto InnerSource quais são suas necessidades e então faça a mudança diretamente no projeto compartilhado. Então, além de suas habilidades de codificação, você precisa de habilidades de comunicação para ser bem sucedido 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ã.

“Mas eu poderia simplesmente ir e bifurcar o projeto, fazer minhas mudanças lá e me salvar de toda essa coordenação em cima!”. Claro, forjar o projeto é uma maneira de fazer seu trabalho. Exceto que, a longo prazo, isso significa que cabe a você manter essa versão bifurcada para sua equipe e levar suas mudanças adiante para qualquer nova liberação que a equipe anfitriã faça. Contribuir com suas mudanças para a equipe anfitriã também significa que você pode se beneficiar de seu conhecimento mais profundo do componente. Eles podem identificar problemas em seu patch que de outra forma só teria se tornado óbvio na produção.

Um bom contribuinte pode confortavelmente fazer uma chamada para quando faz sentido técnico e empresarial introduzir uma dependência e reutilizar um componente em vez de duplicar o trabalho. Eles podem falar com a gerência para explicar os benefícios das contribuições InnerSource.

Assim como Inner.FonteApenas sobreFonteCódigo? Claro que não. Se o negócio de sua equipe depende de um componente externo, você quer ter certeza de que é bem mantido e bem executado. Como contribuidor InnerSource, você pode ajudar a equipe anfitriã de várias maneiras. Relatar problemas que você vê ao usar o componente é uma contribuição valiosa. Criar ou consertar casos de teste que mostram que o código não está funcionando como esperado é valioso. Assim como melhorar a documentação, então outros gastam menos tempo usando-a e contribuindo para ela. Apoiar outros usuários, ajudar na triagem de bugs pode ser uma contribuição valiosa. Melhorar construções é outro exemplo de uma contribuição valiosa.

Resumindo, nenhuma contribuição é pequena demais para contribuir. Aqui está um que eu fiz paraTemores/Modelos. Uma simples mudança de etiqueta em um gráfico.

Neste artigo você aprendeu sobre o que é preciso para se tornar um contribuinte. Olhamos para a mentalidade compartilhada. Nós mergulhamos profundamente nos benefícios de compartilhar soluções. Finalmente demos uma olhada no que as contribuições do InnerSource normalmente parecem.

Contribuidor Ethos

No último segmento delineamos por que você quer reutilizar componentes e se tornar ativo como contribuinte. Este artigo compartilha boas práticas sobre como contribuir com sucesso suas mudanças na base de códigos da equipe anfitriã.

Um contribuinte InnerSource tentando fazer uma contribuição para a equipe anfitriã é essencialmente um convidado em sua casa. Em geral, espera-se que um bom convidado se comporte de certa forma:

• Eles batem na porta.
• Eles antecipam e seguem as regras da casa.
• Eles entendem que não são o dono da casa e agem de acordo.

Como essas expectativas se aplicam aos projetos InnerSource?

Ao visitar seus vizinhos, provavelmente não entrará em casa sem bater ou tocar o sino da porta, mesmo que a porta esteja aberta. Da mesma forma em InnerSource como visitante você não será capaz (ou convidado) de se comprometer diretamente com qualquer repositório de códigos.

Em vez disso, depois de fazer suas mudanças na base de códigos, você as submeterá como um pedido de retirada. Como você não faria grandes mudanças e o que você considera melhorias para seus vizinhos em casa, em InnerSource você vai antecipar e seguir as diretrizes de colaboração do projeto. Por sua vez, seus anfitriões mostrarão o caminho em InnerSource que se traduz para committers de confiança existentes gastando seu tempo com convidados mentores.

E as lindas festas de verão que você foi? Geralmente há algum planejamento antes do tempo para escolher a data e hora certa, para preparar comida suficiente, ou para tê-la contribuído pelos convidados. O mesmo acontece com mudanças maiores em projetos InnerSource, um projeto provavelmente pedirá que você envie um problema descrevendo sua necessidade e sua solução proposta antes de fazer uma grande modificação. Passar tempo no projeto inicial em vez de pular direto na implementação salva os contribuintes de ter que refazer muito de seu trabalho. Compartilhar o progresso mais cedo – mesmo quando ainda não está terminado – ajuda a equipe anfitriã a orientar o contribuinte para uma solução melhor. Muito parecido.A lei de Yonik de remendos inacabadosexplica: “Um remendo semi-cozido em Jira, sem documentação, sem testes e sem compatibilidade para trás é melhor do que nenhum remendo.”

Isso implica que projetos InnerSource não dão valor à comunicação cara a cara? Não exatamente: há valor em encontrar participantes cara a cara. Lembre-se que toda a comunicação escrita carece de muita largura de banda comparada ao encontro em pessoa: não há gestos, nem imitações, nem mesmo o tom de voz para ajudar na compreensão. Reuniões pessoais são particularmente valiosas para desafios interpessoais, resolver conflitos e mal-entendidos. No entanto, a comunicação sobre as decisões do projeto deve ser mantida por escrito, para que outros possam acompanhar e influenciar o projeto, e mesmo anos depois é possível rastrear por que uma determinada decisão foi tomada.

Aqui está minha regra geral: sinta-se à vontade para encontrar-se com o café. Muitas vezes isso ajuda a formar uma equipe mais forte, especialmente quando a equipe é dividida em vários locais físicos. Certifique-se de que todas as decisões sejam tomadas de uma forma transparente e assíncrona para que todos, incluindo aquelesÀ espreitaNa sua conversa, pode entrar e se tornar contribuidores ativos. Um exemplo de quão longe se pode tomar uma decisão aberta é explicado em vários exercícios noDiário da Organização Aberto.

Agora, como você descobre onde um projeto InnerSource gostaria de discutir mudanças e direção futura do projeto? Muitos projetos InnerSource descrevem como eles gostam de ser abordados por potenciais contribuintes em seu README.MD. Se esse documento ficar muito grande para lidar, as diretrizes de contribuição tendem a ser divididas em um arquivo chamado CONTRIBUTING.MD. Seguir essas recomendações ajuda muito os contribuintes a vender a oferta.

Em todas essas interações, esteja preparado para “vender” sua contribuição para a equipe anfitriã. Articule o valor que a contribuição trará ao ecossistema deles.

A equipe anfitriã assumirá a manutenção para suas mudanças. Faz sentido oferecer-se para cumprir um30 dias de garantia.em sua submissão. Isso pode aliviar o medo da equipe anfitriã de que os Contribuintes não estejam disponíveis para suporte com correção de bugs após o tempo na contribuição.

Quando você estiver visitando seus vizinhos, eles provavelmente vão ajudá-lo em seu apartamento: eles vão lhe mostrar o caminho para sua sala de estar e onde o banheiro está localizado. Se você ficar mais tempo, eles provavelmente lhe darão mais detalhes: no meu caso, um exemplo seria evitar ligar a máquina de lavar louça e a chaleira elétrica ao mesmo tempo para evitar explodir o fusível.

Da mesma forma, cada sistema de software vem com suas próprias peculiaridades e complexidades. Muitas vezes os mais óbvios são bem documentados. Em projetos menores, esta documentação pode ser encontrada no README.Md. Em grandes, a documentação específica da contribuição pode ser encontrada no documento CONTRIBUTING.MD.

Nestes arquivos você pode esperar encontrar informações sobre como verificar e construir o projeto, como executar a suíte de testes, como enviar alterações para o projeto. Pode indicar documentação adicional se se desviar em grande parte de ferramentas padrão ou se há coisas que você deve ter em mente ao fazer mudanças.

Passar por essa documentação geralmente acaba sendo um grande economizador de tempo, já que te impede de seguir o caminho errado e avisa sobre becos sem saída. Se você descobrir que as coisas estão faltando com base em sua experiência – patches para essa documentação são normalmente muito bem-vindos: não há ninguém mais adequado para melhorá-lo do que um novo contribuinte que vê o projeto pela primeira vez.

Tente descobrir junto com o projeto em seu canal de comunicação preferido se as mudanças que você tem em mente fazem sentido em geral. No início, pode ser assustador ter essas conversas em um meio público que é arquivado e pesquisável. O benefício aqui é com outros vindo atrás de você com propostas semelhantes: em vez de seguir o mesmo caminho novamente, eles podem aprender o que já foi discutido, e começar a partir daí.

Ser um contribuinte significa estar mais perto da equipe anfitriã do que alguém apenas pedir um recurso. Ainda assim, contribuidores não são responsáveis pelo projeto de software para o qual estão contribuindo.

Como resultado, a última chamada sobre como a contribuição deve ser com a equipe anfitriã. Ajuda a se aproximar da equipe anfitriã com uma mentalidade humilde, com a suposição de que todos estão colaborando para o propósito da organização compartilhada. Ajuda a ser aberto e transparente – não só sobre o que foi implementado e como, mas também por que a mudança era necessária.

Trate qualquer feedback como um presente: outros estão tentando melhorar sua solução, salvando você de problemas mais adiante.

Há uma chance de que a equipe anfitriã não aceite sua contribuição. Nesse caso, ajuda trabalhar com a equipe, descobrir se há um sub-aspecto de sua necessidade que pode ser resolvido em seu projeto. Colabore sobre o sub-aspecto, e então encontre outra maneira de resolver os problemas restantes.

Neste segmento aprendemos a abordar melhor um projeto InnerSource como contribuinte. Também olhamos como comunicar melhor nossa necessidade de mudança e trabalhar na solução junto com a equipe anfitriã.

Mecânica de Contribuir

Você está pronto para começar a contribuir para outras equipes projetos / acordos? Você está ansioso para reduzir seus bloqueadores não por aumento de gestão, mas por colaboração? Esta seção dá conselhos práticos e destaques tem que lembrar quando faz uma contribuição InnerSource. Permite que você e a equipe anfitriã tenham uma experiência tão agradável quanto possível, estabelecendo as bases para mais contribuições e grande colaboração.

Este artigo está separado nos três passos que você provavelmente experimentará.

• Solicitando sua oportunidade de contribuição e preparando-se para trabalhar nela.
• Na verdade, criando a contribuição
• Polir e embrulhar bem o presente e apresentá-lo à equipe anfitriã.

Se sua contribuição for maior, você possivelmente passará por (algumas) dessas etapas repetidamente enquanto você se dirige ao seu objetivo comum. É muito provável que, como você faz isso, tudo vai se sentir mais e mais natural – talvez você vai até se perguntar por que você estava fazendo qualquer outra coisa antes.

Uma diferença chave é o tempo de volta. Com cada primeira contribuição você está vindo para uma nova equipe. Como resultado, você precisará conhecer sua base de códigos, tecnologias usadas, e também seu ambiente de desenvolvimento preferido (quadro de teste de pensamento, sistema de construção). Mesmo nos casos em que este tipo de ferramenta é padronizado, cada equipe terá desenvolvido algumas peculiaridades individuais. Além do lado técnico, você pode ser confrontado com diferenças na comunicação (pensar em revisões de código). Mesmo que volte depois de um tempo, os times e membros podem ter mudado. Leve o tempo que quiser para encontrar um amigo que não vê há um tempo e que está visitando agora.

Dê a si mesmo tempo suficiente. Comece cedo o suficiente, para que seu trabalho esteja disponível para você alavancar na hora que precisar. É melhor adicionar mais tempo de folga inicialmente – você vai ter uma sensação sobre as voltas vezes uma vez que você trabalhar com a equipe anfitriã. Muitas vezes, você notará uma redução no tempo por equipe anfitriã depois de fazer algumas contribuições bem-sucedidas para essa equipe anfitriã. Este efeito pode ser observado com o Open Source também, você pode ler mais sobre ele. Aqui..

Em suas equipes clássicas todos tinham uma ideia dos tempos esperados. Dentro de um contexto InnerSource este pode não ser o caso, nem devido a grandes diferenças de fuso horário (por exemplo. Seattle, EUA com PDT vs Berlim, Alemanha com CEST) ou você não está disponível em tempo integral como com sua equipe original, mesmo que eles estejam no mesmo local físico que você. Assim, para evitar frustração de ambos os lados, impaciência e outros efeitos não-trust-building, você vai precisar fazer explicitamente gestão de expectativas em relação aos seus tempos de reação esperados. Uma abordagem é apenas reagir rapidamente com um “Eu vou olhar para ele, eu não vou chegar a ele nos próximos dias embora” para um Trusted Committer feedback se você sabe que você só será capaz de voltar para eles em poucos dias. Idealmente, você pode fornecer-lhes uma estimativa aproximada quando você provavelmente terá tempo para dar uma olhada em sua entrada. Fazer isso constrói confiança por confiabilidade mesmo sobre contato não físico, maior distância ou mídia assíncrona. Confiança estabelecida permitirá que você supere incertezas no caminho colaborativo à sua frente.

InnerSource coloca enorme peso na comunicação escrita, em particular quando se trata de decisões de projeto. Isso implica que a comunicação pessoal é proibida?

Claramente não: enquanto a comunicação escrita brilha quando se trata de arquivo e buscabilidade, a comunicação pessoal brilha quando se trata de largura de banda de comunicação. Tente arranjar tempo para encontrar pessoas por trás dos nomes. Se possível, tente encontrá-los com sua bebida favorita ou comida. Quando se pode ouvir as pessoas falarem, quando se sabe suas idiossincrasias, a colaboração remota será mais fácil.

Você tem uma grande característica que você quer contribuir? Excelente! Não seria horrível se todo o seu trabalho fosse desperdiçado? Isso pode acontecer quando a equipe anfitriã já está construindo algo muito semelhante, está planejando deprecar o software, ou não vê o que você está propondo para ser um ajuste para o projeto deles. Este desafio é frequente, e muitas relações de equipe sofreram por não concordar antecipadamente que uma contribuição é um bom ajuste.

Faça-se feliz e a equipe anfitriã (e possivelmente salve algum trabalho) obtendo um acordo da equipe anfitriã sobre o design técnico/usuário da contribuição Antes Trabalhando nas mudanças e enviando um pedido de pull. Você tem que entender como a equipe anfitriã gostaria que você procurasse por isso. É melhor perguntar a Trusted Committer Sobre como discutir melhor sua proposta.

É sabedoria comprovada da arena Open Source que, se você pode escolher como discutir sua proposta, você deve tentar escolher um caminho escrito. Idealmente, escolha o caminho onde os artefatos são públicos, pesquisáveis e perma-linkáveis para permitir referenciar sua proposta em discussões posteriores sobre esta futura contribuição ou outras contribuições para vir – por você ou outros.

Este tipo de acordo inicial de alto nível vai economizar tempo em retrabalho ou rejeição do seu pedido.

Ótimo, você se familiarizou com a abordagem da equipe anfitriã, e eles estão ansiosos para receber seu pedido de retirada. Quais estão esperando por você agora?

Primeiro, você estará em menos contato direto com eles. Segundo, não se espera que você seja tão experiente e eficiente quanto pode estar nos projetos em tempo integral que sua equipe possui. Como pode lidar com isso o melhor?

Tente examinar sua documentação, os arquivos de conversa e artefatos de código da equipe anfitriã para se desbloquear. Isso é similar à situação em que você e a maioria das pessoas se encontram quando usam um dos projetos populares da OSS.

Assim como em projetos Open Source, pergunte à equipe anfitriã se as coisas não vão a lugar algum mesmo depois de tentar se desbloquear. As perguntas que você faz e as respostas que recebe ajudarão os outros a virem depois de resolver os mesmos problemas. Certifique-se de que sua comunicação termine em um arquivo pesquisável que esteja intimamente ligado ao próprio projeto. Se você vir oportunidades de melhoria fáceis para alcançar esse objetivo se ainda não for alcançado, você poderia tentar – muito educadamente – sugerir uma melhoria para sua equipe anfitriã. Às vezes o status quo surge de pura casualidade e permanece assim porque ninguém tinha uma ideia diferente ou se importava o suficiente. Sugestões para melhorias podem ser bem-vindas nesses casos. Não faz nenhum dos dois lados nenhum bem para você girar para sempre em um problema que poderia ser resolvido em alguns minutos de conversa com alguém mais experiente sobre o projeto. Tudo bem pedir ajuda.

No entanto, há uma diferença chave, trazendo vantagem para você e outras pessoas no futuro: em quase todos os casos você deve preferir os canais de comunicação oficiais dos projetos – isso pode ser uma lista de discussão, uma sala de bate-papo, um rastreador de problemas ou algo similar, dependendo do propósito de ter uma forma mais síncrona ou assíncrona de interagir, ou as diferentes necessidades de estrutura na comunicação. Todos eles geralmente têm em comum que eles são baseados em texto, arquivados, pesquisáveis e vêm com links estáveis – isso significa que sua pergunta e a resposta serão escritas, e as referências que você vincula nessas respostas também serão mantidas acessíveis. Desta forma, você pode se beneficiar deste conhecimento passivo documentado em sua busca e ajudar futuros contribuintes têm a mesma vantagem. Tal documentação passiva poderia até mesmo servir para enriquecer a documentação ‘oficial’, caso ela contivesse gemas especialmente valiosas, como definições importantes que foram criadas ad-hoc.

Como você trabalha, se você encontrar documentação desaparecida (ou desatualizada), faça um favor ao próximo contribuinte e atualize-a com o que você descobriu. As equipes do projeto estão muitas vezes felizes em receber adições, atualizações ou correções para sua documentação existente – você acabou de encontrar outra oportunidade para contribuir! (Ou apenas educadamente fornecer-lhes um feedback sobre sua experiência, e o que teria ajudado você.)

Todos temos preferências e opiniões sobre o estilo de código, indentação, etc. O projeto da equipe anfitriã também os tem. Tente se adaptar e combinar essas preferências mesmo que não seja o que você normalmente faria, e mesmo que não seja especificado nos projetos. CONTRIBUIÇÃO.. Se não tem certeza, pode sempre perguntar educadamente. No entanto, uma contribuição para um recurso ou correção de bugs não é hora de introduzir uma nova forma de estruturar ou formatar o código do projeto.

Você completou todo o trabalho essencial, descobriu todas as peculiaridades do problema e o projeto que você está contribuindo, o tempo que você planejou para o novo recurso a ser usado vem mais perto, e você quer garantir que sua contribuição seja fundida o mais rápido e suave possível.

Aqui está o que você pode fazer para tornar a revisão e fusão o mais fácil possível para o Trusted Committer e a equipe anfitriã. Isso pode ser bem parecido com o que você já pode estar fazendo em seu próprio projeto para aceitar suas mudanças. Se esse for o caso – grande, isso vai vir natural para você!

O ponto básico aqui é permitir que Trusted Committer para validar a contribuição sem sua presença e para garantir fácil manutenção. Imagine que você construiu uma característica ou manipulação de uma peculiaridade insolúvel, ou um ajuste de performance importante, e seu código não é totalmente óbvio (ou pode até mesmo parecer hacky / errado à primeira vista). Se você cobriu isso com um teste – e idealmente derramou algumas palavras sobre a lógica por trás dele em um comentário – um futuro editor será lembrado sobre o propósito do código, e o(s) teste(s) vai garantir que o valor que seu código percebe será mantido, mesmo nas novas implementações. Para conseguir isso, faça o seguinte:

• Adicione testes para sua contribuição de código, para que validar a função de sua contribuição por outros funcione bem, mesmo depois de algum tempo, quando você trabalha em outros projetos ou pode ter parado de contribuir para este projeto.
  • Muitas vezes os projetos terão verificações automatizadas contra pedidos de retirada usando esses testes e o nível de cobertura de código. Tente cumprir os critérios que esses testes impõem.
• Muitos projetos fornecerão scripts de construção e validação de projetos que permitem testar suas mudanças localmente.
  • Use-os para garantir que sua contribuição funcione o melhor possível antes de abrir um pedido.
  • Ter que rever pedidos defeituosos com erros fáceis de corrigir muitas vezes erros confiáveis. Eles não consertarão seu código, mas pedirão que o faça. Isso pode criar mais idas e voltas e retardar a fusão.
  • Mas ninguém é perfeito. Faça o seu melhor, use scripts de validação preparados se houver algum, e dê o seu melhor tiro com um pedido de puxar!
  • Se o seu pedido continua quebrando os testes, e você não pode descobrir por que depois de dar o seu melhor tiro: tente destacar esses testes no comentário do pedido, ilustrar sua compreensão atual do problema e pedir ajuda nele.
• Não se esqueça de seu próprio projeto que desencadeou sua contribuição em primeiro lugar. Crie uma construção modificada do projeto compartilhado com suas mudanças e experimente em seu próprio projeto que o consome.

Você quer garantir que seu pedido inclua qualquer atualização de documentação relevante para suas mudanças. Se a documentação morar em um lugar diferente, certifique-se de adicioná-los lá e linká-los em seu pedido.

Para tornar a revisão de código o mais fácil possível para o comitente confiável ou outras pessoas revisá-lo, tente seguir estas dicas:

• Certifique-se de que seu pedido inclui apenas as mudanças relevantes para o problema que você está completando.
• Tente evitar commits super-grandes, commits com mensagens de commit pouco claras, gazilhões de arquivos, mudanças incoerentes (por exemplo, tocando vários tópicos).
• Fornecer uma descrição clara do que este pedido de puxar muda, por que ele faz isso, e que edição e design documentos (se houve algum) que se refere.
• Se houver algo incomum ou inesperado no pedido, destaque-o e forneça a explicação. Isso tornará mais fácil raciocinar e resolver possíveis questões de bloqueio que um revisor pode ter durante a revisão.
  • O mesmo vale para o cenário em que você estava inseguro sobre a implementação ou sua abordagem – realce-o e peça uma visão.
  • Seja civilizada e espere civilidade do Trusted Committer Revisão.
• Fazer pedidos muito amplos e grandes os torna mais difíceis de rever, então levará muito mais tempo até serem aceitos.
  • Se você tem uma característica maior que você está contribuindo, muitas vezes ajuda a dividi-la em vários pedidos que são submetidos, revistos e aceitos sequencialmente. Você ainda pode ligá-los com um problema que você está se referindo.
    • Algumas ferramentas também têm funcionalidade de solicitação de recrutamento / WIP que você pode usar para marcar explicitamente o trabalho inacabado e não-polido e ainda obter feedback precoce de sua equipe anfitriã Trusted Committers.
    • Isso permite garantir que você está indo em um caminho que sua equipe anfitriã está feliz em fundir uma vez que está feito, aderindo à ideia de “libertar cedo, liberar frequentemente” de certa forma.
    • A responsabilidade da equipe anfitriã é criar uma atmosfera onde compartilhar e discutir trabalho não totalmente polido é possível e bem-vindo. Se você não pode falhar seguro, você não pode inovar, e a colaboração se torna muito difícil.
    • Tente se equilibrar entre pedir uma revisão mais cedo e fornecer mudanças significativas.

Alguns desses recursos podem estar escondidos atrás de paredes de pagamento. Às vezes seu empregador tem uma assinatura que permite o acesso, caso contrário, bibliotecas públicas da universidade muitas vezes permitem o acesso para os convidados, também.

Benefícios de se tornar um contribuinte InnerSource

Contribuintes são o sangue vital dos projetos InnerSource. Cada projeto que é executado como um projeto InnerSource vem tanto com a promessa e com o objetivo final de expandir sua equipe de desenvolvimento além dos fundadores originais, explorando o potencial de mais colaboradores entre usuários (também às vezes referidos como clientes em corporações) desse projeto.

No entanto, o que motivaria um desenvolvedor individual a gastar tempo em um projeto que não está sob a direção de seu gerente? O que motivaria um gerente a arranjar tempo para seus desenvolvedores melhorarem projetos que não estão 100% sob sua alçada?

A motivação mais óbvia é o que normalmente atrai os primeiros contribuintes para o código aberto também.

Lembra daquele inseto irritante que trabalha há tanto tempo? O tempo e energia que manter essas soluções custa? E se, ao invés de esperar que a equipe a montante conserte esse problema no futuro, você mesmo pudesse consertar? Nesta situação de “destruir sua própria coceira” os contribuintes da primeira vez geralmente começam a resolver problemas em projetos que dependem para seu trabalho diário para reduzir o número de soluções em sua própria base de código.

Ao decidir se criar e contribuir com uma solução em vez de manter sua própria solução, pense no benefício que a contribuição trará para a qualidade de suas próprias mudanças. Em vez de trabalharem em isolamento, aqueles que trabalham no projeto a montante poderão não só revisar, mas também melhorar sua solução. Você recebe apoio e orientação que acelera muito seu próprio esforço de desenvolvimento.

Passar mais tempo com os outros significa que, com o tempo, você aprenderá como a equipe funciona, como ela se organiza, que ferramenta usa para construir seu projeto. Muitas vezes seus próprios projetos se beneficiarão dessa experiência: em vez de apenas ler sobre uma nova biblioteca ou construir um sistema, você será capaz de obter experiência prática com ela antes de ir em frente e introduzi-la em seus próprios projetos. Trabalhar em mais de um projeto central significa que você será exposto a um ecossistema maior a partir do qual desenhar melhores práticas e soluções para desafios.

Um bom efeito colateral de poder passar algum do seu tempo em outras equipes é que sua reputação e impacto expandem os limites de sua própria equipe. Então, além de aprender com os outros e crescer, você começa a influenciar projetos. Você influencia diretamente através de suas próprias contribuições e compartilhando sua experiência e conhecimento sobre ferramentas de projeto e configuração. Esse compartilhamento pode ajudar o projeto a melhorar e acelerar os ciclos de desenvolvimento.

Além de todos esses critérios objetivos, há um componente que é muito difícil de medir, mas foi relatado tanto em InnerSource quanto em projetos Open Source: as pessoas participam porque encontram trabalho nesses projetos pessoalmente cumprindo e se divertindo. Provavelmente, o aspecto de estar em posição de se auto-selecionar tarefas para trabalhar tem um papel importante. Esta auto-seleção normalmente também leva a projetos de acolhimento sendo muito acolhedores e solidários em seu esforço para manter os contribuintes motivados.

Lembra daquele inseto irritante que foi finalmente consertado no rio? Por que sua equipe gastaria um esforço extra para contribuir com isso?

Para começar, significa que o custo e o tempo de manutenção estão agora com o projeto upstream. Para cada novo lançamento é sobre eles em vez de em sua equipe para ter certeza de que ele continua trabalhando com suas modificações e requisitos.

Ter membros da equipe trabalhando como colaboradores ativos em projetos sua equipe depende de meios que eles podem ter uma palavra na direção do projeto e linhas temporais, o que pode ser benéfico para sua equipe.

Usando equipes InnerSource pode estabelecer um caminho médio entre “ser independente e construir o seu próprio” (incluindo qualquer número de novos bugs que você possui) e “salvar tempo e dinheiro contando com implementações existentes” (ao custo de criar dependências de longo prazo que só pode ser influenciado de forma limitada). Dessa forma, equilibrar reimplantação versus reutilização torna-se mais fácil.

Lembra daquela funcionalidade específica do domínio da sua empresa, mas que é mantida em várias implementações em toda a empresa? E se houvesse uma maneira de evitar uma dúzia de implementações de buggy e fundi-las em um ativo compartilhado? E se o processo de desenvolvimento desse ativo compartilhado funcionasse sem o usual dreno de energia que as dependências centrais trazem para a mesa? Muitos projetos de código aberto estão sendo usados por um grande número de jogadores, alguns dos quais participam de seu projeto e desenvolvimento. Encorajar a colaboração entre equipes em projetos InnerSource a nível corporativo significa que você pode impulsionar a inovação central das bordas de sua organização.

Em geral, é bem entendido que projetos comFator de ônibusde uma ou duas pessoas representam um risco para a organização – ainda mais, quando esse projeto acaba sendo central para o propósito do negócio. InnerSource ajuda não só a tornar esses projetos transparentes, mas também fornece ferramentas para melhorar essa situação, colocando o foco em mentorar e expandir a base do contribuinte.

Enquanto a colaboração entre equipes torna difícil avaliar as contribuições individuais, também permite aprender e compartilhar conhecimento dentro da organização. Como resultado, o impacto dos indivíduos vai melhorar. Melhores práticas e inovação positiva se espalharão mais facilmente por toda a organização. Como efeito colateral, melhorias no ambiente de trabalho se espalharão mais facilmente pela organização, ajudando a reter empregados.

Do lado tecnológico, ter mais olhos com um fundo mais diversificado implica que as mudanças de código serão colocadas sob muito mais escrutínio, levando a uma melhor qualidade geral e segurança.

Finalmente, o foco em permitir que usuários e clientes do projeto participem no desenvolvimento fornece um incentivo muito claro para tornar esses projetos fáceis de começar com: baseado em ferramentas padrão, fácil de entender, fácil de reutilizar e como resultado mais modular e substituível.

Como vimos neste artigo, muitas das razões para indivíduos e corporações se ativarem em Open Source também se aplicam a projetos InnerSource. Também vimos que não são apenas razões altruístas que levam as pessoas a colaborar em projetos InnerSource – muitas vezes é fácil identificar razões de negócios para quando colaboração como esta faz muito sentido.

Conclusão

Obrigado por rever o segmento contribuinte do Caminho de Aprendizagem InnerSource Commons. Com esta seção você aprendeu sobre o papel do contribuinte – o sangue vital dos projetos InnerSource. Contribuidores são externos à equipe de donos de componentes, e trazem informações valiosas adicionais para o projeto.

Nesta seção você aprendeu sobre como se tornar um contribuinte encontrando oportunidades para contribuir. Revisamos a mentalidade e hábitos necessários para encontrar ou criar tais oportunidades. Também discutimos o ethos do papel e uma abordagem sugerida que provavelmente levará a contribuições bem sucedidas.

Dada a mentalidade, hábitos e ethos, ainda há alguns detalhes que podem impedi-lo de contribuir com sucesso – daí, discutimos essas porcas e parafusos em maior detalhe.

Por último, mas não menos importante, convencer seus companheiros de equipe e sua organização em vários níveis pode ser difícil, assim, discutimos os benefícios da contribuição de várias perspectivas para tornar este processo mais fácil para você.

Esperamos que tenha gostado de assistir os vídeos, e/ou ler os artigos, e será capaz de tirar algumas novas insights interessantes para sua jornada para InnerSource e ser um bom contribuinte.

Se você ainda não fez isso, gostaríamos de convidá-lo para aprender mais sobre os outros aspectos do InnerSource em nosso caminho de aprendizagem InnerSource: http://innersourcecommons.org/learningpath/

Convidamos você para verificar o grupo InnerSource InnerSource Commons online – sinta-se livre para participar da discussão e compartilhar suas experiências e lições aprendidas em sua organização.

Viva e tenha projetos prósperos!

Diário de trabalho

Mais de uma resposta pode estar correta em algumas perguntas.

1. Posso garantir que outros sigam minhas sugestões para melhorar o projeto.
2. A equipe anfitriã manterá as características que acrescento em nome da minha equipe.
3. Posso moldar a solução para melhor atender as necessidades da minha equipe.
4. Eu posso ajudar a moldar todos os aspectos do projeto além do próprio código (por exemplo, revisão GitHub, triagem de bugs, testes, documentação).

Por que 1 está errado: comunidades abertas não são uma ditadura. Como contribuinte, você é parte de uma comunidade ajudando a solução a crescer e prosperar. Isso pode envolver compromisso às vezes, mas pagará benefícios a mais longo prazo para você e a comunidade.

Reduzir a quantidade de trabalho necessário para implementar um recurso de cliente é uma das principais razões para InnerSource. É correto que contribuir com mudanças de volta aos projetos hospedeiros significa que a equipe anfitriã se torna consciente da mudança e vai levá-la em consideração em quaisquer refatorações que eles estão fazendo indo em frente. Dessa forma, o trabalho que você como contribuinte tem que fazer para se adaptar a novas versões está sendo reduzido significativamente. Ainda assim, isso não implica que na aceitação a equipe anfitriã será a única pessoa responsável por garantir que a mudança que você submeteu funcione como pretendido: o padrão de garantia de 30 dias fornece um meio formal para definir quanto tempo os contribuintes são responsáveis pela correção de problemas na modificação que submeteram. Na prática, os contribuintes muitas vezes se aproximam da equipe anfitriã e fornecem seus conhecimentos.

Por que 3 está correto, soluções compartilhadas desenvolvem-se com contribuições de partes interessadas. Tornar-se um contribuinte permite moldar a solução, sempre em consulta e colaboração com outros membros da comunidade.

As contribuições vão além do código. Há muitos aspectos que ajudam a manter uma solução saudável e, assim, torná-la bem sucedida, diferentes aspectos requerem habilidades diferentes, embora não tornem uma mais importante do que a outra. Se o código é a máquina, então pense nestas áreas de contribuições como a graxa que mantém a máquina funcionando suavemente.

1. Necessidades que são compartilhadas em todo o negócio são bons candidatos para InnerSource.
2. Meu projeto será o mais rápido se eu tiver o mínimo possível de dependências.
3. A equipe de hospedagem implementará as características que preciso.
4. Eu deveria trabalhar apenas em recursos necessários pela minha equipe.

Quando muitas equipes do negócio têm a mesma necessidade, um projeto InnerSource é uma ótima maneira de atender essas necessidades em escala sem trabalho duplicado.

Se você pular a chance de alavancar o código que já está escrito, você perderá tempo codificando soluções para problemas que já estão resolvidos em vez de adicionar valor único em sua equipe.

Você pode perguntar, mas pode haver momentos em que a próxima necessidade que você tem no projeto não é a próxima prioridade para a equipe anfitriã trabalhar. Nestes casos você ainda pode obter o que você precisa fazendo uma contribuição InnerSource para o projeto.

Trabalhar em outras características de um projeto, ou fazer trabalhos de fundo, como reorganizar código ou documentação, pode indiretamente contribuir para o sucesso da sua equipe, então é legítimo investir tempo nessas coisas.

Mais de uma resposta pode estar correta em algumas perguntas.

1. O trabalho da minha equipe é crucial para o sucesso da empresa, então a voz da minha equipe tem mais peso em uma comunidade de soluções compartilhadas do que em outras.
2. Como sou convidada para o projeto, tenho direito a respostas rápidas e abrangentes para minhas perguntas da equipe anfitriã.
3. Como convidado do projeto, devo me certificar de entender e seguir as regras e diretrizes como delineado na documentação associada (começando com, mas não limitado a, os arquivos README.Md e CONTRIBUTING.MD) e pode fazer perguntas respeitosamente depois para esclarecimentos ou ajuda.
4. Meu compromisso é com a mudança que ofereço. Assim que minha contribuição for aceita, meu trabalho está feito e posso focar no núcleo do meu próprio projeto novamente.

Mesmo que sua equipe possa desempenhar um papel mais central na empresa, você ainda é o convidado quando interage com um projeto InnerSource. A responsabilidade final pelas decisões tomadas sobre o projeto está com seus responsáveis confiáveis.

Não há nada de errado em fazer boas perguntas, e elas devem ser respondidas em tempo hábil. No entanto, você é um convidado e precisa respeitar o tempo e esforço dos outros na comunidade. Portanto, certifique-se de ler e entender toda a documentação disponível antes de fazer perguntas, e esteja preparado para respostas de qualquer membro do projeto educado, não apenas líderes de equipe anfitriã. Isso ajuda seu status na comunidade e evita a aleatorização.

InnerSource enfatiza a criação de documentação, tanto como pano de fundo para o trabalho (por exemplo, README.md e CONTRIBUTING.md, e para justificar decisões individuais e mudanças de código. A razão para uma cultura de documentação é fornecer a você, como contribuinte, com o fundo que precisa para encaixar sua mudança com sucesso no projeto.

Por que 4 está errado, aceitar sua contribuição é uma conquista a ser celebrada. No entanto, seu envolvimento não termina aí. Você deve planejar estar disponível no mínimo para cumprir um30 dias de garantia.em suas mudanças (e seu impacto), ou ainda melhor: ficar perto da comunidade e ajudar com contribuições adicionais.

1. Os donos de soluções e revisores dependem de contribuições, então ajudo o projeto postando uma mudança de código (como uma correção para um bug que descobri ou um novo recurso que preciso) imediatamente. A revisão do código vai resolver qualquer problema.
2. Estou confiante que minha contribuição não será rejeitada, pois isso constituiria comportamento hostil para os contribuintes.
3. Fico noiva e disponível para o projeto para apoiar minhas mudanças e ajudar a levar o projeto adiante.
4. Só trabalho com pessoas com quem estou acostumado, pois isso torna a colaboração mais eficiente.

Antes de contribuir, precisa comunicar sua intenção a outros membros do projeto. Surpresas em projetos criam muita confusão, esforço desperdiçado e irritação. Comunicação rápida e aberta enviará uma mensagem clara de intenção e aumentará as chances de uma experiência de contribuição suave.

Grandes contribuições são valorizadas em soluções abertas e compartilhadas, mas tenha em mente que você é um convidado. As alterações sugeridas ao código podem ser rejeitadas por muitas razões: porque elas são contrárias à intenção da solução, não atendem aos padrões de codificação, etc. Isto não é uma reflexão pessoal sobre você, mas uma decisão profissional. Mitigar isso entendendo os requisitos delineados na documentação do projeto (README.md, CONTRIBUTING.md, etc.) e os planos do projeto para o futuro. Se faltar documentação, pergunte sobre os padrões, expectativas e planos do projeto. Sua primeira contribuição pode ser escrever ou revisar a documentação desaparecida.

Por que 3 está correto: projetos precisam de pessoas para serem envolvidas e ficarem no topo das questões abertas, ajudar a resolver problemas, e pesar em planos. Ficar engajado te ajudará a construir uma reputação positiva e lhe proporcionar a oportunidade de aprender mais sobre o espaço de problemas do projeto.

Ao se envolver, você deve se envolver com a comunidade como um todo (todos os convidados, bem como o anfitrião em nossa metáfora) e trabalhar em aberto. Localização física ou local organizacional não deve desempenhar um papel em como você se envolve ou com quem você se envolve. Afinal, InnerSource é sobre trabalhar juntos além dos limites para o sucesso de todos.

Mais de uma resposta pode estar correta em algumas perguntas.

1. Entendo que contribuições para um bom projeto InnerSource levam quase o mesmo tempo que contribuições para o projeto da minha equipe.
2. Comunico minha intenção de contribuição para a equipe anfitriã e asseguro acordo quanto ao escopo e tempo.
3. Planejo refazer o código que encontro durante meu trabalho de contribuição ao meu estilo de código para que seja homogêneo em estilo e fácil de entender.
4. Planejo que meus pedidos sejam limitados para torná-los mais fáceis de entender, revisar e integrar.

Por muitas razões, contribuições para uma solução aberta e compartilhada provavelmente levará mais tempo do que mudanças para um projeto fechado de uma única equipe. Por exemplo, a coordenação com o anfitrião pode não ser direta como é com sua equipe imediata. Seus interesses e interesses dos anfitriões podem não se alinhar facilmente, e compromissos podem precisar ser encontrados. Logística também pode adicionar sobrecarga, como simplesmente trabalhar em diferentes fusos horários. Para mitigar esses atrasos, planejem com mais tempo. Isso aliviará o estresse e a tensão e aumentará suas chances de um engajamento bem sucedido.

Através da comunicação, você permite que todos entendam sua intenção e dêem conselhos quando necessário. A comunicação garante que você entenda os planos e objetivos dos outros e possa trabalhar juntos optimamente para o maior impacto.

Por que 3 está errado, contribuir com um recurso ou correção de bugs não é hora de introduzir um estilo de codificação ou documentação diferente. Mudar os estilos de codificação e convenção em um projeto é um grande empreendimento, então você deve alinhar suas mudanças com os estilos de codificação e documentação no projeto. Se for necessário um estilo de código diferente, fale como um problema e discuta com a equipe de hospedagem e os outros participantes fora da sua contribuição atual.

Por que 4 está correto, mudanças pequenas são mais fáceis de entender, não só no código envolvido na revisão, mas também no impacto que sua mudança sugerida pode ter no resto da solução. As discussões no âmbito limitado levarão a uma aceitação mais rápida das mudanças e, portanto, um benefício mais imediato para a solução.

1. Se eu ficar preso, revejo a documentação e o código para começar de novo. Se isso falhar, peço esclarecimentos ou ajuda nos canais públicos do projeto.
2. Meu código tem testes para as mudanças que estou contribuindo, testei e verifiquei minhas mudanças antes de contribuir, e os testes estão integrados no gasoduto CD/CI para o projeto.
3. Eu atualizei a documentação e testes para alinhar com as mudanças de código que eu contribuo.
4. Minha contribuição combina com o estilo do projeto.

Por que 1 está correto, você deve investigar a documentação que é fornecida para responder suas perguntas. Quando você reconhece que sua resposta está faltando na documentação, ou não é claramente explicado o suficiente, fazer uma pergunta ao projeto é o próximo passo certo. Não só um esclarecimento fará você se mover novamente, como ajudará futuros contribuintes.

Ter testes adequados para o código que você escreve é uma boa prática de engenharia para garantir que o código seja robusto e sustentável. Em um projeto InnerSource, os testes também ajudam a criar confiança em você como contribuinte. Automatizar os testes como parte de um processo de integração de código também permite que projetos InnerSource espalhem manutenção por todos os responsáveis do projeto, independentemente de seu status de membro com a equipe do projeto InnerSource originado. Assim, integração contínua e entrega contínua (CI/CD) são valiosas em InnerSource.

Verificando testes e documentação para as mudanças necessárias são parte de uma contribuição sólida e ajudará a guiar futuros contribuintes pelos caminhos certos.

As convenções de código foram criadas para permitir que todos os participantes entendessem o código rapidamente. Suas mudanças precisam se misturar com os atuais estilos de código e convenções para garantir que sua contribuição também seja fácil de revisar e manter por todos os outros.

Mais de uma resposta pode estar correta em algumas perguntas.

1. Posso implementar uma solução que gosto sem as restrições da equipe.
2. Eu compartilho o esforço de desenvolvimento com outros e, assim, obter funcionalidade que de outra forma eu teria precisado implementar e manter sozinho.
3. Estou construindo minha reputação dentro da empresa.
4. Posso me tornar um engenheiro melhor.

Você tem que trabalhar dentro das restrições do projeto compartilhado. Nesse aspecto, InnerSource não é muito diferente de trabalhar em uma equipe saudável.

Em projetos compartilhados, você efetivamente junta seus recursos, multiplicando seu impacto e a velocidade com que os recursos podem ser lançados.

Ao interagir com pessoas fora de sua equipe imediata, mais pessoas aprenderão a conhecer você, seu estilo de trabalho e suas habilidades, ajudando a construir sua reputação.

Por que 4 está correto: interagindo com outros engenheiros de diferentes equipes ampliará seu conhecimento e escopo, ajudando assim a projetar e construir um código melhor.

1. Uma contribuição para a base de código de outra equipe requer tipicamente menos manutenção de você do que uma mudança para sua própria base de código.
2. Uma disseminação mais ampla do conhecimento-chave reduz o risco de perder a memória organizacional quando as pessoas saem.
3. Porque outros dependem de suas contribuições, você pode garantir que as equipes dependentes apoiem a missão da sua equipe.
4. Você pode influenciar e ajudar a direcionar projetos compartilhados em apoio aos seus cenários de uso.

Uma vez que a contribuição foi integrada no projeto de outra equipe, ela se torna parte integrante dele. O contribuinte geralmente mantém a responsabilidade pelo novo recurso para um período de graça acordado, após o qual a equipe de hospedagem mantém o código como o resto do projeto. No entanto, sua equipe deve ficar noiva, porque você depende do código e o conhece bem. Isso ajudará a manter sua influência e evitar surpresas.

As mudanças organizacionais são um fato da vida. As pessoas mudam de emprego, as organizações precisam se ajustar às novas direções da empresa, e assim por diante. Quando o conhecimento chave é restrito a um único indivíduo ou equipe, ele pode se perder rapidamente. Quando o conhecimento se espalha pela comunidade usando a base de códigos compartilhados, sempre deve haver alguém com conhecimento suficiente para ajudar a impulsionar o projeto ou solução de forma consistente.

Por que 3 está errado: contribuições não são um meio para ganhar vantagem sobre os outros. Eles são um meio de compartilhar um caminho comum para o benefício de todos os participantes. A tentativa de usar contribuições como alavanca para ganhar vantagem é muitas vezes enfrentada com duras críticas, até mesmo desencadeando uma divisão na comunidade e um garfo do código, que neste caso não é saudável e indesejável.

Contribuir para um projeto InnerSource dá a melhor chance de garantir que o projeto compartilhado tenha a funcionalidade necessária para seus cenários. Não só pode contribuir com o código para conseguir o que quer, mas o processo InnerSource cria canais de comunicação e procedimentos de tomada de decisão que levam em conta suas opiniões.

1. Menos desenvolvedores são necessários para completar projetos a tempo.
2. Aumentar a documentação ajuda a determinar por que as decisões foram tomadas, e ajuda novos desenvolvedores a se atualizarem.
3. A difusão mais ampla do conhecimento incentiva a aprendizagem fora da área de trabalho imediata e elimina silos especializados sobre projetos importantes.
4. Projetos compartilhados levam a um melhor alinhamento entre equipes e colaboração cruzada.

Por que 1 está errado: InnerSource deve ser adotado para alinhar o desenvolvimento com os objetivos de cada equipe, mas não para economia de custos ou redução de pessoal. Projetos InnerSource requerem tanto codificação (e um pouco mais comunicação) do que projetos silos. Satisfação, no entanto, deve ser maior no final entre as equipes, bem como clientes.

InnerSource adota, do modelo de código aberto, o princípio de que todas as discussões e decisões devem ser escritas e preservadas. Através de listas de discussão e fóruns, comentários no repositório de controle de versão, e relatórios de bugs, a organização preserva informações sobre os objetivos do projeto e os desenvolvedores de trade-offs fizeram. Isso é valioso mais tarde para muitos propósitos.

Por que 3 está correto: práticas InnerSource conectam desenvolvedores a códigos e pessoas com quem eles normalmente não interagem. Essas conexões espalham conhecimento técnico sobre projetos específicos e criam novas vias sociais onde o conhecimento flui mais facilmente no futuro. Ambos os aspectos têm o resultado de reduzir o conhecimento siloado na empresa.

Como os projetos são compartilhados mais amplamente, as equipes que os usam tendem a se aproximar como uma necessidade de usar a mesma base de código compartilhada. Essa visão compartilhada reduz o trabalho duplicativo e é um benefício geral para a empresa.