diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 51a75ac34..d18bcba43 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -16,3 +16,7 @@
/book/zh/ @WillemJiang
/translation/pt/ @jrcosta @zilio
/book/pt/ @jrcosta @zilio
+/pattern-categorization/pt-br/ @jrcosta @zilio
+/translation/gl/ @psanxiao
+/book/gl/ @psanxiao
+/pattern-categorization/gl/ @psanxiao
diff --git a/.github/workflows/book.yml b/.github/workflows/book.yml
index 9c6dac81d..b56f538b3 100644
--- a/.github/workflows/book.yml
+++ b/.github/workflows/book.yml
@@ -1,10 +1,11 @@
name: Gitbook Generation
on:
+ workflow_dispatch:
push:
branches:
- main
- pull_request:
+ pull_request_target:
branches:
- main
@@ -14,12 +15,10 @@ jobs:
strategy:
matrix:
- language: [en, ja, zh, pt-br]
+ language: [en, ja, zh, pt-br, gl]
steps:
- uses: actions/checkout@v3
- with:
- ref: ${{ github.head_ref }}
- uses: ruby/setup-ruby@v1
with:
@@ -37,3 +36,4 @@ jobs:
uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: Writing updated toc.md for the ${{ matrix.language }} book
+ branch: ${{ github.head_ref }}
diff --git a/.github/workflows/generate-mindmap.yml b/.github/workflows/generate-mindmap.yml
index 9da560145..cafe00238 100644
--- a/.github/workflows/generate-mindmap.yml
+++ b/.github/workflows/generate-mindmap.yml
@@ -1,6 +1,7 @@
name: Generate Mindmap
on:
+ workflow_dispatch:
push:
branches:
- "main"
@@ -9,6 +10,8 @@ on:
- ".github/workflows/generate-mindmap.yml"
- "pattern-categorization/innersource-program-mind-map.md"
- "pattern-categorization/package.json"
+ - "pattern-categorization/gl/*"
+ - "pattern-categorization/pt-br/*"
defaults:
run:
@@ -17,6 +20,11 @@ defaults:
jobs:
generate-mindmap:
runs-on: ubuntu-latest
+
+ strategy:
+ matrix:
+ folder: [".", "./gl", "./pt-br"]
+
steps:
- uses: actions/checkout@v3
- name: Use Node.js
@@ -28,18 +36,18 @@ jobs:
- name: Install Node.js dependencies
run: npm install
- name: Run Markmap
- run: npx markmap --no-toolbar innersource-program-mind-map.md -o innersource-program-mind-map.html
+ run: npx markmap --no-toolbar ${{ matrix.folder }}/innersource-program-mind-map.md -o ${{ matrix.folder }}/innersource-program-mind-map.html
- name: Screenshot Markmap Website
id: screenshot-generator
uses: swinton/screenshot-website@v1.x
with:
- source: pattern-categorization/innersource-program-mind-map.html
+ source: pattern-categorization/${{ matrix.folder }}/innersource-program-mind-map.html #strange syntax here. seems to not respect the working-directory default either
destination: innersource-program-mind-map.png
full-page: false
- name: Copy Screenshot
- run: cp ${{ steps.screenshot-generator.outputs.path }} .
+ run: cp ${{ steps.screenshot-generator.outputs.path }} ${{ matrix.folder }}
- name: Reduce Screenshot Size (PNG)
- run: npx optipng innersource-program-mind-map.png
+ run: npx optipng ${{ matrix.folder }}/innersource-program-mind-map.png
- name: Commit Changes
uses: stefanzweifel/git-auto-commit-action@v4
with:
diff --git a/.github/workflows/i18n-consistency-checker.yaml b/.github/workflows/i18n-consistency-checker.yaml
index 4b7a5f6b2..e0084b4a2 100644
--- a/.github/workflows/i18n-consistency-checker.yaml
+++ b/.github/workflows/i18n-consistency-checker.yaml
@@ -15,7 +15,7 @@ jobs:
runs-on: ubuntu-latest
strategy:
matrix:
- language: [ja, zh]
+ language: [ja, zh, pt-br, gl]
steps:
- uses: actions/checkout@v3
with:
@@ -24,7 +24,7 @@ jobs:
id: check-consistency
run: |
# Declare the flags
- declare -A flags=( ["ja"]=":jp: Japanese" ["zh"]=":cn: Chinese")
+ declare -A flags=( ["ja"]=":jp: Japanese" ["zh"]=":cn: Chinese" ["pt-br"]=":brazil: Brazilian Portuguese" ["gl"]="Galician")
issue_title="${flags['${{matrix.language}}']}: Content Consistency Issue"
diff --git a/.github/workflows/lint-patterns.yml b/.github/workflows/lint-patterns.yml
index 408619ea7..14d4f2b33 100644
--- a/.github/workflows/lint-patterns.yml
+++ b/.github/workflows/lint-patterns.yml
@@ -1,6 +1,6 @@
# from: https://github.com/marketplace/actions/markdown-linting-action
# To test this locally, switch to the root of the repo and run:
-# markdownlint -r config/lint/pattern-template.js -c config/lint/pattern-template.yml patterns/2-structured/*.md patterns/2-structured/project-setup/*.md patterns/3-validated/*.md
+# markdownlint -r config/lint/pattern-template.js -c config/lint/pattern-template.yml patterns/2-structured/*.md patterns/3-validated/*.md
name: Pattern Syntax Validation
on:
@@ -12,7 +12,6 @@ on:
- ".github/workflows/lint-patterns.yml"
- ".github/lint-pattern-syntax/*"
- "patterns/2-structured/*.md"
- - "patterns/2-structured/project-setup/*.md"
- "patterns/3-validated/*.md"
jobs:
@@ -27,4 +26,4 @@ jobs:
with:
rules: './.github/lint-pattern-syntax/pattern-template.js'
config: './.github/lint-pattern-syntax/pattern-template.yml'
- args: 'patterns/2-structured/*.md patterns/2-structured/project-setup/*.md patterns/3-validated/*.md'
+ args: 'patterns/2-structured/*.md patterns/3-validated/*.md'
diff --git a/.github/workflows/pattern-metrics.yaml b/.github/workflows/pattern-metrics.yaml
index d1750f3f7..4419ab4fc 100644
--- a/.github/workflows/pattern-metrics.yaml
+++ b/.github/workflows/pattern-metrics.yaml
@@ -52,7 +52,7 @@ jobs:
# Store CODEOWNERS_FILTERto GitHub Action environment (not permanent)
echo "CODEOWNERS_FILTER=$CODEOWNERS_FILTER" >> "$GITHUB_ENV"
- - name: Run issue-metrics tool
+ - name: Run issue-metrics tool for issues
uses: github/issue-metrics@v2
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
diff --git a/README.md b/README.md
index a2c6693d8..78d2b902a 100644
--- a/README.md
+++ b/README.md
@@ -5,7 +5,7 @@
# InnerSource Patterns
-
+
This repository contains the InnerSource Patterns collected by the [InnerSource Commons][isc-website]. These patterns are InnerSource best practices codified in a specific format to make it easy to understand, evaluate, and reuse them.
@@ -47,9 +47,9 @@ Our mission
* [Review Committee](patterns/2-structured/review-committee.md) - *The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarise themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.*
* [Service vs. Library](patterns/2-structured/service-vs-library.md) - *Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.*
* [Trusted Committer](patterns/2-structured/trusted-committer.md) - *Many InnerSource projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.*
-* [Standard Base Documentation](patterns/2-structured/project-setup/base-documentation.md) - *New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.*
-* [Issue Tracker Use Cases](patterns/2-structured/project-setup/issue-tracker.md) - *The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.*
-* [Communication Tooling](patterns/2-structured/project-setup/communication-tooling.md) - *The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.*
+* [Standard Base Documentation](patterns/2-structured/base-documentation.md) - *New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.*
+* [Issue Tracker Use Cases](patterns/2-structured/issue-tracker.md) - *The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.*
+* [Communication Tooling](patterns/2-structured/communication-tooling.md) - *The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.*
* [Cross-Team Project Valuation](patterns/2-structured/crossteam-project-valuation.md) - *It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.*
* [Transparent Cross-Team Decision Making using RFCs](patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - *InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.*
* [Start as an Experiment](patterns/2-structured/start-as-experiment.md) - *Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.*
@@ -108,6 +108,7 @@ This is why we keep these patterns at the bottom of the list.
* [Bad Weather For Liftoff](patterns/1-initial/bad-weather-for-liftoff.md)
* [Incentive mechanisms to foster voluntary contribution](patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md)
* [Duplicated Projects](patterns/1-initial/duplicated-projects.md)
+* [Sustainable InnerSource Program](patterns/1-initial/sustainable-innersource-program.md)
## What are InnerSource Patterns?
diff --git a/TRUSTED-COMMITTERS.md b/TRUSTED-COMMITTERS.md
index 1721bc85d..3b1a32f23 100644
--- a/TRUSTED-COMMITTERS.md
+++ b/TRUSTED-COMMITTERS.md
@@ -25,6 +25,7 @@ While they don't take all responsibilities of a Trusted Committer (yet), they do
* Japanese - [@yuhattor](https://github.com/yuhattor)
* Chinese - [@WillemJiang](https://github.com/WillemJiang)
* Brazilian Portuguese - [@jrcosta](https://github.com/jrcosta), [@zilio](https://github.com/zilio)
+* Galician - [@psanxiao](https://github.com/psanxiao)
## Hall of Fame (aka Alumni)
diff --git a/assets/img/gl/CONTRIBUTING-for-contributors.png b/assets/img/gl/CONTRIBUTING-for-contributors.png
new file mode 100644
index 000000000..d0a8c1772
Binary files /dev/null and b/assets/img/gl/CONTRIBUTING-for-contributors.png differ
diff --git a/assets/img/gl/README-for-users.png b/assets/img/gl/README-for-users.png
new file mode 100644
index 000000000..17fd8d155
Binary files /dev/null and b/assets/img/gl/README-for-users.png differ
diff --git a/assets/img/gl/bios-principles.png b/assets/img/gl/bios-principles.png
new file mode 100644
index 000000000..dcd72a807
Binary files /dev/null and b/assets/img/gl/bios-principles.png differ
diff --git a/assets/img/gl/communication-tooling.png b/assets/img/gl/communication-tooling.png
new file mode 100644
index 000000000..8301837c9
Binary files /dev/null and b/assets/img/gl/communication-tooling.png differ
diff --git a/assets/img/gl/core-team.png b/assets/img/gl/core-team.png
new file mode 100644
index 000000000..a272cbb7d
Binary files /dev/null and b/assets/img/gl/core-team.png differ
diff --git a/assets/img/gl/extensions-for-sustainable-growth.png b/assets/img/gl/extensions-for-sustainable-growth.png
new file mode 100644
index 000000000..293910e08
Binary files /dev/null and b/assets/img/gl/extensions-for-sustainable-growth.png differ
diff --git a/assets/img/gl/repository_activity_score.png b/assets/img/gl/repository_activity_score.png
new file mode 100644
index 000000000..280eebe21
Binary files /dev/null and b/assets/img/gl/repository_activity_score.png differ
diff --git a/assets/img/gl/review-committee-sketch.png b/assets/img/gl/review-committee-sketch.png
new file mode 100644
index 000000000..e17e11b2f
Binary files /dev/null and b/assets/img/gl/review-committee-sketch.png differ
diff --git a/assets/img/standard-base-documentation/README.md b/assets/img/standard-base-documentation/README.md
index 22160c45a..7eacaf14d 100644
--- a/assets/img/standard-base-documentation/README.md
+++ b/assets/img/standard-base-documentation/README.md
@@ -1,6 +1,6 @@
# Credits
-The current illustration is a digital remake of this [original visual](/patterns/2-structured/project-setup/assets/base_docs_drawing.png).
+The current illustration is a digital remake of this [original visual](./base_docs_drawing.png).
If you want to edit this illustration, please request access to this [source document](https://docs.google.com/presentation/d/11JOByEO9QXlRLXX5BIv9rjUzPzCKErZzknD1OLcprQQ/edit?usp=sharing).
The humans in the illustration are [bro](https://storyset.com/illustration/coding/bro) and [pana](https://storyset.com/illustration/high-five/pana) from Storyset.
diff --git a/patterns/2-structured/project-setup/assets/base_docs_drawing.png b/assets/img/standard-base-documentation/base_docs_drawing.png
similarity index 100%
rename from patterns/2-structured/project-setup/assets/base_docs_drawing.png
rename to assets/img/standard-base-documentation/base_docs_drawing.png
diff --git a/patterns/2-structured/project-setup/assets/base_docs_drawing.svg b/assets/img/standard-base-documentation/base_docs_drawing.svg
similarity index 100%
rename from patterns/2-structured/project-setup/assets/base_docs_drawing.svg
rename to assets/img/standard-base-documentation/base_docs_drawing.svg
diff --git a/book/en/toc.md b/book/en/toc.md
index 82e952290..4755accc5 100644
--- a/book/en/toc.md
+++ b/book/en/toc.md
@@ -21,7 +21,7 @@ Instead edit toc_template.md
* [30 Day Warranty](../../patterns/2-structured/30-day-warranty.md) - When accepting contributions from outside of your own team, there is a natural aversion to taking responsibility for code not written by the team itself. Through the 30 Day Warranty the contributing team consents to provide bug fixes to the receiving team, which will increase the level of trust between both teams and makes it more likely that contributions get accepted.
* [Common Requirements](../../patterns/2-structured/common-requirements.md) - Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
-* [Communication Tooling](../../patterns/2-structured/project-setup/communication-tooling.md) - The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.
+* [Communication Tooling](../../patterns/2-structured/communication-tooling.md) - The users of an InnerSource project have trouble getting help and getting in touch with the host team. By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.
* [Contracted Contributor](../../patterns/2-structured/contracted-contributor.md) - Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
* [Core Team](../../patterns/2-structured/core-team.md) - Even when an InnerSource project is widely needed, contributions and usage may be hindered because the project is difficult to work with. Establish a core team that is dedicated to take care of the project's fundamental items. Their work enables contributors to add and use the features that provide value to their scenarios.
* [Cross-Team Project Valuation](../../patterns/2-structured/crossteam-project-valuation.md) - It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.
@@ -32,13 +32,13 @@ Instead edit toc_template.md
* [Group Support](../../patterns/2-structured/group-support.md) - What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.
* [InnerSource License](../../patterns/2-structured/innersource-license.md) - Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An InnerSource License provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.
* [InnerSource Portal](../../patterns/2-structured/innersource-portal.md) - Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and InnerSource project owners to attract an outside audience.
-* [Issue Tracker Use Cases](../../patterns/2-structured/project-setup/issue-tracker.md) - The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.
+* [Issue Tracker Use Cases](../../patterns/2-structured/issue-tracker.md) - The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.
* [Maturity Model](../../patterns/2-structured/maturity-model.md) - Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.
* [Praise Participants](../../patterns/2-structured/praise-participants.md) - After an inner source contribution, it's important to thank the contributor for their time and effort. This pattern gives guidance that not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others.
* [Repository Activity Score](../../patterns/2-structured/repository-activity-score.md) - Potential contributors want to find active InnerSource projects in need of their help. By calculating a repository activity score for each project, a ranked list of projects can be created (e.g. on the InnerSource Portal), so that potential contributors can more easily determine which project they want to contribute to.
* [Review Committee](../../patterns/2-structured/review-committee.md) - The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarize themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.
* [Service vs. Library](../../patterns/2-structured/service-vs-library.md) - Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.
-* [Standard Base Documentation](../../patterns/2-structured/project-setup/base-documentation.md) - New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md/COMMUNICATION.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.
+* [Standard Base Documentation](../../patterns/2-structured/base-documentation.md) - New contributors to an InnerSource project have a hard time figuring out who maintains the project, what to work on, and how to contribute. Providing documentation in standard files like README.md/CONTRIBUTING.md/COMMUNICATION.md enables a self service process for new contributors, so that they can find the answers to the most common questions on their own.
* [Standard Release Process](../../patterns/2-structured/release-process.md) - Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.
* [Start as an Experiment](../../patterns/2-structured/start-as-experiment.md) - Start your InnerSource initiative as a time limited experiment to make it easier for managers unfamiliar with InnerSource to endorse and support the initiative.
* [Transparent Cross-Team Decision Making using RFCs](../../patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.
@@ -48,9 +48,9 @@ Instead edit toc_template.md
* [Pattern Template](../../meta/pattern-template.md)
* Extras
- * [README Template](../../patterns/2-structured/project-setup/templates/README-template.md)
- * [CONTRIBUTING Template](../../patterns/2-structured/project-setup/templates/CONTRIBUTING-template.md)
- * [COMMUNICATION Template](../../patterns/2-structured/project-setup/templates/COMMUNICATION-template.md)
+ * [README Template](../../patterns/2-structured/templates/README-template.md)
+ * [CONTRIBUTING Template](../../patterns/2-structured/templates/CONTRIBUTING-template.md)
+ * [COMMUNICATION Template](../../patterns/2-structured/templates/COMMUNICATION-template.md)
* [RFC Template](../../patterns/2-structured/templates/rfc.md)
## Resources
diff --git a/book/en/toc_template.md b/book/en/toc_template.md
index cb7b3b956..85aea6452 100644
--- a/book/en/toc_template.md
+++ b/book/en/toc_template.md
@@ -25,9 +25,9 @@ Instead edit toc_template.md
* [Pattern Template](../../meta/pattern-template.md)
* Extras
- * [README Template](../../patterns/2-structured/project-setup/templates/README-template.md)
- * [CONTRIBUTING Template](../../patterns/2-structured/project-setup/templates/CONTRIBUTING-template.md)
- * [COMMUNICATION Template](../../patterns/2-structured/project-setup/templates/COMMUNICATION-template.md)
+ * [README Template](../../patterns/2-structured/templates/README-template.md)
+ * [CONTRIBUTING Template](../../patterns/2-structured/templates/CONTRIBUTING-template.md)
+ * [COMMUNICATION Template](../../patterns/2-structured/templates/COMMUNICATION-template.md)
* [RFC Template](../../patterns/2-structured/templates/rfc.md)
## Resources
diff --git a/book/gl/.gitbook.yaml b/book/gl/.gitbook.yaml
new file mode 100644
index 000000000..fb44a6a2c
--- /dev/null
+++ b/book/gl/.gitbook.yaml
@@ -0,0 +1,5 @@
+root : ./
+
+structure:
+ readme: introduction.md
+ summary: toc.md
diff --git a/book/gl/contribute.md b/book/gl/contribute.md
new file mode 100644
index 000000000..05c176a1f
--- /dev/null
+++ b/book/gl/contribute.md
@@ -0,0 +1,29 @@
+# Contribúa a este libro
+
+Quere mellorar este libro? Estupendo!
+
+O libro Modelos InnerSource é un [proxecto de software libre](https://github.com/InnerSourceCommons/InnerSourcePatterns) en si mesmo e dá a benvida a calquera forma de contribución, por pequena que sexa.
+
+Non importa se desexa axudarnos a corrixir erratas, a mellorar o deseño ou a contribuír con modelos completamente novos baseados nas experiencias InnerSource que realizou no seu lugar de traballo. Calquera aportación é benvida.
+
+Se nunca antes realizou unha contribución a un proxecto de software libre, saiba que a comunidade de Modelos InnerSource é un grupo de persoas amigables e, polo tanto, é un lugar seguro para tentalo.
+
+## Antes de comezar
+
+As fontes do Modelo InnerSource e este mesmo libro atópanse nun repositorio de GitHub. Polo tanto, necesitará unha conta de usuario/a de GitHub para realizar modificacións e suxestións a este libro. Se aínda non ten unha, diríxase a [github.com](https://github.com/) e cree unha conta gratuíta.
+
+## Diferentes xeitos de contribución
+
+Velaquí algunhas formas nas que pode contribuír:
+
+1. Corrección ortotipográficas, de formato ou doutros erros que atope neste libro.
+2. Mellora do contido dun modelo existente (por exemplo, pode engadir unha breve descrición de como está a empregar vostede o modelo no apartado *Exemplos coñecidos*).
+3. Aportación dun novo modelo no que describa como superou os desafíos relacionados con InnerSource na súa organización.
+
+Para (1) e (2), basta con premer na ligazón **Editar en GitHub** que observa na parte superior de cada páxina deste libro para acceder directamente ao arquivo respectivo do noso repositorio de GitHub, onde pode suxerir os cambios que considere.
+
+Para (3) necesita clonar o repositorio [InnerSourcePatterns](https://github.com/InnerSourceCommons/InnerSourcePatterns) e engadir un novo arquivo co modelo suxerido. Para facer tales importantes contribucións a este libro, revise a sección de [CONTRIBUTING.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/CONTRIBUTING.md) e tamén o noso [Manual de contribución](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/meta/contributor-handbook.md).
+
+## Licenzas das Contribucións
+
+O contido deste repositorio ten licenza [CC-BY-SA-4.0](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/LICENSE.txt). Se contribúe ao mesmo, estanos a outorgar (e, por ende, a tódolos/as demais) o dereito a empregar a súa contribución de acordo coa devandita licenza.
diff --git a/book/gl/explore-patterns.md b/book/gl/explore-patterns.md
new file mode 100644
index 000000000..210f4c65e
--- /dev/null
+++ b/book/gl/explore-patterns.md
@@ -0,0 +1,19 @@
+# Explore os modelos
+
+A comunidade InnerSource Commons aporta cada vez máis modelos a este libro; o que é incrible!
+
+Pero, como facilitar que os/as lectores/as descubran os modelos que poden axudalos/as na súa situación particular?
+
+Para isto proporcionamos este mapa conceptual, que **clasifica os modelos en función das diferentes fases dun programa InnerSource** e dos desafíos que poden xurdir nas respectivas fases.
+
+![Mapa conceptual dos modelos InnerSource](../../pattern-categorization/gl/innersource-program-mind-map.png)
+
+## Mellore este mapa conceptual
+
+Se vostede detecta algo neste mapa conceptual que lle resulta incorrecto, pode [abrir unha incidencia](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues) na que describa o problema xunto co arranxo que se debería levar a cabo.
+
+Ademais, se ten outras ideas para dar a coñecer estes modelos ou desexa mellorar este mapa conceptual, revise a documentación do noso enfoque de [Categorización de modelos](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/pattern-categorization/README.md) e verifique como [contribuír a este libro](./contribute.md).
+
+## Referencias
+
+A idea de categorizar modelos como este baséase, parcialmente, na descrición en [*Thoughts on an InnerSource Pattern Language*](https://drive.google.com/file/d/13AY8glCOdpLOVuz7cVD6QOB8d2xbHCS1/view) [Reflexións arredor do modelo InnerSource] de Tim Yao, Bob Hanmer e Padma Sudarsan (2018). Para obter máis detalles, pode consultar a diapositiva 15 da presentación.
diff --git a/book/gl/fondos-publicos.png b/book/gl/fondos-publicos.png
new file mode 100644
index 000000000..8e65d80ad
Binary files /dev/null and b/book/gl/fondos-publicos.png differ
diff --git a/book/gl/innersource-patterns-book-cover.png b/book/gl/innersource-patterns-book-cover.png
new file mode 100644
index 000000000..eb3596857
Binary files /dev/null and b/book/gl/innersource-patterns-book-cover.png differ
diff --git a/book/gl/introduction.md b/book/gl/introduction.md
new file mode 100644
index 000000000..570924641
--- /dev/null
+++ b/book/gl/introduction.md
@@ -0,0 +1,77 @@
+# Introdución
+
+![Modelos InnerSource](innersource-patterns-book-cover.png)
+
+{% hint style="info" %}
+Vostede está a ler unha versión preliminar do libro *Modelos InnerSource: Guía das mellores prácticas por casos: Fáciles de entender, avaliar e aplicar*, polo que é posible que algunhas ligazóns non funcionen, ou atope algún erro. Pode axudarnos a corrixilos e así poder ofrecer o mellor libro posible, se escolle facer [contribucións](contribute.md) a este libro.
+{% endhint %}
+
+Benvido ao libro **Modelos de InnerSource**.
+
+Este libro contén as mellores prácticas de InnerSource debulladas nun formato pensado especificamente para que sexan sinxelas de comprender, de avaliar e de aplicar no seu contexto. Referímonos a este tipo de formato como **modelo**.
+
+[InnerSource Commons](http://innersourcecommons.org) recompilou estes modelos ao longo de varios anos e publicou os máis maduros neste libro, no que os membros da comunidade revisitan cada modelo a partir de, polo menos, un exemplo de uso coñecido.
+
+Nesta introdución explicamos [que é InnerSource](#que-é-innersource), [que é un modelo](#que-son-os-modelos-innersource) e [como empregar eses modelos](#como-pode-empregar-os-modelos-innersource) na súa organización.
+
+Se xa está a empregar InnerSource na súa empresa e quere contribuír aportando experiencias a este libro, encantaríanos [recibir as súas contribucións](./contribute.md)
+
+## Que é InnerSource?
+
+Definimos InnerSource como:
+
+> O uso de principios e prácticas de software libre para o desenvolvemento de software dentro dos límites dunha organización.
+
+InnerSource toma as leccións aprendidas do desenvolvemento de software libre e aplícaas á forma en que as empresas desenvolven software de maneira interna. Cando os/as desenvolvedores/as xa estaban afeitos a traballar en software libre de xeito universal, xurdiu un forte desexo de volver a introducir esas prácticas dentro do *firewall* e de aplicalas ao software que as empresas poden amosarse reticentes a lanzar.
+
+Para as empresas que crean na súa meirande parte software de código pechado, InnerSource pode ser unha boa ferramenta coa que eliminar os silos, fomentar e escalar a colaboración interna, acelerar a incorporación de novos/as enxeñeiros/as e identificar as oportunidades para contribuír ao mundo do software libre.
+
+## Que son os modelos InnerSource?
+
+Os modelos son unha forma de describir unha solución probada e repetible para un problema nun contexto concreto. Os modelos empregan un formato sinxelo co que, na propia aplicación da solución, axudan a comprender as limitacións do problema, os aspectos que mellorar e o contexto resultante; é dicir, a nova situación xerada trala aplicación desta solución.
+
+Os modelos poden proporcionar aos/ás participantes de InnerSource Commons un medio polo que compartir información de xeito conciso, para mellorar a práctica InnerSource. Algunhas das seccións principais destes modelos son: Título, Problema, Contexto, Aspectos que mellorar e Solucións.
+
+* [Vídeos de Youtube sobre que son os modelos](http://bit.ly/innersource_patterns_videos): Visualice esta serie de vídeos de YouTube de entre 2 e 5 minutos, na que se explican os modelos InnerSource.
+* [Webinario sobre os modelos](https://youtu.be/i-0IVhfRVFU): O 16 de marzo de 2017 levouse a cabo este webinario no que se debateu en vivo un modelo donut (minuto 24:30). É un exemplo do proceso de revisión que seguimos. Tamén pode consultar o [webinario sobre modelos InnerSource de O’Reilly do 1 de xuño de 2017](http://www.oreilly.com/pub/e/3884).
+* [Prototipo de modelo](../../translation/gl/templates/pattern-template.md): Observe a estrutura dun modelo InnerSource para ter unha idea do que acontece nun modelo novo.
+* [Introdución aos modelos InnerSource (presentación en inglés do cumio de outono de 2016)](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc), de Tim Yao e Padma Sudarsan (PDF). Expón os antecedentes e algúns exemplos de modelos, e permitiralle comprender en detalle os motivos polos que facer uso dos nosos modelos e como facelo. Consulte tamén a [Introdución aos modelos InnerSource (do cume de outono de 2017)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) de Tim Yao e Bob Hanmer (PDF).
+
+## Como pode empregar os modelos InnerSource?
+
+Os modelos deben empregarse coidadosamente. Non poden aplicarse de xeito indiscriminado. Na maioría dos casos, vostede necesitará adaptar unha solución á súa situación particular; mais a información proporcionada no modelo, que define o contexto (os límites inamovibles) e os aspectos que mellorar (os límites que poden cambiar e equilibrarse entre si), debería servir de axuda para poñela en práctica. Teña en conta que tamén deberá determinar se existen limitacións adicionais (o contexto e os aspectos que queira mellorar a empresa) que se apliquen á súa compañía/organización en particular e deban engadirse ao modelo (como se fose unha especie de filtro). Estas limitacións adicionais poden chegar a requirir pasos adicionais para chegar a unha solución.
+
+O impreso do modelo é útil para describir solucións probadas, pero tamén se pode empregar para xerar ideas sobre novas solucións onde aínda non se estableceron modelos. Isto débese a que a anatomía dun modelo proporciona un marco de traballo para pensar sobre un problema dun xeito estruturado. Vostede tamén pode crear un *modelo de donut* (completando os campos de problema, contexto, aspectos que mellorar e contexto resultante; pero deixando a solución en branco) como unha forma de pedir axuda á comunidade InnerSource Commons (para encontrar unha solución comprobada ou para aportar ideas sobre que cousas probar).
+
+## Como contribuír?
+
+Consulte: [Como contribuír a este libro](./contribute.md).
+
+## Créditos
+
+Este libro é o resultado de moitos anos de traballo de incontables [contribuidores/as de software libre](https://github.com/InnerSourceCommons/InnerSourcePatterns/graphs/contributors) de todo o mundo. A súa vontade de compartir abertamente os desafíos que afrontaron as súas empresas e o xeito no que InnerSource lles axudou a abordar eses desafíos, fan deste libro un recurso valioso para calquera que inicie o seu percorrido InnerSource.
+
+Queremos facer unha mención especial ao InnerSource Patterns Working Group, que nutriu a calidade dos modelos e axudou a outros/as a facer contribucións. E tamén compilou a selección de modelos dispoñibles neste libro.
+
+A imaxe do título do libro foi creada por [Sebastian Spier](https://spier.hu) e adaptada dunha imaxe de [Tony Hisgett - Alhambra 6](https://www.flickr.com/photos/hisgett/29345405788/), dispoñible baixo a licenza [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/).
+
+**Moitas grazas a tódolos/as contribuidores/as! E feliz día InnerSource. :)**
+
+## Licenza
+
+![Licenza Creative Commons](https://i.creativecommons.org/l/by-sa/4.0/88x31.png)
+
+Modelos InnerSource de [InnerSourceCommons.org](http://innersourcecommons.org) ten unha licenza [Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/).
+
+## Sobre a tradución
+
+Esta tradución á lingua galega foi elaborada pola [AMTEGA](https://amtega.xunta.gal) (Xunta de Galicia). Cofinanciada a través de Fondos Europeos. Esta iniciativa foi coordinada pola [Oficina de Software Libre](https://amtega.xunta.gal/gl/software-libre).
+
+Distribúese baixo licenza Creative Commons Atribución - Compartir Igual 4.0 Internacional (CC BY-SA 4.0). Pode consultar as condicións desta licenza [aquí](https://creativecommons.org/licenses/by-sa/4.0/deed.gl).
+
+**Autoras da tradución:**
+
+* Leticia Gómez Cadahía
+* María Lucía González Castro
+
+![Fondos Públicos](fondos-publicos.png)
diff --git a/book/gl/toc.md b/book/gl/toc.md
new file mode 100644
index 000000000..588d8c369
--- /dev/null
+++ b/book/gl/toc.md
@@ -0,0 +1,56 @@
+# Índice
+
+
+
+
+
+* [Introdución](./introduction.md)
+* [Índice](./toc.md)
+* [Explore os modelos](./explore-patterns.md)
+* [Contribúa a este libro](./contribute.md)
+
+![Mapa conceptual dos modelos InnerSource](../../pattern-categorization/gl/innersource-program-mind-map.png)
+
+## Modelos
+
+* [Agradecemento aos/ás participantes](../../translation/gl/patterns/praise-participants.md) - Tras unha contribución a un proxecto InnerSource, é importante agradecer ao/á colaborador/a polo seu tempo e esforzo. Este modelo brinda unha orientación que non só recoñece dun xeito eficaz a súa contribución, senón que tamén xera un maior compromiso deste/a e doutros/as contribuidores/as.
+* [Casos de uso cun sistema de seguimento de incidencias](../../translation/gl/patterns/issue-tracker.md) - O host team de InnerSource non logra ter transparencia nos plans nin no progreso, e tampouco no contexto para os cambios. Isto resólvese aumentando os casos de uso co sistema de seguimento de incidencias do proxecto para que tamén favoreza o intercambio de ideas, o debate sobre estas e o deseño de funcionalidades.
+* [Comece como un experimento](../../translation/gl/patterns/start-as-experiment.md) - Comece a súa iniciativa InnerSource como un experimento de tempo limitado para facilitar que o persoal directivo, que non estea familiarizado con InnerSource, secunde e apoie a iniciativa.
+* [Comité de revisión](../../translation/gl/patterns/review-committee.md) - O modelo de traballo InnerSource é un afastamento radical dos enfoques máis tradicionais, tanto para os/as desenvolvedores/as como para os/as seus/súas superiores/as. Ao establecer un comité de revisión como interface entre a iniciativa InnerSource e tódolos altos cargos das áreas empresariais que participan nela, é máis probable que estes últimos se familiaricen coa iniciativa e a apoien; xa que lles brinda un certo nivel de supervisión e control, sen fomentar a microxestión.
+* [Contracted contributor](../../translation/gl/patterns/contracted-contributor.md) - Os/As socios/as que desexen contribuír a InnerSource son disuadidos/as de facelo polos/as seus/súas superiores/as. Os contratos e acordos formais son un alivio.
+* [Core team](../../translation/gl/patterns/core-team.md) - Incluso cando se necesita moito un proxecto InnerSource, as colaboracións e o seu uso poden verse obstaculizados porque é difícil traballar co proxecto. Estableza un core team que se dedique a coidar dos elementos fundamentais do proxecto. O traballo do core team permite aos/ás contribuidores/as engadir e empregar as funcionalidades que aportan valor aos seus escenarios.
+* [Cualificación da actividade do repositorio](../../translation/gl/patterns/repository-activity-score.md) - Os/As potenciais contribuidores/as queren atopar proxectos InnerSource activos que precisen da súa participación. Ao calcular a cualificación da actividade do repositorio para cada proxecto, pódese crear unha listaxe clasificada de proxectos (por exemplo, no portal InnerSource) para que os/as posibles contribuidores/as poidan determinar dun xeito máis doado en que proxecto desexan colaborar.
+* [Documentación base estándar](../../translation/gl/patterns/base-documentation.md) - Os/As novos/as contribuidores/as dun proxecto InnerSource teñen dificultades para determinar quen mantén o proxecto, en que traballar e como contribuír. Ao proporcionar documentación en arquivos estándar como README.md/CONTRIBUTING.md permítese un proceso de autoservizo para os/as novos/as contribuidores/as, de xeito que poidan atopar por si mesmos/as as respostas ás preguntas máis comúns.
+* [Documente os seus principios reitores](../../translation/gl/patterns/document-your-guiding-principles.md) - A explicación habitual de InnerSource baseada en «aplicar as mellores prácticas de software libre dentro dunha organización» non funciona correctamente coas persoas que carecen de experiencia con software libre. Como solución, os principios InnerSource máis importantes documéntanse e publícanse de maneira aberta.
+* [Extensións para o crecemento sostible](../../translation/gl/patterns/extensions-for-sustainable-growth.md) - Un proxecto InnerSource está a recibir demasiadas contribucións, o que dificulta o seu mantemento. Os/As responsables ofrecen un mecanismo de extensión fóra do proxecto principal, que permite escalar as capacidades do proxecto cun custo e gastos xerais de mantemento mínimos.
+* [Ferramentas de comunicación](../../translation/gl/patterns/communication-tooling.md) - Os/As usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e poñerse en contacto co host team. Mediante o uso sistemático de ferramentas de comunicación asíncrona, os debates serán visibles e permanecerán arquivados e accesibles; o que se traduce nunha mellora do nivel de asistencia aos/ás usuarios/as.
+* [Garantía de 30 días](../../translation/gl/patterns/30-day-warranty.md) - Cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos equipos e fará que sexa máis probable que se acepten as contribucións.
+* [Gig marketplace](../../translation/gl/patterns/gig-marketplace.md) - Establécese un marketplace mediante a creacion dunha intranet que enumere as necesidades específicas do proxecto InnerSource como «Gigs», con requisitos explícitos de tempo e habilidades. Isto permitirá ao personal directivo comprender mellor o compromiso no tempo e os beneficios profesionais dos/as seus/súas traballadores/as, o que aumentará a probabilidade de obter a aprobación para realizar contribucións InnerSource.
+* [Licenza InnerSource](../../translation/gl/patterns/innersource-license.md) - Dúas entidades xurídicas que pertencen á mesma organización queren compartir o código fonte do software entre elas, mais preocúpanlles as implicacións en termos de responsabilidades legais ou de contabilidade entre as empresas.
+* [Líder da comunidade experto/a en InnerSource](../../translation/gl/patterns/dedicated-community-leader.md) - Seleccione persoas con habilidades técnicas e de comunicación para liderar as comunidades e garantir o éxito no inicio dunha iniciativa InnerSource
+* [Modelo de madurez](../../translation/gl/patterns/maturity-model.md) - Os equipos comezaron a adoptar InnerSource e a práctica estase estendendo a varios departamentos. Con todo, a comprensión do que constitúe un proxecto InnerSource varía. A solución consiste en proporcionar un modelo de madurez que permita aos equipos realizar unha autoavaliación e descubrir modelos e prácticas que aínda non coñecían.
+* [Portal InnerSource](../../translation/gl/patterns/innersource-portal.md) - Os/As contribuidores/as potenciais non poden descubrir dun xeito sinxelo os proxectos InnerSource nos que están interesados/as. Ao crear unha intranet que indexe toda a información dispoñible do proxecto InnerSource, permítese que os/as contribuidores/as coñezan os proxectos que lles poderían interesar; do mesmo xeito que lles serve aos/ás project owners de InnerSource para atraer a un público externo.
+* [Requisitos comúns](../../translation/gl/patterns/common-requirements.md) - O código común dun repositorio compartido non satisfai as necesidades de tódolos equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización.
+* [Servizo vs. libraría](../../translation/gl/patterns/service-vs-library.md) - Os equipos DevOps poden ser reticentes a traballar máis alá dos límites do equipo, en bases de código comúns; posto que non está definido quen sería a persoa responsable de responder ante unha situación de inactividade do servizo. Con frecuencia, a solución pode ser implantar o mesmo servizo en contextos independentes con cadeas de escalada separadas, en caso de caída do servizo ou de factorización dunha gran cantidade de código compartido nunha libraría na que se poidan facer colaboracións.
+* [Soporte grupal](../../translation/gl/patterns/group-support.md) - Que acontece se un equipo ou unha persoa abandona un proxecto InnerSource? Para manter vivo o proxecto fórmase un novo grupo de colaboradores/as interesados/as.
+* [Toma de decisións transparente entre equipos mediante RFC](../../translation/gl/patterns/transparent-cross-team-decision-making-using-rfcs.md) - Os proxectos InnerSource que desexan lograr un alto índice de participación e tomar as mellores decisións posibles para tódalas persoas involucradas, necesitan atopar formas de crear sistemas participativos durante todo o ciclo de vida do software. A publicación de documentos internos con peticións de comentarios (RFC) permite manter debates desde o comezo do proceso de deseño. Tamén aumenta as posibilidades de idear solucións cun alto grao de compromiso por parte de tódalas partes implicadas.
+* [Trusted commiter](../../translation/gl/patterns/trusted-committer.md) - Moitos proxectos InnerSource recibirán valoracións constantemente ou requirirán a posta en marcha de novas funcionalidades e a corrección de erros por parte dos/as contribuidores/as. Nestas situacións, as persoas encargadas do mantemento do proxecto buscan formas de recoñecer e recompensar o traballo do/a contribuidor/a máis alá das contribucións individuais.
+* [Valoración de proxectos entre equipos](../../translation/gl/patterns/crossteam-project-valuation.md) - É difícil convencer acerca do valor dos proxectos InnerSource desenvolvidos entre equipos que non teñen un impacto directo nos ingresos da empresa. Velaquí unha forma de representar o seu proxecto baseada en datos, que articula o seu valor e amplifícao.
+
+## Apéndice
+
+- [Prototipo de modelo](../../translation/gl/templates/pattern-template.md)
+- Extras
+ - [Prototipo README](../../translation/gl/templates/README-template.md)
+ - [Prototipo CONTRIBUTING](../../translation/gl/templates/CONTRIBUTING-template.md)
+
+## Recursos
+
+- [O libro en GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
+- [InnerSource Commons](http://innersourcecommons.org)
diff --git a/book/gl/toc_template.md b/book/gl/toc_template.md
new file mode 100644
index 000000000..fa07ab7a2
--- /dev/null
+++ b/book/gl/toc_template.md
@@ -0,0 +1,34 @@
+# Índice
+
+
+
+
+
+* [Introdución](./introduction.md)
+* [Índice](./toc.md)
+* [Explore os modelos](./explore-patterns.md)
+* [Contribúa a este libro](./contribute.md)
+
+![Mapa conceptual dos modelos InnerSource](../../pattern-categorization/gl/innersource-program-mind-map.png)
+
+## Modelos
+
+<>
+
+## Apéndice
+
+- [Prototipo de modelo](../../translation/gl/templates/pattern-template.md)
+- Extras
+ - [Prototipo README](../../translation/gl/templates/README-template.md)
+ - [Prototipo CONTRIBUTING](../../translation/gl/templates/CONTRIBUTING-template.md)
+
+## Recursos
+
+- [O libro en GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
+- [InnerSource Commons](http://innersourcecommons.org)
diff --git a/book/pt-br/explore-patterns.md b/book/pt-br/explore-patterns.md
index aa1cdb7b0..8caf04f88 100644
--- a/book/pt-br/explore-patterns.md
+++ b/book/pt-br/explore-patterns.md
@@ -6,7 +6,7 @@ Agora, como tornar mais fácil para os leitores descobrirem os padrões que pode
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.
-![Mapa Mental dos Padrões InnerSource](../../pattern-categorization/innersource-program-mind-map.png)
+![Mapa Mental dos Padrões InnerSource](../../pattern-categorization/pt-br/innersource-program-mind-map.png)
## Melhore este Mapa Mental
diff --git a/book/pt-br/toc.md b/book/pt-br/toc.md
index b068430e4..429a3e78c 100644
--- a/book/pt-br/toc.md
+++ b/book/pt-br/toc.md
@@ -15,7 +15,7 @@ Em vez disso, edite toc_template.md
* [Explorar Padrões](./explore-patterns.md)
* [Contribuir para Este Livro](./contribute.md)
-![Mapa Mental dos Padrões InnerSource](../../pattern-categorization/innersource-program-mind-map.png)
+![Mapa Mental dos Padrões InnerSource](../../pattern-categorization/pt-br/innersource-program-mind-map.png)
## Padrões
@@ -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.
diff --git a/book/pt-br/toc_template.md b/book/pt-br/toc_template.md
index b4164ecce..c73a0a57d 100644
--- a/book/pt-br/toc_template.md
+++ b/book/pt-br/toc_template.md
@@ -15,7 +15,7 @@ Em vez disso, edite toc_template.md
* [Explorar Padrões](./explore-patterns.md)
* [Contribuir para Este Livro](./contribute.md)
-![Mapa Mental dos Padrões InnerSource](../../pattern-categorization/innersource-program-mind-map.png)
+![Mapa Mental dos Padrões InnerSource](../../pattern-categorization/pt-br/innersource-program-mind-map.png)
## Padrões
diff --git a/book/scripts/generate_toc.rb b/book/scripts/generate_toc.rb
index 07a51f590..3a42b7088 100644
--- a/book/scripts/generate_toc.rb
+++ b/book/scripts/generate_toc.rb
@@ -77,7 +77,7 @@ def generate_patterns_overview(patterns)
if (BOOK_LANGUAGE == "en")
TOC_TEMPLATE_FILE = "../en/toc_template.md"
TOC_FILE = "../en/toc.md"
- PATTERNS = Dir["../../patterns/2-structured/*.md","../../patterns/2-structured/project-setup/*.md", "../../patterns/3-validated/*.md"]
+ PATTERNS = Dir["../../patterns/2-structured/*.md", "../../patterns/3-validated/*.md"]
else
TOC_TEMPLATE_FILE = "../#{BOOK_LANGUAGE}/toc_template.md"
TOC_FILE = "../#{BOOK_LANGUAGE}/toc.md"
diff --git a/meta/boardreports/2023-11.md b/meta/boardreports/2023-11.md
new file mode 100644
index 000000000..7a4bc88d4
--- /dev/null
+++ b/meta/boardreports/2023-11.md
@@ -0,0 +1,62 @@
+# InnerSource Patterns WG - Report for Board Meeting 2023-11
+
+## Meta
+
+* Reporting Period: 2023-08..2023-10
+* [merged PRs](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls?q=is%3Apr+closed%3A2023-08..2023-10+is%3Amerged)
+* [opened issues](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues?q=is%3Aissue+created%3A2023-08..2023-10+is%3Aopen)
+
+## Engagement
+
+The [patterns book][] is the way InnerSource practices are captured and shared. Recent web analytics:
+
+* total traffic on the patterns book (tracking_id: `G-QL1S8MW5D9`)
+ * 24,920 views total (previous report was 19,704 views)
+ * 2,230 users (11.17 views/users)
+* Most popular patterns:
+ * InnerSource Portal
+ * 30 Day Warranty
+ * Core Team
+ * Maturity Model
+ * Common Requirements
+* traffic for translations:
+ * Japanese - 1,733 views (previous was 1,596)
+ * Chinese - 524 views
+ * Brazilian Portuguese - 1,001 views
+ * Galician - (in next report)
+
+## Changes
+
+Changes are contributed via the [InnerSourcePatterns][] repository:
+
+* new pattern [Standard Release Process](https://github.com/InnerSourceCommons/InnerSourcePatterns/releases/tag/v1.6) - thank you **@dgrizzanti**
+* translation to [Brazilian Portuguese](https://github.com/InnerSourceCommons/InnerSourcePatterns/releases/tag/v1.7) - Thanks to the very awesome **@jrcosta @zilio @DanielleAlmeida** that made this happen.
+* additions of Known Instances (applications of our patterns in the wild)
+ * ADI to innersource-customer-interview-questions.md (initial pattern)
+ * GitHub to [Standard Release Process](https://patterns.innersourcecommons.org/p/release-process)
+* experimenting with various tools to understand the contribution patterns of our community better. e.g. see [these stats](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/625) - shout outs to **@zkoppert** not only for building these tools but also for helping us to integrate them into our repo
+* added a **welcome bot** to our repo, that greats new contributors and points them to helpful info about our contribution process - see [this example](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/573)
+* by using gitbook's "monorepo approach", we are now able to deploying multiple translations in parallel via gitbook a lot easier
+* added a new `COMMUNICATION-template.md` to streamline the communication to the **Standard Base Documentation** pattern. - thank you **@kschueths**
+
+## Things to come
+
+* Toying with the idea to add [Adopters pages](https://innersourcecommons.gitbook.io/innersource-patterns-staging/v/adopters-test/adopters/adopters) to our book. Goal: showcase the organizations and the patterns they use more prominently in our book. Looking for feedback! More [details here](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/623).
+* Galician translation (released in 11/2023 therefore not part of this report yet)
+* hoping to integrate further PRs that were contributed some time back but we did not have time to review them properly (or the communication stopped somewhere)
+ * pattern proposal [Feature Owner](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/573) by Manoj Gawande (@magawande) from Fidelty (part of FINOS?) - new contributor!
+ * proposal to add a [Code of Conduct template](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/556) to the **Standard Base Documentation** pattern - by Jose Roman Martin Gil (@rmarting) from Red Hat - new contributor?
+
+## Trusted Committers (Community)
+
+* Last [Trusted Committer][] added was [@yuhattor](https://github.com/yuhattor) (added 2022-07-21)
+* Trusted Committer candidates in the pipeline: No
+* However fuelled by the translation process we have a couple of people that are taking ownership of keeping the translations in sync with the original patterns. Some of these [translation leads](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/TRUSTED-COMMITTERS.md#translation-leads) might turn into Trusted Committers in the future.
+
+## Next Goals
+
+Same as previous Board report.
+
+[patterns book]: https://patterns.innersourcecommons.org/
+[InnerSourcePatterns]: https://github.com/InnerSourceCommons/InnerSourcePatterns/
+[Trusted Committer]: https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/TRUSTED-COMMITTERS.md
diff --git a/meta/scripts/find_upgradeable_patterns.rb b/meta/scripts/find_upgradeable_patterns.rb
index b80bde4fb..2ac5710a6 100644
--- a/meta/scripts/find_upgradeable_patterns.rb
+++ b/meta/scripts/find_upgradeable_patterns.rb
@@ -76,7 +76,7 @@ def collect_section_nodes(file, section_title)
puts "\n"
puts "## Structured => Validated"
puts "## 2-Structured patterns primed for upgrade to 3-Validated (based on Known Instances only)"
-l2_patterns = Dir["../../patterns/2-structured/*.md", "../../patterns/2-structured/project-setup/*.md"]
+l2_patterns = Dir["../../patterns/2-structured/*.md"]
l2_patterns.each do |file|
known_instances_count = count_known_instances(file)
diff --git a/pattern-categorization/README.md b/pattern-categorization/README.md
index 1dbf14db9..6c80d1f5c 100644
--- a/pattern-categorization/README.md
+++ b/pattern-categorization/README.md
@@ -35,8 +35,15 @@ To test your changes locally, you can also generate the mind map yourself like t
We are using `node 12.x` at the moment.
```
+# install the markmap CLI
npm install -g markmap-cli
-npx markmap --no-toolbar innersource-program-mind-map.md
+
+# then generate the mindmap (it will open in your browser automatically)
+npx markmap --no-toolbar innersource-program-mind-map.md -o innersource-program-mind-map.html
+
+# to generate the mindmap for a different language, run the script on the files in the respetive subfolder.
+# e.g. for Galician (`gl`)
+npx markmap --no-toolbar gl/innersource-program-mind-map.md -o gl/innersource-program-mind-map.html
```
## Future Ideas for Categorization
diff --git a/pattern-categorization/gl/innersource-program-mind-map.html b/pattern-categorization/gl/innersource-program-mind-map.html
new file mode 100644
index 000000000..a4d077149
--- /dev/null
+++ b/pattern-categorization/gl/innersource-program-mind-map.html
@@ -0,0 +1,28 @@
+
+
+
+
+
+
+Markmap
+
+
+
+
+
+
+
+
diff --git a/pattern-categorization/gl/innersource-program-mind-map.md b/pattern-categorization/gl/innersource-program-mind-map.md
new file mode 100644
index 000000000..5497676b4
--- /dev/null
+++ b/pattern-categorization/gl/innersource-program-mind-map.md
@@ -0,0 +1,131 @@
+# [Programa InnerSource](https://patterns.innersourcecommons.org/toc)
+
+## Comezo
+
+### Configuración do programa
+
+#### O persoal directivo dubida se apostar por InnerSource
+
+##### [Comezar como un experimento](https://patterns.innersourcecommons.org/p/start-as-experiment)
+
+#### O crecemento lento da comunidade é unha rémora para InnerSource
+
+##### [Líder da comunidade experto en InnerSource](https://patterns.innersourcecommons.org/p/dedicated-community-leader)
+
+#### Os principios InnerSource non son intuitivos para todos
+
+##### [Documente os seus principios reitores](https://patterns.innersourcecommons.org/p/document-your-guiding-principles)
+
+### Organización do proxecto
+
+#### É difícil avaliar rapidamente un proxecto
+
+##### [Documentación base estándar](https://patterns.innersourcecommons.org/p/base-documentation)
+
+#### A comunicación ad-hoc obstaculiza o crecemento do proxecto
+
+##### [Ferramentas de comunicación](https://patterns.innersourcecommons.org/p/communication-tooling)
+
+#### A folla de ruta e dirección do proxecto son pouco transparentes
+
+##### [Casos de uso cun sistema de seguimento de incidencias](https://patterns.innersourcecommons.org/p/issue-tracker)
+
+## Aplicación
+
+### Desafíos da valoración
+
+#### Como medir o valor dun proxecto empresarial
+
+##### [Valoración de proxectos entre equipos](https://patterns.innersourcecommons.org/p/crossteam-project-valuation)
+
+### Desafíos culturais
+
+#### Esforzo non recoñecido
+
+##### [Agradecemento aos participantes](https://patterns.innersourcecommons.org/p/praise-participants)
+
+##### [Trusted committer](https://patterns.innersourcecommons.org/p/trusted-committer)
+
+### Desafíos técnicos
+
+#### Necesidades non satisfeitas para todos
+
+##### [Requisitos comúns](https://patterns.innersourcecommons.org/p/common-requirements)
+
+#### Medo á responsabilidade compartida de soporte
+
+##### [Servizo vs. Libraría](https://patterns.innersourcecommons.org/p/service-vs-library)
+
+#### Contribucións ao proxecto difíciles de facer e empregar
+
+##### [Core team](https://patterns.innersourcecommons.org/p/core-team)
+
+### Desafíos organizativos
+
+#### Disuasión á contribución de recursos
+
+##### [Contracted contributor](https://patterns.innersourcecommons.org/p/contracted-contributor)
+
+#### Rexeitamento dunha contribución aceptada
+
+##### [Garantía de 30 días](https://patterns.innersourcecommons.org/p/30-day-warranty)
+
+#### Cambio radical da xestión
+
+##### [Comité de revisión](https://patterns.innersourcecommons.org/p/review-committee)
+
+#### Medo á responsabilidade compartida de soporte
+
+##### [Servizo vs. Libraría](https://patterns.innersourcecommons.org/p/service-vs-library)
+
+#### Número de mantedores insuficiente para a escalada do proxecto
+
+##### [Trusted committer](https://patterns.innersourcecommons.org/p/trusted-committer)
+
+#### Coordinación complexa entre equipos
+
+##### [Toma de decisións transparente entre equipos RFC](https://patterns.innersourcecommons.org/p/transparent-cross-team-decision-making-using-rfcs)
+
+#### Proxecto orfo
+
+##### [Core team](https://patterns.innersourcecommons.org/p/core-team)
+
+##### [Soporte grupal](https://patterns.innersourcecommons.org/p/group-support)
+
+### Desafíos entre entidades xurídicas
+
+#### Preocupación polas responsabilidades xurídicas ou a contabilidade entre empresas
+
+##### [Licenza InnerSource](https://patterns.innersourcecommons.org/p/innersource-license)
+
+## Crecemento
+
+### Desafíos de dispoñibilidade
+
+#### Dificultade para atopar ao desenvolvedor axeitado para cada proxecto
+
+##### [Gig marketplace](https://patterns.innersourcecommons.org/p/gig-marketplace)
+
+##### [Portal InnerSource](https://patterns.innersourcecommons.org/p/innersource-portal)
+
+#### Dificultade para atopar proxectos activos
+
+##### [Cualificación da actividade do repositorio](https://patterns.innersourcecommons.org/p/repository-activity-score)
+
+## Escalada
+
+### Autoaprendizaxe/Desafíos de mellora
+
+#### Descoñecemento das mellores prácticas InnerSource
+
+##### [Modelo de madurez](https://patterns.innersourcecommons.org/p/maturity-model)
+
+#### Falta de coñecemento sobre código aberto
+
+##### [Documente os seus principios reitores](https://patterns.innersourcecommons.org/p/document-your-guiding-principles)
+
+### Desafíos técnicos
+
+#### Aumento dos gastos de mantemento
+
+##### [Extensións para o crecemento sostible](https://patterns.innersourcecommons.org/p/extensions-for-sustainable-growth)
diff --git a/pattern-categorization/gl/innersource-program-mind-map.png b/pattern-categorization/gl/innersource-program-mind-map.png
new file mode 100644
index 000000000..299ba3289
Binary files /dev/null and b/pattern-categorization/gl/innersource-program-mind-map.png differ
diff --git a/pattern-categorization/innersource-program-mind-map.html b/pattern-categorization/innersource-program-mind-map.html
index 8555997b1..3ba800f4c 100644
--- a/pattern-categorization/innersource-program-mind-map.html
+++ b/pattern-categorization/innersource-program-mind-map.html
@@ -20,9 +20,9 @@
-
+