Regenerate TOC

Author: spier

book/en/toc.md

@@ -27,9 +27,9 @@ Instead edit toc_template.md
 * [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.
 * [Dedicated Community Leader](../../patterns/2-structured/dedicated-community-leader.md) - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.
 * [Document your Guiding Principles](../../patterns/2-structured/document-your-guiding-principles.md) - The usual InnerSource explanation of "applying open source best practices inside an organization" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely.
-* [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.
 * [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.
 * [Gig Marketplace](../../patterns/2-structured/gig-marketplace.md) - Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements.  This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.
+* [Governance Framework](../../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.
 * [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.