Fixed the formate issue of the Chinese translation

book/zh/toc.md

@@ -23,7 +23,7 @@ Instead edit toc_template.md
 * [Trusted Committer](../../translation/zh/patterns/trusted-committer.md) - 许多内源项目会发现自己处于这样一种情况：他们不断收到来自贡献者的反馈、功能和错误修正。 在这种情况下，项目维护者会想方设法对贡献者的工作进行认可和奖励，而不仅仅是对单一的贡献认可。
 * [不要吝啬对参与者的夸奖](../../translation/zh/patterns/praise-participants.md) - 及时感谢贡献者对内源项目贡献的时间和付出是很重要的。 这种模式不仅提供了有效地承认了贡献的指导，而且还吸引贡献者和其他人的进一步参与。
 * [专职的社群领导](../../translation/zh/patterns/dedicated-community-leader.md) - 选择同时具备沟通和技术能力的人领导社群，以确保成功推动内源倡议。
-* [交流工具](../../translation/zh/patterns/communication-tooling.md) - 一个InnerSource项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。
+* [交流工具](../../translation/zh/patterns/communication-tooling.md) - 一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。
 * [代码仓活跃度评分](../../translation/zh/patterns/repository-activity-score.md) - 潜在的贡献者希望找到需要他们帮助的活跃的内源项目。通过计算每个项目的代码库活跃度评分，可以创建一个项目的排名列表（例如在内源门户网站上），这样潜在的贡献者可以更容易地确定他们想要贡献的项目。
 * [以实验的方式开始](../../translation/zh/patterns/start-as-experiment.md) - 将内源实践倡议作为一个有时间限制的实验开始，使不熟悉内源的管理人员更容易认可和支持该倡议。
 * [共同的需求](../../translation/zh/patterns/common-requirements.md) - 共享代码库中的通用代码不能满足所有想要使用它的项目团队的需要；这一点可以通过需求调整和重构来解决。
@@ -33,7 +33,7 @@ Instead edit toc_template.md
 * [基准级的文档](../../translation/zh/patterns/base-documentation.md) - 内源项目的新贡献者很难搞清楚谁在维护这个项目，该做什么，以及如何贡献。在标准文件中提供文档，如README.md/CONTRIBUTING.md，可以为新的贡献者提供一个自助服务流程，这样他们就可以自己找到最常见问题的答案。
 * [成熟度模型](../../translation/zh/patterns/maturity-model.md) - 各个团队已经开始采用内源。这种做法正在向多个部门蔓延。然而，人们对什么是内源项目的理解各不相同。解决方案是提供一个成熟度模型，让团队通过自我检查，发现他们还没有意识到的模式和做法。
 * [服务 vs. 库](../../translation/zh/patterns/service-vs-library.md) - 由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
-* [核心团队](../../translation/zh/patterns/core-team.md) - 即使一个InnerSource项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
+* [核心团队](../../translation/zh/patterns/core-team.md) - 即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
 * [签约贡献者](../../translation/zh/patterns/contracted-contributor.md) - 想为内源做贡献的同事被他们的直线管理层劝阻。正式的合同和协议为这种困境提供援助。
 * [记录你的指导原则](../../translation/zh/patterns/document-your-guiding-principles.md) - 通常内源对 "在组织内部应用开源最佳实践 "的解释对缺乏开源背景的人来说效果并不好。 作为一种补救措施，内源最重要的原则被记录下来并广泛宣传。
 * [评审委员会](../../translation/zh/patterns/review-committee.md) - 对于开发人员和管理人员来说，内源的工作模式与更多的传统方法截然不同。通过建立一个评审委员会，作为内源计划和所有参与该计划的业务部门高级管理人员之间的接口，后者更有可能更加熟悉并支持该计划，因为评审委员会为他们提供了一定程度的监督和控制，而不会助长微管理。

translation/zh/patterns/common-requirements.md

@@ -18,8 +18,8 @@
 * 每个项目都有自己的交付时间表，一组交付物和客户。
 * 这种模式适用于以下任何一种情况：
     * 有一个**强的代码所有者**，即所有对共享库的修改都必须得到共享库所有者的批准。
-    *有**弱的代码所有权**，即没有人真正拥有这些代码。
-    **没有仁慈的赞助者**，即没有组织或行政人员提供资源，以InnerSource的方式组织公共代码。
+    * 有**弱的代码所有权**，即没有人真正拥有这些代码。
+    * **没有仁慈的赞助者**，即没有组织或行政人员提供资源，以InnerSource的方式组织公共代码。
 
 ## 约束
 

translation/zh/patterns/communication-tooling.md

@@ -4,7 +4,7 @@
 
 ## Patlet
 
-一个InnerSource项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。
+一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。
 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。
 
 ## 上下文
@@ -27,11 +27,11 @@
 
 东道主团队需要明确提供公司公开的、存档的、可搜索的、可链接的沟通渠道的好处，公司内部的任何人都可以免费订阅信息。
 
-在精简 InnerSource 项目的沟通渠道时，目标应该是围绕主题进行沟通，而不是围绕某些人。
+在精简内源项目的沟通渠道时，目标应该是围绕主题进行沟通，而不是围绕某些人。
 
 - 项目应该有自己的问题跟踪器，东道主团队成员采用公开透明的方式进行结构化的沟通、决策和进度跟踪需求，同时也鼓励下游的用户和贡献者遵循同样的原则进行沟通。
 - 该项目应该有一个或多个结构不太严格的讨论渠道。通常情况下，这将是邮件列表、在线论坛甚至是存档的聊天频道。通常情况下，项目开始时只有一个频道就足够了，如果流量增加太多，把关于项目使用的讨论和关于项目开发的讨论分开是有帮助的。
-- 此外，项目应该有一个私人频道，可以在[Trusted Committer](./trusted-committer.md)之间进行敏感的交流--例如，将更多的Trusted Committer加入到东道主团队中。这个渠道的使用应该非常谨慎，因为沟通默认为公开的，只有在非常罕见的情况下才会保持私密。
+- 此外，项目应该有一个私人频道，可以在 [Trusted Committer](./trusted-committer.md) 之间进行敏感的交流--例如，将更多的 Trusted Committer 加入到东道主团队中。这个渠道的使用应该非常谨慎，因为沟通默认为公开的，只有在非常罕见的情况下才会保持私密。
 
 虽然沟通可以发生在书面渠道之外，但尽可能多的信息应该被带回异步渠道。
 

translation/zh/patterns/contracted-contributor.md

@@ -58,7 +58,7 @@
 
 正式的合同对贡献者和社群也有好处。
 
-- 有了一个稳定的贡献者群体，他们中的一些人更有可能最终获得[Trusted Committer](./trusted-committer.md)地位。
+- 有了一个稳定的贡献者群体，他们中的一些人更有可能最终获得 [Trusted Committer](./trusted-committer.md) 地位。
 - 正式的协议为解决内源活动相关的冲突提供了一个基础。请注意，协议调解可能只适用在少数具有文化匹配的公司。
 
 ## 已知实例

translation/zh/patterns/core-team.md

@@ -4,7 +4,7 @@
 
 ## Patlet
 
-即使一个InnerSource项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。
+即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。
 建立一个核心团队，专门负责处理项目的基本事务。
 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
 
@@ -25,7 +25,7 @@
 ## 故事
 
 有一个人人都依赖的中心项目。
-这是一个多么好的 InnerSource 候选项目啊！
+这是一个多么好的内源候选项目啊！
 不幸的是，这个项目是自然发展起来的，各种贡献和补充功能都是胡乱地加进去的。
 现在，它是一个恶心的、厚厚的代码泥潭，没有人理解，每个人都不敢去碰。
 很明显，它应该进行一次大修（例如，重构、测试、文档等），但尽管每个人都需要并希望这项工作发生，却没有人投入时间和精力来完成这些事。
@@ -81,7 +81,7 @@
 
 持续关注这些指标会自然驱使核心团队优先考虑正确的工作，从而围绕项目创建一个繁荣的InnerSource生态系统。
 
-核心团队和 InnerSource 贡献者的职责](../../../assets/img/core-team.png)
+![核心团队和 InnerSource 贡献者的职责](../../../assets/img/core-team.png)
 
 ## 结果上下文
 

translation/zh/patterns/crossteam-project-valuation.md

@@ -44,9 +44,9 @@
 * 如果不这样做，他们会花多少时间（每个用户）来维护他们自己的解决方案？
 
 在进行这些估计时，不可能高度准确地知道任何活动需要多长时间。 这不是你的目标。
-与其说是准确，不如说你应该努力为这些估算_**设定一个最坏情况下的界限**_。
+与其说是准确，不如说你应该努力为这些估算 _**设定一个最坏情况下的界限**_。
 我们的想法是让专家组能够达成一致："我们不知道到底要花多长时间，但我们都同意至少要花这么多时间"。
-具体来说，你应该估计出使用你的项目的_最大_合理时间，以及消费者如果自制、使用和维护他们自己的解决方案的_最小_合理时间。
+具体来说，你应该估计出使用你的项目的 _最大_ 合理时间，以及消费者如果自制、使用和维护他们自己的解决方案的 _最小_ 合理时间。
 
 关于 "实现你自己的解决方案"（home-roll）的成本的一个说明。 自研解决方案的成本不一定（事实上不太可能）与制作一个共享解决方案的成本相同。
 通常情况下，对于相同的功能，建立一个跨团队的共享解决方案所涉及的模块化和质量的投入明显高于只使用一次的快速、硬编码的实现。
@@ -67,11 +67,11 @@
 
 尽管有严谨的外表，这个过程并没有给出衡量跨团队项目产出的确切方法。
 然而，在实践中，它确实提供了一个计算框架，你可以据此对如何资助这个项目做出合理的决定。
-根据上面的解释，在有了好的、合理的数据之后，你应该运作项目投入专门的开发时间，投入_**至少**_要达到以下三个层面中的较小者。
+根据上面的解释，在有了好的、合理的数据之后，你应该运作项目投入专门的开发时间，投入 _**至少**_ 要达到以下三个层面中的较小者。
 
 1. 通过上述公式节省的原始时间。 既然我们都确信这个公式会产生一个低于真实节省的小时数的数字，你就可以有信心，就项目投入到节省的时间，对你来说是稳赚的。
-1. 支持内源性贡献给跨团队项目所需的时间。 由于贡献者很可能会以一次性的方式完成工作，所以资助他们的工作以达到协同工作所需的时间是值得的。
-1. 只要你觉得好就行。拥有一个估值公式的一个有益的副作用是，它自然会迫使大家对项目消费者提供价值的关键使用点进行测量。
+2. 支持内源性贡献给跨团队项目所需的时间。 由于贡献者很可能会以一次性的方式完成工作，所以资助他们的工作以达到协同工作所需的时间是值得的。
+3. 只要你觉得好就行。拥有一个估值公式的一个有益的副作用是，它自然会迫使大家对项目消费者提供价值的关键使用点进行测量。
 
 通过理解这些测量结果，并以其原始形式进行使用，那你就可以得到一个关于项目有多大价值的直觉想法。
 

translation/zh/patterns/dedicated-community-leader.md

@@ -28,7 +28,7 @@
 
 如果一个公司没有在预算和能力方面对最初的内源社群进行大量投资，那么它对内源的承诺的可信度可能会被认为是有问题的。一个具有传统管理文化的公司，如果项目或倡议的表现不尽如人意，其常见的冲动就是更换领导人。在没有社区参与和遵循任人唯贤原则的情况下这样做，将进一步破坏公司对内源的承诺，因为它突出了当前公司文化和目标文化--社区文化之间的摩擦。
 
-内源项目的价值贡献对于许多沉浸在传统项目管理方法中的管理者来说并不明显。这些经理人不太可能把他们的高级人员--通常非内源项目对他们的工作时间优先级要求很高--分配到内源项目中去，来占用他们相当大的工作时间。
+内源项目的价值贡献对于许多沉浸在传统项目管理方法中的管理者来说并不明显。这些经理人不太可能把他们的高级人员（通常非内源项目对他们的工作时间优先级要求很高）分配到内源项目中去，来占用他们相当大的工作时间。
 
 沟通在社群领导的日常工作中占了很大比例。同时，他或她很可能也要带头进行初步开发。在能力有限的情况下，没有经验的领导人会倾向于专注于发展，而忽略了沟通。如果社群领导人很难联系上，或者因为没有时间而对反馈和问题反应迟钝，那么潜在的贡献者做出第一次贡献和对社群做出承诺的障碍就会大增。此外，技术上没有经验的领导者很可能比在公司内有很高知名度的顶尖人才更难吸引和保留经验丰富的贡献者。
 
@@ -90,4 +90,4 @@ _BIOS at Robert Bosch GmbH_. 请注意，博世的内源在大多数情况下是
 ## 翻译校对
 
 - **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
-- **2022-12-11** 校对[龙文选]https://github.com/hncslwx
+- **2022-12-11** 校对[龙文选](https://github.com/hncslwx)

translation/zh/patterns/document-your-guiding-principles.md

@@ -11,7 +11,7 @@
 
 该组织正试图在更大范围内推广内源。
 该倡议是从开源爱好者发起。现在的目标是获得缺乏开源经验的人的支持。
-对于这些人来说，典型的 "应用开源最佳实践 "的口号已经不足以传递内源是什么、它解决了哪些问题以及它使用哪些工具来解决这些问题的信息。
+对于这些人来说，典型的"应用开源最佳实践"的口号已经不足以传递内源是什么、它解决了哪些问题以及它使用哪些工具来解决这些问题的信息。
 因此，内源在组织中的采用速度减慢了。
 当贡献者开始跨越团队边界时进行协作是， 团队对内源的目标是什么以及如何实施最佳实践产生了疑惑。
 
@@ -39,7 +39,7 @@
 
 应该通过记录这两个方面来向团队和个人传递清晰的信息。
 
-1. **目的**--组织为什么要采用内源？
+1. **目的** - 组织为什么要采用内源？
 2. **原则** - 哪些内源原则将有助于解决这些挑战？
 
 下面的章节提供了关于这两个方面的更多细节，意味着可以作为你的组织记录这些原则的起点。
@@ -50,7 +50,7 @@
 
 然而，您的组织希望使用内源来改善哪些组织挑战？
 
-与其一概而论，不如尝试准确地找出与你的组织的挑战相匹配的解决方案--最好是和哪些你想影响的人一起。
+与其一概而论，不如尝试准确地找出与你的组织的挑战相匹配的解决方案 - 最好是和哪些你想影响的人一起。
 
 其他人通过遵循内源最佳实践解决的一些挑战：
 
@@ -99,7 +99,7 @@
 必须有可能通过稳定的URL来提供参考链接交流。
 以往的交流需要以一种容易搜索的方式来储存。
 
-但有两点需要注意。
+但有两点需要注意:
 
 1. 这并不能取代结构化文档。但它可以作为收集结构化文档的一个起点。
 2. 所有的东西都要写出来，而且要让整个组织都能看到，这个规则也有例外。与个人有关的讨论以及与安全有关的讨论是敏感的，不应公开进行。
@@ -122,7 +122,7 @@
 ### Europace AG
 
 上述解决方案中列出的内源原则大部分是基于Europace公司的经验。
-详情见[Europace InnerSource Prinzipien](https://tech.europace.de/post/europace-inner-source-prinzipien/)（德语）。
+详情见 [Europace InnerSource Prinzipien](https://tech.europace.de/post/europace-inner-source-prinzipien/)（德语）。
 
 ### GitHub
 

translation/zh/patterns/innersource-license.md

@@ -47,7 +47,7 @@
 
 该许可证简化了我们组织内部关于共享源代码的对话，并推动第一批法律实体这样做。
 
-**注意：** **已知实例** 中描述的实验还处于早期阶段。因此，一个可靠的 **结果** 还没有形成。几个月后，内源许可证对这一问题空间的影响将更加清晰，本节也将更新。
+**注意：** **已知实例**中描述的实验还处于早期阶段。因此，一个可靠的**结果**还没有形成。几个月后，内源许可证对这一问题空间的影响将更加清晰，本节也将更新。
 
 ## 已知实例
 

translation/zh/patterns/innersource-portal.md

@@ -65,7 +65,7 @@
 ## 已知实例
 
 * **一家大型金融服务机构**利用创建的内源门户提供了一个宣传和发现不同业务部门的内源项目的机制。
-* **SAP**在内源门户中推广内源项目--项目可以使用GitHub主题自行注册。[代码仓活跃度评分](repository-activity-score.md)定义了内源项目在门户中的默认顺序。也可参见[Michael Graf & Harish B (SAP) at ISC.S11 - 应用内源模式非常规路径]（https://www.youtube.com/watch?v=6r9QOw9dcQo&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy&index=6）。它的代码库以[参考实现](https://github.com/SAP/project-portal-for-innersource)的形式发布，并开放给众人贡献。
+* **SAP**在内源门户中推广内源项目--项目可以使用GitHub主题自行注册。[代码仓活跃度评分](repository-activity-score.md)定义了内源项目在门户中的默认顺序。也可参见[Michael Graf & Harish B (SAP) at ISC.S11 - 应用内源模式非常规路径](https://www.youtube.com/watch?v=6r9QOw9dcQo&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy&index=6)。它的代码库以[参考实现](https://github.com/SAP/project-portal-for-innersource)的形式发布，并开放给众人贡献。
 * **Elbit Systems**使用了这个模式，并在上面添加了游戏化内容。
   * [游戏化作为文化变革的手段和内源参与的助推器](https://www.oreilly.com/library/view/oscon-2018-/9781492026075/video321579.html) | Shelly Nizri | OSCON 2018 - 波特兰，俄勒冈州
   * 岛屿、怪兽和内源 [(幻灯片)](https://docs.google.com/presentation/d/1P1OCEK9B6eSrVRUclVWY6meSI-qHOBjM_UAPNvCZamU/edit#slide=id.p15), [(视频)](https://drive.google.com/file/d/1pM89uHMn0vhE3ayFJDGYcCO8R0tAXXZD/view?usp=drivesdk) | 2019年内源春季峰会（爱尔兰，高威）