Writing new ToC for the book

spier · actions-user · commit 4a48f078c1c9 · 2020-09-23T08:06:43.000Z
diff --git a/book/toc.md b/book/toc.md
@@ -4,24 +4,24 @@
 
 ## Patterns
 
-[](../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.
-[ (aka  )](../patterns/2-structured/review-committee.md) - 
-[30 Day Warranty](../patterns/2-structured/30-day-warranty.md) - 
-[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) - An InnerSource project is being used outside the original development team but users are having trouble getting help and getting in touch with the project team. The idea is to setup and document standard communication tooling that allows for discussions to become visible, archived and searchable.
-[Cross-Team Project Valuation](../patterns/2-structured/crossteam-project-valuation.md) - It's hard to sell the value of cross-team, inner sourced 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.
-[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.
-[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.
-[InnerSource Portal](../patterns/2-structured/innersource-portal.md) - Create an intranet website that indexes all available InnerSource project information. This will enable potential contributors to more easily learn about projects that might interest them and for 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.
-[Overcome Acquisition-based Silos (Developer Level)](../patterns/2-structured/overcome-acquisition-based-silos-developer.md) - TBD
-[Overcome Acquisition-based Silos (Management Level)](../patterns/2-structured/overcome-acquisition-based-silos-manager.md) - TBD
-[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 endgenders further engagement from the contributor and others.
-[Provide standard base documentation through a README](../patterns/2-structured/project-setup/base-documentation.md) - 
-[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  ), so that potential contributors can more easily determine which project they want to contribute to.
-[Service vs. library: It's inner source, not inner deployment](../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.
-[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.
-[Trusted Committer](../patterns/2-structured/trusted-committer.md) - Many inner-source 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.
+* [](../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.
+* [ (aka  )](../patterns/2-structured/review-committee.md) - 
+* [30 Day Warranty](../patterns/2-structured/30-day-warranty.md) - 
+* [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) - An InnerSource project is being used outside the original development team but users are having trouble getting help and getting in touch with the project team. The idea is to setup and document standard communication tooling that allows for discussions to become visible, archived and searchable.
+* [Cross-Team Project Valuation](../patterns/2-structured/crossteam-project-valuation.md) - It's hard to sell the value of cross-team, inner sourced 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.
+* [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.
+* [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.
+* [InnerSource Portal](../patterns/2-structured/innersource-portal.md) - Create an intranet website that indexes all available InnerSource project information. This will enable potential contributors to more easily learn about projects that might interest them and for 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.
+* [Overcome Acquisition-based Silos (Developer Level)](../patterns/2-structured/overcome-acquisition-based-silos-developer.md) - TBD
+* [Overcome Acquisition-based Silos (Management Level)](../patterns/2-structured/overcome-acquisition-based-silos-manager.md) - TBD
+* [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 endgenders further engagement from the contributor and others.
+* [Provide standard base documentation through a README](../patterns/2-structured/project-setup/base-documentation.md) - 
+* [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  ), so that potential contributors can more easily determine which project they want to contribute to.
+* [Service vs. library: It's inner source, not inner deployment](../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.
+* [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.
+* [Trusted Committer](../patterns/2-structured/trusted-committer.md) - Many inner-source 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.
 
 ## Appendix
 
