Você já foi bloqueado em sua próxima tarefa de codificação porque outra equipe não teve tempo de adicionar em seu sistema um recurso do qual você depende? Talvez depois de um tempo você até teve que fazer algum trabalho extra em seu projeto para contornar o recurso que falta. Quão bom seria nunca ser bloqueado dessa forma? Com projetos que incorporam os princípios do InnerSource, você nunca será bloqueado esperando que outra equipe entregue algum recurso necessário. Se você não estiver obtendo o que você precisa, você pode fazer a mudança que precisa diretamente no repositório de código da outra equipe, agindo como um colaborador InnerSource. A função Contribuidor descreve uma pessoa que faz contribuições para os repositórios de um projeto da comunidade InnerSource.. Esta pessoa pode ou não fazer parte ou se ver como parte da comunidade. No entanto, para algumas pessoas, há uma espécie de jornada que os contribuidores podem fazer de apenas saber sobre a comunidade para usar o produto da comunidade para interagir com os membros da comunidade e, finalmente, começar a contribuir. Finalmente, alguns deles podem se tornar Trusted Committers. === Relacionamento com outras funções Como um Contribuidor em uma comunidade InnerSource, você irá interagir com pessoas que desempenham outras funções InnerSource, como Trusted Committer ou Product Owner e possivelmente com outros contribuidores. Às vezes, essas funções podem ser desempenhadas pela mesma pessoa, como Trusted Committer e Product Owner em pequenos projetos populares. Esta seção fornece uma visão geral muito curta das outras duas funções, mas gostaríamos de encorajá-lo a ler o https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/01 / [artigo introdutório da função de Trusted Commiter] e recomendamos que você leia o artigo Rebaixando as barreiras para entrada também, antes de se aprofundar nos detalhes da função de Contribuidor nesta seção. Você também pode assistir aos vídeos (https: //innersourcecommons.org/learn/learning-path/trusted-committer/01 /[introdução], reduzindo as barreiras de entrada) em vez de ler os artigos. ==== Trusted Committer Um Trusted Committer será seu anfitrião para sua estadia na comunidade que te recebe. Eles são responsáveis pelo repositório de código do projeto e moverão sua contribuição para produção assim que for aceita. É sua função orientá-lo em seu caminho para contribuir para a comunidade deles. Eles podem ajudá-lo diretamente ou fornecer informações para que você possa seguir sozinho. Essas informações poderiam ser regras internas estabelecidas para revisões, modelos de propostas para mudanças maiores, ndicadores 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, a sustentabilidade e a evolução do projeto tanto do ponto de vista técnico e quanto geral, com a redução da barreira para fazer contribuições para todos, bem como com o cuidado com a sua comunidade em geral. Cuidar da comunidade envolve mantê-la saudável, desenvolvê-la e a seus participantes, e defender suas necessidades em sua organização. ==== Product Owner A função do Product Owner tem alguma semelhança com a função usual de Product Owner do seu projeto. No entanto, existem diferenças: dependendo do tamanho do projeto, esta função é muitas vezes preenchida pela mesma pessoa que atua como Trusted Commiter. Em projetos maiores ou em equipes que usam o InnerSource apenas parcialmente para atender às suas necessidades ao aceitar contribuições, essa função provavelmente será preenchida por alguém que não seja um Trusted Commiter. Sua interação com a função de Product Owner provavelmente se concentrará em determinar o alinhamento com sua contribuição para o produto geral e seu roteiro. Você pode trabalhar com a função de Product Owner para garantir que os aspectos gerais da documentação, ou a consistência UI/UX, sejam mantidos ao integrar sua contribuição. Por último, mas não menos importante, alguém agindo como product owner pode ter se envolvido em trazer o projeto, seus benefícios e comunidade para sua atenção. Se você quiser aprender mais detalhes sobre o que essas outras funções são, e nós o encorajamos a fazer isso, nós preparamos seções separadas sobre Trusted Committer e Product Owner. === Visão geral da seção Nos 5 segmentos a seguir, você aprenderá mais detalhadamente sobre os vários aspectos apresentados aqui. O próximo segmento detalhará mentalidade e hábito que criam oportunidades para se tornar um Colaborador InnerSource. No terceiro segmento, examinaremos o ethos do Colaborador - ou seja, aspectos do comportamento que levarão a um momento agradável e produtivo para você e a equipe anfitriã, e podem gerar mais colaboração. A analogia guest-in-home apresentada nos vídeos introdutórios servirá como um ótimo exemplo. O quarto segmento descreve as práticas a fazer para tornar sua contribuição um sucesso - a mecânica da Contribuição. Vamos dar dicas práticas para alavancar quando se preparar para trabalhar em uma contribuição, durante o desenvolvimento, e também no pull request. Depois de lidarmos com o pessoal, o foco na interação e os aspectos técnicos do papel de contribuidor, o quinto segmento apresenta os benefícios de fazer o esforço para contribuir. Mostraremos os benefícios de várias perspectivas: a sua, a da sua equipe e a perspectiva da empresa como um todo. O último segmento irá recapitular o que aprendemos sobre ser um contribuidor InnerSource. Nós compartilharemos como você pode continuar seu aprendizado de InnerSource tanto com outros vídeos e artigos online quanto com o envolvimento com a comunidade online de InnerSource.
Aprender
Os contribuidores de InnerSource operam fora dos limites regulares da equipe, eles são os elos que cruzam os silos organizacionais Como tal, eles precisam estar cientes de algumas práticas comuns que tornam este trabalho mais eficaz. === Mindset de Compartilhamento Então, você está implementando um novo recurso para o produto da sua equipe. Você precisa de alguma funcionalidade para que esse recurso funcione. Em vez de iniciar a implementação, desacelere um pouco: essa funcionalidade reflete um problema geral? É algo que outras equipes em sua organização enfrentam também devido ao domínio de negócios compartilhado? Esta funcionalidade é ortogonal ao domínio do seu projeto? 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? Deveria haver? === Benefícios de compartilhar soluções Há um provérbio africano afirmando que "Se você quer ir rápido, vá sozinho. Se você quer ir longe, vá junto." O mesmo é verdade para as equipes de desenvolvimento de software: Se você quiser se mover rapidamente, é uma ótima ideia quebrar dependências. A desvantagem para isso pode ser esforço duplicado. 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. Colaborar com outras equipes permite compartilhar o custo de desenvolvimento. Assim como em projetos Open Source, pode permitir que sua equipe construa algo maior do que você poderia ter realizado sozinho. Mas cada equipe tem um roteiro diferente! Eu tentei usar componentes compartilhados antes - eles sempre levaram mais tempo para se integrar do que eu teria levado para reimplementá-los. Sempre faltavam um aspecto ou outro nesses componentes - e minhas solicitações de recursos nunca tiveram prioridade no roteiro da outra equipe! Em contraste com um projeto tradicional, os projetos InnerSource vêm com o papel de um Contribuidor. Sim, haverá momentos em que você deseja que a solução compartilhada tenha um novo recurso. 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. 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ã. Tornar-se um Contribuidor permite que você aja e suporte a equipe anfitriã com a correção desse bug. 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. 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. 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ã. "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!". Com certeza, bifurcar o projeto é uma maneira de fazer seu trabalho. 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. Contribuir com suas mudanças para a equipe anfitriã também significa que você se beneficiará de seu conhecimento mais profundo do componente. Eles podem detectar problemas em seu patch que de outra forma só teriam se tornado óbvios na produção. 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. Eles podem conversar com a gerência para explicar os benefícios das contribuições de InnerSource. === Escopo das contribuições InnerSource Então InnerSource é apenas sobre Código Fonte? Claro que não. 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. Como um Contribuidor de InnerSource, você pode ajudar a equipe anfitriã de várias maneiras: Relatar problemas que você encontra ao usar o componente é uma contribuição valiosa. Criar ou corrigir casos de teste que mostram que o código não está funcionando conforme o esperado é valioso. Assim como melhorar a documentação, outros gastam menos tempo usando-a e contribuindo para ela. Apoiando outros usuários, ajudar com a triagem de bugs podem ser contribuições valiosas. Melhorar os builds é outro exemplo de contribuição valiosa. Resumindo, nenhuma contribuição é muito pequena para contribuir. Aqui está uma que eu fiz para tensorflow/models. Uma mudança de rótulo simples em um gráfico === Resumo deste artigo Neste artigo você aprendeu sobre o que é preciso para se tornar um Contribuidor. Vimos a mentalidade de compartilhamento. Mergulhamos profundamente nos benefícios do compartilhamento de soluções. Finalmente, demos uma olhada em como normalmente é o escopo das contribuições do InnerSource.
Aprender
No último segmento, descrevemos por que você iria querer reutilizar componentes e se tornar ativo como Contribuidor. Este artigo compartilha as melhores práticas sobre como contribuir com sucesso suas mudanças no código base da equipe anfitriã. Um colaborador InnerSource tentando fazer uma contribuição para a equipe anfitriã é essencialmente um convidado em sua casa. Em geral, espera-se que um bom hóspede se comporte de uma certa maneira: * Eles batem na porta. * Eles pressupõem e cumprem as regras da casa. * Eles entendem que não são o proprietário da casa e agem de acordo. Como essas expectativas se aplicam a projetos InnerSource? === Entrar Ao visitar seus vizinhos, você provavelmente não entrará em sua casa sem bater na porta ou tocar a campainha, mesmo que a porta esteja aberta. Da mesma forma no InnerSource como um visitante você não poderá (ou será convidado) a escrever diretamente em qualquer repositório de código. Em vez disso, depois de fazer suas alterações na base de código, você as enviará como uma pull request. Assim como você não iria fazer grandes alterações e o que você considera melhorias na casa de seus vizinhos, em InnerSource você vai seguir as diretrizes de colaboração do projeto. Por sua vez, os seus anfitriões mostrarão o caminho - em InnerSource isso pode ser traduzido nos trusted commiters que dedicam seu tempo em orientar os convidados. E aquelas lindas festas de verão que você foi? Geralmente há algum planejamento com antecedência para escolher a data e hora certas, preparar comida suficiente ou ter a contribuição dos convidados. O mesmo acontece para mudanças maiores nos projetos InnerSource: um projeto provavelmente solicitará que você envie uma issue descrevendo sua necessidade e solução proposta antes de fazer uma grande modificação. Gastar tempo em design inicial em vez de ir direto para a implementação poupa os contribuidores de terem que refazer muito de seu trabalho. Compartilhar o progresso antecipadamente - mesmo quando ainda não está concluído - ajuda a equipe anfitriã a orientar o Contribuidor para uma solução melhor. Como explica a lei dos patches inacabados de Yonik: "Um patch inacabadoo no Jira, sem documentação, sem testes e sem compatibilidade com versões anteriores é melhor do que nenhum patch." Isso implica que os projetos InnerSource não valorizam a comunicação cara a cara? Não exatamente: há valor em conhecer os participantes cara a cara. Lembre-se de que toda comunicação escrita carece de muita largura de banda em comparação com o encontro presencial: não há gestos, nem mímicas, nem mesmo o tom de voz para ajudar na compreensão. Reuniões presenciais são particularmente valiosas para desafios interpessoais, resolvendo 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 até anos mais tarde é possível rastrear por que uma determinada decisão foi tomada. Aqui está a minha regra geral: sinta-se à vontade para se juntarem para tomar um café. Geralmente isso ajuda a construir 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 maneira transparente e assíncrona para que todos - incluindo aqueles que estão observando sua conversa - possam participar e se tornar contribuidores ativos. Um exemplo de até que ponto a tomada de decisão aberta pode ser levada é explicado em vários exercícios do Open Organization Workbook. Agora, como você descobre onde um projeto da InnerSource gostaria de discutir mudanças e a futura direção do projeto? Muitos projetos InnerSource descrevem como eles gostariam de ser abordados por potenciais Contribuidores em seus README.md. Se esse documento se torna muito grande para ser manuseado, as diretrizes de contribuição tendem a ser divididas em um arquivo chamado CONTRIBUTING.md. Seguir essas recomendações ajuda muito aos Colaboradores para venderem a sua oferta. Em todas essas interações, esteja preparado para "vender" sua contribuição para a equipe anfitriã. Articular o valor que a contribuição trará ao seu ecossistema. A equipe anfitriã será a que assumirá a manutenção das suas alterações. Faz sentido oferecer uma garantia de 30 dias em seu envio. Isso pode aliviar o medo da equipe anfitriã de que os Contribuidores não estejam disponíveis para suporte com a correção de erros após o tempo de contribuição. === Antecipar e seguir as regras da casa Quando você estiver visitando seus vizinhos, eles provavelmente te guiarão em seu apartamento: eles mostrarão o caminho para a sala de estar e onde o banheiro está localizado. Se você ficar mais tempo, 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 desarmar o disjuntor. 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, essa documentação pode ser encontrada no README.md. Em projetos maiores, a documentação específica de contribuição pode ser encontrada no documento CONTRIBUTING.md. Nesses arquivos, é possível encontrar informações sobre como efetuar check-out e construir o projeto, como executar o conjunto de testes e como enviar mudanças para o projeto. Ele pode apontar para a documentação adicional se ela se desviar muito do conjunto de ferramentas padrão - ou se houver coisas que você deve ter em mente ao fazer mudanças. Passar por essa documentação geralmente acaba sendo uma grande economia de tempo, pois impede que você siga o caminho errado e te avisa sobre os becos sem saída. Se você achar que algumas coisas estão faltando com base em sua experiência - correções para essa documentação são geralmente muito bem-vindas: não há ninguém mais adequado para melhorá-la do que um novo colaborador 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 da empresa que é arquivado e pesquisável. O benefício aqui é com outros que vêm depois de você com propostas semelhantes: em vez de percorrer exatamente o mesmo caminho novamente, eles podem aprender com o que já foi discutido e começar a partir daí. === Entenda que eles não são os donos da casa e aja de acordo. Ser um Contribuidor essencialmente significa estar mais perto da equipe anfitriã do que alguém simplesmente solicitando um recurso. Ainda assim, os contribuidores não são responsáveis pelo projeto de software para o qual estão contribuindo. Como resultado, a palavra final sobre como a contribuição deve ser é da equipe anfitriã. Ajuda abordar a equipe anfitriã com uma mentalidade humilde, presumindo que todos estão colaborando para o propósito da organização compartilhada. Ajuda ser aberto e transparente, não apenas sobre o que foi implementado e como, mas também o porquê da mudança ter sido necessária. Trate qualquer feedback como um presente: os 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 solucionado em seu projeto. Colabore nesse sub-aspecto e, em seguida, encontre outra maneira de resolver os problemas restantes de sua parte. ## Resumo deste segmento Neste segmento, aprendemos como abordar melhor um projeto InnerSource como um Contribuidor. Também analisamos como comunicar melhor nossa necessidade para a mudança e trabalhar na solução em conjunto com a equipe anfitriã.
Aprender
Você está pronto para começar a contribuir com projetos / repositórios de outras equipes? Quer reduzir seus bloqueios colaborando em vez de gerenciar? Esta seção fornece conselhos práticos e destaca pontos a serem lembrados ao fazer uma contribuição InnerSource. Ele permite que você e a equipe anfitriã tenham a experiência mais agradável possível, estabelecendo a base para mais contribuições e grande colaboração. Este artigo é separado nas três etapas 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 para a equipe anfitriã. Se a sua contribuição for maior, você possivelmente percorrerá (alguns) desses passos repetidamente à medida que você iterar em direção ao objetivo comum. É muito provável que, à medida que você fizer isso, tudo se torne cada vez mais natural para você - você pode até se perguntar por que estava fazendo outra coisa antes. === Preparando para trabalhar ==== Tempos de entrega Uma diferença fundamental é o tempo de entrega. Com cada nova contribuição, você está chegando a uma nova equipe (anfitriã). Como resultado, você precisará conhecer sua base de código, as tecnologias usadas e também seu ambiente de desenvolvimento preferido (pense em uma estrutura de teste, sistema de build). Mesmo nos casos em que estes tipos de ferramentas estão padronizados, cada equipe terá desenvolvido algumas peculiaridades individuais. Além do lado técnico, você pode se deparar com diferenças na comunicação (pense nas renisões de código). Mesmo se você estiver voltando depois de um tempo, as práticas e os membros das equipes podem ter mudado. Não tenha pressa, como faria para conversar com um amigo que você não vê há algum tempo e que você está visitando agora. Dê tempo suficiente a si mesmo. Comece com antecedência suficiente, para que seu trabalho esteja disponível para você aproveitar no momento que precisar. É melhor adicionar mais tempo de folga inicialmente - você terá uma melhor ideia sobre os tempos de resposta depois de trabalhar com a equipe anfitriã. Muitas vezes, você notará uma redução no tempo de resposta por parte da equipe anfitriã depois de fazer algumas contribuições bem-sucedidas para essa equipe anfitriã. Esse efeito pode ser observado com Open Source também, você pode ler mais sobre ele aqui. ==== Gestão de expectativas Em suas equipes tradicionais, todos tinham uma ideia dos tempos de resposta. Dentro de um contexto InnerSource, isso pode não ser o caso, seja devido a grandes diferenças de fuso horário (por exemplo, Seattle, EUA com PDT vs Berlim, Alemanha com CEST) ou você não estar disponível em tempo integral como com sua equipe original, mesmo se eles estiverem no mesmo local físico que você. Assim, para evitar a frustração de ambos os lados, impaciência e outros efeitos que geram desconfiança, você precisará explicitamente fazer o gerenciamento de expectativas com relação aos tempos de resposta esperados. Uma abordagem é apenas reagir rapidamente com um "Vou dar uma olhada, embora não o faça nos próximos dias" a um comentário de um Trusted Committeter se você souber que só poderá respondê-lo em alguns dias. O ideal é que você possa fornecer a eles uma estimativa aproximada de quando provavelmente terá tempo para dar uma olhada em suas opiniões. Fazer isso constrói confiança através da confiabilidade, mesmo por meio de contato não físico, maior distância ou mídia assíncrona. A confiança estabelecida permitirá que você supere os obstáculos da incerteza na jornada colaborativa à sua frente. ==== Construindo confiança InnerSource valoriza muito a comunicação escrita - em particular quando se trata de decisões de projeto. Isso implica que a comunicação presencial é proibida? Calor que não: enquanto a comunicação escrita brilha quando se trata de arquivamento e capacidade de pesquisa, a comunicação presencial brilha quando se trata de largura de banda de comunicação. Tente reservar um tempo para se encontrar com as pessoas por trás dos nomes. Se possível, tente encontrá-los para uma bebida ou para comer algumas coisa. Quando você é capaz de ouvir as pessoas falando, quando você sabe suas idiossincrasias, a colaboração remota se tornará mais fácil. ==== Evitando rejeição Você tem uma funcionalidade grande que deseja 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 descontinuar o software, ou não vê o que você está propondo para ser um ajuste para seu projeto. Esse desafio é frequente, e muitas relações de equipe sofreram por não concordarem antecipadamente que uma contribuição é um bom ajuste. Deixe você e a equipe anfitriã felizes (e possivelmente economize algum trabalho) obtendo o acordo da equipe anfitriã sobre o design técnico/do usuário da contribuição antes de trabalhar nas alterações e enviar um pull request. Você precisará entender como a equipe anfitriã gostaria que você abordasse isso. É melhor perguntar a um Trusted Committer sobre a melhor forma de discutir sua proposta. No âmbito do Open Source tem sido repetidamente demonstrado que se você pode escolher como discutir sua proposta, você deve tentar escolher uma forma escrita. Idealmente, escolha a forma em que os artefatos sejam públicos, pesquisáveis e permanentemente linkáveis para permitir a referência à sua proposta em discussões posteriores sobre esta contribuição futura ou outras contribuições futuras - por você ou por outros. Esse tipo de acordo inicial de alto nível economizará tempo no retrabalho ou na rejeição de seu pull request no futuro. === Criando o pull request ==== Comunicação e desbloqueio Ótimo, você se familiarizou com a abordagem da equipe anfitriã e eles estão ansiosos para receber seu pull request. Quais dicas estão esperando por você agora? Primeiro, você terá menos contato direto com eles. Em segundo lugar, não é esperado que você tenha tanto conhecimento e proficiência quanto seria nos projetos de tempo integral de sua equipe. Como você pode lidar com isso agora da melhor forma possível? Tente examinar a documentação, os arquivos de conversa e os artefatos de código da equipe para se desbloquear. Isso é semelhante à situação em que você e a maioria das pessoas provavelmente se encontram ao usar um dos projetos OSS populares. Assim como em projetos Open Source, pergunte à equipe anfitriã se as coisas não avançam mesmo depois de tentar se desbloquear. As perguntas que você faz e as respostas que você recebe ajudarão a outros que vêm depois de você a 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. Caso você veja oportunidades fáceis de melhoria para atingir essa meta, caso ela ainda não tenha sido alcançada, você pode tentar - muito educadamente - sugerir uma melhoria à sua equipe anfitriã. Às vezes, o status quo surge por pura casualidade e permanece assim porque ninguém teve uma ideia diferente ou se importou o suficiente. Sugestões de melhoria podem ser bem-vindas nesses casos. Não faz bem algum a nenhum dos lados ficar girando para sempre em torno de um problema que poderia ser resolvido em uma conversa de alguns minutos com alguém com mais conhecimento do projeto. Tudo bem pedir ajuda. Porém, há uma diferença fundamental que trará vantagens 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 ferramenta de gestão de incidentes ou algo semelhante, dependendo do propósito de ter uma maneira mais síncrona ou assíncrona de interagir, ou as diferentes necessidades de estrutura na comunicação. Todos eles geralmente têm em comum o fato de serem baseados em texto, arquivados, pesquisáveis e vêm com links estáveis - isso significa que sua pergunta e a resposta serão anotadas, e as referências que você vincular nessas respostas também serão mantidas acessíveis. Desta forma, você poderá se beneficiar da busca por conhecimento documentado passivamente. E ajudar futuros colaboradores a ter a mesma vantagem. Essa documentação passiva poderia até servir para enriquecer a documentação 'oficial', caso ela contenha jóias especialmente valiosas - como definições importantes que foram criadas ad hoc. Conforme você trabalha, se você identificar ausência de documentação (ou documentação desatualizada), faça um favor ao próximo Contribuidor e atualize com o que você descobriu. As equipes do projeto geralmente ficarão felizes em receber adições, atualizações ou correções para a 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 lhe ajudado.) ==== Elaborando o código Todos nós temos nossas preferências e opiniões sobre estilo de código, indentação, etc. O projeto da equipe anfitriã também tem. Tente adaptar e combinar essas preferências mesmo que não seja o que você faria normalmente, e mesmo que não esteja especificado no `CONTRIBUTING.md` do projeto. Se você não tem certeza, você sempre pode pedir educadamente. No entanto, uma contribuição para um recurso ou uma correção de bug não é o momento certo de introduzir uma nova maneira de estruturar ou formatar o código do projeto. === Enviando o pull request Você concluiu todo o trabalho essencial, descobriu todas as peculiaridades do problema e do projeto para o qual está contribuindo, o tempo planejado para o novo recurso ser usado está mais próximo e você quer ter certeza de que sua contribuição será mesclada o mais rápido e tranquilamente possível. Aqui está o que você pode fazer para tornar a revisão e mesclagem o mais fácil possível para o Trusted Committer e a equipe anfittriã. Isso pode ser bastante semelhante ao que você já está fazendo em seu próprio projeto para que suas mudanças sejam aceitas. Se esse é o caso - ótimo, isso vai ser natural para você! ==== Teste e automação O ponto básico aqui é permitir que o Trusted Committer valide a contribuição sem sua presença e assegure fácil manutenção. Imagine que você construiu um recurso ou tratou de uma peculiaridade insolúvel, ou um importante ajuste de desempenho, e seu código não é totalmente óbvio (ou pode até parecer hackeado/errado à primeira vista). Se você tiver coberto isso com um teste - e, idealmente, adicionou algumas palavras sobre a lógica por trás disso em um comentário - um futuro editor será lembrado sobre o propósito do código, e o(s) teste(s) garantirão que o valor do seu código os resultados serão mantidos, mesmo nas novas implementações. Para conseguir isso, faça o seguinte: * Adicione testes para sua contribuição de código, para que a validação da função de sua contribuição por outras pessoas funcione bem, mesmo depois de algum tempo, quando você estiver trabalhando em outros projetos ou tiver parado de contribuir para este projeto. Muitas vezes, os projetos terão verificações automatizadas contra pull requests usando esses testes e o nível de cobertura de código. Tente atender aos critérios que esses testes impõem. * Muitos projetos fornecerão scripts de construção e validação de projeto que permitem testar localmente suas mudanças. Use-os para garantir que sua contribuição funcione o melhor possível antes de abrir um pull request. Ter que revisar pull requests defeituosas com erros fáceis de corrigir muitas vezes incomoda os trusted committers. Eles não corrigirão seu código, mas solicitarão que você o faça. Isso pode criar mais idas e voltas e retardar a mesclagem. Ninguém é perfeito. Faça o seu melhor, use scripts de validação preparados se houver, e dê o seu melhor com um pull request! Se seu pull request continua quebrando os testes e você não consegue descobrir o porquê depois de dar o seu melhor: tente destacar esses testes no comentário do pull request, ilustre seu entendimento atual do problema e peça ajuda sobre. * Não se esqueça do seu próprio projeto que desencadeou a sua contribuição em primeiro lugar. Crie uma versão modificada do projeto compartilhado com suas alterações e teste em seu próprio projeto que a consome. ==== Documentação e capacidade de revisão Você deseja assegurar que seu pull request inclua quaisquer atualizações de documentação relevantes para suas alterações. Se a documentação estiver em um local diferente, certifique-se de incluí-la e vinculá-la em seu pull request. Para tornar a revisão do código o mais fácil possível para o trusted committer ou outras pessoas que o revisam, tente seguir estas dicas: * Certifique-se de que seu pull request inclua apenas as mudanças relevantes para o problema que você está concluindo. * Tente evitar commits muito grandes, commits com mensagens de commit pouco claras, zilhões de arquivos, alterações incoerentes (por exemplo, tocar em vários tópicos). * Forneça uma descrição clara do que esse pull request muda, por que faz isso e quais documentos de emissão e design (se houver) a que ele se refere. * Se houver algo incomum ou inesperado no pull request, destaque e forneça a explicação. Isso tornará mais fácil raciocinar e resolver possíveis questões de bloqueio que um revisor possa ter durante a revisão. O mesmo vale para o cenário em que você não tinha certeza da implementação ou da sua abordagem - destaque-a e peça um insight. Seja civilizado e espere civilidade da revisão do Trusted Committe. * Fazer pull requests muito amplos e grandes os tornam mais difíceis de revisar, então levará muito mais tempo até que eles sejam aceitos. Se você tiver um recurso maior que você está contribuindo, geralmente ajuda se você dividi-lo em vários pull requests que são enviados, revisados e aceitos sequencialmente. Ainda é possível conectá-los a um problema ao qual você está se referindo. * Algumas ferramentas também têm a funcionalidade de pull request de Rascunho / WIP que você pode usar para marcar explicitamente o trabalho inacabado e não polido e ainda obter feedback antecipado dos Trusted Committers. * Isso permite que você assegure que você está seguindo um caminho que sua equipe anfitriã ficará feliz em mesclar assim que terminar, aderindo de certa forma à ideia de "lançar antecipadamente, liberar frequentemente". * 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, você não pode inovar, e a colaboração torna-se muito difícil. * Tente equilibrar entre pedir uma revisão antecipada e fornecer mudanças significativas para revisão. === Artigos adicionais Alguns desses recursos podem estar escondidos atrás de acessos pagos. Às vezes, seu empregador tem uma assinatura que permite o acesso, caso contrário, as bibliotecas universitárias públicas também permitem o acesso aos convidados. ==== Construção de confiança através da colaboração
Aprender
Os colaboradores são a força vital dos projetos da InnerSource. Cada projeto executado como um projeto InnerSource vem 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 os usuários (às vezes também chamados de clientes em corporações) daquele 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 reservar tempo para que seus desenvolvedores melhorassem projetos que não estão 100% sob sua alçada? === Motivação individual A motivação mais óbvia é o que normalmente atrai os primeiros contribuidores para o Open Source também. Lembra daquele bug irritante que você tem trabalhado por tanto tempo? O tempo e a energia que a manutenção dessas soluções custam? E se, em vez de esperar que a equipe de envio de dados corrija esse problema no futuro, você pudesse ir em frente e corrigi-lo? Nessa situação de "coçar sua própria coceira", os colaboradores iniciantes geralmente começam a corrigir problemas em projetos dos quais eles dependem para seu trabalho diário para reduzir o número de soluções alternativas em sua própria base de código. Ao decidir se deve criar e contribuir com uma correção em vez de manter sua própria solução alternativa, pense no benefício que a contribuição trará para a qualidade de suas próprias alterações. Em vez de trabalhar isoladamente, aqueles que trabalham no projeto upstream poderão não apenas revisar, mas também melhorar sua solução. Você obtém suporte e orientação que acelera muito seu próprio esforço de desenvolvimento. Passar mais tempo com os outros significa que, ao longo do tempo, você aprenderá como a equipe funciona, como ela se organiza, quais ferramentas ela usa para construir seu projeto. Muitas vezes seus próprios projetos se beneficiarão dessa experiência: em vez de apenas ler sobre alguma nova biblioteca ou sistema de construção, você será capaz de ganhar experiência prática com ela antes de ir em frente e introduzí-la em seus próprios projetos. Trabalhar em mais de um projeto principal significa que você estará exposto a um ecossistema maior do qual poderá extrair melhores práticas e soluções para desafios. Um bom efeito colateral de ser capaz de passar algum 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 por meio de suas próprias contribuições e compartilhando sua experiência e conhecimento sobre as ferramentas e a configuração do projeto. Esse compartilhamento pode ajudar o projeto upstream 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 que foi relatado tanto em InnerSource quanto em projetos Open Source: as pessoas participam porque acham que o trabalho nesses projetos é pessoalmente satisfatório e divertido. Muito provavelmente, o aspecto de estar em uma posição para realmente selecionar tarefas para trabalhar desempenha um papel importante. Esta auto-seleção normalmente também faz com que os projetos anfitriões sejam muito receptivos e solidários em seus esforços para manter os colaboradores motivados. === Motivação no nível da equipe Lembra daquele bug irritante que finalmente foi corrigido? Por que sua equipe deve gastar um esforço extra para contribuir com essa correção para o projeto upstream? Por um lado, significa que o custo de manutenção e o tempo estão agora com o projeto de envio de dados. Para cada nova versão, cabe a eles, e não à sua equipe, garantir que continue funcionando com suas modificações e requisitos. Ter membros da equipe trabalhando como colaboradores ativos em projetos dos quais sua equipe depende significa que eles podem ter uma palavra a dizer na direção do projeto e prazos, o que pode ser benéfico para sua equipe. Usando o InnerSource, as equipes podem estabelecer um caminho intermediário entre "ser independente e construir seu próprio" (incluindo qualquer número de novos bugs que você possui) e "economizar tempo e dinheiro confiando em implementações existentes" (ao custo de criar dependências de longo prazo que só podem ser influenciadas de forma limitada). Dessa forma, equilibrar a reimplementação versus a reutilização se torna mais fácil. === Motivação da empresa Lembra daquela funcionalidade que é específica do domínio da sua empresa, mas que é mantida em múltiplas implementações em toda a empresa? E se houvesse uma maneira de evitar uma dúzia de implementações problemáticas e fundi-las em um ativo compartilhado? E se o processo de desenvolvimento para esse ativo compartilhado fosse executado sem o consumo usual de energia que as dependências centrais trazem à mesa? Muitos projetos open source estão sendo usados por um grande número de participantes - alguns dos quais participam de seu design e desenvolvimento. Incentivar a colaboração entre equipes em projetos InnerSource no nível corporativo significa que você pode impulsionar a inovação central a partir das bordas de sua organização. Em geral, é bem entendido que projetos com um bus factor de uma ou duas pessoas representam um risco para a organização - ainda mais, quando esse projeto acaba por ser central para o propósito do negócio. O InnerSource ajuda não apenas a tornar esses projetos transparentes, mas também fornece ferramentas para melhorar essa situação, colocando o foco em orientar e expandir a base de contribuidores. Embora a colaboração entre equipes torne difícil avaliar as contribuições individuais, ela também permite o aprendizado e o compartilhamento de 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, as melhorias no ambiente de trabalho se espalharão mais facilmente pela organização, ajudando a reter os funcionários. No lado tecnológico, ter mais olhos com uma formação mais diversificada implica que as alterações de código serão submetidas a uma análise muito mais rigorosa, levando a uma melhor qualidade e segurança globais. Finalmente, o foco em permitir que os usuários do projeto e clientes participem do desenvolvimento fornece um incentivo muito claro para tornar esses projetos fáceis de começar: com base em ferramentas padrão, fácil de entender, fácil de reutilizar e, como resultado, mais modular e substituível. === Conclusão Como vimos neste artigo, muitas das razões para indivíduos e corporações se tornarem ativos no 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 a colaboração como esta faz muito sentido.
Aprender
Obrigado por revisar o segmento de Contribuidor do Caminho de Aprendizagem da InnerSource Commons. Nsta seção você aprendeu sobre o papel do Contribuidor - a força vital dos projetos InnerSource. Os contribuidores são externos à equipe de proprietários do componente e trazem informações valiosas adicionais ao projeto. Nesta seção, você aprendeu sobre como se tornar um contribuidor, encontrando oportunidades para contribuir. Revisamos a mentalidade e os hábitos necessários para encontrar ou criar essas oportunidades. Também discutimos o espírito do papel e uma abordagem sugerida que provavelmente levará a contribuições bem-sucedidas. Dada a mentalidade, os hábitos e o espírito certos, ainda há alguns detalhes que podem impedir que você contribua com sucesso - por isso, discutimos essas partes em mais detalhes. Por último, mas não menos importante, convencer seus colegas de equipe e sua organização em vários níveis pode ser difícil, então discutimos os benefícios da contribuição de várias perspectivas para tornar esse processo mais fácil para você. Esperamos que você tenha gostado de assistir aos vídeos, e / ou ler os artigos, e que possa obter alguns novos insights interessantes para sua jornada em direção ao InnerSource e ser um bom contribuidor. Se você ainda não fez isso, gostaríamos de convidá-lo a saber mais sobre os outros aspectos do InnerSource em nosso caminho de aprendizado do InnerSource: http://innersourcecommons.org/learningpath/ Convidamos você a conferir o grupo InnerSource InnerSource Commons online - sinta-se à vontade para participar da discussão e compartilhar suas experiências e lições aprendidas em sua organização. Viva por muito tempo e tenha projetos prósperos!
Aprender