From cc3838dca0699341383a66d2f371226546a5743a Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 16 Aug 2023 00:22:59 +0000 Subject: [PATCH] Update Learning Path articles --- .../learning-path/introduction/01.pt-br.md | 27 ++++ .../learning-path/introduction/02.pt-br.md | 75 ++++++++++ .../learning-path/introduction/03.pt-br.md | 81 ++++++++++ .../learning-path/introduction/04.pt-br.md | 51 +++++++ .../learning-path/introduction/05.pt-br.md | 120 +++++++++++++++ .../learning-path/introduction/06.pt-br.md | 29 ++++ .../learning-path/introduction/07.pt-br.md | 140 ++++++++++++++++++ .../learning-path/introduction/08.pt-br.md | 90 +++++++++++ .../introduction/_index.pt-br.md | 9 ++ .../trusted-committer/01.pt-br.md | 2 +- .../trusted-committer/03.pt-br.md | 2 +- .../trusted-committer/04.pt-br.md | 37 +++++ 12 files changed, 661 insertions(+), 2 deletions(-) create mode 100644 content/en/learn/learning-path/introduction/01.pt-br.md create mode 100644 content/en/learn/learning-path/introduction/02.pt-br.md create mode 100644 content/en/learn/learning-path/introduction/03.pt-br.md create mode 100644 content/en/learn/learning-path/introduction/04.pt-br.md create mode 100644 content/en/learn/learning-path/introduction/05.pt-br.md create mode 100644 content/en/learn/learning-path/introduction/06.pt-br.md create mode 100644 content/en/learn/learning-path/introduction/07.pt-br.md create mode 100644 content/en/learn/learning-path/introduction/08.pt-br.md create mode 100644 content/en/learn/learning-path/introduction/_index.pt-br.md create mode 100644 content/en/learn/learning-path/trusted-committer/04.pt-br.md diff --git a/content/en/learn/learning-path/introduction/01.pt-br.md b/content/en/learn/learning-path/introduction/01.pt-br.md new file mode 100644 index 0000000000..e6a1b157cd --- /dev/null +++ b/content/en/learn/learning-path/introduction/01.pt-br.md @@ -0,0 +1,27 @@ +--- +title: Introdução +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Armando Guimarães + url: https://github.com/ArmandoGuimaraes + - name: rrrutledge + url: https://github.com/rrrutledge +image: https://img.youtube.com/vi/l93ohSHhr5U/mqdefault.jpg +featured: true +weight: 1 +youtubeCode: l93ohSHhr5U +--- +
+

Esta Trilha de Aprendizado fornece uma introdução ao InnerSource. +InnerSource é a aplicação de práticas e princípios de código aberto ao desenvolvimento de software dentro da empresa. +O software InnerSource permanece proprietário da empresa, mas dentro dela está aberto para qualquer pessoa usá-lo e contribuir com ele. +Essa estratégia permite uma colaboração ampla e eficaz, produzindo software responsivo e ágil para as necessidades em constante mudança de seus muitos interessados internos.

+
+
+

Esta Trilha de Aprendizado ensina como reconhecer situações que são boas candidatas para o InnerSource. +Descreveremos em alto nível como o InnerSource pode ajudar nessas situações. +Você se familiarizará com os termos compartilhados usados ao discutir o InnerSource. +Também enumeraremos os princípios-chave nos quais o InnerSource se baseia e os benefícios vistos quando ele é aplicado de forma eficaz.

+
+ \ No newline at end of file diff --git a/content/en/learn/learning-path/introduction/02.pt-br.md b/content/en/learn/learning-path/introduction/02.pt-br.md new file mode 100644 index 0000000000..f96b01ccb4 --- /dev/null +++ b/content/en/learn/learning-path/introduction/02.pt-br.md @@ -0,0 +1,75 @@ +--- +title: Quais problemas o InnerSource resolve? +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Armando Guimarães + url: https://github.com/ArmandoGuimaraes + - name: rrrutledge + url: https://github.com/rrrutledge +image: https://img.youtube.com/vi/v9fL-E3ZVdc/mqdefault.jpg +featured: false +weight: 2 +youtubeCode: v9fL-E3ZVdc +--- +
+

A InnerSource incentiva e recompensa a colaboração e a reutilização de código com qualquer pessoa, independentemente de sua posição na estrutura organizacional da empresa. +Essa abordagem difere do que é visto em organizações tradicionais, onde ideias e produtos de trabalho tendem a ficar presos dentro dos limites da hierarquia corporativa interna e seus silos. +Vamos explorar uma situação que dá um exemplo dessa ideia.

+
+
+

Imagine duas equipes na mesma empresa entregando softwares separados com o software de uma equipe dependendo do software da outra. +Um exemplo pode ser uma experiência do usuário que depende de um serviço de API para recuperar dados para exibição. +Essa situação é comum em grandes empresas, onde uma única equipe de produção de software pode ter dezenas ou centenas de consumidores.

+
+
+

Quando as equipes de consumo precisam de muitos recursos, as equipes de produção normalmente têm algum tipo de requisitos e processo de priorização para decidir em quais recursos trabalharão. +Para solicitações de recursos críticos que não são priorizadas para trabalho imediato, a equipe de consumo geralmente pode escolher uma das três opções abaixo, cada uma com suas próprias desvantagens.

+
+
+
    +
  1. +

    Espere. A equipe de consumo pode não fazer nada e continuar sem a funcionalidade solicitada. +Esta opção requer a menor quantidade de trabalho do seu lado. +Dependendo do benefício da solicitação de recurso, esperar pode ser bom. +No entanto, pode vir com muita dor, especialmente se a funcionalidade solicitada nunca for entregue.

    +
    2. +
  2. +

    Gambiarra. Uma equipe consumidora que não quer esperar pode fazer trabalho extra em outro lugar para compensar a ausência do recurso solicitado. +Este trabalho extra pode vir como mudança no projeto alvo. +Alternativamente, eles podem criar um novo projeto que atenda às suas necessidades e substitua o uso de todo ou parte do sistema da equipe de produção (duplicação de código/projeto). +Essa estratégia permite que a equipe consumidora obtenha o recurso solicitado apenas por meio de seus próprios esforços. Ele vem com várias desvantagens, no entanto.

    +
    +
      +
    1. +

      Qualquer trabalho feito pela equipe de consumo permanece indisponível para qualquer outro consumidor com a mesma solicitação de recurso.

      +
      2. +
    2. +

      A equipe de consumo inadvertidamente se inscreveu para o fardo de longo prazo de manter o código recém-escrito, que não está no domínio de competência da equipe principal.

      +
      3. +
    3. +

      A empresa como um todo adquire projetos e códigos duplicados no mesmo espaço de problema.

      +
      4. +
    +
    +
    3. +
  3. +

    Escalar. A equipe de consumo pode não aceitar um "não" como resposta e, em vez disso, advogar para alguém na hierarquia de gerenciamento dos produtores para influenciar (ou forçar) a equipe de produção a fazer o trabalho. +Essa opção parece atraente para a equipe consumidora porque eles obtêm o recurso solicitado sem fazer o trabalho de implementá-lo ou mantê-lo. +No entanto, ainda é um empecilho para a equipe, porque necessariamente desvia um pouco de sua atenção e trabalho para a tarefa de escalonamento que não é de engenharia. +Além disso, essa opção não é dimensionável, pois há apenas algumas vezes em que um consumidor pode escalar solicitações de recursos antes de prejudicar sua credibilidade. +A escalação é igualmente perturbadora (ainda mais) para os membros da equipe de produção, que são retirados de seu fluxo de trabalho normal e métodos de priorização para lidar com a solicitação de recurso escalada.

    +
    4. +
+
+
+

Esta discussão prepara o terreno para o InnerSource. +O InnerSource se aplica ao mesmo tipo de situação em que uma equipe de consumo não consegue obter o que precisa por meio de solicitação de recurso. +O InnerSource fornece uma maneira para as equipes obterem os benefícios de esperar, solução alternativa e escalar sem as desvantagens associadas.

+
+
+

O InnerSource também oferece uma melhoria geral à cultura de engenharia, pois os engenheiros têm a chance de trabalhar com uma variedade maior de novas tecnologias e pessoas. +Os desenvolvedores orientam e aprendem uns com os outros enquanto compartilham ideias e soluções em silos organizacionais. +Engenheiros e equipes podem reutilizar soluções internas para problemas de commodities, permitindo que se concentrem em fluxos de trabalho de maior valor para a organização.

+
+ \ No newline at end of file diff --git a/content/en/learn/learning-path/introduction/03.pt-br.md b/content/en/learn/learning-path/introduction/03.pt-br.md new file mode 100644 index 0000000000..482289a892 --- /dev/null +++ b/content/en/learn/learning-path/introduction/03.pt-br.md @@ -0,0 +1,81 @@ +--- +title: Como funciona o InnerSource? +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Armando Guimarães + url: https://github.com/ArmandoGuimaraes + - name: rrrutledge + url: https://github.com/rrrutledge +image: https://img.youtube.com/vi/jPPwnaEBd8U/mqdefault.jpg +featured: false +weight: 3 +youtubeCode: jPPwnaEBd8U +--- +
+

Digamos que a equipe A use um software produzido pela equipe B. +A equipe A envia uma solicitação de recurso para a equipe B, mas a equipe B não consegue implementar esse recurso a tempo para a equipe A. +Em uma configuração InnerSource, se a equipe A não conseguir obter essa solicitação de recurso, ela enviará um pull request. +Isso quer dizer que a equipe A implementa o recurso diretamente no software da equipe B e envia um pull request com as alterações de código. +Integrantes da Equipe B para revisar e aceitar o código enviado.

+
+
+

Neste exemplo, chamamos a equipe A de equipe Guest e a equipe B de equipe Host. +Os termos Guest e Host sugerem uma situação análoga a receber um visitante em casa. +Nessa situação, a maioria das pessoas quer ser um bom anfitrião. +Eles garantem que as coisas sejam mantidas limpas e arrumadas antes da chegada de seus convidados. +Os visitantes são recebidos na porta e convidados a entrar. +Eles podem usar os recursos e utilidades que estão nas áreas públicas da casa. +Pode haver algumas regras da casa que os hóspedes devem seguir. +Da mesma forma, a maioria dos hóspedes deseja mostrar respeito pela casa e pelo anfitrião. +Eles são cuidadosos com os itens da casa e seguem as regras durante a estadia. +Eles podem esperar ou aguardar um convite de retorno, desde que tenham sido corteses e educados. +Esses conceitos em torno de uma visita domiciliar são uma metáfora para a atitude e os comportamentos que as equipes devem trazer enquanto uma hospeda a outra, fazendo uma contribuição de convidado para a base de código.

+
+
+

Vamos dar uma olhada mais de perto em como a mecânica do processo InnerSource pode funcionar. +Para ajudar nesta explicação, nomearemos alguns indivíduos-chave nas equipes de convidados e anfitriões. +Primeiro, o Product Owner determina qual funcionalidade a equipe anfitriã está disposta a aceitar como contribuição. +O Contributor é o indivíduo da equipe convidada que envia a contribuição do código para revisão pela equipe anfitriã. +O Trusted Committer representa a equipe anfitriã no fornecimento de qualquer suporte e orientação oportunos que o Contributor precisa para enviar com sucesso o pull request. +Em pequenos esforços, uma única pessoa geralmente preenche os papéis de Product Owner e de Trusted Committer.

+
+
+

Com essas definições, aqui está o esboço básico de uma contribuição InnerSource.

+
+
+ +
+
+

Observe que essas etapas não pressupõem um sistema específico para a organização geral do tempo ou das prioridades de uma equipe. A InnerSource assume que as equipes já possuem métodos de organização existentes e fornece uma estrutura de como usá-los para trabalhar em conjunto onde há uma equipe convidada desejando contribuir com código para um host.

+
+
+

Essa opção funciona bem para a equipe convidada porque ela obtém a funcionalidade de que precisa quando precisa, sem assumir a carga de longo prazo da manutenção da solução. +Funciona para a equipe anfitriã porque ela consegue escalar e atender melhor seus consumidores. +Funciona para a empresa como um todo porque as soluções para problemas compartilhados acabam em locais compartilhados e mantidos centralmente, onde qualquer um pode usá-los. +Mais tempo de engenharia permanece focado na produção de código que resolve os problemas da empresa, em vez da mecânica da negociação de recursos e do processo de escalonamento.

+
+
+

Recursos Adicionais

+
+ +
+
+ \ No newline at end of file diff --git a/content/en/learn/learning-path/introduction/04.pt-br.md b/content/en/learn/learning-path/introduction/04.pt-br.md new file mode 100644 index 0000000000..76a2e3ba21 --- /dev/null +++ b/content/en/learn/learning-path/introduction/04.pt-br.md @@ -0,0 +1,51 @@ +--- +title: Quais são os benefícios do InnerSource? +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Armando Guimarães + url: https://github.com/ArmandoGuimaraes + - name: rrrutledge + url: https://github.com/rrrutledge +image: https://img.youtube.com/vi/PFLmOWCEpi4/mqdefault.jpg +featured: false +weight: 4 +youtubeCode: PFLmOWCEpi4 +--- +
+

Há muitos benefícios em colaborar via InnerSource. +O InnerSource oferece à empresa uma estratégia escalável para equipes convidadas obterem solicitações de recursos quando precisarem sem o ônus de manutenção de longo prazo. +A empresa como um todo ganha à medida que o tempo das equipes convidadas é colocado em código que outras pessoas podem usar.

+
+
+

Embora esse resultado seja um benefício brilhante do InnerSource, há muitos benefícios para as equipes anfitriãs que recebem contribuições regulares do InnerSource. +Lembre-se de que, como parte do processo InnerSource, o Product Owner na equipe anfitriã concorda desde o início que os recursos fornecidos são bons e desejáveis. +A InnerSource permite que a equipe anfitriã receba ajuda na criação de um produto melhor para seus consumidores!

+
+
+

InnerSource fornece à equipe anfitriã uma estratégia escalável para atender a quantidades variadas de recursos solicitados por seus muitos consumidores. +Dada a capacidade fixa dos membros em tempo integral da equipe anfitriã, é provável que, às vezes, os roteiros de negócios combinados de seus consumidores exijam quantidades muito (ou mesmo irracionais) de trabalho a serem feitas nos produtos da equipe anfitriã. +Sem o InnerSource, essa situação leva facilmente a uma equipe estressada e sobrecarregada lidando com muitas solicitações de recursos encaminhadas a seus líderes.

+
+
+

No entanto, se a equipe anfitriã operar via InnerSource, os recursos de engenharia necessários para construir esses recursos aparecerão proporcionalmente à sua importância na forma de contribuidores convidados. +InnerSource torna-se um multiplicador de força que permite que a equipe anfitriã aja temporariamente maior do que seu tamanho real durante períodos de alta demanda. +Quando a demanda termina, o rendimento da equipe volta aos níveis normais, tudo sem qualquer microgerenciamento do número de funcionários ou itens de trabalho da equipe. +O InnerSource permite que o tempo de engenharia flua organicamente onde a organização precisa dele em um determinado momento.

+
+
+

Além do trabalho bruto que a equipe anfitriã é capaz de realizar em seu sistema, as contribuições regulares do InnerSource fornecem à equipe anfitriã melhores requisitos e alinhamento de priorização com todos os seus consumidores. +Uma equipe anfitriã pode fazer o melhor levantamento de requisitos sobre o trabalho que produz, mas quando o próprio consumidor é quem está enviando o trabalho, as chances são muito maiores de que a mudança resultante esteja alinhada exatamente com o que o consumidor precisa. +Embora possa ser apenas uma única equipe convidada enviando a alteração, essa equipe provavelmente representa muitos outros consumidores.

+
+
+

Além desse alinhamento, há também um treinamento geral e educação de contribuidores enquanto eles trabalham e aprendem com https://innersourcecommons.org/learn/ Learning-path/trusted-committer[trusted committers]. +Essa interação ajuda os colaboradores a aprender e crescer em suas carreiras, resultando em maior satisfação no trabalho. +A documentação do projeto melhora para permitir essas contribuições em escala. +Os contribuidores sentem uma participação no projeto da equipe anfitriã. +É algo que eles recomendam a seus colegas ou novas equipes que eles ingressam. +Eles entendem melhor o projeto e são capazes de responder a perguntas sobre ele para outras pessoas, aliviando a equipe de acolhimento de um pouco desse fardo. +Mais pessoas contribuindo para um projeto naturalmente polinizam ideias de toda a empresa. +Esse aprendizado e alinhamento entre equipes ao longo do tempo serve para quebrar os silos tradicionais da empresa.

+
+ \ No newline at end of file diff --git a/content/en/learn/learning-path/introduction/05.pt-br.md b/content/en/learn/learning-path/introduction/05.pt-br.md new file mode 100644 index 0000000000..260fb78946 --- /dev/null +++ b/content/en/learn/learning-path/introduction/05.pt-br.md @@ -0,0 +1,120 @@ +--- +title: Princípios do InnerSource +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Armando Guimarães + url: https://github.com/ArmandoGuimaraes + - name: rrrutledge + url: https://github.com/rrrutledge +image: https://img.youtube.com/vi/rLiDsM3w5YM/mqdefault.jpg +featured: false +weight: 5 +youtubeCode: rLiDsM3w5YM +--- +
+

Cada empresa, equipe, projeto e indivíduo é diferente. +Devido a esse fato, a maneira exata como o conceito de InnerSource funciona varia de uma situação para outra. +Em seu núcleo, no entanto, estão quatro princípios que formam a base de qualquer instância bem-sucedida do InnerSource. +Esses princípios são inspirados em projetos de código aberto bem-sucedidos e são necessários para que o InnerSource alcance os benefícios descritos anteriormente.

+
+
+

Os princípios são:

+
+
+ +
+
+

Vamos dar uma olhada em cada um desses princípios com mais detalhes.

+
+
+

Abertura

+
+

A configuração de um projeto aberto permite uma contribuição sem atrito. +Os projetos devem ser descobertos e bem documentados por meio dos arquivos README.md e CONTRIBUTING.md na raiz do repositório. +Qualquer pessoa dentro de uma organização deve ser capaz de encontrar um projeto desejado e aumentá-lo sem uma quantidade excessiva de orientação direta dos membros da equipe anfitriã. +As informações de contato da equipe anfitriã devem prevalecer em todos os canais que fizerem sentido para o projeto. +As intenções da equipe anfitriã de aceitar as contribuições da InnerSource para seu projeto devem ser compartilhadas por meio de canais relevantes da organização para aumentar a conscientização. +Particularmente em configurações menores, você pode querer estabelecer uma "transmissão" regular sobre o trabalho do InnerSource que sua equipe está fazendo. +Em configurações maiores, no entanto, tal transmissão pode criar muito ruído e pode ser mais apropriado garantir que o projeto seja detectável em uma ferramenta fácil de usar. +Lembre-se, o objetivo é a conscientização, use os canais adequados que funcionam na SUA empresa.

+
+
+

De forma alguma a lista acima é exaustiva. +A abertura do projeto normalmente estará diretamente relacionada ao sucesso de um projeto em termos de InnerSource. +Quanto mais aberto for, menos barreiras serão colocadas para potenciais contribuidores. +Quanto menos aberto, mais difícil se torna para qualquer um contribuir.

+
+
+
+

Transparência

+
+

Para que as equipes convidadas possam contribuir significativamente para um projeto, a equipe anfitriã deve ser transparente. +Isso significa que as equipes convidadas devem entender:

+
+
+ +
+
+

Quando possível, o acima deve ser comunicado de forma clara e detalhada, desde as definições internas dos itens das equipes até cenários de casos especiais específicos do projeto. +Essa comunicação deve ser feita de forma que possa ser facilmente consultada e compreendida por quem não faz parte da equipe principal.

+
+
+
+

Mentoria Priorizada

+
+

Mentoria da equipe anfitriã para a equipe convidada via trusted committers é um aspecto fundamental do InnerSource. +Contribuidores em equipes convidadas são aprimorados para que entendam o suficiente sobre o projeto/repo da equipe host para alterá-lo com sucesso. +No processo de fazer isso, eles entendem melhor o sistema de software da equipe anfitriã como um consumidor geral e embaixador do projeto/software. +Esse colaborador individual pode, com o tempo e com experiência, assumir um papel mais amplo no projeto como um trusted committer.

+
+
+

É fundamental que essa orientação para colaboradores seja Priorizada pela equipe anfitriã. +A equipe anfitriã deve se esforçar para arranjar tempo para orientar os colaboradores da equipe convidada no momento em que o colaborador precisar em vez de quando for conveniente para a equipe anfitriã. +Às vezes, pode ser uma mudança de cultura para os engenheiros da equipe anfitriã gastar tempo ajudando outras pessoas a codificar, em vez de apenas codificar a si mesmos. +Essa orientação é valiosa tanto para o colaborador individual quanto para o anfitrião, e vale a pena fazer bem. +Isso prova ser mutuamente benéfico a longo prazo. Ao melhorar o código, o colaborador forja ou melhora os relacionamentos dentro de uma organização que podem não ter existido de outra forma. +O código aberto reconhece prontamente esse ponto e considera uma honra alcançar o status de trusted committer em um projeto.

+
+
+
+

Contribuição voluntária do código

+
+

A primeira palavra Voluntário significa que o engajamento no InnerSource tanto das equipes convidadas quanto das anfitriãs ocorre por sua própria vontade. +A equipe convidada doa voluntariamente o código para a equipe anfitriã e a equipe anfitriã o aceita voluntariamente. +Essa natureza optativa significa que cada equipe precisa ter certeza de que seu envolvimento agrega valor aos objetivos das outras. +Nunca uma equipe anfitriã é obrigada a aceitar uma contribuição que não esteja alinhada com sua missão geral. +Nunca uma equipe convidada é obrigada a enviar uma contribuição que não promova sua própria missão e prioridades.

+
+
+

A palavra Código enfatiza que a colaboração entre o convidado e o anfitrião vai até o código. +O envolvimento do convidado na abertura de problemas, atualização de requisitos, correção de documentos etc. é bom, mas a colaboração precisa chegar até o envio de código para obter todos os benefícios que temos.

+
+
+ \ No newline at end of file diff --git a/content/en/learn/learning-path/introduction/06.pt-br.md b/content/en/learn/learning-path/introduction/06.pt-br.md new file mode 100644 index 0000000000..ff0b15cf00 --- /dev/null +++ b/content/en/learn/learning-path/introduction/06.pt-br.md @@ -0,0 +1,29 @@ +--- +title: Conclusão +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Armando Guimarães + url: https://github.com/ArmandoGuimaraes + - name: rrrutledge + url: https://github.com/rrrutledge +image: https://img.youtube.com/vi/cFmg-c9IunM/mqdefault.jpg +featured: false +weight: 6 +youtubeCode: cFmg-c9IunM +--- +
+

Nest trilha de aprendizado, apresentamos uma introdução ao InnerSource. +A InnerSource aplica as melhores práticas e princípios de código aberto ao desenvolvimento interno de software. +Ele oferece uma opção adicional aos consumidores quando as equipes de produção não conseguem entregar uma solicitação de recurso necessária. +O InnerSource bem-sucedido envolve um product owner e trusted committer do * time anfitrião , bem como um contributor da *equipe convidada. +Feito de forma eficaz, o InnerSource traz muitos benefícios para ambas as equipes participantes. +Os princípios-chave sobre os quais o InnerSource eficaz funciona são contribuição voluntária de código e orientação prioritária.

+
+
+

Embora este treinamento contenha uma visão geral de alto nível do InnerSource, há muitos outros detalhes úteis para fazer o InnerSource realmente funcionar para sua equipe. +Se você quiser se manter conectado à conversa em andamento sobre o InnerSource e suas melhores práticas, junte-se a the InnerSource Commons. +O Commons patrocina um canal Slack, um grupo de trabalho de padrões InnerSource e vários encontros presenciais a cada ano. +A participação no Commons é uma ótima maneira de ficar conectado com o que há de mais recente no InnerSource.

+
+ \ No newline at end of file diff --git a/content/en/learn/learning-path/introduction/07.pt-br.md b/content/en/learn/learning-path/introduction/07.pt-br.md new file mode 100644 index 0000000000..27bc1ebca8 --- /dev/null +++ b/content/en/learn/learning-path/introduction/07.pt-br.md @@ -0,0 +1,140 @@ +--- +title: FAQ +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Armando Guimarães + url: https://github.com/ArmandoGuimaraes + - name: rrrutledge + url: https://github.com/rrrutledge +image: images/learn/LP-article-default.png +featured: false +weight: 7 +youtubeCode: "" +--- +
+

Para concluir o segmento de Introdução da Trilha de Aprendizado, aqui estão algumas Perguntas Frequentes que as pessoas têm ao embarcar em sua jornada InnerSource.

+
+
+

Qual é o custo/overhead de manter um projeto InnerSource?

+
+

Depende! Um projeto InnerSource que incentiva pequenos pull requests e tem diretrizes de contribuição claras pode exigir pouca sobrecarga, com a maior parte do trabalho sendo revisões de código. Para saber mais sobre as práticas que podem reduzir a necessidade de manutenção de projetos InnerSource, sugerimos que você consulte InnerSource Patterns, especialmente:

+
+
+ +
+
+
+

Qual é o custo/overhead de contribuir para um projeto InnerSource?

+
+

50% mais esforço para o commit. 100% menos esforço para manter.

+
+
+
+

Por que não apenas código aberto?

+
+

Por favor, faça-o se o projeto fizer sentido! Alguns projetos são específicos para sua empresa ou são uma vantagem competitiva, então você vai querer mantê-los como InnerSource. Alguns precisam iterar mais rapidamente do que pode ser feito abertamente.

+
+
+

Se a sua organização não estiver familiarizada com a execução de projetos de código aberto, a InnerSource pode ajudar as pessoas a aprender as habilidades necessárias para abrir o código no futuro.

+
+
+
+

Isso vai nos atrasar?

+
+

Depende de quão longe você está indo. Você provavelmente irá muito mais longe do que pensa.

+
+
+
+Se você quer ir rápido +
+
+
+
+

Estaremos apenas revisando PRs o dia todo, todos os dias?

+
+

Nesse caso, sua equipe principal está com falta de pessoal. Uma equipe saudável é composta de forma que haja tempo para ajudar os colaboradores e fazer contribuições essenciais.

+
+
+

Você pode mitigar isso definindo a expectativa, possivelmente por meio de SLAs. Se os contribuidores esperam revisões de PR em uma hora, talvez você fique parado revisando PRs o tempo todo, mas se você definir um SLA de 1 dia ou 1 semana, esse não será o caso.

+
+
+
+

Como convencemos a gerência de que essa é uma boa ideia?

+
+

Descubra o que eles querem e obtenha um exemplo de trabalho do InnerSource, de preferência dentro da sua organização, que mostre que eles estão conseguindo. Se o OSPO/ISPO da sua organização gerencia projetos InnerSource, entre em contato com eles para obter suporte.

+
+
+
+

Como convencemos os engenheiros de que essa é uma boa ideia?

+
+

A InnerSource oferece aos engenheiros a oportunidade de desenvolver sua carreira, tanto em termos de habilidades quanto reconhecimento dentro de sua organização:

+
+
+ +
+
+

Além disso, muitos engenheiros valorizam o código aberto; O InnerSource adota práticas de código aberto e pode ser um passo em direção ao código aberto para muitos projetos.

+
+
+
+

Quais são as expectativas tanto do anfitrião quanto do colaborador?

+
+

Trabalhar juntos! Isso pode ser completamente assíncrono por meio de pull requests ou envolver atualizações regulares da comunidade - o que funcionar para você.

+
+
+

A comunicação e o apoio devem ir em ambas as direções e ser abertos e colaborativos, promovendo uma cultura de segurança psicológica. O feedback sobre contribuições ou código existente deve ser abordado com uma mentalidade de crescimento e como parceria para melhorar as coisas.

+
+
+
+

Como manteremos o controle do projeto?

+
+

Por meio das funções Trusted Committer e Product Owner, você ainda pode garantir que o código recebido seja adequado tanto do ponto de vista do produto quanto da engenharia. Você não precisa mesclar o código que não é adequado.

+
+
+

Você também deve definir diretrizes de contribuição claras e ser transparente na direção do projeto. Alguns Padrões que podem ajudar:

+
+
+ +
+
+
+

Como fazemos com que as pessoas façam contribuições?

+
+

Sua equipe e a cultura da organização em geral devem valorizar a colaboração. Concentre-se no valor comercial - as equipes são capazes de se desbloquear onde o software que usam tem bugs ou não possui os recursos necessários. Onde os colaboradores não têm necessidade imediata de negócios, você pode anunciar que está procurando ajuda.

+
+
+ \ No newline at end of file diff --git a/content/en/learn/learning-path/introduction/08.pt-br.md b/content/en/learn/learning-path/introduction/08.pt-br.md new file mode 100644 index 0000000000..792bae6460 --- /dev/null +++ b/content/en/learn/learning-path/introduction/08.pt-br.md @@ -0,0 +1,90 @@ +--- +title: O InnerSource é adequado para o meu projeto? +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Armando Guimarães + url: https://github.com/ArmandoGuimaraes + - name: rrrutledge + url: https://github.com/rrrutledge +image: images/learn/LP-article-default.png +featured: false +weight: 8 +youtubeCode: "" +--- +
+

InnerSource é a aplicação dos princípios de código aberto ao desenvolvimento de software interno da empresa. Feito corretamente, desbloqueia o progresso e facilita a adoção de serviços e módulos compartilhados. +Este artigo contém orientações e perguntas a serem feitas ao considerar a adoção de uma abordagem InnerSource para executar seu projeto.

+
+
+

As contribuições virão?

+
+

Uma abordagem InnerSource só faz sentido se forem esperadas contribuições dos usuários do projeto. +Você pode esperar contribuições se vir ou antecipar quantidades perceptíveis de energia direcionada à área do seu projeto por seus usuários. Alguns exemplos:

+
+
+ +
+
+
+

Vou apoiar contribuições?

+
+

Mesmo com colaboradores dispostos, o código não flui. +Você precisará encorajar e apoiar contribuições por meio de atividades como:

+
+
+ +
+
+
+

É específico da empresa?

+
+

Os projetos InnerSource fazem sentido quando o projeto é específico para a empresa ou quando seu uso exclusivo dá à empresa uma vantagem estratégica de negócios. +Outros projetos colaborativos devem ser executados como código aberto para aumentar o pool de contribuição e o impacto.

+
+
+
+

Resumo

+
+

Se as contribuições vierem e você apoiar essas contribuições e seu projeto for específico da empresa, então a InnerSource é a certa para o seu projeto.

+
+
+ \ No newline at end of file diff --git a/content/en/learn/learning-path/introduction/_index.pt-br.md b/content/en/learn/learning-path/introduction/_index.pt-br.md new file mode 100644 index 0000000000..857f46c756 --- /dev/null +++ b/content/en/learn/learning-path/introduction/_index.pt-br.md @@ -0,0 +1,9 @@ +--- +título: Introdução +destaque: true +image: images/learn/LP_thumbnail_introduction.jpg +weight: 0 +--- + +Confira a Introdução para aprender sobre os tipos de problemas em que o InnerSource pode ajudar, como fazê-lo, os tipos de benefícios que você pode esperar ao participar e os princípios subjacentes que fazem tudo funcionar. + \ No newline at end of file diff --git a/content/en/learn/learning-path/trusted-committer/01.pt-br.md b/content/en/learn/learning-path/trusted-committer/01.pt-br.md index 00a6fcd9c4..2f836f3cef 100644 --- a/content/en/learn/learning-path/trusted-committer/01.pt-br.md +++ b/content/en/learn/learning-path/trusted-committer/01.pt-br.md @@ -82,7 +82,7 @@ Ao promover a abertura e a transparência, os Trusted Committers criam confianç

https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/05/ [Reduzindo as barreiras para fazer contribuições]

  • -

    https://innersourcecommons.org/learn/learning-path/trusted-committer/04/ [Melhorando a comunidade]

    +

    https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/04/ [Melhorando a comunidade]

  • https://innersourcecommons.org/learn/learning-path/trusted-committer/06/ [Promovendo as necessidades da comunidade]

    diff --git a/content/en/learn/learning-path/trusted-committer/03.pt-br.md b/content/en/learn/learning-path/trusted-committer/03.pt-br.md index af2ff4ede4..06e4a58965 100644 --- a/content/en/learn/learning-path/trusted-committer/03.pt-br.md +++ b/content/en/learn/learning-path/trusted-committer/03.pt-br.md @@ -38,7 +38,7 @@ Eles fornecem a teoria ou a experiência por trás da mudança e oferecem sugest Ao fazer isso, os Trusted Committers podem aumentar a velocidade de aprendizado em suas comunidades muito além do que em projetos tradicionais de desenvolvimento de software. Acreditamos que os Trusted Committers devem priorizar a integração e a orientação durante pull requests ao invés de atingir datas de lançamento comunicadas, a menos que haja uma razão muito boa para não fazê-lo. Uma boa orientação durante pull requests leva a um nível mais alto de confiança e engajamento dos https://innersourcecommons.org/learn/learning-path/contributor [Contributors], que por sua vez leva a mais contribuições. -Vamos discutir mais sobre isso em "Melhorando a Comunidade". +Vamos discutir mais sobre isso em "Melhorando a Comunidade". Finalmente, algumas pessoas permanecem em comunidades InnerSource porque elas se concentram no desenvolvimento de software em vez de atividades consideradas gerais ou desperdícios, especialmente comuns em grandes empresas com um forte foco em processos. A tarefa do Trusted Committer nesse contexto é assegurar que os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] possam realmente focar em seus projetos comunicando e publicando diretrizes de contribuição úteis. Um aspecto importante dessas diretrizes é explicar o que chamamos de signaling em pull requests: como deve ser um comentário? diff --git a/content/en/learn/learning-path/trusted-committer/04.pt-br.md b/content/en/learn/learning-path/trusted-committer/04.pt-br.md new file mode 100644 index 0000000000..778557947d --- /dev/null +++ b/content/en/learn/learning-path/trusted-committer/04.pt-br.md @@ -0,0 +1,37 @@ +--- +title: Desenvolvendo Membros da Comunidade +contributors: + - name: Fernando Correa + url: https://github.com/fer-correa + - name: Senthil Nathan + url: https://github.com/nysenthil + - name: rrrutledge + url: https://github.com/rrrutledge +image: https://img.youtube.com/vi/452IVT7TKsE/mqdefault.jpg +featured: false +weight: 4 +youtubeCode: 452IVT7TKsE +--- +
    +

    Há uma participação contínua em uma comunidade InnerSource. +Há pessoas que não tem conhecimento da comunidade. +Newcomers podem estar interessados na comunidade e seu produto, mas ainda não o usaram. +Consumers usam o software, mas podem não ter feito uma contribuição +Depois, temos os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] que fizeram pelo menos uma contribuição e, finalmente, os Trusted Committers, que estão assumindo a responsabilidade pelo software e pela comunidade. +Como um Trusted Committer, você é responsável por mover os indivíduos ao longo deste fluxo contínuo e desenvolver suas capacidades de fazer contribuições. +Nesse sentido, os Trusted Committers atuam como multiplicadores de força em sua comunidade. +É importante que os Trusted Committers façam o marketing de seus produtos e comunidades para aumentar o número de newcomers e consumidores. +Eles também devem comunicar aos consumidores as oportunidades para fazer contribuições e tentar obter e alinhar os interesses de potenciais https://innersourcecommons.org/learn/learning-path/contributor [Contributors] com os da comunidade. +O que geralmente funciona bem é se os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] são capazes de trabalhar em algo que beneficie seu departamento ou função na empresa. +Ferramentas de desenvolvimento e automação são bons exemplos. +Por fim, é responsabilidade do Trusted Commiter identificar e apoiar https://innersourcecommons.org/learn/learning-path/contributor [Contributors] com potencial de crescimento, incentivando-os a enfrentar tarefas desafiadoras e orientá-los para a conclusão destas tarefas. +Esta é, em nossa opinião, a mais nobre responsabilidade de um Trusted Commiter, e é gratificante tanto para o Trusted Commiter como para o seu Contributor. +Ouvimos Trusted Committers dizer que orientar e ver as pessoas desenvolverem suas habilidades mais do que compensa o fato de que elas têm menos tempo para realmente gastar escrevendo software. +Conforme mencionado na https://innersourcecommons.org/pt-br/learn/learning-path/trusted-committer/03 / [seção anterior], aprendizado e crescimento pessoal são razões pelas quais as pessoas se juntam e permanecem em uma comunidade InnerSource. +Desenvolver seus https://innersourcecommons.org/learn/learning-path/contributor [Contributores] é uma das ferramentas mais poderosas que os Trusted Commiters têm à disposição para aumentar a velocidade, a produção e a longevidade de suas comunidades. +Também é um dos principais argumentos para convencer a gerência a permitir que seus funcionários participem de uma comunidade InnerSource, pois isso tornará seus funcionários mais valiosos para a empresa em geral e os ajudará a reter os principais talentos. +Em resumo, os Trusted Commiters precisam atrair novos https://innersourcecommons.org/learn/learning-path/contributor [Contributors] e aumentar sua capacidade de fazer contribuições. +Esta atividade acaba por aumentar a capacidade da comunidade de criar software melhor mais rapidamente. +Eles fazem isso comunicando oportunidades para fazer contribuições e ajudando e orientando os Contributors, permitindo que eles cresçam.

    +
    + \ No newline at end of file