Re-generating ToC for pt-br translations (InnerSourceCommons#607)

* Allow for GHA for gitbook generation to be run manually
* Writing updated toc.md for the pt-br book

.github/workflows/book.yml

@@ -1,6 +1,7 @@
 name: Gitbook Generation
 
 on:
+  workflow_dispatch:
   push:
     branches:
       - main

book/pt-br/toc.md

@@ -27,6 +27,7 @@ Em vez disso, edite toc_template.md
 * [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.
+* [Extensões para Crescimento Sustentável](../../translation/pt-br/patterns/extensions-for-sustainable-growth.md) - Um projeto InnerSource está recebendo um grande número de contribuições, tornando a manutenção difícil. Ao oferecer um mecanismo de extensão fora do projeto principal, os mantenedores possibilitam a expansão das capacidades do projeto com custos mínimos e sobrecarga de manutenção.
 * [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.
@@ -35,9 +36,11 @@ Em vez disso, edite toc_template.md
 * [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.
+* [Processo de Liberação Padrão](../../translation/pt-br/patterns/release-process.md) - As equipes podem hesitar em adotar um projeto InnerSource se não tiverem certeza de sua maturidade. Para abordar isso, notas de lançamento consistentes e artefatos publicados são cruciais. Essas práticas demonstram um compromisso sólido com o projeto, transmitindo confiança e garantindo aos usuários o comprometimento contínuo com software sustentável e bem gerenciado.
 * [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.
+* [Suporte em Grupo](../../translation/pt-br/patterns/group-support.md) - O que acontece se uma equipe ou indivíduo não suporta mais um projeto InnerSource? Mantenha o projeto vivo formando um grupo de indivíduos interessados.
 * [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.