Merge branch 'main' into innersource-before-open-source

Author: spier

.github/CODEOWNERS

@@ -20,3 +20,5 @@
 /translation/gl/    @psanxiao
 /book/gl/           @psanxiao
 /pattern-categorization/gl/  @psanxiao
+/translation/es/    @ovas04
+/book/es/           @ovas04

.github/workflows/book.yml

@@ -15,7 +15,7 @@ jobs:
 
     strategy:
       matrix:
-        language: [en, ja, zh, pt-br, gl]
+        language: [en, ja, zh, pt-br, gl, es]
 
     steps:
     - uses: actions/checkout@v4

.github/workflows/generate-mindmap.yml

@@ -12,6 +12,7 @@ on:
       - "pattern-categorization/package.json"
       - "pattern-categorization/gl/*"
       - "pattern-categorization/pt-br/*"
+      - "pattern-categorization/es/*"
 
 defaults:
   run:
@@ -27,7 +28,7 @@ jobs:
 
     strategy:
       matrix:
-        folder: [".", "./gl", "./pt-br"]
+        folder: [".", "./gl", "./pt-br", "./es"]
 
     steps:
     - uses: actions/checkout@v4

.github/workflows/i18n-consistency-checker.yaml

@@ -15,7 +15,7 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        language: [ja, zh, pt-br, gl]
+        language: [ja, zh, pt-br, gl, es]
     steps:
       - uses: actions/checkout@v4
         with:
@@ -24,7 +24,7 @@ jobs:
         id: check-consistency
         run: |
           # Declare the flags
-          declare -A flags=( ["ja"]=":jp: Japanese" ["zh"]=":cn: Chinese" ["pt-br"]=":brazil: Brazilian Portuguese" ["gl"]="Galician")
+          declare -A flags=( ["ja"]=":jp: Japanese" ["zh"]=":cn: Chinese" ["pt-br"]=":brazil: Brazilian Portuguese" ["gl"]="Galician" ["es"]=":es: Spanish" )
         
           issue_title="${flags['${{matrix.language}}']}: Content Consistency Issue"
         
@@ -86,4 +86,3 @@ jobs:
           fi
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        

README.md

@@ -58,6 +58,7 @@ Our mission
 * [Extensions for Sustainable Growth](/patterns/2-structured/extensions-for-sustainable-growth.md) - *An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.*
 * [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.*
 * [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.*
+* [Explicit Governance Levels](patterns/2-structured/governance-levels.md) - *Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.*
 
 ### Maturity Level 1: Initial
 
@@ -71,7 +72,6 @@ Our mission
 * [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.*
 * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.*
-* [Transparent Governance Levels](patterns/1-initial/governance-levels.md) - *There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.*
 * [Governance Level Guided Project Setup](/patterns/1-initial/governance-based-project-setup.md) - *Before publishing their first InnerSource project, a team wants to choose an appropriate Governance Level but is unsure about the impact of the different levels on their daily doing. A dedicated list of resources (best practices, recommended patterns, target maturity levels) provides specific guidance to the team and helps them to make an educated decision.*
 * [Contained InnerSource](patterns/1-initial/contained-innersource.md) - *Apply InnerSource methods to facilitate collaboration in a cross-divisional project but don't invest in soliciting contributions from outside of that project.*
 * [Good First Project](patterns/1-initial/good-first-project.md) - *An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.*
@@ -93,6 +93,7 @@ Our mission
 * [Circle Communities](/patterns/1-initial/circle-communities.md) - *InnerSource adoption is slow in organizations due to limited understanding, engagement, and contextual relevance. Circle Communities address this by fostering synchronous conversations that build connections, close knowledge gaps, and cultivate collaboration and continuous learning.*
 * [Internal Developer Platform](/patterns/1-initial/internal-developer-platform.md) - *As InnerSource adoption increases throughout an organisation, it is not unusual that project teams start to face inefficiencies in scaling their efforts due to fragmented tooling, environments, and workflows. An Internal Developer Platform (IDP) provides a way to tackle this type of challenges through a centralized, self-service system that standardizes development environments and integrates tools to enhance consistency, collaboration, and developer productivity.*
 * [Document Architecture Decisions](/patterns/1-initial/document-architecture-decisions.md) - *InnerSource contributors often face challenges in grasping the system's design rationale, which can result in misalignment between maintainers, contributors, and stakeholders — potentially discouraging participation. To enhance decision-making and transparency, we recommend capturing architecture decisions and their consequences in a lightweight, accessible format to streamline onboarding, clarify decisions, and support long-term project sustainability.*
+* [InnerSource Incentives and Disincentives](/patterns/1-initial/incentives-and-disincentives.md) - *Lack of awareness for incentives as well well as disincentives for InnerSource contribution decrease the chances of an InnerSource project receiving contributions; this is addressed by sharing a comprehensive list of potential incentives and disincentives.
 
 <!--
 NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential for readers to quickly browse our patterns.

TRUSTED-COMMITTERS.md

@@ -26,6 +26,7 @@ While they don't take all responsibilities of a Trusted Committer (yet), they do
 * Chinese - [@WillemJiang](https://github.com/WillemJiang)
 * Brazilian Portuguese - [@jrcosta](https://github.com/jrcosta), [@zilio](https://github.com/zilio)
 * Galician - [@psanxiao](https://github.com/psanxiao)
+* Spanish - [@ovas04](https://github.com/ovas04)
 
 ## Hall of Fame (aka Alumni)