diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 973e03c7f..3ef0ce782 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -8,11 +8,15 @@
# the repo. Unless a later match takes precedence,
# @global-owner1 and @global-owner2 will be requested for
# review when someone opens a pull request.
-* @lenucksi @NewMexicoKid @cewilliams @spier @robtuley
-
-# Trying out folder-specific CODEOWNERS permissions, by example of our Japanese book
-/translation/ @yuhattor
-/book/ @yuhattor
+* @lenucksi @NewMexicoKid @cewilliams @spier @robtuley @yuhattor
+
+# These people ar familiar with the translation of our patterns to a specific language:
+/translation/ja/ @yuhattor
+/book/ja/ @yuhattor
+/translation/zh/ @WillemJiang
+/book/zh/ @WillemJiang
+/translation/pt/ @jrcosta @zilio
+/book/pt/ @jrcosta @zilio
# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
diff --git a/.github/workflows/book.yml b/.github/workflows/book.yml
index 939bfb841..d34ad40dc 100644
--- a/.github/workflows/book.yml
+++ b/.github/workflows/book.yml
@@ -14,7 +14,7 @@ jobs:
strategy:
matrix:
- language: [en, ja, zh]
+ language: [en, ja, zh, pt]
steps:
- uses: actions/checkout@v3
diff --git a/book/en/toc_template.md b/book/en/toc_template.md
index 256d8b244..9013b1327 100644
--- a/book/en/toc_template.md
+++ b/book/en/toc_template.md
@@ -19,7 +19,7 @@ Instead edit toc_template.md
## Patterns
-<>
+<>
## Appendix
diff --git a/book/ja/toc_template.md b/book/ja/toc_template.md
index 01ab26bbe..0bc3a7019 100644
--- a/book/ja/toc_template.md
+++ b/book/ja/toc_template.md
@@ -19,7 +19,7 @@ Instead edit toc_template.md
## パターン
-<>
+<>
## 付録
diff --git a/book/pt-br/.gitbook.yaml b/book/pt-br/.gitbook.yaml
new file mode 100644
index 000000000..fb44a6a2c
--- /dev/null
+++ b/book/pt-br/.gitbook.yaml
@@ -0,0 +1,5 @@
+root : ./
+
+structure:
+ readme: introduction.md
+ summary: toc.md
diff --git a/book/pt-br/contribute.md b/book/pt-br/contribute.md
new file mode 100644
index 000000000..78c99241a
--- /dev/null
+++ b/book/pt-br/contribute.md
@@ -0,0 +1,31 @@
+# Contribua para este Livro
+
+Deseja tornar este livro melhor? Isso é incrível!
+
+O livro Padrões InnerSource em si é um [projeto de código aberto][repositório] e acolhe qualquer forma de contribuição. Nada é insignificante!
+
+Não importa se deseja nos auxiliar a corrigir erros de gramática/ortografia, melhorar o design ou contribuir com padrões inteiramente novos baseados nas experiências InnerSource que teve em seu local de trabalho. Amamos todas essas contribuições! :)
+
+Se nunca contribuiu para um projeto de código aberto anteriormente, saiba que a comunidade Padrões InnerSource é formada por pessoas amigáveis e é um ambiente seguro para experimentar.
+
+## Antes de Começar
+
+As fontes dos Padrões InnerSource e deste livro estão mantidas em um repositório no GitHub. Portanto, será necessário ter uma conta de usuário no GitHub para fazer edições e sugestões neste livro. Caso não possua uma ainda, visite [github.com](https://github.com) e crie uma conta gratuitamente.
+
+## Diferentes Formas de Contribuir
+
+Aqui estão algumas maneiras pelas quais pode contribuir:
+
+1. Corrigir erros de ortografia, formatação ou outras falhas que notar neste livro.
+2. Melhorar o conteúdo de um padrão existente (por exemplo, adicionando uma breve descrição de como está usando um padrão como uma _Instância Conhecida_).
+3. Contribuir com um novo padrão, descrevendo como superou desafios relacionados ao InnerSource em sua organização.
+
+Para (1) e (2) acima, pode simplesmente clicar no link **Editar no GitHub** que vê no topo de cada página deste livro. Isso o levará diretamente ao arquivo correspondente em nosso repositório GitHub, onde pode sugerir suas alterações.
+
+Para (3), será necessário clonar o repositório [InnerSourcePatterns][repositório] e adicionar um novo arquivo com o padrão que está sugerindo. Ao fazer contribuições maiores para este livro, revise nosso [CONTRIBUTING.md](../../CONTRIBUTING.md) e também nosso [Manual do Colaborador](../../meta/contributor-handbook.md).
+
+## Licença das Contribuições
+
+O conteúdo deste repositório está licenciado sob [CC-BY-SA-4.0](../../LICENSE.txt). Ao contribuir para este repositório, nos concede (e a todos os outros, também) o direito de usar sua contribuição de acordo com essa licença.
+
+[repositório]: https://github.com/InnerSourceCommons/InnerSourcePatterns
diff --git a/book/pt-br/explore-patterns.md b/book/pt-br/explore-patterns.md
new file mode 100644
index 000000000..aa1cdb7b0
--- /dev/null
+++ b/book/pt-br/explore-patterns.md
@@ -0,0 +1,19 @@
+# Explore Patterns
+
+Cada vez mais padrões estão sendo contribuídos para este livro pela comunidade InnerSource Commons. Isso é incrível!
+
+Agora, como tornar mais fácil para os leitores descobrirem os padrões que podem ajudá-los em sua situação específica?
+
+Para esse propósito, fornecemos este mapa mental. Ele **classifica os padrões com base nas diferentes fases de um Programa InnerSource** e nos desafios que podem surgir nas respectivas fases.
+
+
+
+## Melhore este Mapa Mental
+
+Se você notar algo neste mapa mental que pareça errado, por favor [abra uma issue](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues), descrevendo o problema e a correção que deve ser feita.
+
+Além disso, se você tiver outras ideias para melhorar a descoberta desses padrões ou quiser tornar este mapa mental melhor, revise a documentação de nossa abordagem de [Categorização de Padrões](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/pattern-categorization/README.md) e também veja como [contribuir para este livro](contribute.md).
+
+## Referências
+
+A ideia de categorizar os padrões dessa forma é vagamente baseada em uma descrição em [Thoughts on an InnerSource Pattern Language](https://drive.google.com/file/d/13AY8glCOdpLOVuz7cVD6QOB8d2xbHCS1/view) por Tim Yao, Bob Hanmer e Padma Sudarsan (2018). Para detalhes específicos, veja o slide 15 na apresentação.
diff --git a/book/pt-br/innersource-patterns-book-cover.jpg b/book/pt-br/innersource-patterns-book-cover.jpg
new file mode 100644
index 000000000..45b84660f
Binary files /dev/null and b/book/pt-br/innersource-patterns-book-cover.jpg differ
diff --git a/book/pt-br/introduction.md b/book/pt-br/introduction.md
new file mode 100644
index 000000000..2a50c4454
--- /dev/null
+++ b/book/pt-br/introduction.md
@@ -0,0 +1,67 @@
+# Introdução
+
+
+
+{% hint style="info" %}
+Você está lendo uma versão inicial do Livro de Padrões InnerSource e ainda pode encontrar links quebrados, erros de ortografia ou outros problemas.
+Por favor, nos ajude a corrigi-los para produzirmos o melhor livro possível :). Saiba como [contribuir para este livro](contribute.md).
+{% endhint %}
+
+Bem-vindo ao **Livro de Padrões InnerSource**.
+
+Este livro contém as melhores práticas InnerSource codificadas em um formato específico para facilitar a compreensão, avaliação e aplicação delas em seu contexto. Chamamos esse formato de **padrão**.
+
+A [InnerSource Commons](http://innersourcecommons.org) coletou esses padrões ao longo de muitos anos, publicando os padrões mais maduros neste livro, onde membros da comunidade revisam cada padrão, com pelo menos uma instância conhecida de uso do padrão.
+
+Nesta introdução, explicamos [o que é InnerSource](#o-que-é-innersource), [o que é um padrão](#o-que-são-padrões-innersource) e [Como você pode usar Padrões InnerSource?](#como-você-pode-usar-padrões-innersource) em sua organização.
+
+Se você já está usando InnerSource em sua empresa e deseja contribuir com suas experiências para este livro, adoraríamos [receber suas contribuições](contribute.md)!
+
+## O que é InnerSource?
+
+Definimos InnerSource como:
+
+> O uso de princípios e práticas de código aberto para o desenvolvimento de software dentro dos limites de uma organização.
+
+O InnerSource aproveita as lições aprendidas com o desenvolvimento de software de código aberto e as aplica à forma como as empresas desenvolvem software internamente. À medida que os desenvolvedores se acostumaram a trabalhar em software de código aberto de alta qualidade, surge um forte desejo de trazer essas práticas de volta para dentro da empresa e aplicá-las ao software que as empresas podem relutar em lançar.
+
+Para empresas que constroem principalmente software de código fechado, o InnerSource pode ser uma ótima ferramenta para quebrar barreiras, incentivar e ampliar a colaboração interna, acelerar a integração de novos engenheiros e identificar oportunidades de contribuir com software para o mundo de código aberto.
+
+## O que são Padrões InnerSource?
+
+Padrões são uma forma de descrever uma solução repetível e comprovada para um problema dentro de um contexto. Os padrões seguem uma forma simples que auxilia durante a implementação de uma solução para entender as restrições do problema, compreender as forças que você precisa equilibrar e o contexto resultante - a situação criada pela aplicação da solução.
+
+Os padrões podem fornecer uma maneira para os participantes da InnerSource Commons compartilharem informações de forma concisa, melhorando a prática do InnerSource. Os padrões são divididos em Título, Declaração do Problema, Contexto, Forças e Soluções como suas principais seções.
+
+* [`O que são padrões?` Vídeos no Youtube](http://bit.ly/innersource_patterns_videos) - Assista a uma série de vídeos no Youtube de 2-5 minutos explicando Padrões InnerSource.
+* [Webinar de Discussão de Padrões](https://youtu.be/i-0IVhfRVFU) - Realizamos um webinar em 16 de março de 2017 para discutir ao vivo um *donut pattern*[^1] (vá para 24:30 para a discussão). Isso ilustra o processo de revisão que seguimos. Veja também o [Webinar O'Reilly de 1 de junho de 2017 sobre Padrões InnerSource](http://www.oreilly.com/pub/e/3884).
+* [Modelo de Padrão](../../meta/pattern-template.md) - Veja um padrão InnerSource esqueleto para ter uma ideia do que é necessário para criar um novo padrão!
+* [Introdução aos Padrões InnerSource (apresentação do Fall Summit 2016)](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc) - *Tim Yao e Padma Sudarsan* (PDF). Fundo e exemplos detalhados de padrões - Entenda detalhadamente por que e como interagir com nossos padrões. Veja também a [Introdução aos Padrões InnerSource (Fall Summit 2017)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) *Tim Yao e Bob Hanmer* (PDF).
+
+## Como você pode usar Padrões InnerSource?
+
+Os padrões devem ser usados com cuidado. Eles não podem ser aplicados indiscriminadamente. Na maioria dos casos, você precisará adaptar a solução fornecida à sua situação; mas as informações dadas no padrão, definindo o contexto (restrições imutáveis) e as forças (restrições que podem ser alteradas e equilibradas entre si), devem ajudá-lo a fazer isso. Note que você também precisará determinar se existem restrições adicionais (contexto da empresa e forças da empresa) que se aplicam à sua empresa/organização específica e que devem ser adicionadas ao padrão (como um tipo de filtro). Essas restrições adicionais podem exigir etapas de solução adicionais a serem aplicadas.
+
+A forma do padrão é útil para descrever soluções comprovadas, mas também pode ser usada para *brainstorming de novas soluções* onde os padrões ainda não estão estabelecidos. Isso ocorre porque a anatomia de um padrão fornece um framework para pensar em um problema de maneira estruturada. Você também pode criar um *donut pattern* (preenchendo os campos de problema, contexto, forças e contexto resultante, mas deixando a solução em branco) como uma maneira de pedir ajuda à comunidade da InnerSource Commons (para encontrar uma solução comprovada ou para gerar ideias para tentar).
+
+## Como Contribuir?
+
+Por favor, consulte: [Contribuir para este livro](./contribute.md)
+
+## Créditos
+
+Este livro é o resultado de muitos anos de trabalho de inúmeros [Contribuidores de Código Aberto](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors) de todo o mundo. Sua disposição em compartilhar abertamente os desafios que enfrentaram em suas empresas e como o InnerSource os ajudou a enfrentar esses desafios torna este livro um recurso valioso para outros em sua jornada InnerSource.
+
+Queremos mencionar especificamente o Grupo de Trabalho InnerSource Patterns. Eles têm nutrido a qualidade dos Padrões InnerSource e ajudaram outros a contribuir. Por último, eles também compilaram uma seleção de padrões disponíveis neste livro.
+
+A imagem de capa deste livro foi criada por [Sebastian Spier](https://spier.hu) e adaptada a partir de uma imagem de [Tony Hisgett - Alhambra 6](https://www.flickr.com/photos/hisgett/29345405788/), disponível sob [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/).
+
+**Obrigado a todos os contribuidores! E feliz Dia InnerSource :)**
+
+## Licenciamento
+
+
+
+InnerSourcePatterns por [InnerSourceCommons.org](http://innersourcecommons.org) está licenciado sob uma [Licença Internacional Creative Commons Attribution-ShareAlike 4.0](http://creativecommons.org/licenses/by-sa/4.0/).
+
+[^1]: *Donut pattern* não possui tradução direta para português. No contexto em que está utilizado refere-se a um padrão ainda não está totalmente definido, com o campo solução ainda pendente de discussões.
diff --git a/book/pt-br/toc.md b/book/pt-br/toc.md
new file mode 100644
index 000000000..b068430e4
--- /dev/null
+++ b/book/pt-br/toc.md
@@ -0,0 +1,54 @@
+# Sumário
+
+
+
+
+
+* [Introdução](./introduction.md)
+* [Sumário](./toc.md)
+* [Explorar Padrões](./explore-patterns.md)
+* [Contribuir para Este Livro](./contribute.md)
+
+
+
+## Padrões
+
+* [Avaliação de Projeto entre Equipes](../../translation/pt-br/patterns/crossteam-project-valuation.md) - É difícil vender o valor de projetos InnerSource entre equipes que não proporcionam um impacto direto na receita da empresa. Aqui está uma maneira baseada em dados para representar seu projeto que articula seu valor e o amplifica.
+* [Casos de uso do Issue Tracker](../../translation/pt-br/patterns/issue-tracker.md) - A equipe responsável pelo InnerSource falha em tornar não apenas os planos e o progresso transparentes, mas também o contexto das mudanças. Isso é resolvido aumentando os casos de uso do Issue Tracker do projeto para também servir como espaço para brainstorming, discussões de implementação e design de recursos.
+* [Colaborador Contratado](../../translation/pt-br/patterns/contracted-contributor.md) - Associados que desejam contribuir com o InnerSource são desencorajados a fazê-lo por sua gerência de linha. O alívio é fornecido por meio de contratos e acordos formais.
+* [Comitê de Revisão](../../translation/pt-br/patterns/review-committee.md) - O Modelo de Trabalho InnerSource é uma ruptura radical das abordagens mais tradicionais, tanto para desenvolvedores quanto para gerentes. Ao estabelecer um Comitê de Revisão como uma interface entre a iniciativa InnerSource e todos os gerentes sêniores das unidades de negócios que participam dela, é mais provável que estes últimos se familiarizem com a iniciativa e a apoiem, uma vez que isso lhes proporciona um certo nível de supervisão e controle sem promover a microgestão.
+* [Documentação Base Padrão](../../translation/pt-br/patterns/base-documentation.md) - Novos contributors para um projeto InnerSource têm dificuldade em descobrir quem é o responsável pelo projeto, o que trabalhar e como contribuir. Fornecer documentação em arquivos padrão como README.md/CONTRIBUTING.md permite um processo de autoatendimento para novos contributors, para que possam encontrar as respostas para as perguntas mais comuns por conta própria.
+* [Documente seus Princípios Orientadores](../../translation/pt-br/patterns/document-your-guiding-principles.md) - A explicação comum do InnerSource, "aplicando as melhores práticas de código aberto dentro de uma organização", não funciona bem com pessoas que não possuem um background em código aberto. Como solução, os princípios mais importantes do InnerSource são documentados e publicados amplamente.
+* [Elogiar Participantes](../../translation/pt-br/patterns/praise-participants.md) - Após uma contribuição de InnerSource, é importante agradecer ao contribuidor pelo seu tempo e esforço. Este padrão fornece orientações que não apenas reconhecem efetivamente a contribuição, mas também promovem um maior envolvimento do contribuidor e de outros.
+* [Equipe Central](../../translation/pt-br/patterns/core-team.md) - Mesmo quando um projeto InnerSource é amplamente necessário, as contribuições e uso podem ser prejudicados porque o projeto é difícil de trabalhar. Estabelecer uma equipe central dedicada a cuidar dos itens fundamentais do projeto. O trabalho deles permite que os contributors adicionem e usem recursos que oferecem valor para seus cenários.
+* [Ferramentas de Comunicação](../../translation/pt-br/patterns/communication-tooling.md) - Os usuários de um projeto InnerSource têm dificuldade em obter ajuda e entrar em contato com a equipe responsável pelo projeto. Ao usar consistentemente ferramentas de comunicação assíncronas, o projeto torna as discussões visíveis, arquivadas e pesquisáveis, o que leva a um nível melhorado de suporte para os usuários.
+* [Garantia de 30 dias](../../translation/pt-br/patterns/30-day-warranty.md) - Ao aceitar contribuições de fora da sua própria equipe, há uma aversão natural em assumir a responsabilidade pelo código que não foi escrito pela própria equipe. Através da Garantia de 30 dias, a equipe contribuinte concorda em fornecer correções de bugs para a equipe receptora, o que aumentará o nível de confiança entre as duas equipes e torna mais provável que as contribuições sejam aceitas.
+* [Gig Marketplace](../../translation/pt-br/patterns/gig-marketplace.md) - Estabeleça um mercado criando um site intranet que liste necessidades específicas de projetos InnerSource como "Gigs", com requisitos explícitos de tempo e habilidades. Isso permitirá que os gerentes entendam melhor o compromisso de tempo de seus funcionários e os benefícios profissionais, aumentando assim a probabilidade de obter a aprovação para fazer contribuições InnerSource.
+* [Inicie como um Experimento](../../translation/pt-br/patterns/start-as-experiment.md) - Comece a sua iniciativa InnerSource como um experimento com limite de tempo para tornar mais fácil para os gestores que não estão familiarizados com o InnerSource endossar e apoiar a iniciativa.
+* [Licença InnerSource](../../translation/pt-br/patterns/innersource-license.md) - Duas entidades jurídicas que pertencem à mesma organização desejam compartilhar código-fonte de software entre si, mas estão preocupadas com as implicações em termos de responsabilidades legais ou contabilidade entre empresas.
+* [Líder de Comunidade Dedicado](../../translation/pt-br/patterns/dedicated-community-leader.md) - Selecione pessoas com habilidades tanto em comunicação quanto em técnicas para liderar as comunidades e garantir o sucesso na iniciativa InnerSource
+* [Modelo de Maturidade](../../translation/pt-br/patterns/maturity-model.md) - As equipes começaram a adotar o InnerSource. A prática está se espalhando para vários departamentos. No entanto, a compreensão do que constitui um projeto InnerSource varia. A solução é fornecer um modelo de maturidade para permitir que as equipes realizem uma autoavaliação e descubram padrões e práticas das quais ainda não têm conhecimento.
+* [Portal InnerSource](../../translation/pt-br/patterns/innersource-portal.md) - Potenciais contribuidores não conseguem descobrir facilmente os projetos de InnerSource que lhes interessam. Ao criar um site de intranet que indexa todas as informações disponíveis sobre projetos de InnerSource, você permite que os contribuidores aprendam sobre projetos que possam interessá-los e que os proprietários de projetos de InnerSource atraiam um público externo.
+* [Repositório Pontuação de Atividade](../../translation/pt-br/patterns/repository-activity-score.md) - Potenciais contribuidores desejam encontrar projetos InnerSource ativos que precisem de sua ajuda. Ao calcular uma pontuação de atividade do repositório para cada projeto, uma lista classificada de projetos pode ser criada (por exemplo, no Portal InnerSource), para que os potenciais contribuidores possam determinar mais facilmente em qual projeto desejam contribuir.
+* [Requisitos Comuns](../../translation/pt-br/patterns/common-requirements.md) - O código comum em um repositório compartilhado não está atendendo às necessidades de todas as equipes de projeto que desejam usá-lo; isso é resolvido por meio do alinhamento de requisitos e refatoração.
+* [Serviço vs. Biblioteca](../../translation/pt-br/patterns/service-vs-library.md) - Equipes em um ambiente DevOps podem relutar em trabalhar além dos limites de suas equipes em bases de código comuns, devido à ambiguidade sobre quem será responsável por responder a interrupções de serviço. A solução é perceber que muitas vezes é possível implantar o mesmo serviço em ambientes independentes com cadeias de escalonamento separadas no caso de interrupções de serviço, ou separar grande parte do código compartilhado em uma biblioteca única e colaborar nela.
+* [Tomada de Decisão Transparente entre Equipes usando RFCs](../../translation/pt-br/patterns/transparent-cross-team-decision-making-using-rfcs.md) - Projetos InnerSource que desejam alcançar altas taxas de participação e tomar as melhores decisões possíveis para todos os envolvidos precisam encontrar maneiras de criar sistemas participativos ao longo de todo o ciclo de vida do software. A publicação de documentos internos de "Requests for Comments" (RFCs) permite discussões desde o início do processo de design e aumenta as chances de construir soluções com um alto grau de comprometimento de todas as partes envolvidas.
+* [Trusted Committer](../../translation/pt-br/patterns/trusted-committer.md) - Muitos projetos InnerSource se encontram em uma situação em que consistentemente recebem feedback, funcionalidades e correções de bugs de contribuidores. Nessas situações, os mantenedores do projeto buscam maneiras de reconhecer e recompensar o trabalho do contribuidor acima e além de contribuições individuais.
+
+## Apêndice
+
+* [Modelo de Padrão](../../meta/pattern-template.md)
+* Extras
+ * [Modelo de README](../../translation/pt-br/templates/README-template.md)
+ * [Modelo de CONTRIBUTING](../../translation/pt-br/templates/CONTRIBUTING-template.md)
+
+## Recursos
+
+* [Este livro no GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
+* [InnerSource Commons](http://innersourcecommons.org)
diff --git a/book/pt-br/toc_template.md b/book/pt-br/toc_template.md
new file mode 100644
index 000000000..b4164ecce
--- /dev/null
+++ b/book/pt-br/toc_template.md
@@ -0,0 +1,34 @@
+# Sumário
+
+
+
+
+
+* [Introdução](./introduction.md)
+* [Sumário](./toc.md)
+* [Explorar Padrões](./explore-patterns.md)
+* [Contribuir para Este Livro](./contribute.md)
+
+
+
+## Padrões
+
+<>
+
+## Apêndice
+
+* [Modelo de Padrão](../../meta/pattern-template.md)
+* Extras
+ * [Modelo de README](../../translation/pt-br/templates/README-template.md)
+ * [Modelo de CONTRIBUTING](../../translation/pt-br/templates/CONTRIBUTING-template.md)
+
+## Recursos
+
+* [Este livro no GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
+* [InnerSource Commons](http://innersourcecommons.org)
diff --git a/book/scripts/generate_toc.rb b/book/scripts/generate_toc.rb
index 49a608c2f..07a51f590 100644
--- a/book/scripts/generate_toc.rb
+++ b/book/scripts/generate_toc.rb
@@ -93,7 +93,7 @@ def generate_patterns_overview(patterns)
## Inject the list of patterns into the ToC template
new_toc_content = open(TOC_TEMPLATE_FILE).readlines().join()
-new_toc_content = new_toc_content.gsub(/<>/,toc_snippet)
+new_toc_content = new_toc_content.gsub(/<>/,toc_snippet)
## Write the new ToC to file
File.write(TOC_FILE, new_toc_content)
diff --git a/book/zh/toc_template.md b/book/zh/toc_template.md
index 461eb6fe8..a4098a1d7 100644
--- a/book/zh/toc_template.md
+++ b/book/zh/toc_template.md
@@ -19,7 +19,7 @@ Instead edit toc_template.md
## 模式
-<>
+<>
## 附录
diff --git a/translation/pt-br/README.md b/translation/pt-br/README.md
new file mode 100644
index 000000000..ab76789bb
--- /dev/null
+++ b/translation/pt-br/README.md
@@ -0,0 +1,62 @@
+# Processo de Tradução e Recomendações
+
+Se você deseja contribuir para a tradução dos Padrões InnerSource, ótimo! Adoraríamos trabalhar com você!
+
+Primeiro, consulte [CONTRIBUTING.md](/CONTRIBUTING.md) para obter instruções básicas de contribuição.
+
+Este documento aborda princípios básicos de tradução, como você pode contribuir e o processo de revisão.
+
+Observação: Este documento contém recomendações com o objetivo de eliminar barreiras para novos colaboradores no processo de tradução. Caso note algo faltando, sinta-se à vontade para fazer sugestões.
+
+## Os Princípios de Tradução e Recomendações
+
+- O alvo da tradução são padrões estruturados. Encontre-os na pasta [/patterns/2-structured/](../../patterns/2-structured/). Apenas os padrões estruturados serão publicados no Gitbook.
+- O inglês é recomendado para mensagens de commit. Se suas alterações forem mescladas, suas mensagens de commit serão vistas por membros de todo o mundo. Isso facilitará para os membros globais encontrar suas atividades e também acelerará a colaboração.
+- Em relação a Pull Requests e Issues, é uma boa ideia usar o inglês, pelo menos para o título e a declaração de propósito no prefácio. Contribuições em seu idioma e discussões acompanhantes podem ser úteis para outros projetos de tradução no futuro.
+- Cada país tem seu próprio contexto cultural e histórico, assim como diferentes contextos linguísticos. Não é necessário discutir nuances específicas de idioma e expressões linguísticas difíceis em inglês em sua revisão. Especialmente se for uma comunidade local de várias pessoas traduzindo juntas, priorize a facilidade de tradução nessa comunidade.
+
+## Como Contribuir para a Tradução
+
+### Melhorando uma Tradução Existente
+
+- Faça suas alterações no respectivo arquivo `.md`.
+- Quando estiver pronto, envie um Pull Request.
+
+### Traduzindo um Novo Padrão InnerSource
+
+- Copie o padrão que deseja traduzir de `/patterns/2-structured/.md` para `/translation//patterns/.md`.[^1] Certifique-se de manter o mesmo nome de arquivo.
+- Inicie sua tradução nesse novo arquivo.
+- Quando estiver pronto, envie um Pull Request.
+
+### Iniciando a Tradução de um Novo Idioma
+
+Isso é incrível! Agradecemos sua paixão. Ao implementar práticas InnerSource em sua região, podem existir barreiras de idioma. Há um grande valor em fazer com que as pessoas em sua organização entendam InnerSource em seu próprio idioma.
+
+Antes de iniciar uma nova tradução, converse conosco no Slack (no canal `#innersource-patterns`). Alternativamente, abra uma issue neste repositório do GitHub para iniciar uma conversa assíncrona sobre seu projeto de tradução.
+
+A tradução deve começar criando um branch `book-` para trabalhar.[^1]
+Por exemplo, `book-jp` é usado para a tradução japonesa.
+
+Existem algumas coisas que você deve preparar antes de iniciar um projeto de tradução.
+
+- `/translation//patterns/`
+- `/translation//templates/`
+- `/translation//README.md`
+
+No entanto, como o git não cria pastas vazias, é melhor criar diretórios correspondentes ou adicionar arquivos `.keep` para manter as pastas.
+
+### Qualidade da Tradução e Processo de Revisão
+
+Consideramos uma boa prática ter **pelo menos um falante nativo** revisando a tradução.
+
+Especificamente para termos especiais, como "Trusted Committer", revise não apenas a correção gramatical, mas também a adequação. Se encontrar um termo ou expressão difícil de entender, não hesite em perguntar.
+
+### Publicação das Traduções
+
+Os livros atualmente disponíveis estão em inglês e japonês.
+
+Os Trusted Committers neste repositório também serão integrados durante o processo de tradução.
+
+Quando completar uma tradução em `/translation//`, um pipeline do GitHub Actions será executado para gerar a saída para publicação no Gitbook. O processo é detalhado em [/book/README.md](/book/README.md).
+
+[^1]: Substitua `` pelo código de idioma [ISO 639-1 de 2 letras](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) para seu idioma.
diff --git a/translation/pt-br/patterns/30-day-warranty.md b/translation/pt-br/patterns/30-day-warranty.md
new file mode 100644
index 000000000..847fe0333
--- /dev/null
+++ b/translation/pt-br/patterns/30-day-warranty.md
@@ -0,0 +1,76 @@
+## Title
+
+Garantia de 30 dias
+
+## Patlet
+
+Ao aceitar contribuições de fora da sua própria equipe, há uma aversão natural em assumir a responsabilidade pelo código que não foi escrito pela própria equipe. Através da Garantia de 30 dias, a equipe contribuinte concorda em fornecer correções de bugs para a equipe receptora, o que aumentará o nível de confiança entre as duas equipes e torna mais provável que as contribuições sejam aceitas.
+
+## Problema
+
+Uma equipe desenvolve um componente que é utilizado em toda a organização. Essa equipe resiste em aceitar ou rejeita completamente contribuições (pedidos de recursos). Esse comportamento bloqueia o progresso e leva a interrupções frequentes devido a escalonamentos.
+
+## Contexto
+
+- As equipes dependem de outra equipe para aceitar suas contribuições para que um componente produzido pela equipe receptora possa ser utilizado pela equipe contribuinte.
+- A equipe receptora não possui os recursos, conhecimento, permissão e/ou inclinação para escrever o componente/pedido de recurso por si própria.
+
+## Forças
+
+- Existe desconfiança em relação às contribuições devido a um histórico de trapaças: equipes enviaram contribuições incompletas e posteriormente solicitaram correções para torná-las prontas para uso em produção.
+- Se o código é contribuído por uma equipe externa, a equipe receptora tem a suspeita natural de que a outra equipe não sabe como escrever código que atenda às expectativas da equipe receptora.
+- Cada equipe olha primeiro para ajudar seus próprios líderes a alcançar seus próprios objetivos. Essa direção de lealdade pode complicar a resolução desse problema.
+- Existe uma aversão natural em assumir a responsabilidade pelo código não escrito por si próprio.
+- O código contribuído precisa ser amplamente reescrito antes de ser aceito na base de código.
+- Existe o medo de que os contribuintes não estejam disponíveis para dar suporte na correção de bugs após o tempo da contribuição.
+- As equipes temem que o código contribuído levará a custos de manutenção altos (ou mais altos), mas não sabem como controlar isso.
+- As equipes receptoras podem temer que ensinar outras pessoas a contribuir com o código irá expor dívida técnica em seu sistema e que essa visibilidade possa ser prejudicial.
+- As equipes receptoras podem não acreditar que receberão um código aceitável, não importa quanto mentoria seja fornecida.
+- Qualquer uma das equipes pode não se sentir confiante em medir riscos ou certificar que eles são mitigados em uma contribuição; o próprio sistema é um tanto frágil (pode não haver maneiras de testar completamente e detectar todos os problemas).
+
+## Solução
+
+Aborde os medos tanto da equipe que recebe quanto da equipe que contribui, estabelecendo um **período de garantia de 30 dias** a partir do momento em que o código contribuído entra em produção. Durante este período de garantia, a equipe contribuinte concorda em fornecer correções de bugs à equipe receptora.
+
+Observe que o período de garantia também pode ser de 45, 60 ou 100 dias. A duração pode variar com base nas restrições do projeto, no ciclo de vida do software do projeto, nos compromissos com os clientes e em outros fatores.
+
+Além disso, ajuda a fornecer diretrizes claras de [contribuição](./base-documentation.md), especificando as expectativas da equipe receptora e da equipe contribuinte.
+
+
+
+## Contexto Resultante
+
+- A equipe receptora está disposta a aceitar contribuições e é capaz de compartilhar a carga de trabalho de adaptações/correções iniciais.
+- Aumenta a transparência e justiça.
+- Evita que as escalações se tornem muito pesadas.
+
+## Instâncias Conhecidas
+
+- Isso foi testado e comprovado com sucesso na PayPal.
+- O GitHub internamente usa esse padrão com um prazo de garantia modificado de 6 semanas.
+- A Microsoft recomenda esse padrão como um princípio - as equipes estabelecem seu próprio tempo específico, correspondendo às suas necessidades e confiança.
+
+## Autores
+
+- Cedric Williams
+
+## Reconhecimento
+
+- Dirk-Willem van Gulik
+- Padma Sudarsan
+- Klaas-Jan Stol
+- Georg Grütter
+
+## Estado
+
+* Structured
+* Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.
+
+## Variações
+
+- Assegurar a cooperação das equipes dependentes, tornando-as numa comunidade, através da nomeação de mais do que um "[Trusted Committers](./trusted-committer.md)" (TCs) por mérito próprio.
+
+## Histórico de Tradução
+
+- **2022-04-13** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-13** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/base-documentation.md b/translation/pt-br/patterns/base-documentation.md
new file mode 100644
index 000000000..01b3a35d2
--- /dev/null
+++ b/translation/pt-br/patterns/base-documentation.md
@@ -0,0 +1,102 @@
+## Title
+
+Documentação Base Padrão
+
+## Patlet
+
+Novos contributors para um projeto InnerSource têm dificuldade em descobrir quem é o responsável pelo projeto, o que trabalhar e como contribuir. Fornecer documentação em arquivos padrão como `README.md`/`CONTRIBUTING.md` permite um processo de autoatendimento para novos contributors, para que possam encontrar as respostas para as perguntas mais comuns por conta própria.
+
+## Problema
+
+Uma equipe deseja compartilhar um projeto recém-iniciado ou já existente com toda a organização e receber contribuições. Os potenciais contributors muitas vezes ficam perdidos: eles não conseguem identificar os canais de comunicação preferidos da equipe. Eles têm dificuldade em julgar rapidamente se uma nova funcionalidade faz sentido ser adicionada ou não. Eles têm dificuldade em entender exatamente quais colegas estão mantendo ativamente o projeto no momento.
+
+## Contexto
+
+Um projeto será compartilhado com outros como um projeto InnerSource. Para que outros possam entender do que se trata o projeto e como contribuir, o projeto precisa fornecer alguma documentação básica. Até agora, o projeto não tem nenhuma documentação ou faltam alguns aspectos necessários para que os usuários possam testá-lo de forma autônoma e para que os contributors possam se atualizar rapidamente.
+
+## Forças
+
+- O projeto foi convertido em um projeto InnerSource apenas recentemente. Antes, os usuários eram apenas internos ou passavam por sessões pessoais presenciais para serem integrados. Da mesma forma, as pessoas que trabalhavam no projeto passavam por sessões pessoais de integração que não escalavam com o aumento do número de contribuidores ou contribuidores remotos. Como resultado, falta documentação de autoatendimento.
+- O projeto foi recém-criado como um projeto InnerSource. No entanto, a equipe anfitriã não tem experiência com InnerSource. Como resultado, eles precisam de orientação sobre quais informações incluir em sua documentação, onde colocar essa documentação para que outros possam encontrá-la e quais tipos de leitores abordar em sua documentação.
+- O projeto foi convertido em um projeto InnerSource apenas recentemente e a equipe anfitriã tem pouca experiência com InnerSource. Como resultado, a documentação existente aborda muitos aspectos técnicos, mas não abrange a comunicação, coordenação e informações necessárias para facilitar o planejamento transparente.
+- O projeto foi convertido em um projeto InnerSource apenas recentemente. Como resultado, muito conhecimento implícito que existe dentro da equipe não está escrito ou não é óbvio para os contributors.
+- A falta de documentação faz com que potenciais contributors levem muito tempo para configurar e começar a trabalhar. Produzir documentação (e mantê-la atualizada) requer um investimento de tempo. Mesmo que a equipe anfitriã conte com contributors para ajudar com a documentação ausente, essas contribuições ainda precisam de tempo para serem revisadas.
+- Os membros do projeto estão gastando muito tempo respondendo perguntas de como começar. Manter um banco de dados abrangente do que poderia ser considerado perguntas de suporte requer muito tempo e esforço.
+- Diferentes equipes dentro da organização têm padrões divergentes para formatar o código-fonte e usar padrões de software. Como resultado, as contribuições muitas vezes acabam sendo reescritas em grande parte ou até mesmo completamente. Padronizar tudo isso e fazer cumprir o padrão muitas vezes exigiria muito tempo e trabalho.
+- O trabalho adicional de explicações repetidas e reescritas diminui a utilidade da abordagem InnerSource.
+- Escalações frequentes devido ao trabalho extra e atrasos devido a reescritas levam a uma situação de grande problema ("big cheese situation").
+
+## Solução
+
+Abordar a necessidade de documentação mais clara para novos contribuidores. O objetivo ao criar essa documentação deve ser tornar o processo de início o mais automatizado possível, com perguntas frequentes respondidas em um formato padrão de documentação.
+
+### README.md
+
+Se ainda não existir, crie um arquivo `README.md para o seu projeto. Ele deve conter:
+
+* [Missão do projeto](https://producingoss.com/en/producingoss.html#mission-statement) de forma concisa possível. Deve responder qual é o propósito do projeto e permitir que os contributors façam uma boa primeira avaliação se um recurso sugerido provavelmente estará dentro do escopo do projeto ou não.
+* Uma seção "Primeiros passos" para os usuários downstream do projeto. Deve explicar como configurar/integrar os artefatos do projeto, bem como uma explicação dos primeiros passos típicos para usuários iniciantes.
+* Documentação mais detalhada para usuários do projeto - ou um link para isso.
+* Documentação necessária para fazer modificações no projeto - ou um link para isso.
+* Documentação sobre como contribuir para o projeto - ou um link para isso.
+* Uma seção "Iniciando" que explique quais canais públicos, arquivados e vinculáveis de comunicação o projeto utiliza. Isso deve incluir um link para o rastreador de problemas do projeto, mas também para quaisquer outras mídias de discussão utilizadas.
+* Uma seção "Quem somos" explicando quem são os [Trusted Committers](./trusted-committer.md) por trás do projeto - com uma explicação de que, em vez de entrar em contato com essas pessoas em particular, os canais públicos de comunicação acima devem ser usados para comunicação.
+* Uma explicação dos critérios para o projeto transformar contributors em Trusted Committers - se esse caminho existir.
+
+
+
+### CONTRIBUTING.md
+
+Se a explicação dos passos para fazer uma contribuição for muito complexa, crie um documento separado `CONTRIBUTING.md`. Este documento deve responder a perguntas frequentes que os contribuidores fizeram no passado. Não é necessário fornecer um livro abrangente de uma vez. Em vez disso, compartilhe informações que se mostraram necessárias para os contribuidores. Provavelmente, isso abordará um ou mais dos seguintes tópicos:
+
+* Como fazer checkout do código fonte do projeto do controle de versão.
+* Como fazer modificações no projeto (potencialmente incluindo informações sobre diretrizes de codificação).
+* Como fazer build do projeto.
+* Como executar testes para garantir que as modificações acima não estejam introduzindo novos bugs.
+* Como enviar suas modificações de volta ao projeto.
+* Algumas informações sobre o tempo de resposta esperado para as modificações feitas.
+
+
+
+Existem muitos bons exemplos de como escrever um arquivo `README.md` e que tipo de informações incluir em um arquivo `CONTRIBUTING.md` em vários projetos de código aberto. Páginas como [como escrever um readme que se destaca](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a), o [Guia de Código Aberto do GitHub](https://opensource.guide/) e o livro [Producing Open Source](https://producingoss.com/en/producingoss.html) têm informações valiosas sobre que tipo de informações fornecer. Embora Producing Open Source não tenha um capítulo sobre como escrever um bom README em si, o capítulo [Começando a partir do que você tem](https://producingoss.com/en/producingoss.html#starting-from-what-you-have) fornece uma lista bastante extensa de coisas que os membros da equipe, usuários e contributors precisarão. Os projetos InnerSource provavelmente não cobrirão todos esses aspectos desde o início, mas a própria lista é útil para inspiração do que pode ser abordado.
+
+Além disso, este padrão vem com dois modelos básicos para você começar imediatamente: [README-template.md](../templates/README-template.md) e [CONTRIBUTING-template.md](../templates/CONTRIBUTING-template.md)
+
+## Contexto Resultante
+
+* O tempo necessário para que os contribuidores se ambientem é significativamente reduzido.
+* O tempo gasto respondendo às perguntas iniciais de [Trusted Committers](./trusted-committer.md) é significativamente reduzido, deixando-os mais tempo para trabalhar em outras tarefas.
+* As escalonamentos devido a mal-entendidos e falta de alinhamento são significativamente reduzidos.
+
+## Instâncias Conhecidas
+
+* Europace AG - Veja a postagem do blog [InnerSource: Adicionando documentação básica](https://tech.europace.de/post/innersource-base-documentation/)
+* Paypal Inc.
+* Mercado Libre - criado um site de documentação que contendo informações sobre como começar com InnerSource e definido também os artefatos básicos que um repositório deve ter para ser InnerSource (README, CONTRIBUTING, CODING_GUIDELINES, etc.).
+
+## Autores
+
+* Isabel Drost-Fromm
+
+## Alias
+
+Fornecer documentação básica padrão através de um README
+
+## Estado
+
+* Structured
+* Drafted in December 2019.
+
+## Referências
+
+* [README-template.md](../templates/README-template.md) and
+* [CONTRIBUTING-template.md](../templates/CONTRIBUTING-template.md)
+
+## Créditos
+
+[Web](https://storyset.com/web) and [People](https://storyset.com/people) illustrations by Storyset
+
+## Histórico de Tradução
+
+- **2022-04-14** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-14** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/common-requirements.md b/translation/pt-br/patterns/common-requirements.md
new file mode 100644
index 000000000..ddd986bcd
--- /dev/null
+++ b/translation/pt-br/patterns/common-requirements.md
@@ -0,0 +1,78 @@
+## Title
+
+Requisitos Comuns
+
+## Patlet
+
+O código comum em um repositório compartilhado não está atendendo às necessidades de todas as equipes de projeto que desejam usá-lo; isso é resolvido por meio do alinhamento de requisitos e refatoração.
+
+## Problema
+
+O código comum no repositório compartilhado não está atendendo às necessidades de todos os projetos que desejam usá-lo.
+
+## Contexto
+
+* Muitos projetos estão tentando usar um código comum. Existe um repositório compartilhado que todos os projetos acessam.
+* Alguém (ou algum projeto) escreveu o código em primeiro lugar e o contribuiu para o repositório.
+* O código comum é uma pequena porcentagem do resultado geral de qualquer um dos projetos.
+* Cada projeto tem seu próprio cronograma de entrega, conjunto de entregas e clientes.
+* Este padrão se aplica em qualquer uma dessas situações:
+ * há um **Proprietário de Código Forte** ou seja, todas as mudanças no repositório compartilhado devem ser aprovadas pelo proprietário do repositório
+ * há uma **propriedade de código fraca** ou seja, ninguém realmente é dono do código
+ * não há um **Patrocinador Benevolente** ou seja, nenhuma organização ou executivo está fornecendo recursos para organizar o código comum de forma InnerSource.
+
+## Forças
+
+No código disponibilizado pelo projeto original tem um conjunto de necessidades. Suas necessidades são semelhantes ao que algumas das organizações receptoras desejam, mas não exatamente as mesmas. Os requisitos do código devem ser derivados das necessidades reais dos clientes.
+
+As necessidades dos diferentes clientes são geralmente bastante similares; no entanto, elas podem ser expressas de maneira diferente ou ponderadas de forma diferente entre os clientes. Um exemplo pode ser como alguns clientes querem que algum resultado seja apresentado de uma forma, enquanto outros querem que seja apresentado na ordem inversa. É simples fazer a tradução entre eles, mas requer codificação adicional para um dos casos e, como resultado, o módulo que calcula o resultado não pode ser reutilizado por ambos os clientes.
+
+Muitos clientes querem que o fornecedor os ajude a saber do que precisam. A empresa tem muitos "Engenheiros de Sistemas" que escrevem requisitos para os produtos. Esses requisitos devem ser uma destilação das necessidades dos clientes para orientar o desenvolvimento do produto.
+Reutilizar o código é um objetivo importante para economizar tempo e dinheiro da empresa.
+
+## Solução
+
+Existem dois aspectos para resolver este problema que devem ser feitos em paralelo:
+
+1. Alinhar os requisitos dos projetos para que o código que atenda aos requisitos de um projeto também atenda às necessidades dos outros projetos.
+2. Refatorar o código em peças menores para as quais os muitos projetos que o utilizam possam concordar com os requisitos.
+
+Além disso, aproveite que os clientes esperam que o fornecedor ajude a elucidar os requisitos. Promova o alinhamento dos requisitos durante as negociações com o cliente e influencie os requisitos do cliente em vez de alterar o componente.
+
+No exemplo apresentado acima, o fornecedor ajuda ambos os clientes a perceberem que eles querem a mesma coisa, e isso economizará esforço (e dinheiro) se eles concordarem em aceitar o resultado no mesmo formato.
+
+
+
+## Contexto Resultante
+
+Isso pode exigir negociação de mudanças nos requisitos com o cliente. As mudanças também podem exigir o envolvimento das equipes de vendas e gerentes de produtos para obter alinhamento nos requisitos. O cliente pode precisar de incentivos, como descontos, para concordar com as mudanças.
+
+Um desafio relacionado (e possivelmente um novo padrão) é um exercício de escrita de histórias circulares relatado em uma empresa que usa o InnerSource. Em resumo:
+
+* Os desenvolvedores escrevem uma história para resolver um problema de uma maneira.
+* Os gerentes de programa reescrevem a história para expressar melhor suas necessidades - mantendo a essência da história. Quando a história retorna para os desenvolvedores, eles não a reconhecem como algo que eles queriam fazer originalmente e, portanto, hesitam em implementá-la.
+* A solução para esse padrão é ter mais assentos ao redor da mesa de planejamento para que as modificações de histórias sejam compreendidas em todo o projeto, não apenas nos campos dos desenvolvedores ou gerentes de programa.
+
+## Instâncias Conhecidas
+
+* Grande provedor de telecomunicações
+
+## Estado
+
+* Structured
+
+## Autores
+
+Robert Hanmer
+
+## Reconhecimento
+
+* Manrique Lopez
+* Daniel Izquierdo
+* Tim Yao
+* Sebastian Spier
+
+## Histórico de Tradução
+
+- **2022-04-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/communication-tooling.md b/translation/pt-br/patterns/communication-tooling.md
new file mode 100644
index 000000000..0bfeac5f7
--- /dev/null
+++ b/translation/pt-br/patterns/communication-tooling.md
@@ -0,0 +1,84 @@
+## Title
+
+Ferramentas de Comunicação
+
+## Patlet
+
+Os usuários de um projeto InnerSource têm dificuldade em obter ajuda e entrar em contato com a equipe responsável pelo projeto.
+Ao usar consistentemente ferramentas de comunicação assíncronas, o projeto torna as discussões visíveis, arquivadas e pesquisáveis, o que leva a um nível melhorado de suporte para os usuários.
+
+## Problema
+
+Uma equipe está aberta a receber contribuições dos usuários downstream do seu componente. A coordenação e comunicação acontecem de forma ad-hoc, levando a informações incoerentes sendo compartilhadas, atrasos nas respostas recebidas, e os contributors contatando múltiplos membros da equipe anfitriã antes de receberem uma resposta definitiva.
+
+## Contexto
+
+- Uma equipe depende do componente de outra equipe.
+- Ela gostaria de fazer contribuições para esse componente.
+- Mesmo quando a comunicação é feita por escrito, ela ocorre de forma individual.
+
+## Forças
+
+- A equipe anfitriã está interessada em receber contribuições e disposta a orientar os colaboradores.
+- As equipes têm uma forte cultura de comunicação verbal e têm pouca experiência em configurar canais de comunicação assíncronos específicos do projeto.
+- Os canais de comunicação podem estar alinhados a grupos específicos que devem ser alcançados, mas não por objetivo de comunicação específico.
+
+## Solução
+
+A equipe anfitriã deve fornecer canais de comunicação arquivados, pesquisáveis e vinculáveis públicos da empresa, aos quais qualquer pessoa na empresa possa se inscrever, uma vez que existem benefícios mensuráveis em apoiar canais de comunicação escritos e abertos.
+
+O objetivo ao otimizar os canais de comunicação para projetos InnerSource deve ser alinhar a comunicação em torno de tópicos, não em torno de determinados grupos de pessoas.
+
+Um projeto deve configurar as seguintes ferramentas de comunicação:
+
+1. um **issue tracker dedicado** onde a comunicação estruturada, a tomada de decisões e o acompanhamento do progresso possam ocorrer de forma transparente para todos os membros da equipe anfitriã, mas também para os usuários e colaboradores downstream acompanharem. Para outras aplicações do issue tracker, consulte [Issue Tracker Use Cases](./issue-tracker.md).
+2. **canal(is) de discussão pública** que possuem uma estrutura menos rígida. Normalmente, isso será listas de e-mails, fóruns on-line, sistemas de perguntas e respostas ou até mesmo canais de bate-papo arquivados. Geralmente, é suficiente começar com apenas um canal para o projeto. Se o tráfego aumentar demais, é útil separar as discussões sobre o uso do projeto das discussões sobre o desenvolvimento do projeto.
+3. **um canal privado** onde a comunicação sobre tópicos sensíveis possa ocorrer entre [Trusted Committers](./trusted-committer.md) - por exemplo, adicionando mais Trusted Committers à equipe anfitriã. Esse canal deve ser usado com muito cuidado, de modo que a comunicação padrão seja aberta e seja mantida privada apenas em circunstâncias muito raras.
+
+While communication can happen outside of those written channels, as much information as possible should be brought back to the asynchronous channels.
+
+All communication channels should be documented in the project `README.md`. For more details on the use of this file see [Standard Base Documentation](./base-documentation.md).
+
+Embora a comunicação possa ocorrer fora desses canais escritos, o máximo de informações possível deve ser trazido de volta para os canais assíncronos.
+
+
+
+## Contexto Resultante
+
+Configurar e utilizar consistentemente canais de comunicação assíncronos oficiais ajuda a criar um nível básico de [documentação passiva](https://www.oreilly.com/library/view/understanding-the-innersource/9781491986899/ch04.html) que pode ser referenciado novamente quando surgirem perguntas semelhantes no futuro.
+
+Com a comunicação acontecendo em aberto, outros podem facilmente acompanhar o progresso do projeto e se envolver ativamente contribuindo. Outras pessoas observando e lendo reduzem a barreira para se envolver, aumentando a probabilidade de receber contribuições.
+
+Com perguntas sendo respondidas em público, mais pessoas podem adicionar suas perspectivas levando a uma imagem completa - isso inclui não apenas membros da equipe anfitriã, mas também usuários do projeto.
+
+Manter a comunicação em canais assíncronos permite que os participantes com diferentes horários - seja devido a fusos horários diferentes ou devido a rotinas diferentes, horários de reuniões ou rotinas de equipe - contribuam significativamente para o projeto.
+
+Responder perguntas nesses canais significa que não apenas outros membros da equipe podem ouvir e fornecer informações adicionais, mas também significa que outros usuários com a mesma pergunta veem (ou mais tarde encontram) a resposta anterior, levando a uma menor necessidade de repetir explicações.
+
+## Instâncias Conhecidas
+
+* Europace AG
+* Paypal Inc.
+* Mercado Libre
+
+## Autores
+
+Isabel Drost-Fromm
+
+## Reconhecimento
+
+Sebastian Spier (for the visual)
+
+## Estado
+
+* Structured
+* Drafted in December 2019.
+
+## Créditos
+
+[People](https://storyset.com/people) illustrations by Storyset
+
+## Histórico de Tradução
+
+- **2022-04-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/contracted-contributor.md b/translation/pt-br/patterns/contracted-contributor.md
new file mode 100644
index 000000000..920ae171f
--- /dev/null
+++ b/translation/pt-br/patterns/contracted-contributor.md
@@ -0,0 +1,92 @@
+## Title
+
+Colaborador Contratado
+
+## Patlet
+
+Associados que desejam contribuir com o InnerSource são desencorajados a fazê-lo por sua gerência de linha. O alívio é fornecido por meio de contratos e acordos formais.
+
+## Problema
+
+Sem o suporte da gerência intermediária, é provável que o número total de colaboradores e, consequentemente, a quantidade de contribuições feitas e o valor gerado pela iniciativa InnerSource fiquem abaixo das expectativas da gerência de nível superior. Isso provavelmente será amplificado se não houver financiamento adequado e capacitação dos [Líderes Comunitários Dedicados](dedicated-community-leader.md). Isso corre o risco de fazer com que a gerência de nível superior abandone a ideia do InnerSource.
+
+## Contexto
+
+Uma grande corporação iniciou uma iniciativa InnerSource. Os principais objetivos da iniciativa são aumentar a eficiência do desenvolvimento de software distribuído e promover a inovação, permitindo que todos os associados contribuam voluntariamente para projetos InnerSource, independentemente do tópico e unidade de negócios.
+
+A gerência de nível superior está apoiando a iniciativa InnerSource. Para eles, a iniciativa InnerSource é apenas uma de muitas iniciativas para promover a inovação e a eficiência. Eles estão financiando o InnerSource com dinheiro e capacidade para líderes de comunidade e estão dando autonomia quanto à forma como o orçamento é gasto. Eles também estão limitando a amplitude e duração da iniciativa e participam de revisões periódicas até que haja comprovação de que ela produz os resultados esperados (consulte o [Comitê de Revisão](review-committee.md)). A gerência de nível superior anunciou seu apoio ao InnerSource em várias reuniões internas da empresa.
+
+No entanto, a gerência de nível superior ainda não capacitou ou incentivou os gerentes de nível intermediário a permitir ou até mesmo motivar seus funcionários a participar de atividades de InnerSource interdepartamentais. Além disso, a capacidade de cada associado geralmente é alocada para projetos não InnerSource por 100% do seu tempo de trabalho. A colaboração interorganizacional ainda não é a norma e os gerentes de linha geralmente não têm metas fora de sua própria organização. Espera-se que as contribuições para projetos InnerSource sejam feitas durante o horário de trabalho, e não durante o tempo livre.
+
+## Forças
+
+- Os gerentes são responsáveis pelos resultados de suas unidades de negócio. Permitir que sua equipe participe de atividades de InnerSource que possam gastar tempo fazendo contribuições fora de sua unidade de negócio reduz efetivamente a capacidade de sua unidade. Isso provavelmente tornará mais difícil para os gerentes atingir ou exceder seus objetivos.
+- Os gerentes de linha e os recursos humanos, por padrão, avaliarão o desempenho de seus subordinados em relação aos objetivos de suas unidades de negócio, o que pode não estar alinhado com os objetivos da comunidade InnerSource.
+- Quanto menos cobertura executiva um gerente de linha perceber que tem, menos provável é que ele ou ela faça com que sua equipe participe de atividades de InnerSource que contribuam para outra unidade de negócio.
+- Quanto menos transparência e controle um gerente de linha tiver sobre o trabalho realizado por um de seus subordinados, menos provável é que permita que ele contribua.
+- Quanto menos formalmente o trabalho em InnerSource for gerenciado e organizado, menos provável é que um gerente de linha acostumado a processos formais aprove a contribuição de um de seus funcionários para o InnerSource.
+- Quanto mais tempo um associado gasta em contribuições para um projeto InnerSource que não beneficia seu trabalho diário, mais aumentará a carga de trabalho para seus colegas de equipe em sua unidade de negócio.
+- Os contribuidores individuais provavelmente considerarão a participação no InnerSource como uma oportunidade para melhorar sua rede profissional dentro da empresa e adquirir conhecimento e experiência na área técnica de suas contribuições.
+
+## Solução
+
+Estabeleça um contrato formal entre o contribuidor, seu gerente de linha e um escritório de governança InnerSource (ISGO) financiado e dirigido centralmente. O ISGO reembolsará as unidades de negócios que contrataram os contribuidores pelo tempo contratado.
+
+- O contrato especifica uma porcentagem máxima do tempo de trabalho do associado em InnerSource.
+- O contrato declara claramente que o trabalho na unidade de negócios do contribuidor tem prioridade sobre o trabalho em InnerSource.
+- O contrato afirma que não é necessário trabalhar em InnerSource pelo percentual máximo especificado no contrato.
+- O contrato é assinado pelo contribuidor, pelo gerente de linha do contribuidor, pelo escritório de governança e pelo [Dedicated Community Leader](dedicated-community-leader.md) da comunidade na qual o contribuidor irá contribuir.
+- O escritório de governança oferece mediação entre o contribuidor e seu gerente de linha em caso de conflito relacionado ao tempo para contribuições.
+- O [Dedicated Community Leader](dedicated-community-leader.md) participa ou fornece informações para as avaliações de desempenho dos contribuidores contratados por mais de 20%.
+
+
+
+## Contexto Resultante
+
+A formalização do contrato e o reembolso financiado centralmente comunicam de maneira convincente o apoio da organização à iniciativa InnerSource, o que capacita a gestão intermediária a aprová-la:
+
+- A alocação de fundos corporativos às unidades de negócios para o reembolso da capacidade de desenvolvimento sinaliza aos gerentes de linha que InnerSource é considerado valioso pela organização, que tem cobertura executiva e que se espera que eles também o apoiem.
+- Um contrato formal sinaliza que o trabalho em InnerSource é gerenciado profissionalmente e inspira confiança.
+- Um contrato formal aumenta a transparência e fornece uma melhor visão geral sobre a capacidade disponível do associado para sua unidade de negócios e projetos InnerSource, reduzindo assim o risco de "capacidade superagendada/sobrecarregada".
+
+Um contrato formal também é benéfico para os contribuidores e comunidades:
+
+- Com um grupo estável de contribuidores, é mais provável que alguns deles eventualmente alcancem o status de [Trusted Committer](./trusted-committer.md).
+- Um contrato formal fornece uma base para resolver conflitos relacionados à participação em atividades InnerSource. Note que a mediação provavelmente terá sucesso apenas em algumas empresas com uma cultura propícia a isso.
+
+## Instâncias Conhecidas
+
+- BIOS at Robert Bosch GmbH
+
+## Estado
+
+* Structured
+
+## Autores
+
+- Georg Grütter (Robert Bosch GmbH)
+
+## Reconhecimento
+
+- Diogo Fregonese (Robert Bosch GmbH)
+- Robert Hansel (Robert Bosch GmbH)
+- Jim Jagielski
+- Tim Yao
+- Cedric Williams
+- Klaas-Jan Stol
+- Padma Sudarsan
+- Nick Stahl
+- Ofer Hermoni
+- Robert C. Hanmer
+
+## Changelog
+
+- **2016-10-25** - first review
+- **2017-05-09** - rework
+- **2017-09-08** - second review, final rework and merged
+- **2021-02-27** - fixing issues with display of the pattern in the book
+
+## Histórico de Tradução
+
+- **2022-04-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/core-team.md b/translation/pt-br/patterns/core-team.md
new file mode 100644
index 000000000..335fe8320
--- /dev/null
+++ b/translation/pt-br/patterns/core-team.md
@@ -0,0 +1,115 @@
+## Title
+
+Equipe Central
+
+## Patlet
+
+Mesmo quando um projeto InnerSource é amplamente necessário, as contribuições e uso podem ser prejudicados porque o projeto é difícil de trabalhar.
+Estabelecer uma equipe central dedicada a cuidar dos itens fundamentais do projeto.
+O trabalho deles permite que os contributors adicionem e usem recursos que oferecem valor para seus cenários.
+
+## Problema
+
+* É difícil contribuir para o projeto.
+Isso pode ser devido a coisas como:
+ * Não é possível executar o projeto localmente.
+ * Documentação insuficiente.
+ * Código confuso.
+ * Testes inadequados.
+* É difícil usar o projeto.
+Algumas possíveis causas:
+ * Documentação ruim (novamente).
+ * Bugs frequentes.
+ * Configuração não intuitiva.
+
+## História
+
+Existe um projeto central do qual todos dependem.
+Que ótimo candidato para InnerSource!
+Infelizmente, o projeto cresceu organicamente, com várias contribuições e adições feitas de forma descuidada.
+Agora é uma massa espessa e confusa de código que ninguém entende e todos têm medo de tocar.
+É claramente necessário uma revisão completa (por exemplo, refatoração, testes, documentação, etc.), mas mesmo que todos precisem e queiram que esse trabalho aconteça, ninguém tira tempo para fazê-lo.
+
+## Contexto
+
+- Muitas equipes precisam do projeto.
+- O projeto tem uma dívida técnica significativa.
+- Adoção e iteração lentas no projeto.
+- Não há um proprietário ou mantenedor que assuma a responsabilidade pelo ecossistema de projeto e contribuição como um todo.
+
+## Forças
+
+- Cada equipe contribuinte está ocupada e, portanto, prioriza o trabalho que resulta em um retorno imediato para si mesmos.
+- Conforme o projeto cresce, a tendência natural é que ele se torne mais difícil de usar e modificar.
+
+## Solução
+
+Forme uma equipe central cujo trabalho é manter este projeto em um estado para que outros possam facilmente aderir e contribuir para ele.
+Esta equipe central faz o trabalho necessário para um ecossistema de uso e contribuição saudável.
+Este trabalho crítico tende a não ser priorizado como uma contribuição.
+Categorias desse tipo de trabalho incluem comunicação, ambiente local e infraestrutura de DevOps.
+
+Aqui estão alguns exemplos específicos:
+
+- Bugs em produção
+- Documentação
+- Tutoriais e exemplos para integração de novos colaboradores
+- Testes automatizados
+- Integração e entrega contínua (CI/CD)
+- Ambiente local de desenvolvimento
+- Modularização
+- Versionamento
+- Monitoramento
+- Desbravamento de novas classes/categorias de funcionalidades.
+
+Cada um desses itens é muito importante para um ecossistema de produto saudável, mas é improvável que seja priorizado como uma contribuição.
+
+A equipe central pode ser composta por um pequeno número de pessoas em tempo integral ou parcial.
+A escolha depende da quantidade de trabalho necessário, da disponibilidade de recursos e da cultura da organização.
+A consideração mais importante é formar a equipe de forma que permita que a organização a capacite e a responsabilize da mesma maneira que qualquer outra equipe.
+
+Devido ao seu papel central, os membros da equipe central devem quase sempre ocupar também o papel de **Trusted Committers** (para mais informações sobre esse conceito, consulte [Learning Path][tc-learning-path] e [Pattern][tc-pattern]).
+Enquanto o papel do Trusted Committer se concentra principalmente em facilitar a contribuição e uso do projeto por outros, um membro da equipe central contribui regularmente para o projeto também.
+A equipe central não possui sua própria agenda de negócios que determine suas contribuições.
+Eles decidem sobre o que trabalhar com base no que ajudará mais os outros a usar e contribuir para o projeto.
+
+Uma boa maneira de lembrar constantemente a equipe central desse objetivo é pedir que eles relatem regularmente sobre:
+
+- número de equipes ativas que usam o projeto
+- número de contribuições fora das equipes para o projeto.
+
+O foco contínuo nesses indicadores naturalmente levará a equipe central a priorizar geralmente o trabalho correto para criar um ecossistema InnerSource próspero em torno do projeto.
+
+
+
+## Contexto Resultante
+
+- O projeto é fácil de usar e contribuir.
+- Muitas equipes usam e contribuem para o projeto.
+- A equipe central tem o sucesso definido em termos da interação e resposta dos outros ao seu projeto.
+
+## Fundamentação
+
+Separar uma equipe central e encarregá-la dessa forma ajuda a preencher as lacunas que um projeto de sucesso precisa, mas são deixadas para trás por contribuidores que estão perseguindo apenas sua própria agenda. A equipe central preenche essas lacunas e lubrifica as engrenagens para que o ecossistema de contribuição permaneça saudável.
+
+## Instâncias Conhecidas
+
+* **Nike** implementou esse padrão para gerenciar o esforço de InnerSource em torno de seus pipelines de CI/CD reutilizáveis.
+* **WellSky** estabeleceu uma equipe central para um projeto importante. Isso permitiu que eles escalassem significativamente suas contribuições de InnerSource para esse projeto - veja [Wide-Scaled InnerSource with a Core Team](https://www.youtube.com/watch?v=kgxexjYdhIc).
+* **BBVA AI Factory** implementou esse padrão como parte de uma estratégia de InnerSource para promover a contribuição e reutilização de código de ciência de dados - veja [Mercury: Scaling Data Science reusability at BBVA](https://www.bbvaaifactory.com/mercury-acelerando-la-reutilizacion-en-ciencia-de-datos-dentro-de-bbva/).
+
+## Estado
+
+Structured
+
+## Autores
+
+[Russell R. Rutledge](https://github.com/rrrutledge)
+
+[tc-learning-path]: https://innersourcecommons.org/learn/learning-path/trusted-committer/
+[tc-pattern]: ./trusted-committer.md
+
+## Histórico de Tradução
+
+- **2022-04-21** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-21** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/crossteam-project-valuation.md b/translation/pt-br/patterns/crossteam-project-valuation.md
new file mode 100644
index 000000000..13c2a9cf8
--- /dev/null
+++ b/translation/pt-br/patterns/crossteam-project-valuation.md
@@ -0,0 +1,106 @@
+## Title
+
+Avaliação de Projeto entre Equipes
+
+## Patlet
+
+É difícil vender o valor de projetos InnerSource entre equipes que não proporcionam um impacto direto na receita da empresa. Aqui está uma maneira baseada em dados para representar seu projeto que articula seu valor e o amplifica.
+
+## Contexto
+
+* Você é responsável por uma equipe cross que serve como plataforma para outros na empresa.
+* O projeto entre equipes não proporciona nenhum valor direto para a receita da empresa.
+
+## Problema
+
+Projetos entre equipes podem ter um impacto muito grande na empresa, mas são difíceis de representar de maneira baseada em dados. Como resultado, é fácil e comum tanto buscar projetos que não fornecem valor real quanto subfinanciar o que, de outra forma, produziria grande valor.
+
+## Forças
+
+* Os projetos precisam demonstrar valor (objetivo ou subjetivo) à liderança da empresa para serem financiados.
+* O valor do projeto entre equipes é disperso em várias unidades de negócios finais.
+* Devido a essa dispersão, o valor do projeto entre equipes é difícil de medir diretamente.
+
+## Solução
+
+Estabeleça um padrão e modelo de como valorizar projetos entre equipes.
+
+Tais modelos nos fornecem a ferramenta necessária para nos concentrarmos e ampliar a colaboração de alto valor para a empresa.
+
+O core de todo o valor do projeto entre equipes é a ideia de que podemos realizar mais juntos do que separados. Atribuir valor a um esforço entre equipes é um exercício em quantificar _quanto mais_ está sendo feito juntos. O delta exato na produtividade variará de acordo com o domínio e o projeto. Existe um processo comum pelo qual você pode criar um modelo para calculá-lo.
+
+### Explicação
+
+Monte uma pequena equipe de especialistas em seu domínio.
+Usando essa equipe de especialistas, estime 4 coisas sobre cada consumidor de sua saída de projeto:
+
+* Quanto tempo leva para que eles consumam a saída do seu projeto?
+* Quanto tempo levaria para que eles criassem o valor da saída do seu projeto para si mesmos?
+* Qual a porcentagem da saída do seu projeto é realmente útil para eles?
+* Quanto tempo eles gastariam em manutenção da solução criada por eles mesmos, em base contínua (idealmente por uso)?
+
+Ao fazer essas estimativas, é impossível saber com alta precisão exatamente quanto tempo cada atividade leva. Isso não é o seu objetivo. Em vez de exatidão, você deve se esforçar para **estabelecer um limite mínimo** nessas estimativas.
+A ideia é que o grupo de especialistas seja capaz de dizer uns aos outros: "Não sabemos exatamente quanto tempo levaria, mas todos concordamos que é pelo menos isso."
+Especificamente, você deve estimar um tempo máximo razoável para consumir a saída do seu projeto e tempos mínimos razoáveis para os consumidores, caso contrário, criar, usar e manter suas próprias soluções.
+
+Uma observação sobre o custo de "criar sua própria solução" (home-roll). O custo de criar uma solução por conta própria NÃO é necessariamente o mesmo (muito improvável, na verdade) do custo de criar uma solução compartilhada. Muitas vezes, para a mesma funcionalidade, a modularidade e qualidade envolvidas na construção de uma solução compartilhada entre equipes tornam o investimento significativamente maior do que uma implementação rápida e codificada usada apenas uma vez.
+
+### Fórmula
+
+Depois de estimar os limites piores casos, você pode calcular o valor da saída do seu projeto de equipe cross durante um determinado período de tempo usando a fórmula simples:
+
+```
+[Tempo Economizado] - [Tempo Investido]
+
+([Número de novas implementações] * [Custo para desenvolver internamente] * [Porcentagem de funcionalidade útil] + [Número de usos] * [Custo de manutenção por uso]) - ([Número de novas implementações] * [Custo de implementação])
+
+[Número de novas implementações] * ([Custo para desenvolver internamente] * [Porcentagem de funcionalidade útil] - [Custo de implementação]) + [Número de usos] * [Custo de manutenção por uso]
+```
+
+### Comentário
+
+Apesar das aparências de rigor, esse processo não produz uma forma exata de medir a saída de projetos entre equipes.
+Na prática, entretanto, ele oferece um modelo através do qual você pode tomar uma decisão adequada de como financiar esse trabalho.
+Depois de ter dados bons e razoáveis conforme explicado acima, você deve financiar horas de desenvolvimento dedicadas para executar o projeto em, _**pelo menos**_ um dos três níveis abaixo:
+
+1. O número de horas poupadas pela fórmula acima. Como todos temos certeza de que a fórmula produzirá um número abaixo do verdadeiro número de horas salvas, você pode ter a confiança de que financiar o projeto até esse ponto é uma vitória certa para você.
+1. A quantidade de tempo que leva para dar suporte a contribuições internas para projetos entre equipes. Como o colaborador provavelmente teria feito o trabalho de qualquer maneira de forma única, vale a pena financiar o tempo que leva para facilitar o trabalho dele ser compartilhado.
+1. Qualquer quantia que pareça boa para você. Um efeito colateral intencional de ter uma fórmula de valoração é que ela naturalmente força a medição dos pontos-chave de uso que fornecem valor aos consumidores.
+
+Essas medidas podem ser compreendidas e utilizadas em sua forma bruta para lhe fornecer uma ideia intuitiva de quão valioso é o projeto.
+
+Algumas pessoas podem se preocupar com a falta de precisão nessa abordagem de valoração. Mas tudo bem se esse processo não fornecer uma medição exata. Ele só precisa ser preciso o suficiente para cumprir dois objetivos:
+
+1. Dar um meio de representar o valor do que está acontecendo para aqueles que estão organizando e financiando esforços entre equipes.
+1. Ajudar aqueles envolvidos a saber quais áreas de esforço entre equipes são prioritárias com base em seu valor.
+
+Na prática, desde que essas valorações estejam dentro de uma ordem de grandeza da realidade e uma da outra, elas são suficientemente precisas para cumprir esses propósitos. Elas fornecerão uma melhoria significativa nos resultados em relação às valorações ad hoc (e aos efeitos resultantes) descritas na seção Problema no início deste documento.
+
+## Contexto Resultante
+
+* Meios baseados em dados para discutir o valor e financiamento do projeto de equipe cross com a liderança.
+* Métricas-chave em torno do projeto de equipe cross instrumentalizadas em forma bruta.
+* Definir como o projeto de equipe cross fornece valor tende a levar a ele produzir maior valor para a empresa.
+* Projeto geralmente bem-sucedido e "buzz" em torno dele.
+
+## Instâncias Conhecidas
+
+* Nike
+
+## Estado
+
+* Structured
+* Proven in multiple domains.
+
+## Autores
+
+* Russ Rutledge
+
+## Reconhecimento
+
+* Jeremiah Wright por me ensinar a pensar em projetos entre equipes como um negócio interno que opera na moeda do tempo dos desenvolvedores.
+
+## Histórico de Tradução
+
+- **2022-04-27** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-27** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/dedicated-community-leader.md b/translation/pt-br/patterns/dedicated-community-leader.md
new file mode 100644
index 000000000..a6ab2862a
--- /dev/null
+++ b/translation/pt-br/patterns/dedicated-community-leader.md
@@ -0,0 +1,93 @@
+## Title
+
+Líder de Comunidade Dedicado
+
+## Patlet
+
+Selecione pessoas com habilidades tanto em comunicação quanto em técnicas para liderar as comunidades e garantir o sucesso na iniciativa InnerSource
+
+## Problema
+
+Como garantir que uma nova iniciativa InnerSource tenha o [Líder de Comunidade](http://www.artofcommunityonline.org/) correto para aumentar seu impacto?
+
+Selecionar as pessoas erradas e/ou não fornecer capacitação suficiente para elas pode acarretar em esforços desperdiçados e, em última análise, no fracasso de uma nova iniciativa InnerSource.
+
+## História
+
+Considere a seguinte história. Uma empresa deseja iniciar uma iniciativa InnerSource para promover a colaboração entre as fronteiras organizacionais. Eles decidiram começar com uma fase experimental com escopo limitado. A gerência selecionou um tópico piloto adequado para a primeira comunidade do InnerSource e espera contribuições de muitas unidades de negócios da organização. A empresa nomeou um novo contratado para liderar a comunidade durante 50% do seu tempo de trabalho, pois ele ainda não estava 100% planejado. Após seis meses, a comunidade recebeu apenas algumas contribuições, a maioria delas de uma única unidade de negócios. A empresa substitui o líder da comunidade por alguém que tem um histórico mais longo na empresa, dessa vez por apenas 30% de seu tempo. Após mais seis meses, o número de contribuições aumentou apenas marginalmente. A empresa não está mais convencida de que o InnerSource ajuda a atingir sua meta de aumentar a colaboração entre divisões e abandona o InnerSource.
+
+## Contexto
+
+- A empresa é uma empresa grande e antiga. Ela não tem experiência anterior em código aberto ou em outros modelos de trabalho baseados na comunidade. A cultura da empresa é mais bem caracterizada como um estilo clássico de gerenciamento de cima para baixo e, em geral, está em desacordo com a cultura da comunidade.
+- Embora haja apoiadores e um patrocinador na gerência de alto nível, a gerência intermediária da empresa ainda não está convencida do InnerSource.
+- A gerência não foi convencida a fornecer mais do que um orçamento limitado para financiar apenas um líder da comunidade em tempo parcial.
+- O líder da comunidade inicialmente selecionado tem pouca ou nenhuma experiência anterior com o modelo de trabalho de código aberto.
+- O líder da comunidade de desenvolvedores inicialmente selecionado não tem uma rede extensa na empresa.
+
+## Forças
+
+Se uma empresa não investe significativamente na comunidade inicial de InnerSource em termos de orçamento e capacidade para InnerSource, a credibilidade de seu compromisso com InnerSource pode ser questionada. Um impulso comum de uma empresa com uma cultura de gestão tradicional diante de um projeto ou iniciativa que não esteja atendendo às expectativas é substituir seu líder. Fazer isso sem envolver a comunidade e seguir princípios meritocráticos ainda prejudicará o compromisso da empresa com InnerSource, destacando o atrito entre a cultura atual da empresa e a cultura almejada - uma cultura comunitária.
+
+A contribuição de valor dos projetos InnerSource não será óbvia para muitos gerentes que estão imersos em métodos tradicionais de gerenciamento de projetos. Esses gerentes são menos propensos a designar um de seus principais funcionários, que geralmente são muito solicitados por projetos que não são InnerSource, para um projeto InnerSource por uma porcentagem significativa do tempo de trabalho deles.
+
+A comunicação ocupa uma porcentagem significativa do trabalho diário de um líder da comunidade. Ao mesmo tempo, ele ou ela provavelmente também terá que liderar o desenvolvimento inicial. Diante de capacidade limitada, líderes inexperientes tenderão a se concentrar no desenvolvimento e negligenciar a comunicação. A barreira para potenciais colaboradores fazerem sua primeira contribuição e se comprometerem com a comunidade será muito maior se o líder da comunidade for difícil de alcançar ou demorar a responder a feedback e perguntas por falta de tempo. Além disso, líderes tecnicamente inexperientes provavelmente terão mais dificuldade para atrair e reter colaboradores altamente experientes do que um funcionário de destaque com alto grau de visibilidade dentro de uma empresa teria.
+
+Se uma comunidade não consegue crescer rápido o suficiente e ganhar impulso, é provável que não consiga demonstrar de forma convincente o potencial do InnerSource.
+
+Se a empresa selecionar um gerente de projeto ou de linha experiente imerso em métodos tradicionais de gestão para ser o líder da comunidade, é provável que ele ou ela se concentre em tópicos de gestão tradicional, como alocação de recursos, fornecimento de estrutura e canais de relatório, em vez de liderar pelo exemplo por meio de princípios meritocráticos. Isso minará a credibilidade da iniciativa InnerSource aos olhos dos desenvolvedores.
+
+## Solução
+
+Selecione um líder da comunidade que:
+
+- Possua experiência no modelo de trabalho em código aberto ou em modelos de trabalho comunitário similares.
+- Tenha as habilidades interpessoais necessárias para atuar como líder natural.
+- Lidere pelo exemplo e, assim, justifique sua posição na meritocracia da comunidade.
+- Seja um excelente articulador de rede.
+- Inspire os membros da comunidade.
+- Seja capaz de se comunicar efetivamente tanto com a alta gestão quanto com os desenvolvedores.
+- Seja capaz de lidar com os aspectos gerenciais do trabalho comunitário.
+
+Empodere o líder da comunidade a dedicar 100% do seu tempo ao trabalho comunitário, incluindo comunicação e desenvolvimento. Informe a gestão sobre a necessidade de ser sensível às opiniões da comunidade ao engendrar uma mudança na gestão da comunidade. Idealmente, capacite a comunidade a indicar seu próprio líder.
+
+## Contexto Resultante
+
+Um líder da comunidade com as propriedades descritas acima dará um rosto e incorporará o compromisso da empresa com o InnerSource. Isso tornará mais provável que outros associados em sua rede sigam seu exemplo e contribuam para o InnerSource. Com o tempo, ele ou ela poderá construir uma equipe central estável de desenvolvedores e, assim, aumentar as chances de sucesso para o projeto InnerSource. Ao convencer uma audiência grande o suficiente dentro de sua empresa sobre o potencial do InnerSource, ele ou ela fará uma contribuição importante para mudar a cultura da empresa em direção a uma cultura comunitária.
+
+Ter líder da comunidade excelentes e dedicados é uma condição prévia para o sucesso do InnerSource. No entanto, não é uma solução mágica. Existem muitos desafios do InnerSource que vão além do que um líder da comunidade pode enfrentar, como desafios orçamentários, legais, fiscais ou organizacionais.
+
+## Instâncias Conhecidas
+
+_BIOS na Robert Bosch GmbH_. Note que o InnerSource na Bosch teve como objetivo principal aumentar a inovação e, em grande parte, lidou com produtos voltados para uso interno. Esse padrão atualmente não é utilizado na Bosch por falta de financiamento.
+
+## Alias
+
+Gerente de Comunidade Dedicado
+
+## Estado
+
+* Structured
+
+## Autores
+
+- Georg Grütter (Robert Bosch GmbH)
+- Diogo Fregonese (Robert Bosch GmbH)
+
+## Reconhecimento
+
+- Tim Yao
+- Padma Sudarsan
+- Nigel Green
+- Nick Yeates
+- Erin Bank
+- Daniel Izquierdo
+
+## Changelog
+
+- **2016-11-06** - 1st review
+- **2017-04-06** - 2nd review
+
+## Histórico de Tradução
+
+- **2022-04-21** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-21** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/document-your-guiding-principles.md b/translation/pt-br/patterns/document-your-guiding-principles.md
new file mode 100644
index 000000000..9d824db10
--- /dev/null
+++ b/translation/pt-br/patterns/document-your-guiding-principles.md
@@ -0,0 +1,215 @@
+## Title
+
+Documente seus Princípios Orientadores
+
+## Patlet
+
+A explicação comum do InnerSource, "aplicando as melhores práticas de código aberto dentro de uma organização", não funciona bem com pessoas que não possuem um background em código aberto.
+Como solução, os princípios mais importantes do InnerSource são documentados e publicados amplamente.
+
+## Problema
+
+A organização está tentando implementar o InnerSource em uma escala maior.
+A iniciativa começou entre entusiastas de código aberto.
+O objetivo agora é obter a adesão de pessoas que não possuem experiência em código aberto.
+Para esse público, o slogan típico de "aplicar as melhores práticas de código aberto" não é mais suficiente para transmitir a mensagem do que é o InnerSource, quais problemas ele resolve e quais ferramentas ele usa para solucionar esses problemas.
+Como resultado, a adoção do InnerSource na organização diminui.
+As equipes desenvolvem ideias divergentes sobre os objetivos do InnerSource e como implementá-lo da melhor maneira, o que leva a confusão quando os contribuidores começam a cruzar as fronteiras das equipes
+
+## História
+
+Experimentos iniciais em uma organização mostraram que as melhores práticas de colaboração em código aberto podem ser benéficas.
+O próximo passo agora é levar a iniciativa para equipes e indivíduos que não possuem um amplo conhecimento em código aberto.
+
+A meta agora é comunicar claramente os objetivos da iniciativa InnerSource, bem como um caminho claro para alcançar os mesmos.
+
+## Contexto
+
+* A terminologia InnerSource está circulando entre os funcionários.
+* A iniciativa começou entre entusiastas do código aberto.
+
+## Forças
+
+* As equipes têm dificuldade em comunicar exatamente quais são os aspectos importantes do InnerSource.
+* As pessoas que não possuem experiência em código aberto falham em entender o que significa trazer as melhores práticas do código aberto para dentro da organização.
+* No dia a dia, as equipes que tentam seguir as melhores práticas do InnerSource têm dificuldade em decidir se o que estão fazendo está alinhado com os valores gerais do InnerSource.
+
+## Solução
+
+Aqueles que lideram a iniciativa InnerSource na organização precisam ajudar as equipes e indivíduos que têm pouco conhecimento em código aberto e, portanto, têm menos compreensão intuitiva do InnerSource.
+
+A clareza deve ser fornecida às equipes e indivíduos por meio da documentação dessas duas áreas:
+
+1. **Propósito** - Por que a organização deseja adotar o InnerSource?
+2. **Princípios** - Quais são os princípios do InnerSource que ajudarão a enfrentar esses desafios?
+
+As seguintes seções fornecem mais detalhes sobre ambos, destinados a servir como possíveis pontos de partida para documentá-los em sua organização.
+
+### Por que a organização quer adotar o InnerSource?
+
+No passado, o InnerSource provou ser bem-sucedido em resolver várias questões comumente encontradas em organizações.
+
+Porém, quais desafios organizacionais a sua organização espera melhorar usando o InnerSource?
+
+Em vez de fazer generalizações, tente identificar exatamente as soluções que correspondam aos desafios da sua organização - de preferência com aqueles afetados pela mudança que você deseja ver.
+
+Alguns desafios que outras organizações abordaram seguindo as melhores práticas do InnerSource:
+
+* Reduzir silos de desenvolvimento causados por uma cultura excessiva de propriedade.
+* Aumentar a velocidade de inovação, reduzindo o tempo gasto resolvendo problemas semelhantes, promovendo um código saudável para reutilização.
+* Aumentar a velocidade de desenvolvimento através de uma melhor colaboração entre equipes.
+* Resolver dependências de projetos/equipes além de "esperar" ou "construir soluções alternativas", reduzindo gargalos de engenharia.
+* Aumentar a qualidade.
+* Aumentar a satisfação dos funcionários.
+* Aumentar o sucesso de novas contratações.
+* Construir documentação acionável.
+
+### Quais princípios do InnerSource ajudarão a abordar esses desafios?
+
+Uma vez que as equipes compreendem quais problemas o InnerSource irá ajudá-las a resolver, o próximo passo é explicar quais princípios ajudam a enfrentar esses desafios.
+
+Com base nos princípios básicos de desenvolvimento de código aberto, as seguintes diretrizes têm se mostrado bem-sucedidas:
+
+(1) O código deve ser hospedado de forma transparente dentro da organização.
+
+O código-fonte, documentação e dados relevantes para o desenvolvimento do projeto devem estar disponíveis e serem facilmente encontrados por qualquer pessoa na organização.
+
+(2) Contribuições em vez de pedidos de funcionalidade.
+
+Todos os envolvidos em um projeto agem como potenciais colaboradores e são tratados e apoiados como tal.
+As contribuições permanecem como sugestões em vez de requisitos.
+A coordenação antes de uma contribuição ajuda a evitar esforço desperdiçado.
+Os projetos fornecem diretrizes de contribuição para evitar fricção.
+
+(3) Erros são oportunidades de aprendizado.
+
+Com o trabalho visível em toda a organização, qualquer erro é visível para todos. Como resultado, deve ser estabelecida uma cultura em que os erros sejam oportunidades de aprendizado em vez de falhas que devem ser evitadas a todo custo.
+
+(4) Escrita acima de comunicação verbal.
+
+Para projetos que envolvem várias equipes, potencialmente em horários de reunião divergentes, é necessário colaborar de forma assíncrona.
+O objetivo dos projetos InnerSource é recrutar novos colaboradores.
+Para isso, futuros colaboradores potenciais precisam ser capazes de acompanhar o progresso do projeto de forma autônoma com uma barreira muito baixa para entrada.
+Se a comunicação relevante do projeto acontecer por meio de comunicação síncrona, os argumentos discutidos precisam ser registrados no canal escrito - as decisões devem ser finalizadas apenas lá.
+Como efeito colateral, isso leva a uma documentação básica passiva que é muito valiosa para qualquer recém-chegado ao projeto.
+
+(5) Permitir que conselhos escritos acumulem em um arquivo persistente e pesquisável.
+
+Toda a comunicação do projeto, em particular as decisões tomadas e as discussões que levaram a essas decisões, precisam ser arquivadas.
+Deve ser possível referenciar a comunicação por meio de URLs estáveis.
+A comunicação anterior precisa ser armazenada de forma que possa ser facilmente pesquisada.
+
+Dois avisos, no entanto:
+
+1. Isso não substitui a documentação estruturada. No entanto, pode servir como ponto de partida para coletar documentação estruturada.
+2. Há exceções à regra de que tudo deve ser escrito e acessível a toda a organização: discussões relacionadas a pessoas e discussões relacionadas à segurança são sensíveis e não devem ser realizadas publicamente.
+
+(6) Recompensar Trusted Committership
+
+Todas as contribuições (por exemplo, código fonte, documentação, relatórios de bugs, participação em discussões, suporte ao usuário, marketing) são bem-vindas e são recompensadas.
+Aqueles que demonstram apoio ao projeto são convidados como [Trusted Committers](./trusted-committer.md).
+Todos os Trusted Committers de um projeto são publicados.
+
+## Contexto Resultante
+
+* Membros da organização entendem quais desafios podem ser enfrentados aplicando as melhores práticas de InnerSource.
+* Membros da organização sem experiência prévia em código aberto entendem os valores e princípios básicos dos projetos InnerSource.
+* Membros da organização sem experiência prévia em código aberto conseguem verificar suas atividades diárias em relação a um conjunto de valores comuns estabelecidos.
+* As práticas de desenvolvimento da organização se tornam mais semelhantes aos projetos de código aberto, tornando mais fácil para os membros da organização participar de projetos de código aberto.
+
+## Instâncias Conhecidas
+
+### Europace AG
+
+Os princípios de InnerSource listados na Solução acima são em sua maioria baseados na experiência da Europace.
+Para mais detalhes, consulte [Europace InnerSource Prinzipien](https://tech.europace.de/post/europace-inner-source-prinzipien/) (em alemão).
+
+### GitHub
+
+#### Objetivo
+
+Muitas vezes, na GitHub, trabalhamos em um modelo em que equipes contribuem com recursos para áreas fora de sua responsabilidade. Exemplos comuns incluem engenharia de vendas contribuindo com recursos para desbloquear uma venda, projetos especiais contribuindo com recursos urgentemente necessários e de alto impacto em todo o produto e uma equipe trabalhando em várias áreas para entregar uma funcionalidade.
+
+#### Princípios
+
+No geral, os princípios descritos neste documento visam evitar o aumento da dívida técnica e da carga de suporte para a equipe responsável. Muitas vezes, ajuda é oferecida a uma equipe porque eles estão atrasados devido aos custos de suporte e manutenção em sua área de responsabilidade e não têm capacidade para contribuir para o recurso. Qualquer novo recurso realizado por outra equipe que aumente essa carga de suporte ou dívida técnica significa ainda menos tempo para a equipe responsável trabalhar em novos recursos, portanto, queremos garantir que sejam feitos corretamente.
+
+Ao mesmo tempo, buscamos ser uma empresa na qual os engenheiros trabalhem livremente em diferentes áreas e prioridades de negócios frequentemente exigem que contribuamos para áreas fora de nossas áreas principais de responsabilidade.
+
+Um bom resumo dos princípios é deixar a área em tão bom estado quanto ou em melhor estado do que você a encontrou.
+
+Com isso em mente, aqui estão os princípios em que concordamos:
+
+- Evite produtos minimamente viáveis (MVPs) que acumulam dívida de recursos. Está tudo bem lançar um MVP para obter feedback do cliente, mas a equipe que contribui deve estar comprometida em concluir o conjunto de recursos. Exemplos incluem:
+ - Compromisso em ir além do MVP para uma solução que irá satisfazer a maioria dos clientes.
+ - Suporte completo para administração de novos recursos (por exemplo, suporte na interface do usuário de configurações, em vez de apenas executar uma linha de comando).
+ - Disponibilização de recursos tanto na interface do usuário quanto na API, em vez de fornecer apenas uma API (ou vice-versa).
+ - Garantir que os recursos funcionem em ambientes de servidor local e em nuvem.
+- Apoiar o trabalho de criação de novas funcionalidades desde o início até depois da sua implementação em produção
+ - Coordenar o lançamento incremental
+ - Lidar com os tickets de suporte
+ - Planejar tempo para lidar com o feedback dos clientes (funcionalidades e bugs)
+
+- Construir recursos da maneira correta (não acumular dívidas técnicas)
+ - Concordar com requisitos e solução com as equipes de Produto e Engenharia
+ - Arquitetura e design adequados
+ - Certificar-se de que os dados sejam armazenados adequadamente para evitar migrações de dados posteriormente.
+ - Telemetria adequada está em vigor
+ - Cobertura de testes adequada está em vigor
+ - Suportado em ambientes de produção na nuvem e local (incluindo configuração, backup/restauração, migrações, etc.)
+ - Correção de bugs
+ - Documentação atualizada
+
+#### Compromisso
+
+Usamos um modelo de engajamento porque gostamos de definir quais medidas concretas podem ser tomadas por uma equipe ao contribuir com recursos para áreas fora de sua área de responsabilidade.
+
+Um modelo de envolvimento típico no GitHub é parecido com este:
+
+- Obter a aprovação do conjunto de recursos e do plano de implementação do proprietário do produto.
+- Obtenha a aprovação do projeto de engenharia, incluindo a abordagem dos requisitos não funcionais (telemetria, cobertura de testes, testes em vários ambientes e suporte) do proprietário da engenharia (geralmente o gerente e o diretor de engenharia).
+- Faça revisões de código ao longo do processo, juntamente com a revisão de quaisquer requisitos novos ou alterados.
+
+### Robert Bosch GmbH
+
+#### Objetivo
+
+Promover a colaboração, o aprendizado e a inovação é o foco principal da iniciativa Bosch InnerSource (BIOS).
+
+#### Princípios
+
+Para isso, a Bosch aplicou os seguintes princípios:
+
+- **Abertura**: Reduzimos as barreiras de entrada nas comunidades de BIOS o máximo que podemos.
+- Transparência**: Somos radicalmente transparentes e compartilhamos nossos produtos de trabalho, nossa comunicação e nossa tomada de decisões com todos os associados da empresa.
+- Voluntariedade**: A decisão de participar e contribuir com a comunidade da BIOS fica a cargo de cada associado. Os funcionários devem trabalhar na BIOS porque estão intrinsecamente motivados, e não porque o gerente lhes disse isso.
+- Autodeterminação**: As comunidades da BIOS são livres para escolher no que trabalhar, quando trabalhar e quais ferramentas e processos usar para trabalhar.
+- Meritocracia**: O poder é investido nos membros do projeto BIOS com base em seus méritos, ou seja, com base na qualidade e na quantidade de suas contribuições.
+
+
+
+Os princípios _Abertura_, _Transparência_ e _Voluntariedade_ ajudaram a desenvolver diversas comunidades de associados intrinsecamente motivados.
+A _Meritocracia_ provou ser uma motivação eficaz para fazer grandes contribuições.
+A _Autodeterminação_ permitiu que as comunidades usassem seu tempo limitado para contribuições da maneira mais eficaz e eficiente.
+
+## Estado
+
+Structured
+
+## Autores
+
+* Isabel Drost-Fromm
+* Georg Grütter
+
+## Reconhecimento
+
+* Zack Koppert - for sharing GitHub's approach in the Known Instances
+
+## Alias
+
+Explicit InnerSource Principles
+
+## Histórico de Tradução
+
+- **2022-04-29** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-29** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/gig-marketplace.md b/translation/pt-br/patterns/gig-marketplace.md
new file mode 100644
index 000000000..03588a33a
--- /dev/null
+++ b/translation/pt-br/patterns/gig-marketplace.md
@@ -0,0 +1,78 @@
+## Title
+
+Gig Marketplace
+
+## Patlet
+
+Estabeleça um mercado criando um site intranet que liste necessidades específicas de projetos InnerSource como "Gigs", com requisitos explícitos de tempo e habilidades. Isso permitirá que os gerentes entendam melhor o compromisso de tempo de seus funcionários e os benefícios profissionais, aumentando assim a probabilidade de obter a aprovação para fazer contribuições InnerSource.
+
+## Problema
+
+Nem os gerentes nem os funcionários entendem como poderiam se beneficiar ao se envolverem em um projeto InnerSource.
+
+É difícil para os funcionários comunicarem à sua gestão qual o compromisso de tempo que eles precisarão ter para um projeto InnerSource.
+
+Os gerentes não têm uma maneira uniforme de acompanhar ou recompensar o envolvimento de seus funcionários em projetos InnerSource.
+
+## História
+
+Você criou com sucesso um programa InnerSource em sua empresa e obteve o apoio da alta gerência, gerência intermediária e desenvolvedores. No entanto, após quase um ano, houve poucas contribuições reais para quaisquer projetos InnerSource fora das equipes que os criaram originalmente. Após entrevistar todas as partes envolvidas, o principal obstáculo parece ser que é difícil saber o compromisso de tempo que os desenvolvedores terão se optarem por se envolver em um projeto InnerSource e como se beneficiarão pessoalmente. Também não há uma maneira uniforme de anunciar quais oportunidades de contribuição existem, o que será solicitado e aproximadamente quanto tempo levará. Os gerentes são solidários e desejam que seus funcionários participem, mas até agora têm falta de uma maneira de contabilizar ou recompensar as atividades de seus funcionários dentro de projetos InnerSource. O que pode ser feito para melhorar esta situação para todas as partes envolvidas (proprietários de projetos InnerSource, possíveis contribuidores e gerentes de desenvolvimento)?
+
+## Contexto
+
+Os funcionários gostariam de ter contato com atividades realizadas em outras áreas da empresa sem ter de deixar seus cargos atuais. Os projetos InnerSource existem e poderiam proporcionar essas experiências, mas há dois fatores principais que impedem os funcionários de participar. O primeiro é a incapacidade de descobrir facilmente quais são as oportunidades de contribuição existentes nos projetos InnerSource em andamento e de comunicá-las aos seus gerentes. O segundo é a incapacidade dos gerentes de planejar e contabilizar o tempo que seus funcionários dedicam a essas tarefas do projeto InnerSource. Como resultado, os proprietários de projetos InnerSource estão encontrando dificuldades para criar comunidades de tamanho suficiente para cumprir suas metas declaradas.
+
+## Forças
+
+* Os funcionários não têm uma maneira fácil de descobrir as oportunidades existentes no InnerSource
+* Os funcionários não entendem como a contribuição pode beneficiá-los profissionalmente.
+* Os gerentes não entendem os requisitos de tempo/esforço associados às tarefas relacionadas ao projeto InnerSource.
+
+### Pré-requisitos
+
+* Os funcionários têm recebido tempo de seus gerentes para se envolverem em projetos InnerSource.
+* Os gerentes exigem uma forma de quantificar, rastrear e registrar as contribuições do InnerSource para que possam ser contabilizadas e recompensadas.
+
+## Solução
+
+Crie um site de intranet baseado em "Gig", no qual os indivíduos possam anunciar suas habilidades e áreas de interesse e os proprietários de projetos InnerSource possam anunciar oportunidades de colaboração.
+
+Os funcionários devem ser capazes de criar um perfil dentro do aplicativo no qual possam listar suas habilidades e áreas de interesse. O sistema deve aproveitar essas informações, informando proativamente os indivíduos (por e-mail ou por outros meios) quando for publicada uma vaga que corresponda a um ou mais desses critérios.
+
+Cada Gig postada por um proprietário de projeto InnerSource deve incluir os requisitos estimados de habilidade e tempo para que possam ser facilmente combinados com um funcionário disponível e claramente comunicados à sua gerência direta. A descrição também deve incluir uma justificativa de como isso beneficiará a pessoa que assumir a tarefa, a fim de torná-la o mais atraente possível.
+
+Um sistema baseado em pontos poderia ser criado para recompensar e rastrear o envolvimento de um funcionário em uma gig. Por exemplo, 10 pontos concedidos ao proprietário da gig por postar uma gig depois de concluída e 100 pontos para um desenvolvedor que concluir uma gig. Os pontos acumulados pela conclusão de Gigs poderiam ser usados como um mecanismo de gamificação e como critérios de gerenciamento de desempenho para obter informações sobre as áreas de especialização existentes em uma organização.
+
+Aqueles que desejarem aceitar uma gig devem primeiro ser avaliados pelo proprietário da gig para determinar se o funcionário tem as habilidades necessárias e o tempo alocado por seu gerente para concluir a gig.
+
+A transparência das contribuições feitas por meio de Gigs pode ajudar um colaborador a construir (ou diminuir) sua reputação, criando assim uma probabilidade maior de que a qualidade da contribuição seja alta. A conclusão de gigs também pode funcionar como prova de especialização em uma determinada área.
+
+A natureza das gigs postadas no marketplace pode incluir habilidades técnicas e interpessoais, como a organização de um evento em grupo, a redação de um relatório ou solicitações de orientação etc.
+
+O ideal é que a criação do Gig Marketplace seja assumida por uma equipe dentro de uma organização com a responsabilidade de fornecer infraestrutura e recursos para toda a empresa.
+
+## Contexto Resultante
+
+O Gig Marketplace InnerSource aumentou enormemente o número de projetos InnerSource, bem como o número de funcionários envolvidos neles. A natureza autodirigida do Gig Marketplace aumentou a satisfação no trabalho entre os funcionários, permitindo-lhes um nível de escolha no trabalho que realizam e com quem podem fazer parcerias em toda a empresa. Os funcionários entendem exatamente no que estão se inscrevendo e o que podem esperar da experiência. Os gerentes têm mais condições de estimar e acompanhar os compromissos de tempo de seus funcionários com relação aos projetos do InnerSource, reconhecer seus esforços individuais e usar a conclusão de Gigs como uma forma de validar suas habilidades específicas. Os gerentes também podem aproveitar qualquer tempo ocioso que seus funcionários possam estar enfrentando, permitindo que eles se voltem para o trabalho disponível no Gig Marketplace. Os dados gerados pelas interações no Gig Marketplace também estão ajudando a orientar as decisões de contratação e treinamento em todos os departamentos.
+
+Quando usado em combinação com o padrão do Portal InnerSource, o Gig Marketplace fornece um nível mais refinado de contexto e detalhes, além dos links para os repositórios de código e a documentação do projeto ao qual o Gig está relacionado.
+
+## Instâncias Conhecidas
+
+* Uma grande organização de serviços financeiros usou a criação de um site do InnerSource Gig Marketplace para promover seu programa InnerSource.
+* A SAP implementou o padrão Gig Marketplace - um novo programa InnerSource foi adicionado à plataforma interna de empregos, onde posições e ofertas semelhantes podem ser publicadas.
+* Foi comprovado que o padrão Gig Marketplace funciona extremamente bem com o padrão associado [InnerSource Portal] (./innersource-portal.md) nesse contexto. O InnerSource Portal aumenta a conscientização sobre projetos específicos que estão em andamento, enquanto o Gig Marketplace anuncia tarefas de um determinado tipo disponíveis para serem trabalhadas nesses projetos.
+
+## Estado
+
+* Structured
+
+## Autores
+
+* Stephen McCall
+* Shreyans Dugar
+
+## Histórico de Tradução
+
+- **2022-04-29** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-04-29** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/innersource-license.md b/translation/pt-br/patterns/innersource-license.md
new file mode 100644
index 000000000..bf1dd0813
--- /dev/null
+++ b/translation/pt-br/patterns/innersource-license.md
@@ -0,0 +1,96 @@
+## Title
+
+Licença InnerSource
+
+## Patlet
+
+Duas entidades jurídicas que pertencem à mesma organização desejam compartilhar código-fonte de software entre si, mas estão preocupadas com as implicações em termos de responsabilidades legais ou contabilidade entre empresas.
+
+Uma **Licença InnerSource** fornece uma estrutura legal reutilizável para o compartilhamento de código-fonte dentro da organização. Isso abre novas opções de colaboração e torna explícitos os direitos e obrigações das entidades jurídicas envolvidas.
+
+## Problema
+
+Quando duas ou mais entidades jurídicas dentro de uma organização desejam compartilhar código entre si, elas precisam de um acordo sobre os termos e, muitas vezes, um contrato legal. Criar tais acordos por projeto requer esforço e cria uma barreira para o compartilhamento. Por exemplo, uma equipe dentro de uma entidade jurídica pode decidir não compartilhar seu código-fonte com outra entidade jurídica na organização porque parece complicado.
+
+Barreiras para o compartilhamento podem levar a silos e à duplicação de esforços na reconstrução de soluções semelhantes em várias partes da organização.
+
+No momento do compartilhamento do código-fonte, não é possível prever de forma confiável qual será o valor do compartilhamento. Se a atividade de compartilhamento requer um esforço significativo (ou seja, negociar os termos de uso), as entidades jurídicas têm menos probabilidade de fazê-lo, pois estão preocupadas com o retorno sobre o investimento.
+
+## Contexto
+
+- Uma grande organização com muitas entidades jurídicas (subsidiárias) que desejam compartilhar código. À medida que a organização cresce, o valor desse padrão aumenta.
+- Conforme definição, as entidades jurídicas possuem seus próprios direitos e obrigações legais.
+- Várias dessas entidades jurídicas estão desenvolvendo software e usando serviços de outras entidades jurídicas. Elas têm motivação para contribuir com o código-fonte umas das outras.
+- Uma complexidade suficiente da organização e de sua estrutura organizacional.
+
+## Forças
+
+- **Nível de esforço** necessário para escrever acordos formais, especialmente se eles precisam levar em conta perspectivas técnicas, legais e de negócios.
+- Uma grande organização (composta por muitas entidades jurídicas) possui muitas **regulações internas**. Quaisquer novos acordos que sejam feitos devem estar em conformidade com essas regulamentações, como segurança, privacidade, processos de aquisição, etc. O volume de regulamentações pode dificultar a avaliação de se o compartilhamento de software entre duas entidades jurídicas está em conformidade com essas regulamentações, especialmente quando não há um procedimento padrão.
+- Se alguma das entidades jurídicas na organização possui um **modelo de negócios** que depende de código proprietário e contabilidade de taxas de licenciamento dentro da organização.
+- **Cultura empresarial** que não está acostumada à colaboração InnerSource e ao compartilhamento de código. Isso resulta em incerteza sobre os direitos e obrigações ao usar código compartilhado.
+- A liberdade de uso do software leva à competição e à disseminação da propriedade.
+- Existem contratos legais em vigor que cobrem o compartilhamento de código-fonte. Esses contratos não são padronizados, o que cria esforço adicional na negociação e compreensão para cada projeto. Os contratos existentes também podem não permitir o compartilhamento de código-fonte de uma maneira aberta o suficiente para suportar uma abordagem verdadeiramente InnerSource.
+- Alternativamente, não existem contratos legais em vigor, mas o código-fonte é compartilhado informalmente. Isso pode criar incerteza em casos em que é necessária clareza sobre a propriedade e os direitos e obrigações.
+
+## Solução
+
+Criar uma **Licença InnerSource** personalizada de acordo com as necessidades da organização em questão (e suas entidades jurídicas). Esta licença precisa ser genérica o suficiente para ser aplicada às relações interempresariais mais importantes.
+
+É importante escrever a Licença InnerSource de forma que permita verdadeiras colaborações semelhantes ao OpenSource entre as fronteiras das entidades jurídicas envolvidas. Portanto, as 4 liberdades do software livre devem ser integradas à licença.
+
+A Licença é escrita como um documento legal formal e pode ser usada como parte de contratos entre as entidades jurídicas para governar acordos de compartilhamento de código.
+
+## Contexto Resultante
+
+Com a Licença InnerSource, temos uma ferramenta para compartilhar código entre entidades jurídicas dentro da nossa organização.
+
+A licença simplifica as conversas dentro da nossa organização sobre compartilhamento de código-fonte e está motivando as primeiras entidades jurídicas a fazê-lo.
+
+**Nota**: O experimento descrito em **Instâncias Conhecidas** ainda está em uma fase inicial. Portanto, um **contexto resultante** sólido ainda não foi formado. Em alguns meses, os efeitos da Licença InnerSource nesse espaço de problemas estarão mais claros e esta seção poderá ser atualizada.
+
+## Instâncias Conhecidas
+
+A DB Systel criou sua própria Licença InnerSource, consulte [DB Inner Source License][db-inner-source-license]. Eles usaram a [EUPL][eupl], já que ela oferecia um ponto de partida semelhante ao do código aberto, e depois trabalharam nas restrições e regras adicionais necessárias em seu contexto organizacional específico.
+
+As primeiras entidades legais (empresas) dentro da DB AG estão usando sua Licença InnerSource.
+
+Uma consequência positiva que já está aparecendo é que simplifica a conversa, especialmente se algumas das partes envolvidas ainda não conhecem bem o conceito de InnerSource. Licenças são um conceito bem conhecido, portanto ter uma licença InnerSource é um ótimo ponto de partida para discussão.
+
+Os experimentos também estão revelando que existem outros desafios de colaboração que precisam ser resolvidos para levar a um verdadeiro modelo de contribuição e colaboração InnerSource.
+
+Os desafios de colaboração mencionados incluem:
+
+- tornar os projetos licenciados como InnerSource descobríveis.
+- construir comunidades para colaboração em projetos, assim como em Open Source.
+
+Vale mencionar que até agora, o software compartilhado sob essa licença InnerSource é principalmente ferramentas, infraestrutura e ferramentas mais baixas na pilha de tecnologia.
+
+## Estado
+
+* Structured
+* O experimento listado em **Exemplos Conhecidos** está em execução desde 02/2020. A experiência inicial mostra os primeiros efeitos positivos, mas mais experiência é necessária para avaliar totalmente o padrão.
+
+## Autores
+
+- Cornelius Schumacher (DB Systel GmbH)
+- Schlomo Schapiro (DB Systel GmbH)
+- Sebastian Spier
+
+## Referências
+
+- FOSSBack 2020 Presentation: [Cornelius Schumacher - Blending Open Source and Corporate Values](https://youtu.be/hikC6U8X_Ec) - watch 27:30 and onwards for details about the InnerSource License
+- [DB Inner Source License][db-inner-source-license]
+
+## Glossário
+
+- organização - um guarda-chuva para várias entidades legais. (sinônimos: grupo, empresa) (e.g., Lufthansa)
+-entidade jurídica - Uma entidade que possui seus próprios direitos e obrigações legais (sinônimos: empresa, subsidiária) (por exemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...)
+
+[db-inner-source-license]: https://github.com/dbsystel/open-source-policies/blob/master/DB-Inner-Source-License.md
+[eupl]: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12
+
+## Histórico de Tradução
+
+- **2022-05-04** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-05-04** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/innersource-portal.md b/translation/pt-br/patterns/innersource-portal.md
new file mode 100644
index 000000000..1bd7953d5
--- /dev/null
+++ b/translation/pt-br/patterns/innersource-portal.md
@@ -0,0 +1,104 @@
+## Title
+
+Portal InnerSource
+
+## Patlet
+
+Potenciais contribuidores não conseguem descobrir facilmente os projetos de InnerSource que lhes interessam. Ao criar um site de intranet que indexa todas as informações disponíveis sobre projetos de InnerSource, você permite que os contribuidores aprendam sobre projetos que possam interessá-los e que os proprietários de projetos de InnerSource atraiam um público externo.
+
+## Problema
+
+Os times de projetos de InnerSource estão achando difícil atrair contribuições externas.
+
+Os projetos de InnerSource em sua organização estão aumentando, mas os potenciais contribuidores não têm uma maneira fácil de descobri-los.
+
+## História
+
+Você está tentando estabelecer uma prática de InnerSource dentro de sua organização. Você está ciente de que alguns projetos estão sendo executados usando um modelo InnerSource, mas sua existência é comunicada apenas por boca a boca, e-mail ou conversas laterais com outros funcionários. Como resultado, os proprietários de projetos de InnerSource estão achando difícil atrair contribuidores.
+
+Não há um recurso único e compartilhado para os funcionários em toda a organização acessarem, que permita descobrir facilmente todos os projetos de InnerSource em andamento. Isso está limitando severamente o potencial de crescimento de cada projeto de InnerSource.
+
+O que pode ser feito para ajudar todos os projetos de InnerSource a aumentar sua visibilidade para o maior público possível e atrair contribuidores em toda a organização?
+
+## Contexto
+
+* Sua organização está interessada em adotar um estilo de trabalho InnerSource.
+* Os proprietários de projetos de InnerSource estão procurando uma maneira de atrair audiências para seus projetos. No entanto, eles estão limitados pelos canais de comunicação disponíveis para eles, através dos quais poderiam anunciar para potenciais contribuidores.
+* Os projetos de InnerSource em sua organização estão aumentando.
+* Agravando esse problema está o fato de que o aplicativo compartilhado de gerenciamento de controle de _código fonte_ em uso tem capacidades de pesquisa tão limitadas que até mesmo os desenvolvedores em busca de projetos de InnerSource acham frustrante localizá-los.
+
+### Pré-requisitos
+
+* Os gerentes deram aceitação tácita de que seus funcionários devem participar de projetos de InnerSource.
+* Um sistema compartilhado de gerenciamento de controle de _código fonte_ está em uso, que fornece acesso programático ao conteúdo dos repositórios que hospeda.
+* Há um departamento dentro de sua organização com a responsabilidade de promover a colaboração em InnerSource.
+
+## Forças
+
+* O potencial completo das equipes de engenharia separadas de colaborar em desafios compartilhados não está sendo realizado.
+* É difícil para indivíduos descobrir quais projetos InnerSource existem.
+* É difícil para proprietários de projetos InnerSource atrair uma audiência de contribuidores externos.
+
+## Soluções
+
+Crie um site de intranet de Portal InnerSource onde os proprietários de projetos InnerSource possam anunciar facilmente a disponibilidade de seus projetos.
+
+As propriedades chave do portal são:
+
+* Os visitantes do Portal InnerSource devem ser capazes de ver todos os projetos disponíveis, bem como buscar projetos específicos com base em vários critérios, como nome do projeto, tecnologias em uso, nomes de contribuintes, unidade de negócios patrocinadora, etc.
+* As informações exibidas por meio do Portal InnerSource devem estar sob o controle total dos proprietários do projeto InnerSource em todos os momentos. Preferencialmente, obtendo essas informações diretamente de um arquivo de dados específico ou metadados armazenados no próprio repositório do projeto.
+* Os proprietários do projeto devem incluir todas as informações relevantes sobre seus projetos nesses arquivos de dados, incluindo o nome do projeto, nomes dos contribuintes confiáveis, uma breve descrição e links para o repositório de código ou qualquer documentação de suporte.
+(opcional) Embora a maioria das organizações opte por tornar seu portal disponível apenas na intranet, algumas organizações escolheram disponibilizar seu portal na internet pública. Esta * última opção pode ser interessante para organizações que desejam mostrar informações adicionais sobre sua abordagem InnerSource em seu portal, por exemplo, para fins de marca e recrutamento.
+
+Ao lançar o portal, deve-se considerar uma campanha de comunicação promovendo a adição de arquivos de dados ou metadados do InnerSource aos repositórios de código, a fim de aumentar o número de projetos exibidos no portal.
+
+Uma [implementação de referência](https://github.com/SAP/project-portal-for-innersource) de um portal InnerSource está disponível no GitHub e aberta para contribuições. Ele lista todos os projetos InnerSource de uma organização de maneira interativa e fácil de usar. Os projetos podem se registrar automaticamente usando um tópico dedicado no GitHub e fornecer metadados adicionais.
+
+
+
+## Contexto Resultante
+
+* O Portal InnerSource permitiu que os proprietários de projetos InnerSource divulgassem seus projetos para um público em toda a organização. Devido a essa maior visibilidade, eles estão atraindo comunidades de contribuidores muito maiores do que nunca.
+* Para aqueles que desejam se envolver em projetos InnerSource, o Portal InnerSource permitiu que eles descobrissem exatamente o tipo de oportunidades em que estão interessados, pesquisando simultaneamente todos os projetos InnerSource disponíveis com base em critérios específicos.
+* Atender às necessidades desses dois públicos ajudou a estabelecer o InnerSource como uma opção viável e atraente para todas as áreas da organização aproveitarem para realizar coisas juntas que não poderiam ter feito separadamente.
+
+## Instâncias Conhecidas
+
+* **Uma grande organização de serviços financeiros** utilizou a criação de um Portal InnerSource para fornecer um mecanismo de publicidade e descoberta de projetos InnerSource existentes em diferentes unidades de negócios.
+* **SAP** promove projetos InnerSource no Portal InnerSource - os projetos podem se registrar automaticamente usando tópicos do GitHub. O [Repository Activity Score](repository-activity-score.md) define a ordem padrão dos projetos InnerSource no portal. Veja também [Michael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns](https://www.youtube.com/watch?v=6r9QOw9dcQo&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy&index=6). Seu código-fonte é publicado como uma [implementação de referência](https://github.com/SAP/project-portal-for-innersource) e está aberto para contribuições.
+* **Elbit Systems** utilizou esse padrão e adicionou gamificação por cima.
+ * [Gamification As Means of Cultural Change and InnerSource Engagement Booster](https://www.oreilly.com/library/view/oscon-2018-/9781492026075/video321579.html) | Shelly Nizri | OSCON 2018 - Portland, Oregon
+ * Of Islands, Monsters & InnerSource [(slides)](https://docs.google.com/presentation/d/1P1OCEK9B6eSrVRUclVWY6meSI-qHOBjM_UAPNvCZamU/edit#slide=id.p15), [(video)](https://drive.google.com/file/d/1pM89uHMn0vhE3ayFJDGYcCO8R0tAXXZD/view?usp=drivesdk) | InnerSource Spring Summit 2019 (Galway, Ireland)
+ * O código que implementa essa plataforma foi disponibilizado como código aberto e está disponível em [gitlab.com/gilda2](https://gitlab.com/gilda2)
+* **American Airlines** promove projetos InnerSource por meio de um [Mercado Interno InnerSource](https://tech.aa.com/2020-10-30-innersource/). Da mesma forma que a SAP, os projetos se registram adicionando `innersource` como um tópico no GitHub. Os projetos podem ser pesquisados e filtrados por linguagem, tópicos, número de problemas abertos, etc.
+* **Banco Santander** criou um portal público chamado "Santander ONE Europe InnerSource Community" para apoiar e aumentar a adoção do InnerSource. Além do catálogo de projetos, o portal inclui conteúdo relevante, como documentação, forma de trabalho, notícias e eventos.
+
+
+
+* **Airbus** implantou o [portal SAP](https://github.com/SAP/project-portal-for-innersource) com modificações mínimas para se adequar à identidade visual da Airbus. Além disso, o [rastreador Python](https://github.com/zkoppert/innersource-crawler) foi corrigido para funcionar com instâncias do GitHub Enterprise.
+
+* **Mercado Libre** utiliza uma instância do [portal SAP](https://github.com/SAP/project-portal-for-innersource) para descobrir projetos InnerSource existentes dentro da organização.
+
+## Referências
+
+* O padrão de Portal InnerSource tem se mostrado extremamente eficiente quando combinado com o padrão de [Mercado de Trabalhos InnerSource](./gig-marketplace.md) associado, nesse contexto.
+
+## Estado
+
+* Structured
+
+## Autores
+
+* Stephen McCall
+
+## Reconhecimento
+
+* Shelly Nizri
+* Melinda Malmgren
+* Michael Graf
+* Jesús Alonso Gutierrez
+
+## Histórico de Tradução
+
+- **2022-06-13** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-06-13** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/issue-tracker.md b/translation/pt-br/patterns/issue-tracker.md
new file mode 100644
index 000000000..10995dee0
--- /dev/null
+++ b/translation/pt-br/patterns/issue-tracker.md
@@ -0,0 +1,57 @@
+## Title
+
+Casos de uso do Issue Tracker
+
+## Patlet
+
+A equipe responsável pelo InnerSource falha em tornar não apenas os planos e o progresso transparentes, mas também o contexto das mudanças. Isso é resolvido aumentando os casos de uso do Issue Tracker do projeto para também servir como espaço para brainstorming, discussões de implementação e design de recursos.
+
+## Problema
+
+Uma equipe desenvolve um componente no qual muitas equipes na organização dependem. Eles utilizam um Issue Tracker padrão para acompanhar bugs abertos e solicitações de recursos. No entanto, o contexto em cada entrada é muito limitado. Como resultado, possíveis colaboradores não têm como saber exatamente sobre qual alteração cada problema está tratando.
+
+## Contexto
+
+A infraestrutura de ferramentas do projeto InnerSource está toda configurada. No entanto, o Issue Tracker do projeto é principalmente usado para compartilhar o progresso. Nos projetos InnerSource, existem muitos outros casos de uso em que um Issue Tracker pode ser usado para facilitar a comunicação remota e assíncrona.
+
+## Forças
+
+- Os colaboradores gostariam de saber se a funcionalidade que estão procurando já está no roadmap. No entanto, devido à falta de contexto nas issues, é impossível determinar se as issues existentes atendem às necessidades da equipe de contribuição.
+- Como resultado, muitas issues duplicadas estão sendo abertas, o que a equipe responsável precisa lidar.
+- Como o contexto nas issues abertas é tão limitado, os colaboradores não conseguem ajudar a equipe responsável implementando issues mais simples que já estão abertas. Como resultado, grande parte do trabalho continua nas mãos da equipe responsável.
+- Com um foco forte na comunicação verbal, é impossível discernir após alguns meses ou anos por que uma determinada funcionalidade foi escolhida para implementação. Como resultado, refatorações, em particular a simplificação do componente, se tornam um exercício de arqueologia de projetos e de solicitar informações de pessoas que se lembram do que foi discutido.
+
+## Solução
+
+Abraçar a filosofia de "escrito em vez de verbal" não apenas para o desenvolvimento de software puro, mas também durante a fase de planejamento de novas funcionalidades:
+
+- Para bugs, funcionalidades planejadas e ideias de funcionalidades, crie issues separadas. Em cada uma delas, inclua o máximo de informações possível para que potenciais colaboradores externos possam entender o contexto. Idealmente, especialmente para alterações mais simples, inclua informações suficientes para que colaboradores externos possam apoiar a equipe responsável implementando a funcionalidade em questão.
+- Potencialmente, use o rastreador de problemas como um canal para fazer perguntas. Isso é especialmente útil se você não tiver outras fontes de comunicação para lidar com perguntas dos usuários.
+- Faça uso de tags e categorias para distinguir issues usadas para diferentes propósitos.
+- Para iniciar uma sessão de brainstorming de forma assíncrona, abra uma issue para coletar ideias. Quando a discussão começar a diminuir, resuma os pontos identificados nesta issue em um documento separado. Envie-o para revisão como uma solicitação de pull para aprofundar os pontos individuais que ainda precisam de esclarecimentos. O documento resultante pode ser usado para publicar os resultados em outros canais apropriados, bem como para referência futura.
+- A maioria das implementações de rastreadores de problemas permite o uso de modelos de issues. Faça uso deles não apenas para coletar informações comumente necessárias para relatórios de bugs, mas também inclua dicas sobre que tipo de informações são necessárias para os outros tipos de uso.
+
+## Contexto Resultante
+
+- Fazer um uso mais intenso do Issue Tracker do projeto para comunicação permite que colaboradores externos acompanhem e tomem melhores decisões sobre o que contribuir.
+- Um foco na comunicação escrita estruturada permite que membros da equipe responsável participem remotamente.
+- Comunicar consistentemente por escrito significa que a documentação passiva das decisões do projeto acumula-se como um subproduto, em vez de exigir atenção adicional.
+- O uso consistente de canais de comunicação públicos atrai mais pessoas para acompanhar uma discussão. Isso significa que há mais pessoas qualificadas que podem responder perguntas, contribuir para issues abertas ou apontar falhas em funcionalidades planejadas que, de outra forma, seriam descobertas apenas muito tempo depois.
+- Mover discussões para uma plataforma de discussão pública cria uma oportunidade para potenciais colaboradores futuros observarem, acompanharem, se familiarizarem e aprenderem sobre os caminhos do projeto muito antes de precisarem se envolver pela primeira vez.
+
+## Instâncias Conhecidas
+
+* Europace AG - See blog post [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
+
+## Autores
+
+Isabel Drost-Fromm
+
+## Estado
+
+Structured
+
+## Histórico de Tradução
+
+- **2022-06-13** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-06-13** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/maturity-model.md b/translation/pt-br/patterns/maturity-model.md
new file mode 100644
index 000000000..e0e43852a
--- /dev/null
+++ b/translation/pt-br/patterns/maturity-model.md
@@ -0,0 +1,220 @@
+## Title
+
+Modelo de Maturidade
+
+## Patlet
+
+As equipes começaram a adotar o InnerSource. A prática está se espalhando para vários departamentos. No entanto, a compreensão do que constitui um projeto InnerSource varia. A solução é fornecer um modelo de maturidade para permitir que as equipes realizem uma autoavaliação e descubram padrões e práticas das quais ainda não têm conhecimento.
+
+## Problema
+
+Quando a adoção do InnerSource em uma empresa começa a aumentar, o acompanhamento individual de cada projeto por meio de um evangelista se torna inviável. Além disso, cada vez mais pessoas estão adquirindo pelo menos uma compreensão básica do que significa trabalhar em um projeto InnerSource. No entanto, ao observar todos os projetos InnerSource, a profundidade de compreensão do conceito divergirá. As equipes podem não estar cientes de padrões comprovados que as ajudariam a avançar para o próximo nível e a resolver problemas e pontos de dor com os quais estão lidando.
+
+## Contexto
+
+Diversas equipes começaram a adotar práticas de InnerSource. O nível exato de compreensão da prática varia entre as equipes. Os problemas específicos com os quais as equipes se deparam divergem dependendo do contexto e ambiente de trabalho de cada equipe. Como resultado, a definição do que são práticas recomendadas importantes em um projeto InnerSource difere conforme cada equipe.
+
+## Forças
+
+As equipes que compartilham aprendizados sobre InnerSource enfrentam mal-entendidos, pois não têm consciência do nível respectivo de adoção do InnerSource.
+
+As equipes acreditam que "tudo se resume a migrar para um ambiente de desenvolvimento de software compartilhado [forge](https://en.wikipedia.org/wiki/Forge_%28software%29)" (GitLab, GitHub ou Bitbucket são exemplos bem conhecidos dessas forjas).
+
+As equipes não têm conhecimento das melhores práticas que as ajudariam a resolver problemas com os quais se deparam em suas atividades diárias.
+
+## Solução
+
+Solicite às equipes que façam uma autoavaliação com base no modelo de maturidade proposto.
+
+### Transparência
+
+**Planos e Produtos**
+
+Os projetos InnerSource se beneficiam do planejamento transparente em toda a organização, permitindo que as partes interessadas compreendam melhor as decisões e as influenciem de maneira que possa ser seguida por outros.
+
+* PP-0: Indivíduos e equipes não divulgam regularmente seus planos ou produtos para múltiplas partes interessadas. Não existem ações formais na organização.
+* PP-1: Indivíduos e equipes dão visibilidade aos seus planos ou produtos para múltiplas partes interessadas antes de iniciá-los. Roadmap compartilhado.
+* PP-2: Já existem roadmaps compartilhados com diretrizes claras e regras de contribuição onde as partes interessadas podem fornecer feedback. No entanto, isso não é padronizado em toda a organização e nem todos os projetos fornecem essas informações.
+* PP-3: Os roadmaps são compartilhados por padrão e há um processo padrão e maneira homogênea de fazer isso em toda a organização no nível de cada projeto InnerSource. Isso contém regras claras para contribuir e influenciar no roadmap.
+
+**Processo e Ferramentas de Desenvolvimento**
+
+Os projetos InnerSource prosperam quando os contribuidores se tornam ativos e participam. Como resultado, tornar a contribuição mais fácil deve ser equilibrado com objetivos técnicos puros.
+
+* DP-0: Cada equipe segue seu próprio processo de desenvolvimento e ferramentas. Eles não são definidos para compartilhar conhecimento e artefatos fora da equipe de desenvolvimento. Equipes de desenvolvimento isoladas.
+* DP-1: As equipes de desenvolvimento usam repositórios de código compartilhados internamente. Algumas equipes desenvolvem seu próprio processo de Integração Contínua (CI), usando ferramentas de CI não corporativas ou padrão. Não há um processo de revisão de código definido, embora algumas equipes de projetos o façam internamente.
+* DP-2: A organização patrocina e promove um repositório compartilhado para o conhecimento coletivo. Algumas equipes desenvolvem seu próprio processo de CI, usando ferramentas de CI corporativas. Existem ambientes de CI. Processo de revisão de código definido e usado por alguns projetos. Às vezes, a revisão de código é feita por membros externos da equipe.
+* DP-3: A maioria das equipes desenvolve seu próprio processo de CI, usando ferramentas de CI corporativas. Existem ambientes de CI. Processo de revisão de código definido e usado. A revisão de código é feita por membros tanto internos quanto externos à equipe.
+
+**Decisões**
+
+Com o intuito de motivar os colegas a contribuir para trabalhos fora de suas equipes principais, eles precisam ter visibilidade no processo de tomada de decisão do projeto anfitrião - mas também sentir que suas vozes estão sendo ouvidas e valorizadas.
+
+* DC-0: Os tomadores de decisão frequentemente retêm intencionalmente ou por acidente dados e recursos relacionados às decisões do projeto.
+* DC-1: Materiais que fazem parte das práticas de tomada de decisão se tornam disponíveis para revisão após as decisões serem finalizadas.
+* DC-2: As pessoas sentem que sabem sobre - e estão contribuindo para moldar - a maioria (mas não todas) das decisões importantes à medida que essas decisões estão sendo tomadas. Materiais que fazem parte das práticas de tomada de decisão estão disponíveis em marcos definidos do projeto.
+* DC-3: As pessoas sentem que fazem parte de um processo compartilhado e padronizado para tomada de decisões coletivas, endossado pela organização. Materiais que fazem parte das práticas de tomada de decisão são continuamente acessíveis durante os processos de trabalho.
+
+**Recursos Úteis**
+
+Para atrair contribuidores, materiais de suporte úteis precisam estar facilmente acessíveis.
+
+* RS-0: Indivíduos e equipes nem contribuem para, nem acessam um repositório compartilhado de conhecimento.
+* RS-1: Indivíduos e equipes disponibilizam materiais do projeto para revisão interna após terem concluído o trabalho. Indivíduos e equipes compartilham recursos, mas em sistemas ou repositórios desconexos, fragmentados ou individualizados/isolados. Indivíduos e equipes compartilham recursos, mas não há uma compreensão comum ou compartilhada dos critérios usados para determinar se as informações são sensíveis ou não. Não "compartilham pensamentos com outros".
+* RS-2: Indivíduos e equipes tornam os materiais relacionados ao projeto acessíveis a alguns membros das equipes de projeto de acordo com formatos e/ou protocolos claramente definidos e compartilhados. Indivíduos e equipes retêm dados e recursos sensíveis, fornecendo detalhes, contexto e escopo limitados.
+* RS-3: Indivíduos e equipes tornam os materiais relacionados ao projeto amplamente acessíveis à organização - e possivelmente também fora da organização - de acordo com formatos e/ou protocolos claramente definidos e compartilhados. Indivíduos e equipes que devem reter dados e recursos sensíveis têm clareza sobre o que não estão compartilhando, e outros entendem por que esses materiais não estão disponíveis para eles.
+
+**Histórias**
+
+Quando se trabalha em equipes anfitriãs, os erros serão automaticamente amplamente visíveis. Para manter os níveis de contribuição elevados, a cultura corporativa precisa celebrar o fracasso como uma oportunidade de crescimento e aprendizado.
+
+* ST-0: Indivíduos e equipes não compartilham sucessos nem falhas para que outros possam aprender.
+* ST-1: Indivíduos e equipes se sentem à vontade para compartilhar histórias sobre sucessos, mas não sobre falhas.
+* ST-2: Indivíduos e equipes se sentem à vontade para compartilhar histórias de sucessos e falhas durante retrospectivas e revisões.
+* ST-3: Indivíduos e equipes se sentem à vontade para compartilhar histórias de sucessos e falhas, e aprendem com as falhas de acordo com protocolos formais.
+
+### Colaboração
+
+**Canais para Prover Feedback**
+
+Para reduzir silos, os colegas precisam se sentir à vontade para compartilhar feedback abertamente. Uma maneira fácil de apoiar isso é usar os mesmos princípios de comunicação em todas as hierarquias.
+
+Idealmente, você acabará com canais de comunicação adequados que sejam conhecidos por todos na organização - com canais focados em diferentes objetivos (anúncios, suporte ao usuário, canais de desenvolvimento, discussões de infraestrutura, etc.). Algumas das melhores práticas que você estabelecerá à medida que seus projetos InnerSource amadurecem: Adoção de diretrizes de netiqueta, abertura de um conjunto comprovado de canais padrão (que estão sendo arquivados, acessíveis publicamente, pesquisáveis) para cada novo projeto InnerSource.
+
+* CF-0: Não existem processos nem canais estabelecidos. Alguns membros da organização compartilham materiais por meio de canais ou discussões privadas.
+* CF-1: A organização está no processo de estabelecer diretrizes internas e canais para incentivar pontos de vista diversos sobre decisões da empresa/departamentais, para que qualquer pessoa pertencente à organização possa usá-los. Alguns membros da organização compartilham materiais de tomada de decisão informalmente usando plataformas não oficiais. Líderes mantêm pelo menos um canal claro e direto para que os membros da organização compartilhem opiniões construtivas sobre alguns assuntos relevantes para o trabalho.
+* CF-2: A organização estabeleceu diretrizes e canais internos, e fornece recursos específicos (programas de treinamento, acesso a conteúdo, etc.) para incentivar e solicitar pontos de vista diversos sobre decisões de equipe ou decisões em geral.
+* CF-3: Membros da organização compartilham materiais de tomada de decisão em plataformas oficialmente sancionadas. Membros da organização compartilham materiais abertamente por meio de múltiplos canais e métodos para feedback. Líderes usam esses canais, encorajam abertamente outros a usá-los e mantêm registros voltados para a equipe ou públicos do feedback que receberam e/ou das ações que tomaram para abordar esse feedback.
+
+**Liderança**
+
+Projetos InnerSource incentivam os funcionários a contribuírem para projetos fora da influência direta de seu gerente direto. Isso requer uma cultura de confiança.
+
+* LS-0: Cultura de comando e controle, dentro de uma organização altamente hierárquica.
+* LS-1: Alguns líderes estão abertos a receber feedback e a criar um ambiente onde as pessoas se sintam seguras para fornecê-lo.
+* LS-2: A maioria dos líderes na organização está aberta a receber feedback e a criar um ambiente onde as pessoas se sintam seguras para fornecê-lo. Os líderes demonstram passividade em entender se todos os membros se sentem capacitados e habilitados a compartilhar. A organização incentiva os líderes a buscarem ativamente vozes não presentes no diálogo para inclusão.
+* LS-3: Os membros se sentem capacitados e habilitados a compartilhar opiniões construtivas sobre qualquer assunto relevante para o trabalho ou sobre o qual sintam paixão.
+
+**Estrutura Organizacional e Funcional**
+
+Quando o InnerSource sai do nível de codificação pura e entra no nível de comunidade e grupo de trabalho, existe o potencial para reduzir silos, mesmo onde a colaboração direta de código não é possível.
+
+* OF-0: Grupos de trabalho tendem a ser estáticos em termos de membros e conjuntos de habilidades.
+* OF-1: Existem equipes multifuncionais, mas os papéis da equipe muitas vezes são obscuros e as estruturas de governança são vagas.
+* OF-2: Equipes multifuncionais são comuns e as equipes publicam seus papéis e objetivos abertamente.
+* OF-3: Equipes multifuncionais são comuns e tornam suas atividades amplamente conhecidas pela organização; por sua vez, a organização promove as melhores práticas para trabalhar juntos.
+
+**Contribuição**
+
+O objetivo ao projetar padrões de contribuição precisa manter a colaboração em mente, se a intenção é reduzir silos.
+
+* CB-0: Totalmente isolado, sem colaboração fora das equipes. Alguma colaboração ocorre devido a equipes multifuncionais.
+* CB-1: Membros da organização e equipes colaboram, mas frequentemente afirmam que é "muito difícil". Equipes revisitam raramente os resultados de suas colaborações.
+* CB-2: Membros da organização e equipes buscam ativamente oportunidades para colaborar. Equipes discutem, revisitam e debatem rotineiramente os resultados de seus esforços colaborativos e tornam esses resultados disponíveis por padrão.
+* CB-3: Membros da organização colaboram interna e externamente de maneiras que beneficiam a todos os envolvidos. Equipes discutem, revisitam e debatem rotineiramente os resultados de seus esforços colaborativos, compartilham suas aprendizagens fora da organização e disponibilizam esses resultados externamente por padrão.
+
+### Comunidade
+
+**Políticas de Compartilhamento**
+
+Ter uma base de valores compartilhados facilita o trabalho entre as fronteiras das equipes. Cruzar essas fronteiras se torna mais fácil se um conjunto limitado de regras e diretrizes básicas se aplicar em todos os lugares e puder ser facilmente referenciado.
+
+* SP-0: Nenhuma cultura de compartilhamento nem políticas escritas.
+* SP-1: Alguns membros da organização se unem para definir valores e princípios, mas não recebem suporte claro ao fazerem isso.
+* SP-2: Membros da organização documentam coletivamente visões e acordos compartilhados, como declarações de missão e códigos de conduta, tornam-nos facilmente acessíveis e os referenciam frequentemente. Materiais de integração e rituais de orientação fornecem contexto adequado para ajudar novos membros a entender como a organização se beneficiará de suas contribuições.
+* SP-3: Valores e princípios compartilhados orientam processos de tomada de decisão, resolução de conflitos e avaliação entre os membros da organização, que referenciam consistentemente esses valores e princípios em formatos verbais e escritos.
+
+**Sentir-se parte da organização**
+
+Uma das possíveis razões para introduzir o InnerSource nas organizações pode ser o aumento do engajamento. Este ponto acompanha como o engajamento está mudando ao adotar o InnerSource.
+
+* PA-0: Baixo engajamento, sem colaboração, e as pessoas não se sentem à vontade para compartilhar com os outros.
+* PA-1: Membros da organização se sentem à vontade para compartilhar seus pensamentos e opiniões sem medo de retaliação, mas apenas em domínios familiares. As pessoas entendem que as melhores ideias vencem, e as responsabilidades de liderança se acumulam para as pessoas com histórico de contribuição e comprometimento.
+* PA-2: Membros da organização se sentem à vontade para compartilhar seus pensamentos e opiniões sem medo de retaliação. Líderes demonstram dedicação aos valores compartilhados da organização.
+* PA-3: A organização é proativa em dizer aos membros que se beneficia de suas contribuições; como tal, os membros demonstram consciência compartilhada e execução empoderada, e sentem um senso de responsabilidade para com a comunidade. Líderes entendem que crescem ao ajudar os outros a crescer, e eles mentoram membros juniores da organização.
+
+### Governança
+
+**Prémios**
+
+Para impulsionar a adoção, motivadores extrínsecos podem ser usados para aumentar a colaboração entre equipes.
+
+* RW-0: Sem recompensas.
+* RW-1: Líderes são incentivados a recompensar colaborações excepcionais, mas não há políticas ou processos estabelecidos.
+* RW-2: Processos padrão são estabelecidos para recompensar colaborações fora das equipes de desenvolvimento. Líderes de equipe ou conselhos decidem quem deve ser recompensado.
+* RW-3: Recompensas não são apenas propostas pela organização, mas as comunidades podem definir suas recompensas mais valiosas. A comunidade é responsável por decidir quem deve ser recompensado.
+
+**Políticas de Monitoramento**
+
+Projetos InnerSource precisam de um meio para autoavaliação. Métricas podem ser um aspecto para facilitar essa avaliação. Além disso, em organizações com um nível de adoção maduro do InnerSource, esperamos que a adoção do método seja rastreada com base em métricas claras e acordadas.
+
+* MP-0: Não existem políticas de monitoramento existentes em nenhum nível da organização.
+* MP-1: Métricas são importantes para certas equipes, e elas começam a usá-las de maneira isolada.
+* MP-2: Existe uma estratégia em nível organizacional em relação às métricas que ajudam a validar políticas específicas em toda a organização. Essa política de monitoramento existe em nível de alguns projetos InnerSource.
+* MP-3: Existem diretrizes claras, recomendações e treinamentos sobre o uso de métricas com infraestrutura específica fornecida pela organização. Isso funciona em ambos os níveis: programa InnerSource para entender a adoção geral do InnerSource dentro da organização e no nível dos projetos InnerSource.
+
+**Apoio e Manutenção**
+
+Não apenas o desenvolvimento de recursos deve ser de responsabilidade das equipes InnerSource - o suporte e a manutenção também fazem parte das tarefas principais das equipes.
+
+* SM-0: Suporte fornecido pela equipe principal de desenvolvimento ou equipe de suporte. Um contrato comercial garante o suporte. Não há conhecimento sobre o produto fora da equipe.
+* SM-1: Existem regras e regulamentos para formalizar o suporte ao produto, fornecido por uma equipe de suporte dedicada.
+* SM-2: O suporte para contribuições InnerSource é formalizado por meio de padrões InnerSource, como [Garantia de 30 Dias](./30-day-warranty.md) ou [Serviço vs. Biblioteca](./service-vs-library.md).
+* SM-3: Existem regras e regulamentos para formalizar o suporte ao produto, fornecido por uma comunidade madura.
+
+**Cultura**
+
+Existem vários níveis em direção a uma cultura colaborativa.
+
+* CL-0: Silos - equipes trabalham independentemente, mas também em isolamento.
+* CL-1: Reativo - equipes trabalham independentemente, mas sabem como reagir a falhas nas dependências.
+* CL-2: Contributivo - equipes ajudam ativamente a melhorar suas dependências contribuindo.
+* CL-3: Ativista - equipes buscam ativamente ajuda, orientam e recrutam novos contribuidores.
+
+**Papéis InnerSource**
+
+InnerSource traz consigo papéis explícitos. Enquanto nas primeiras etapas alguns padrões podem ser utilizados sem adotar esses papéis, a comunicação dentro dos projetos usando títulos de papel explícitos se torna mais fácil.
+
+* RO-0: Não existem papéis específicos que auxiliem a adoção do InnerSource. Apenas papéis de desenvolvimento comuns estão presentes: desenvolvedor, analista, testador, etc.
+* RO-1: Ocasionalmente, alguns indivíduos e equipes contribuem para outros projetos. Essas são contribuições técnicas, onde o papel de usuário/contribuidor é reconhecido. Para algumas equipes, pode ser identificado pelo menos um membro que é uma referência técnica, explicando o processo de desenvolvimento a outros membros da equipe de desenvolvimento. Essa pessoa poderia ser candidata a cobrir o papel de trusted committer.
+* RO-2: Um papel de Oficial de InnerSource é responsável pela governança e suporte, incluindo processos, etc. Identifica as necessidades de educação e garante que sejam providenciadas para a organização. Lidera e orienta a organização no envolvimento em projetos InnerSource. É o primeiro passo formal no caminho, definindo a visão e o roteiro do InnerSource. A organização definiu um papel de trusted committer, que é um ponto de contato/referência não apenas para membros da equipe de desenvolvimento, mas também para contribuidores externos. Existe um processo padrão que descreve como contribuir para a comunidade, o papel de contribuidor está presente. O papel de Cientista de Dados é responsável por gerenciar os rastros de atividade deixados pela iniciativa InnerSource, necessários para medir a evolução do InnerSource. O papel de trusted committer evoluirá para um perfil mais técnico, e um Gerente de Comunidade será responsável por "energizar" a comunidade, sendo sua principal responsabilidade atrair e reter novos desenvolvedores/usuários (contribuidores/membros da comunidade).
+* RO-3: Evangelistas estão se movimentando dentro da organização, para informar os outros sobre o trabalho atual, o que o InnerSource faz e como fazê-lo, e ajudar os outros a entenderem e se tornarem parte da iniciativa. Contribuidores não técnicos aparecem.
+
+## Contexto Resultante
+
+Todos as equipes têm conhecimento das melhores práticas disponíveis.
+
+As equipes compreendem seu nível de adoção do InnerSource.
+
+Antes de adotar o InnerSource como um modelo de trabalho, as equipes têm ciência das práticas que se espera delas - tanto a curto prazo quanto a longo prazo.
+
+## Instâncias Conhecidas
+
+* Entelgy
+* Zylk
+* Bitergia
+
+## Autores
+
+* Daniel Izquierdo Cortazar
+* Isabel Drost-Fromm
+* Jorge
+* Nerea
+
+## Reconhecimento
+
+* Alexander Andrade (um agradecimento especial pela correção ortográfica)
+
+## Alias
+
+Modelo de Maturidade: Conheça as Melhores Práticas do InnerSource
+
+## Estado
+
+* Structured
+* Drafted in September 2019
+
+## Histórico de Tradução
+
+- **2022-08-19** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-08-19** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/praise-participants.md b/translation/pt-br/patterns/praise-participants.md
new file mode 100644
index 000000000..01081a1bf
--- /dev/null
+++ b/translation/pt-br/patterns/praise-participants.md
@@ -0,0 +1,94 @@
+## Title
+
+Elogiar Participantes
+
+## Patlet
+
+Após uma contribuição de InnerSource, é importante agradecer ao contribuidor pelo seu tempo e esforço.
+Este padrão fornece orientações que não apenas reconhecem efetivamente a contribuição, mas também promovem um maior envolvimento do contribuidor e de outros.
+
+## Problema
+
+Como podemos expressar adequadamente nossa gratidão a um contribuidor por sua contribuição para um projeto InnerSource?
+Pode ser fácil esquecer de fazer isso ou não saber as palavras ou o meio a usar para um efeito adequado e sincero.
+Elogios e agradecimentos são maneiras fáceis e acessíveis de manter os contribuidores e seus gerentes motivados e entusiasmados para continuar.
+Um padrão nesta área facilita a realização desse gesto e garante que a mensagem seja transmitida de forma clara e sincera.
+
+## Contexto
+
+* Você é o [Trusted Committer](./trusted-committer.md) ou mantenedor de um projeto InnerSource.
+* Você valoriza a comunidade de contribuidores e deseja mantê-la e fazê-la crescer.
+
+## Forças
+
+* Você está ocupado, o que torna fácil esquecer de gestos suaves como elogios e agradecimentos.
+* Você pode não ser alguém que se sinta confortável em situações sociais ou tenha facilidade com as palavras.
+* O reconhecimento dos colegas é muito importante para a satisfação no trabalho e o desenvolvimento da carreira.
+
+## Solução
+
+É gratificante para qualquer pessoa ser reconhecida por outros.
+Em um ambiente profissional, um aumento no reconhecimento também é uma via para um aumento de influência e crescimento.
+Toda vez que alguém contribuir para o seu projeto InnerSource, reconheça-os com um sincero e qualificado "obrigado".
+
+Para contribuições não triviais (todas as contribuições de código e contribuições significativas de tempo), agradeça através dos seguintes mecanismos:
+
+* Parece bom para qualquer pessoa ser reconhecida por outros.
+Em um ambiente profissional, um aumento no reconhecimento também é uma via para um aumento de influência e crescimento.
+Qualquer vez que alguém contribuir para o seu projeto InnerSource, reconheça-os com um sincero e qualificado "obrigado".
+
+Para contribuições não triviais (todas as contribuições de código e contribuições significativas de tempo), agradeça através dos seguintes mecanismos:
+
+(1) Chame a pessoa pelo nome em qualquer local de chat (por exemplo, _Slack_) onde você organize a atividade do projeto. Avise a todos o que eles fizeram e agradeça publicamente.
+
+Exemplo:
+
+> Pessoal @aqui deem um high-five para @andrew.clegg por atualizar o _rcs-viewer_ para a versão mais recente do _hebo-client_ (https://github.com/rcs/rcs-viewer/pull/81).
+Obrigado por ajudar a manter esta biblioteca atualizada, Andy!
+
+(2) Envie um e-mail para eles e seu gerente (em cópia) agradecendo-os pela contribuição.
+Para contribuições de código, muitas vezes você pode apenas encaminhar o e-mail de notificação de mesclagem.
+
+Exemplo:
+
+> Olá, Andy, quero agradecer novamente por fazer esta atualização.
+Pode ter sido um pequeno período de tempo, mas é atenção como essa de cada pessoa que faz o projeto RCS funcionar para todos nós.
+Obrigado por resolver seu próprio problema de uma maneira que também melhora o _rcs-viewer_ para todos.
+
+## Contexto Resultante
+
+O feedback como esse deixa o contribuidor com um sentimento fantástico e pronto para voltar para mais.
+Combinar **ambas** as formas de agradecimento dá a eles reconhecimento diante de seus colegas (abrangência) e diante de seu gerente direto (profundidade).
+Há um incentivo sutil para que esses colegas no chat considerem contribuir também e para que o gerente busque circunstâncias apropriadas para incentivar seus outros subordinados a fazer o mesmo.
+Além disso, a conscientização sobre o projeto InnerSource se espalha para o gerente, que pode não ter conhecido previamente o uso e o envolvimento da equipe com ele.
+
+Uma ressalva - seja autêntico.
+Certifique-se de que suas palavras derivem do sincero agradecimento que você sente por dentro pelo que eles fizeram.
+Mantenha o nível e a verbosidade dos elogios adequados ao nível de envolvimento deles.
+Exagerar pode parecer insincero e mecânico, derrotando o propósito de se comunicar.
+
+## Patterns Relacionados
+
+* _Apenas Diga Obrigado_ (do livro [_Fearless Change_](https://fearlesschangepatterns.com/))
+
+## Instâncias Conhecidas
+
+* Nike (multiple projects)
+
+## Estado
+
+* Structured
+
+## Autores
+
+* Russ Rutledge
+
+## Reconhecimento
+
+* [Todd Lisonbee](https://github.com/tlisonbee) por encorajar a "manter isto real"
+* [Isabel Drost-Fromm](https://github.com/MaineC) para [esta explicação adicional](https://youtu.be/h3MPewsk5PU?t=357) de um agradecimento "qualificado".
+
+## Histórico de Tradução
+
+- **2022-08-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-08-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/repository-activity-score.md b/translation/pt-br/patterns/repository-activity-score.md
new file mode 100644
index 000000000..0e30b2c73
--- /dev/null
+++ b/translation/pt-br/patterns/repository-activity-score.md
@@ -0,0 +1,138 @@
+## Title
+
+Repositório Pontuação de Atividade
+
+## Patlet
+
+Potenciais contribuidores desejam encontrar projetos InnerSource ativos que precisem de sua ajuda. Ao calcular uma pontuação de atividade do repositório para cada projeto, uma lista classificada de projetos pode ser criada (por exemplo, no [Portal InnerSource](innersource-portal.md)), para que os potenciais contribuidores possam determinar mais facilmente em qual projeto desejam contribuir.
+
+## Problema
+
+**Em que ordem** os projetos InnerSource devem ser apresentados? Indicadores de classificação típicos, como *GitHub Stars*, *Número de Forks*, *Número de Commits*, *Linhas de Código*, *Última Atualização*, não são suficientes para indicar de forma concisa a atividade de um projeto.
+
+Projetos ativos com muita tração, mas também projetos relativamente novos e entusiasmados que precisam de novos contribuidores, devem ser classificados acima de projetos maduros com pouca atividade ou em modo de manutenção.
+
+Uma nova métrica derivada de vários indicadores de desempenho é necessária para definir uma pontuação confiável e versátil para o nível de atividade de um projeto.
+Ela pode ser usada para ordenar projetos de acordo com o nível de atividade deles.
+
+## História
+
+Quando o InnerSource é praticado por um longo período de tempo ou se expande além de um certo número de projetos (digamos 50 para ter um limite significativo), torna-se difícil encontrar os projetos InnerSource mais populares e ativos no momento. Projetos que existem por muito tempo são conhecidos, mas podem não estar tão ativos. Projetos relativamente novos, por outro lado, não têm reputação ou uma comunidade ativa ainda.
+
+Uma lista de projetos InnerSource não deve ser considerada um recurso estático, mas sim um local emocionante para descobrir e explorar projetos novos e ativos, assim como uma página de notícias que lista os tópicos mais interessantes do dia primeiro. Portanto, é benéfico quando a ordem dos projetos é atualizada regularmente e muda de acordo com a popularidade e atividade do projeto.
+
+Essas considerações levaram a um primeiro protótipo para calcular uma pontuação de atividade do repositório, que funcionou surpreendentemente bem e determina uma ordem sempre em mudança de projetos de acordo com a sua atividade.
+
+## Contexto
+
+A descoberta de projetos InnerSource pode ser facilitada com o [Portal InnerSource](innersource-portal.md) e o padrão [Gig Marketplace](gig-marketplace.md), ou promovendo projetos em outros canais de comunicação e plataformas. A pontuação de atividade define uma ordem padrão na qual os projetos são apresentados à comunidade.
+
+## Forças
+
+Indicadores-chave de desempenho automatizados que podem ser obtidos consultando a API do GitHub são apenas parte da verdade. E quanto à qualidade do código, a disponibilidade de boa documentação ou uma comunidade ativa e prestativa que torna o projeto um local divertido para contribuir?
+
+Esses KPIs "soft" teriam que ser adicionados manualmente ou de forma semi-automática ao cálculo e à pontuação resultante. Se existirem ferramentas que forneçam mais contexto para o repositório, como relatórios de cobertura de código, eles podem ser facilmente incorporados.
+
+## Esboço
+
+
+
+Abordagem centralizada para calcular e aplicar a pontuação de atividade do repositório. Para mais detalhes, veja [Contexto Resultante](#contexto-resultante).
+
+## Solução
+
+A pontuação de atividade do repositório é um valor numérico que representa a atividade (no GitHub) de um projeto InnerSource. Ela é derivada automaticamente de estatísticas do repositório, como estrelas (GitHub stars), observadores (watches) e forks, e pode ser enriquecida com KPIs de outras ferramentas ou avaliações manuais.
+
+Além disso, considera parâmetros de atividade como a data da última atualização e a data de criação do repositório para impulsionar projetos jovens com muita tração. Projetos com diretrizes de contribuição, estatísticas de participação ativa e problemas (backlog público) recebem uma classificação mais alta também.
+
+Tudo isso pode ser obtido e calculado automaticamente usando o conjunto de resultados da [API de pesquisa do GitHub](https://docs.github.com/en/rest/search#search-repositories) e [API de estatísticas do GitHub](https://docs.github.com/en/rest/metrics/statistics). Outros sistemas de controle de versão de código, como BitBucket, GitLab e Gerrit, podem ser integrados também, se uma API similar estiver disponível.
+
+O código abaixo pressupõe que a variável `repo` contenha uma entidade obtida a partir da API de pesquisa do GitHub (`search`) e que o objeto `participation` contenha uma entidade da API do GitHub (`stats/participation`).
+
+Ajustes manuais de acordo com os KPIs "soft" (consulte [Forças](#forças)) podem ser feitos conforme necessário.
+
+``` javascript
+// calcular uma pontuação virtual de InnerSource a partir de estrelas, seguidores, commits e issues
+function calculateScore(repo) {
+ // a pontuação inicial é 50 para dar a repositórios ativos com baixos KPIs do GitHub (forks, seguidores, estrelas) um ponto de partida melhor
+ let iScore = 50;
+ // ponderação: forks e seguidores contam mais, depois estrelas, adiciona um pouco de pontuação para issues abertas também
+ iScore += repo.forks_count * 5;
+ iScore += (repo.subscribers_count ? repo.subscribers_count : 0);
+ iScore += repo.stargazers_count / 3;
+ iScore += repo.open_issues_count / 5;
+
+ // atualizado nos últimos 3 meses: adiciona um bônus multiplicador entre 0..1 à pontuação geral (1 = atualizado hoje, 0 = atualizado há mais de 100 dias)
+ let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400;
+ iScore = iScore * ((1 + (100 - Math.min(iDaysSinceLastUpdate, 100))) / 100);
+
+ // avaliar estatísticas de participação nos últimos 3 meses
+ repo._InnerSourceMetadata = repo._InnerSourceMetadata || {};
+ if (repo._InnerSourceMetadata.participation) {
+ // média de commits: adiciona um bônus multiplicador entre 0..1 à pontuação geral (1 = >10 commits por semana, 0 = menos de 3 commits por semana)
+ let iAverageCommitsPerWeek = repo._InnerSourceMetadata.participation.slice(-13).reduce((a, b) => a + b) / 13;
+ iScore = iScore * ((1 + (Math.min(Math.max(iAverageCommitsPerWeek - 3, 0), 7))) / 7);
+ }
+
+ // cálculo do boost:
+ // todos os repositórios atualizados no ano anterior receberão um boost de até 1000 diminuindo com os dias desde a última atualização
+ let iBoost = (1000 - Math.min(iDaysSinceLastUpdate, 365) * 2.74);
+ // dimensionar gradualmente o boost de acordo com a data de criação do repositório para misturar com estatísticas de engajamento "reais"
+ let iDaysSinceCreation = (new Date().getTime() - new Date(repo.created_at).getTime()) / 1000 / 86400;
+ iBoost *= (365 - Math.min(iDaysSinceCreation, 365)) / 365;
+ // adicionar boost à pontuação
+ iScore += iBoost;
+ // dar aos projetos com uma descrição significativa um boost estático de 50
+ iScore += (repo.description?.length > 30 || repo._InnerSourceMetadata.motivation?.length > 30 ? 50 : 0);
+ // dar aos projetos com um arquivo de diretrizes de contribuição (CONTRIBUTING.md) um boost estático de 100
+ iScore += (repo._InnerSourceMetadata.guidelines ? 100 : 0);
+ // construir uma escala logarítmica para projetos muito ativos (aberta, mas estabilizando em torno de 5000)
+ if (iScore > 3000) {
+ iScore = 3000 + Math.log(iScore) * 100;
+ }
+ // a pontuação final é um valor arredondado começando de 0 (subtraindo o valor inicial)
+ iScore = Math.round(iScore - 50);
+ // adicionar pontuação aos metadados instantaneamente
+ repo._InnerSourceMetadata.score = iScore;
+
+ return iScore;
+}
+```
+
+## Contexto Resultante
+
+Os contribuidores têm a liberdade de dedicar parte do seu tempo a projetos InnerSource. Eles podem optar por contribuir para um projeto do qual dependem para o trabalho em sua equipe regular. No entanto, também podem escolher contribuir para algo completamente diferente, com base em seus interesses e objetivos de desenvolvimento pessoal.
+
+Os projetos podem ser ordenados e apresentados de acordo com a pontuação de atividade do repositório, proporcionando uma ordem significativa em um portal que apresenta projetos a potenciais novos contribuidores. A pontuação pode ser calculada instantaneamente ou em um trabalho de fundo que avalia todos os projetos regularmente e armazena uma lista de resultados.
+
+Um rastreador que pesquisa regularmente todos os repositórios InnerSource (por exemplo, marcados com um [tópico específico](https://github.com/topics) no GitHub) também pode ser uma adição útil. Ele fornece uma lista classificada de projetos que podem ser usados como entrada para ferramentas como o [InnerSource Portal](innersource-portal.md), um mecanismo de busca ou um bot de chat interativo.
+
+## Justificativa
+
+A pontuação de atividade do repositório é um cálculo simples baseado na API do GitHub. Pode ser totalmente automatizada e facilmente adaptada a novos requisitos.
+
+## Instâncias Conhecidas
+
+* Usado no portal de projetos InnerSource da SAP para definir a ordem padrão dos projetos InnerSource. Foi criado pela primeira vez em julho de 2020 e vem sendo ajustado e atualizado com frequência desde então. Quando proposto para o InnerSourceCommons em julho de 2020, este padrão emergiu. Veja também [Michael Graf & Harish B (SAP) em ISC.S11 - O Caminho Inesperado da Aplicação de Padrões InnerSource](https://www.youtube.com/watch?v=6r9QOw9dcQo&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy&index=6).
+
+## Estado
+
+* Structured
+
+## Autores
+
+[Michael Graf (SAP)](mailto:mi.graf@sap.com)
+
+## Reconhecimento
+
+Um agradecimento à comunidade InnerSource Commons por fornecer conselhos extremamente rápidos e muitas contribuições úteis para enriquecer este padrão! Em especial:
+
+* Johannes Tigges
+* Sebastian Spier
+* Maximilian Capraro
+* Tim Yao
+
+## Histórico de Tradução
+
+- **2022-08-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-08-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/review-committee.md b/translation/pt-br/patterns/review-committee.md
new file mode 100644
index 000000000..f83401e88
--- /dev/null
+++ b/translation/pt-br/patterns/review-committee.md
@@ -0,0 +1,62 @@
+## Title
+
+Comitê de Revisão
+
+## Patlet
+
+O Modelo de Trabalho InnerSource é uma ruptura radical das abordagens mais tradicionais, tanto para desenvolvedores quanto para gerentes. Ao estabelecer um Comitê de Revisão como uma interface entre a iniciativa InnerSource e todos os gerentes sêniores das unidades de negócios que participam dela, é mais provável que estes últimos se familiarizem com a iniciativa e a apoiem, uma vez que isso lhes proporciona um certo nível de supervisão e controle sem promover a microgestão.
+
+## Problema
+
+Os gerentes perceberão o Modelo de Trabalho InnerSource como uma ruptura radical dos modelos de trabalho aos quais estão acostumados e têm experiência. Como consequência, é provável que eles rejeitem ou façam uma microgestão da iniciativa InnerSource para tentar minimizar o risco percebido dessa mudança. Em ambos os casos, os benefícios do InnerSource não podem ser obtidos. Como resultado, o InnerSource é subsequentemente desacreditado.
+
+## Contexto
+
+A Empresa A deseja introduzir sua primeira iniciativa InnerSource. A maioria dos gerentes na Empresa A não está familiarizada com o modelo de trabalho de Código Aberto e, em vez disso, está acostumada com um estilo de gestão hierárquico e de controle de cima para baixo.
+
+## Forças
+
+- Quanto mais controle percebido um gerente tem sobre o trabalho na iniciativa InnerSource, mais provável é que ele ou ela apoie a iniciativa mesmo sem experiência prévia.
+- Quanto menos experiência um gerente tem com o modelo de trabalho de Código Aberto, mais provável é que ele ou ela queira controlar o risco da iniciativa.
+- Quanto mais rígidas e controladoras forem as iniciativas InnerSource gerenciadas, menos provável é que o modelo de trabalho de Código Aberto possa ser adotado na extensão necessária. Como resultado, os benefícios do InnerSource não serão obtidos.
+
+## Solução
+
+- Estabelecer um comitê de revisão composto por gerentes seniores de todas as unidades de negócios que participam da iniciativa InnerSource.
+- Os membros do comitê de revisão têm a autoridade para decidir em grupo quais projetos InnerSource receberão suporte de forma geral e financiamento em particular.
+- Os candidatos podem ser eleitos pelos membros do comitê de revisão antes das reuniões para apresentar seus projetos InnerSource propostos durante as reuniões do comitê de revisão para consideração.
+- Os líderes de projetos InnerSource atualmente financiados pelo comitê de revisão são obrigados a relatar o status de seus projetos durante todas as reuniões do comitê de revisão.
+- Os membros do comitê de revisão são obrigados a fornecer feedback construtivo tanto para novos candidatos quanto para os líderes de projetos atuais durante as reuniões do comitê de revisão.
+- Cada projeto InnerSource deve ter a chance de reagir ao feedback recebido em uma sessão do comitê de revisão até a próxima sessão, a fim de evitar o encerramento prematuro do projeto.
+- Um líder de projeto InnerSource também pode apresentar a proposta de encerramento por conta própria em uma reunião do comitê de revisão. O comitê de revisão então deve decidir se as unidades de negócios que utilizam o software precisam ter tempo para implementar medidas para garantir que o desenvolvimento e/ou manutenção do código continue até que uma solução alternativa para o desenvolvimento pela comunidade InnerSource seja encontrada (se for relevante para o negócio ou crítico para a missão).
+- O comitê de revisão deve se reunir regularmente. Uma frequência de duas reuniões por ano tem se mostrado bem-sucedida.
+
+
+
+## Contexto Resultante
+
+- Os gerentes aplicam uma ferramenta com a qual estão familiarizados ao InnerSource para obter a quantidade necessária de informações e controle sobre o funcionamento interno da iniciativa InnerSource. Essa familiaridade tornará mais provável que eles aprovem a iniciativa InnerSource e concedam o grau necessário de liberdade para os projetos InnerSource.
+- Os desenvolvedores ainda podem se auto-organizar até certo ponto. O microgerenciamento não ocorre porque o comitê de revisão se reúne com pouca frequência.
+
+## Instâncias Conhecidas
+
+* BIOS at Robert Bosch GmbH
+
+## Estado
+
+* Structured
+* _Finalized and Reviewed_ as of 8/31/17.
+
+## Autores
+
+- Georg Grütter, Robert Bosch GmbH
+- Diogo Fregonese, Robert Bosch GmbH
+
+## Alias
+
+Cheese Interface
+
+## Histórico de Tradução
+
+- **2022-08-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-08-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/service-vs-library.md b/translation/pt-br/patterns/service-vs-library.md
new file mode 100644
index 000000000..e180500fd
--- /dev/null
+++ b/translation/pt-br/patterns/service-vs-library.md
@@ -0,0 +1,82 @@
+## Title
+
+Serviço vs. Biblioteca
+
+## Patlet
+
+Equipes em um ambiente DevOps podem relutar em trabalhar além dos limites de suas equipes em bases de código comuns, devido à ambiguidade sobre quem será responsável por responder a interrupções de serviço. A solução é perceber que muitas vezes é possível implantar o mesmo serviço em ambientes independentes com cadeias de escalonamento separadas no caso de interrupções de serviço, ou separar grande parte do código compartilhado em uma biblioteca única e colaborar nela.
+
+## Problema
+
+Quando as equipes estão trabalhando em um ambiente DevOps, os desenvolvedores são responsáveis por um recurso do início ao fim: desde o cliente até a implantação, manutenção e suporte. Isso representa um desafio ao trabalhar além dos limites da equipe: as cadeias de escalonamento podem não ser as mesmas para erros que ocorrem em qualquer equipe. O acoplamento entre código-fonte e implantação deixa as equipes com a dúvida de quem é responsável pelo suporte de plantão em caso de erros. Como resultado, as equipes relutam em unir forças, mesmo que haja uma sobreposição significativa nos requisitos.
+
+## Contexto
+
+* As equipes estão trabalhando em um ambiente de micro-serviços.
+* Elas estão organizadas em equipes de DevOps totalmente funcionais: Cada equipe é responsável por suas contribuições do início ao fim, incluindo manutenção, suporte de plantão e suporte ao cliente.
+* Uma equipe tem a tarefa de fornecer um serviço aos seus clientes downstream que é bastante semelhante a um serviço existente construído por outra equipe.
+
+## Forças
+
+* Os caminhos de escalonamento organizacional podem ser diferentes para cada uma das equipes.
+* Os membros de cada equipe podem estar relutantes em fornecer suporte de plantão para erros que não afetam seus próprios clientes downstream.
+* Os níveis de gravidade para os mesmos tipos de erros podem ser diferentes entre as fronteiras das equipes devido a diferentes definições de SLA por equipe/relacionamento com o cliente.
+* As equipes podem ter diferentes restrições de segurança ou regulamentações que regem suas implantações.
+
+## Solução
+
+Separar a responsabilidade pelo código-fonte da implantação: Ambas as equipes trabalham para
+identificar exatamente onde existem sobreposições e sinergias.
+
+Apenas o código-fonte partilhado é mantido como parte do projeto InnerSource com responsabilidade partilhada. O código-fonte partilhado deve ser coerente, na medida em que inclui todo o código de teste (incluindo testes de integração, se disponíveis) e o máximo possível do pipeline de CI para facilitar a validação da contribuição.
+
+Separe os pipelines de configuração e implantação da lógica comercial real.
+Estabelecer uma segunda implantação do serviço para a segunda equipe.
+
+Tratar a base comum como uma biblioteca que é utilizada por ambas as equipes com código partilhado
+propriedade partilhada.
+
+As configurações de implementação podem ser incluídas como projectos separados no seu portfólio InnerSource para permitir que as equipes discutam/colabore ou que uma nova equipe as copie.
+
+## Contexto Resultante
+
+As equipes estão dispostas a colaborar, se beneficiando ao compartilhar o trabalho de implementação da lógica de negócios.
+
+Um serviço que originalmente foi construído especificamente para funcionar em um ambiente é convertido em uma solução mais geral com base em um requisito de negócio específico.
+
+Ambas as equipes conhecem sua respectiva política de escalonamento e configuração de implantação, identificando potencialmente melhorias para sua própria configuração.
+
+A probabilidade de que mudanças sejam necessárias e feitas no código-fonte compartilhado aumenta, levando a oportunidades mais frequentes de refinar, melhorar e otimizar a implementação.
+
+Estimula a padronização operacional incremental no empacotamento de lançamento, telemetria, endpoints de saúde/preparação e assim por diante, à medida que as equipes percebem que podem manter isso de maneira mais eficiente no código compartilhado se concordarem com convenções padrão.
+
+## Veja também
+
+Relacionado a este padrão está o [Garantia de 30 dias](30-day-warranty.md), que adota uma abordagem diferente para lidar com as forças descritas acima.
+
+## Instâncias Conhecidas
+
+* Europace AG
+* Flutter Entertainment: [Flutter InnerSource application](https://innersource.flutter.com/sdlc/) possui um repositório de código compartilhado "service" com contribuições entre equipes e uma pipeline de CI para construir e publicar um artefato de release compartilhado. Cada equipe adotante possui um repositório de "configuração de implantação" que define sua própria implantação. Isso é conduzido por diferentes requisitos regulatórios, práticas de gerenciamento de serviço e incidentes e conjuntos de habilidades de infraestrutura em diferentes áreas do negócio.
+
+## Estado
+
+* Structured
+
+## Autores
+
+* Isabel Drost-Fromm
+* Rob Tuley
+
+## Reconhecimento
+
+Obrigado, Tobias Gesellchen, pela revisão interna na Europace AG.
+
+## Alias
+
+Serviço vs. Biblioteca: É Inner Source, Não implantação interna
+
+## Histórico de Tradução
+
+- **2022-08-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-08-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/start-as-experiment.md b/translation/pt-br/patterns/start-as-experiment.md
new file mode 100644
index 000000000..b0eacd5e0
--- /dev/null
+++ b/translation/pt-br/patterns/start-as-experiment.md
@@ -0,0 +1,79 @@
+## Title
+
+Inicie como um Experimento
+
+## Patlet
+
+Comece a sua iniciativa InnerSource como um experimento com limite de tempo para tornar mais fácil para os gestores que não estão familiarizados com o InnerSource endossar e apoiar a iniciativa.
+
+## Problema
+
+Uma iniciativa InnerSource é considerada, mas não é iniciada porque a gestão está incerta sobre o resultado e, como resultado, não está disposta a comprometer um investimento.
+
+## Contexto
+
+A empresa está considerando o InnerSource para aumentar a eficiência da colaboração em projetos de software. No entanto, a maioria dos gestores não está familiarizada com o modelo de trabalho de código aberto e está mais acostumada com o estilo de gestão hierárquica e de controle de cima para baixo. A ideia do InnerSource é muito popular entre os desenvolvedores de software da empresa, não apenas porque muitos desenvolvedores usam ou estão desenvolvendo ativamente software de código aberto.
+
+## Forças
+
+- Os gestores vão querer validar as alegações de melhoria na colaboração por meio do InnerSource antes de fazer um investimento de longo prazo. Isso geralmente envolve medir as melhorias.
+- Se a iniciativa InnerSource provavelmente terá uma grande adesão entre os desenvolvedores e se muitos projetos provavelmente dependerão dela, a decisão de encerrá-la será muito impopular e, portanto, difícil de ser tomada. A perda de controle percebida resultante pode desencorajar alguns gestores a sequer começar com o InnerSource.
+- A implementação de modelos de trabalho no estilo InnerSource muitas vezes representa uma ruptura radical em relação aos modelos de trabalho praticados anteriormente. Portanto, é provável que processos obrigatórios existentes já não sejam aplicáveis e que processos de governança adequados estejam faltando. O resultado pode ser que seja necessário operar em uma zona de vácuo regulatória, às vezes legal. Exemplos são regulamentos relacionados a impostos e controle de exportações em grandes corporações com várias entidades jurídicas em diversos países.
+
+## Solução
+
+Declare a Iniciativa InnerSource como um experimento com tempo limitado. Defina e comunique os critérios para os projetos ingressarem no experimento InnerSource. Escolha critérios que maximizem as chances de construir uma comunidade saudável. Um conjunto de critérios é bom se as percepções geradas a partir dele dentro do contexto do experimento puderem ser intuitivamente aplicadas a contextos envolvendo outros potenciais projetos InnerSource.
+
+Exemplos de critérios são:
+
+- Distribuição geográfica suficiente de desenvolvedores
+- Mistura departamental suficiente de desenvolvedores
+- Abertura da comunicação dentro da comunidade
+- Caminho de carreira baseado em mérito dentro da comunidade
+- Tomada de decisão democrática dentro da comunidade
+
+Considere designar o final do experimento como um ponto de _pivot_, _mudança_ ou _pausa_ para reavaliação. Também considere estabelecer um [Comitê de Revisão](review-committee.md) para aumentar as chances de aceitação da gestão por meio da participação. Dependendo da cultura da empresa, pode ser útil acompanhar o experimento com métricas apropriadas [Primeiros Passos com Métricas](../../../patterns/1-initial/introducing-metrics-in-innersource.md). Se os projetos no experimento não fornecerem um impacto direto na receita da empresa, considere introduzir [Avaliação de Projetos entre Equipes](crossteam-project-valuation.md) para destacar suas contribuições de valor.
+
+## Contexto Resultante
+
+Os gerentes podem dar início ao InnerSource pelos seguintes motivos:
+
+- A configuração experimental facilita a necessidade dos gerentes analisarem os números do programa InnerSource da mesma forma que fariam para projetos típicos.
+- A possibilidade de falha do experimento é compreendida e aceita. O risco pessoal para os gerentes de apoio é minimizado.
+- Mesmo em caso de falha, a configuração garante que a empresa aprenderá com o experimento.
+- Em caso de sucesso, os dados coletados durante o experimento permitirão que os gerentes façam um compromisso mais duradouro com o InnerSource.
+
+Os participantes no experimento InnerSource agora estão cientes de que devem provar à gestão que o InnerSource oferece os benefícios prometidos. Isso ajudará a focar o trabalho nas atividades que proporcionam o valor mais demonstrável, aumentando assim as chances de sucesso.
+
+Finalmente, começar como um experimento torna muito mais fácil evitar regulamentos e forças, como políticas de ferramentas e processos, que poderiam diminuir as chances de sucesso.
+
+## Patterns Relacionados
+
+- _Trial Run_ (from the book [Fearless Change](https://fearlesschangepatterns.com/))
+
+## Instâncias Conhecidas
+
+- Robert Bosch GmbH (globally distributed software development)
+
+## Estado
+
+* Structured
+
+## Autores
+
+- Georg Grütter (Robert Bosch GmbH)
+
+## Reconhecimento
+
+- Jason Zink (Robert Bosch GmbH)
+- Diogo Fregonese (Robert Bosch GmbH)
+- Robert Hansel (Robert Bosch GmbH)
+- Hans Malte Kern (Robert Bosch GmbH)
+- Russ Rutledge (Nike)
+- Tim Yao (Nokia)
+- Clint Cain (Optum)
+
+## Histórico de Tradução
+
+- **2022-08-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-08-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/transparent-cross-team-decision-making-using-rfcs.md b/translation/pt-br/patterns/transparent-cross-team-decision-making-using-rfcs.md
new file mode 100644
index 000000000..0713d0606
--- /dev/null
+++ b/translation/pt-br/patterns/transparent-cross-team-decision-making-using-rfcs.md
@@ -0,0 +1,130 @@
+## Title
+
+Tomada de Decisão Transparente entre Equipes usando RFCs
+
+## Patlet
+
+Projetos InnerSource que desejam alcançar altas taxas de participação e tomar as melhores decisões possíveis para todos os envolvidos precisam encontrar maneiras de criar sistemas participativos ao longo de todo o ciclo de vida do software. A publicação de documentos internos de "Requests for Comments" (RFCs) permite discussões desde o início do processo de design e aumenta as chances de construir soluções com um alto grau de comprometimento de todas as partes envolvidas.
+
+## Problema
+
+Para que um projeto InnerSource seja saudável, ele precisa de um número substancial de contribuidores. Esses contribuidores (ou equipes) podem ter diferentes requisitos para o projeto em questão, por exemplo, eles podem querer adicionar recursos ao projeto que não são compatíveis entre si ou que levem a um excesso de complexidade na arquitetura.
+
+Descobrir tais desacordos ou mal-entendidos tardiamente no processo, por exemplo, após o software já ter sido construído, é muito custoso. Esses desacordos podem levar à frustração de todas as partes envolvidas e até mesmo serem prejudiciais para a cultura de colaboração saudável do projeto. Uma situação comum em que tal desacordo surge é uma solicitação de alteração (pull request) que fica aberta por muito tempo, pois o autor da solicitação e os mantenedores do projeto basicamente não concordam que a alteração proposta deva ser feita.
+
+Para um projeto InnerSource, essa situação ocorre com mais frequência quando o projeto é mantido por várias equipes na empresa, ou seja, possui propriedade compartilhada.
+
+## História
+
+Um projeto ou aplicação composta por vários projetos é mantido por várias equipes diferentes, cada uma delas sendo responsável por diferentes áreas do projeto ou aplicação. Essas equipes fazem contribuições InnerSource nas áreas umas das outras, mas mudanças maiores que afetam várias partes do projeto são apenas conduzidas pelos líderes técnicos das equipes trabalhando juntos, ou nem acontecem. Isso resulta na maioria dos engenheiros não sendo capazes de realizar mudanças em larga escala que cortem várias partes do projeto, o que reduz a inovação e as oportunidades de colaboração.
+
+Ao implementar um processo e um modelo para RFCs (Requests for Comments), as equipes e indivíduos são capacitados a propor mudanças significativas que afetem várias partes do projeto através de um processo de tomada de decisão transparente, com consulta entre as equipes feita de forma assíncrona. Isso resulta em maior inovação, colaboração mais próxima e disseminação de conhecimento. Isso depende do comprometimento de todas as disciplinas em todos os níveis e de um ambiente de segurança psicológica para que as pessoas possam propor e debater ideias abertamente.
+
+Assim como em qualquer processo, isso deve ser continuamente aprimorado. Pode ser necessário fazer alterações no modelo ou no processo de RFC para garantir que seja inclusivo, colaborativo e eficaz.
+
+## Contexto
+
+- Compartilhamento de Propriedade por Muitas Equipes de um Projeto InnerSource
+- Decisões de design abrangentes não podem ser sempre tomadas por um órgão central (por exemplo, um grupo de arquitetos), pois eles não têm tempo suficiente nem conhecimento específico do domínio para tomar boas decisões em todos os casos.
+- Vários tipos de usuários têm entrada sobre a direção que um determinado projeto está tomando. Esses usuários podem ser: Desenvolvedores, Proprietários de Produto, Gerentes de Produto, etc.
+- As decisões precisam ser tomadas de forma assíncrona, pelo menos em parte, já que não é viável realizar reuniões síncronas frequentes com todos os participantes.
+- Existe o desejo de documentar as decisões tomadas, ou seja, garantir que sejam registradas por escrito, em vez de apenas verbalmente.
+
+## Forças
+
+- Na maioria das vezes, as partes envolvidas desejam tomar uma decisão bastante rápida (por exemplo, o tempo de design inicial é bastante limitado).
+- Escrever as coisas (sem implementá-las imediatamente) muitas vezes é uma nova habilidade para muitas das pessoas envolvidas.
+
+## Esboço
+
+
+
+## Solução
+
+Escolhemos um processo semelhante ao RFC para aumentar a transparência do nosso processo de tomada de decisão entre equipes (consulte também [Requests for Comments][requests-for-comments]).
+
+Elementos importantes da solução são:
+
+- uma descrição de quando publicar um RFC (e quando não fazê-lo)
+- um modelo para documentos RFC
+ - deve provocar o autor do RFC a considerar sua proposta a partir de várias perspectivas
+ - deve fornecer uma visão geral acessível de alto nível e uma explicação detalhada em profundidade
+- um processo bem conhecido e leve em torno de RFCs, por exemplo,
+ - como publicar um RFC e compartilhá-lo com todas as partes interessadas (por exemplo, Slack, lista de discussão)
+ - como coletar feedback para o RFC
+ - como trabalhar no feedback recebido
+ - como levar o RFC a uma conclusão ou decisão (por exemplo, mantenedores relevantes nomeados para aprovar)
+ - ferramentas adequadas escolhidas (por exemplo, não-engenheiros podem não ter acesso a ferramentas de controle de código fonte)
+- um compromisso em iterar no modelo de RFC e no processo
+
+### Exemplos/Modelos
+
+- [Rust][rust] é um bom exemplo de código aberto para modelo e processo de RFC, e tem sido a base para muitos outros processos de RFC.
+- [Modelo de RFC genérico do BBC iPlayer & Sounds](../../../patterns/2-structured//templates/rfc.md), originalmente baseado no modelo do [Rust][rust]
+
+## Contexto Resultante
+
+Implementar um processo semelhante a um RFC provou ser valioso, pois torna o processo de tomada de decisão entre equipes mais transparente para todos, permitindo que todas as vozes sejam ouvidas.
+
+Efeitos positivos observáveis:
+
+- **democratização do processo de tomada de decisão** para decisões que impactam muitas equipes (aliviando também os líderes das equipes dessa carga)
+- **um método de comunicação assíncrono e aberto** que funciona bem entre várias equipes e localidades
+- **empodera indivíduos e equipes** a efetuar mudanças em grande escala
+- **registro de decisões tomadas** para que as pessoas possam consultar para obter contexto
+- **amplia o impacto dos engenheiros experientes** pois eles podem contribuir com soluções de forma assíncrona e remota, em vez de precisar estar presente em uma reunião
+- **alinhamento de terminologia**, por exemplo, ao esclarecer nossa terminologia de testes, como "o que é um teste de sistema?"
+- **alinhamento de processos**, por exemplo, ao esclarecer o processo de suporte fora do horário comercial
+- **maior clareza de pensamento**, já que escrever um RFC faz com que o autor se desafie mais do que normalmente faria
+
+A abordagem de RFC também possui riscos que queremos destacar:
+
+- Nem sempre funciona! Por exemplo, algumas pessoas ainda podem discordar de uma decisão que já foi tomada por meio de um RFC. No entanto, ter o processo de tomada de decisão por escrito ainda é benéfico nesses cenários, pois você pode direcionar as pessoas para quando e por que uma determinada decisão foi tomada.
+- Escrever propostas de design (arquitetura, protocolos, etc.) antecipadamente tem um elemento de design semelhante ao waterfall que não se encaixa na abordagem de desenvolvimento iterativo que muitas equipes de desenvolvimento preferem. Lembre-se: "Software em funcionamento sobre documentação abrangente" ([Manifesto Ágil](https://agilemanifesto.org/)). O processo de RFC deve ser o mais leve possível.
+- Um RFC pode se tornar extenso e difícil de gerenciar. Isso muitas vezes é evidenciado por longas conversas e discussões a seu respeito. Nessas situações, podemos decidir complementar o RFC com comunicação síncrona, como um grupo de trabalho e reuniões presenciais. Mas o tempo ainda é economizado, pois as pessoas podem ler o RFC antes da reunião em vez de terem todas as informações compartilhadas durante a reunião.
+
+## Justificativa
+
+As RFCs têm se mostrado eficazes no mundo do código aberto há muitos anos. Isso é verdade tanto para a Internet como um todo, onde as RFCs têm sido instrumentais no desenvolvimento de padrões (por exemplo, veja [30 Anos de RFCs][30-years-of-rfcs]), quanto para outros projetos de código aberto que adaptaram esse método para promover a tomada de decisões transparente em suas comunidades (por exemplo, [RUST][rust], [ZeroMQ][zeromq]).
+
+No contexto do InnerSource, outras empresas também compartilharam suas experiências com abordagens semelhantes às RFCs, como [Uber][uber] e [Europace][europace].
+
+Além disso, para a tomada de decisões fora das decisões puramente de design de software, modelos transparentes de tomada de decisões podem ser eficazes, por exemplo, ao trabalhar em direção a uma Organização Aberta. Para um exemplo, veja o [Framework de Decisões Abertas][open-decision-framework] da Red Hat (lançado publicamente em 7 de junho de 2016).
+
+## Instâncias Conhecidas
+
+- **BBC iPlayer & Sounds** - Como apresentado na ISC Fall Summit 2020 [Using Internal RFCs to Enhance Collaboration][bbc].
+- **Europace** - Como descrito em Open Organization: [Setting cross-team standards and best practices in the open][europace].
+- **Uber** - Conforme descrito neste post no blog por Gergely Orosz: [Scaling Engineering Teams via RFCs: Writing Things Down][uber].
+- **Google Design Docs** - Como descrito neste post no blog por Malte Ubl: [Design Docs at Google][google].
+- **DAZN** (10/2021) - Uma forma pela qual a DAZN toma decisões técnicas é por meio de RFCs. RFCs são usados para decisões que se aplicam apenas a processos em toda a engenharia! As RFCs ficam em um repositório do GitHub, e os padrões técnicos são gradualmente adotados em suas ferramentas e por seus engenheiros. Uma RFC pode ser proposta por qualquer engenheiro e votada por todos os engenheiros. Se os votos a favor excederem os votos contra, a RFC é adotada. Vale ressaltar que o processo de votação de RFCs ainda não foi "testado sob pressão" por nenhuma decisão controversa. - Como descrito neste post no blog por Lou Bichard: [Building A DX Team: Lessons Learned][dazn].
+
+## Estado
+
+Structured
+
+## Autores
+
+- Tom Sadler
+- Sebastian Spier
+
+## Aliases
+
+- [Design Docs][google]
+- Architecture Decision Record (ADRs) - Não necessariamente um equivalente direto, pois às vezes eles podem ser usados de maneira diferente, por exemplo, RFCs para buscar opiniões e construir consenso, ADRs para registrar decisões e detalhes de implementação.
+
+[requests-for-comments]: https://en.wikipedia.org/wiki/Request_for_Comments
+[30-years-of-rfcs]: https://www.rfc-editor.org/rfc/rfc2555.txt
+[rust]: https://github.com/rust-lang/rfcs
+[zeromq]: https://rfc.zeromq.org
+[uber]: https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/
+[europace]: https://github.com/open-organization/open-org-distributed-work-guide/blob/master/drostfromm-remote-first-through-openess.md#setting-cross-team-standards-and-best-practices-in-the-open
+[open-decision-framework]: https://www.redhat.com/en/about/press-releases/red-hat-releases-open-decision-framework-spur-transparent-and-inclusive-leadership
+[bbc]: https://www.youtube.com/watch?v=U6zlghE0HcE
+[google]: https://www.industrialempathy.com/posts/design-docs-at-google/
+[dazn]: https://medium.com/dazn-tech/building-a-dx-team-lessons-learned-4a66446088bc
+
+## Histórico de Tradução
+
+- **2022-08-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-08-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/patterns/trusted-committer.md b/translation/pt-br/patterns/trusted-committer.md
new file mode 100644
index 000000000..1a246d467
--- /dev/null
+++ b/translation/pt-br/patterns/trusted-committer.md
@@ -0,0 +1,148 @@
+## Title
+
+Trusted Committer
+
+## Patlet
+
+Muitos projetos InnerSource se encontram em uma situação em que
+consistentemente recebem feedback, funcionalidades e correções de bugs de contribuidores.
+Nessas situações, os mantenedores do projeto buscam maneiras de reconhecer e recompensar
+o trabalho do contribuidor acima e além de contribuições individuais.
+
+## Problema
+
+- Os mantenedores do projeto desejam encontrar maneiras de aumentar a capacidade de suporte a um projeto.
+- Os mantenedores do projeto desejam encontrar maneiras de prolongar o valor entregue por um projeto.
+- Os mantenedores do projeto desejam recompensar visivelmente os contribuidores frequentes e capacitá-los a ampliar sua contribuição de valor.
+- Falta de mecanismo e linguagem para reconhecer contribuições entre equipes dentro de uma organização.
+
+## Contexto
+
+- Você é o mantenedor de uma biblioteca, serviço ou recurso compartilhado entre equipes.
+- Você recebe contribuições regulares.
+- Você recebe solicitações regulares de novos recursos.
+- Você recebe solicitações regulares de correções de bugs.
+- Existem contribuidores motivados buscando construir experiência por meio de projetos InnerSource.
+
+## Forças
+
+- Ao longo do ciclo de vida de um projeto, o foco dos mantenedores pode se deslocar para acomodar as mudanças nas prioridades comerciais.
+- Os contribuidores buscam reconhecimento visível de suas contribuições, demonstrando valor.
+- Manter um projeto de complexidade razoável é desgastante para uma equipe pequena.
+- Desenvolver recursos do projeto em escala é desgastante para uma equipe pequena.
+
+## Solução
+
+### Definindo o Papel de Trusted Committer para um Projeto
+
+O que um Trusted Committer lida depende de cada projeto e de seus mantenedores. Certifique-se de documentar dentro do projeto o escopo do seu papel de Trusted Committer. A documentação clara estabelece as expectativas para novos membros da comunidade e estabelece o papel para futuros candidatos.
+
+As seguintes são algumas diretrizes para identificar um possível Trusted Committer:
+
+* Um participante ativo nos canais da comunidade (Slack, triagem de problemas no JIRA, etc.) se torna um Trusted Committer, formalizando assim seu papel no suporte à comunidade.
+* Alguém que frequentemente submete código, documentação ou outras mudanças no repositório. Comece incluindo essa pessoa em pull requests. Se eles estão participando ativamente de pull requests, considere abordá-los sobre oportunidades de colaboração adicional no projeto.
+
+### Formalizando Trusted Committers
+
+O primeiro passo é abordar os candidatos para se tornarem Trusted Committers.
+Os mantenedores devem educar os candidatos sobre o papel de um Trusted Committer. Não há expectativa de que os candidatos aceitem o papel de Trusted Committer. Cada candidato
+deve avaliar se tem a disponibilidade necessária para assumir as responsabilidades.
+
+Quando um candidato aceita o papel, cabe aos mantenedores do projeto
+reconhecer publicamente a transição de usuário para Trusted Committer. Também é uma
+boa ideia adicionar o nome deles a uma seção de Trusted Committers no README do seu projeto.
+Como exemplo:
+
+```markdown
+# nome-do-projeto
+
+... o readme do seu projeto ...
+
+## Líderes do Projeto
+
+### Mantenedores
+
+ - Sua equipe
+
+### [Trusted Committers]
+
+ - O nome do novo trusted committer
+
+[Trusted Committers]: https://exemplo.com/link/para/sua/documentacao-de-trusted-committer.md
+```
+
+### Mantendo Relacionamentos com Trusted Committers
+
+Depois de formalizar um novo Trusted Committer, é uma boa ideia mantê-los informados à medida que você continua a iterar no projeto. Manter eles informados pode ser tão simples quanto convidá-los para o canal do projeto ou tão envolvente quanto incluí-los em suas sessões de planejamento. Mais oportunidades de envolvimento oferecem aos Trusted Committers um caminho para se tornarem Mantenedores, se assim desejarem.
+
+Além de manter os Trusted Committers informados, é bom fazer verificações regulares. Uma cadência sugerida é começar com todas as semanas antes de progredir gradualmente para a cada poucas semanas. O objetivo dessas verificações é garantir que o Trusted Committer se sinta apoiado em seu novo papel. Analogamente a uma reunião individual com seu gerente, se houver problemas, ouça e demonstre empatia para entender o que está impedindo o Trusted Committer de ter sucesso. Sempre [agradeça ao Trusted Committer pelo esforço contínuo][praise] em tornar o projeto bem-sucedido e defina uma nova data para a próxima verificação.
+
+### Encerrando a Participação de um Trusted Committer
+
+Existem momentos que podem exigir a remoção de um Trusted Committer, como quando o Trusted Committer:
+
+* Não está mais disposto a participar;
+* Não consegue mais desempenhar suas funções;
+* Não está mais empregado pela empresa.
+
+Um plano para remover o acesso aos recursos do projeto deve ser acordado por ambas as partes, incluindo a transição de sua entrada na seção de **Trusted Committers** do projeto para uma lista de contribuidores passados.
+
+Ao remover o acesso, [agradeça ao Trusted Committer pela participação publicamente][praise]. O reconhecimento público garante uma comunicação clara da transição e continuidade dentro da comunidade.
+
+## Contexto Resultante
+
+### Para os Contribuidores
+
+Alcançar o status de Trusted Committer para um projeto demonstra iniciativa em
+contribuir para o projeto da comunidade. O reconhecimento por esses esforços
+pode ser usado durante as revisões anuais com os gerentes.
+
+### Para os Mantenedores
+
+Conforme um projeto amadurece, os mantenedores podem ficar menos familiarizados com aspectos-chave
+de um projeto. Trusted Committers preenchem essas lacunas, garantindo que todos os
+aspectos do projeto sejam melhor atendidos ao longo do tempo.
+
+Um conjunto saudável de Trusted Committers garante que, se os mantenedores do projeto se afastarem,
+haja um plano para a administração responsável.
+
+## Instâncias Conhecidas
+
+Isso foi experimentado e comprovado como bem-sucedido em:
+
+- Nike
+- PayPal
+- Mercado Libre - adiciona uma seção no arquivo `CONTRIBUTING.md` para informar quem são os Trusted Committers.
+- Robert Bosch GmbH - nós não chamamos o papel de 'Trusted Committer', mas tivemos esse papel no início de nossa jornada InnerSource. Os Trusted Committers eram financiados em 100% do tempo para poderem se concentrar nesse papel.
+
+
+
+## Estado
+
+- Structured
+- Published internally at Nike; drafted via pull-request in June of 2018.
+
+## Autores
+
+- [Fernando Freire]
+
+## Reconhecimento
+
+- [Russell Rutledge]
+- [Loren Sanz]
+- [Noah Cawley]
+- [Jeremy Hicks]
+- [Doron Katz]
+
+[Doron Katz]: https://github.com/doronkatz
+[Russell Rutledge]: https://github.com/rrrutledge
+[Loren Sanz]: https://github.com/mrsanz
+[Jeremy Hicks]: https://github.com/greatestusername
+[Noah Cawley]: https://github.com/utanapishtim
+[praise]: ./praise-participants.md
+[Fernando Freire]: https://github.com/dogonthehorizon
+
+## Histórico de Tradução
+
+- **2022-08-20** - Tradução [Eneri Junior](https://github.com/jrcosta)
+- **2022-08-20** - Tradução [Humberto Zilio](https://github.com/zilio)
diff --git a/translation/pt-br/templates/COMMUNICATION-template.md b/translation/pt-br/templates/COMMUNICATION-template.md
new file mode 100644
index 000000000..e14340d60
--- /dev/null
+++ b/translation/pt-br/templates/COMMUNICATION-template.md
@@ -0,0 +1,73 @@
+# COMMUNICATION.md
+
+***
+Coloque um arquivo `COMMUNICATION.md` individualizado para o projeto em cada repositório. Se a propriedade do repositório do projeto for transferida para outra equipe no futuro, eles precisarão ser capazes de acessar e editar a documentação relacionada ao projeto. Isso inclui a documentação que descreve os processos de comunicação que os usuários devem usar para entrar em contato com a equipe.
+
+**Exclua o parágrafo superior quando esta seção estiver preenchida.**
+
+## Comunicação da Equipe
+
+Canal da equipe no Slack:
+
+Canais Especiais do Slack: (específicos para tópicos e acessíveis a qualquer pessoa que seja um colaborador externo)
+
+Email da Equipe:
+
+## Como Entrar em Contato
+
+Os seguintes tipos de ações podem ser movidos para a seção apropriada e mais podem ser adicionados:
+
+| Ação | (Contato geral da equipe) |
+|----------------------------------|-----------------------------|
+| Método de Contato | (e-mail ou canal no Slack) |
+| Relatório de Bug | |
+| Solicitação de Recurso | |
+| Dúvidasprocesso de contribuição | |
+| Solicitações de Merge após envio | |
+| Adicionar mais aqui... | |
+
+| Situações Especiais: | Ponto de contato direto (Função)|
+|-----------------------------|---------------------------------|
+| Atualizações de Status | |
+| Outro | |
+| Outro | |
+| Adicionar mais aqui... | |
+
+## Papéis e Responsabilidades
+
+Gerentes ou funções e situações específicas para as quais eles devem ser contatados fora do canal da equipe.
+
+(isto é configurado desta maneira para que o documento possa ser facilmente alterado se houver novos membros na equipe)
+
+| Função | Nome | Método de contato preferido |
+|--------|------|-----------------------------|
+| | | |
+| | | |
+| | | |
+
+## Comunicação Externa
+
+| Cenários | Quando os usuários receberão a comunicação | Stakeholders que receberão | Ação - como receber essas comunicações |
+|---------------------------------------------------------------------------------------|---------------------------------------|-------------------------|--------------------------|
+| Mudanças impactantes (por exemplo, alterações na nossa API ou contratos de mensagens) | | | |
+| Interrupções estendidas/planejadas (tempo de inatividade do serviço para atividades de manutenção) | | | |
+| Interrupções inesperadas | | | |
+| Mudanças específicas de tráfego (por exemplo, de equipe para equipe, etc.) | | | |
+| Lançamento de novos recursos | | | |
+| De acordo com as diretrizes do produto | | | |
+| Fim do mês e congelamento de código em toda a empresa | | | |
+| Equipe interna e outras equipes que contribuem para os repositórios do projeto da equipe | | | |
+| Adicionar mais… | | | |
+
+## Contatos de Documentação
+
+Informe como encontrar o proprietário, a parte responsável ou o grupo de pessoas que devem ser contatadas em caso de dúvidas sobre a documentação no repositório.
+
+Descreva esse processo de comunicação.
+
+Por exemplo:
+
+* Se você tiver perguntas sobre uma parte específica da documentação, pode encontrar o membro da equipe responsável pelas informações aqui:
+* Você pode entrar em contato com a parte responsável enviando uma mensagem no canal xyz, enviando uma mensagem direta no chat, por e-mail, etc. A pessoa que certificou pela última vez a documentação é a parte responsável.
+
+***
diff --git a/translation/pt-br/templates/CONTRIBUTING-template.md b/translation/pt-br/templates/CONTRIBUTING-template.md
new file mode 100644
index 000000000..1c8c56c40
--- /dev/null
+++ b/translation/pt-br/templates/CONTRIBUTING-template.md
@@ -0,0 +1,37 @@
+# Contribuindo para ____
+
+## Tipos de contribuições
+
+Forneça informações sobre que tipos de contribuições o seu projeto está procurando aqui. Por exemplo, isso pode incluir relatórios de bugs, ajuda para responder perguntas de usuários, melhorias na documentação, correções de bugs e implementações de novas funcionalidades.
+
+## Relatórios de Bugs
+
+Adicione informações sobre como enviar relatórios de bugs aqui. Isso deve incluir dicas sobre que tipo de informações o projeto precisará para reproduzir e corrigir problemas. Também pode incluir informações sobre configurações incorretas comuns que parecem ser bugs.
+
+Inclua também informações sobre o que os colaboradores podem esperar em termos de tempo para a primeira resposta e o processo após isso.
+
+## Solicitações de features
+
+Adicione informações sobre como enviar solicitações de features aqui. Inclua também informações sobre o que os colaboradores podem esperar em termos de tempo para a primeira resposta e o processo após isso.
+
+## Contribuição de Documentação
+
+Inclua informações sobre as melhores práticas de documentação que o seu projeto segue, bem como como criar documentação, verificações a serem executadas e como enviar as alterações feitas de volta para o projeto.
+
+## Contribuição de Código Fonte
+
+Esta seção deve conter informações sobre
+
+- Como acessar o código fonte do projeto;
+- Layout geral do projeto;
+- Quaisquer requisitos para o ambiente de desenvolvimento;
+- Diretrizes de formatação de código;
+- Como executar o conjunto de testes.
+
+## Como se tornar um Colaborador Confiável
+
+Esta seção deve deixar explícito o processo para se tornar um Colaborador Confiável, caso essa opção esteja aberta para os contribuidores.
+
+## Como indicar Trusted Committers
+
+Esta seção serve como um lembrete para os Trusted Committers existentes e uma explicação para os novos, detalhando como adicionar outras pessoas à equipe anfitriã. Idealmente, essa informação é idêntica para todos os projetos na organização, para que informações centrais possam ser vinculadas a partir daqui.
diff --git a/translation/pt-br/templates/README-template.md b/translation/pt-br/templates/README-template.md
new file mode 100644
index 000000000..53b6e53e3
--- /dev/null
+++ b/translation/pt-br/templates/README-template.md
@@ -0,0 +1,64 @@
+# Insira o nome do seu projeto aqui
+
+## Missão
+
+Esta seção deve conter uma breve descrição (3-5 frases) da missão do seu projeto. O objetivo é declarar sobre o que você planeja trabalhar e ajudar os contribuidores externos a entenderem mais ou menos quais tipos de recursos provavelmente serão bem-vindos para este projeto.
+
+Veja também o [capítulo de declaração de missão](https://producingoss.com/en/producingoss.html#mission-statement) em Producing Open Source Software.
+
+## Primeiros Passos
+
+Esta seção deve conter uma breve documentação escrita para usuários iniciantes sobre como começar a usar o projeto. Além disso, documentação mais detalhada pode ser vinculada a partir daqui.
+
+## Mais Informações
+
+Esta seção pode listar qualquer uma ou todas as seguintes informações:
+
+- Uma lista de recursos, casos de uso que o software aborda.
+- Informações sobre os princípios de design que são usados para resolver compensações.
+- Links para documentação de nível de usuário mais detalhada.
+- Respostas às perguntas frequentes (FAQ), de preferência em um formato que permita vincular a perguntas específicas e suas respostas para referência mais fácil.
+
+## Obtendo Ajuda
+
+Esta seção deve conter uma breve documentação sobre como obter ajuda para o projeto como usuário. Isso pode ser tão simples quanto direcionar os usuários para o rastreador de problemas se este for o método que seu projeto deseja usar para responder a perguntas. Também pode apontar para um canal de chat arquivado e pesquisável, alguma lista de discussão arquivada e pesquisável, ou algum fórum online para usuários.
+
+## Se envolvendo
+
+Esta seção deve incluir informações sobre como entrar em contato com o projeto:
+Tipicamente, isso conterá links para canais de comunicação arquivados, pesquisáveis e linkáveis.
+
+## Quem somos
+
+Este é um bom lugar para dar crédito aos Trusted Committers do projeto.
+
+Também é um bom lugar para incluir informações sobre o que significa ser um Trusted Committer
+para este projeto - embora o ideal seja que todos os projetos em uma organização usem
+a mesma definição que é vinculada apenas a partir daqui. A razão para manter o
+link aqui é para que colegas que não têm ou têm pouca experiência em trabalhar e
+contribuir para projetos InnerSource tenham um link direto de volta para informações em toda a empresa dos projetos tecnológicos necessários para seu trabalho diário.
+
+## Contribuindo
+
+Esta seção deve documentar (ou vincular à documentação) tudo o que um
+contribuidor de primeira viagem precisa saber para começar. Normalmente, nem todos os
+tópicos abaixo serão cobertos. Foque no que difere em seu projeto do
+setup padrão e no que contribuidores anteriores acharam difícil de entender.
+
+- Encontrar o código-fonte.
+- Encontrar uma lista de problemas para os quais seu projeto precisa de ajuda - esses problemas podem ser técnicos e não técnicos. Geralmente você manterá esses problemas em um rastreador de problemas acessível aos contribuidores.
+- Links para documentação adicional, por exemplo, sobre a arquitetura do projeto, convenções gerais de codificação, convenções de teste...
+- Para contribuições técnicas: Fazer alterações, construir o projeto e testar suas alterações.
+- Enviar suas alterações de volta para o projeto.
+
+Idealmente, você também inclui informações sobre como é o processo preferido para alterações
+no projeto: Os contribuidores devem primeiro abrir um problema e enviar uma
+proposta, ou eles podem enviar alterações imediatamente? O que é importante
+para você ao revisar as contribuições?
+
+Além disso, você deve esboçar quaisquer valores de design que deseja seguir no
+projeto. Tornar esses valores explícitos frequentemente ajuda a resolver trade-offs mais rapidamente e
+mais facilmente. Além disso, ajuda a tornar transparentes as alterações em pressupostos anteriormente implícitos.
+
+Com o tempo, você notará que esta seção crescerá substancialmente. Nesse caso,
+considere mover as informações para arquivos separados, como `CONTRIBUTING.md` e `TESTING.md`.