Update toc

Author: spier

book/en/toc.md

@@ -35,6 +35,7 @@ Instead edit toc_template.md
 * [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) - When you receive an InnerSource contribution, it's important to thank the contributor for their time and effort. Extending your gratiutude not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others. Praising contributors' positive contributions to your InnerSource project motivates those contributors (and their managers) to continue investing in the effort.
+* [Project Governance Levels](../../patterns/2-structured/governance-levels.md) - Several teams are using different InnerSource patterns and all calling it "InnerSource", so the term is not precise enough to usefully describe a set of working practices without confusion. Establishing a more accurate common language that is understood across all teams allows anyone to communicate intent or set expectations efficiently without ambiguity.
 * [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.