GITBOOK-1: change request with no subject merged in GitBook

Author: spier

book/zh/fu-lu/e-wai/README.md

@@ -0,0 +1,2 @@
+# 额外
+

book/zh/introduction.md

@@ -3,8 +3,7 @@
 ![内源模式](innersource-patterns-book-cover.jpg)
 
 {% hint style="info" %}
-你正在阅读《内源模式》的早期版本，可能仍然会发现破碎的链接、拼写错误或其他错误。
-请帮助我们解决这些问题，以便尽可能制作出最好的图书:)。了解如何[为这本书做贡献](contribute.md).
+你正在阅读《内源模式》的早期版本，可能仍然会发现破碎的链接、拼写错误或其他错误。 请帮助我们解决这些问题，以便尽可能制作出最好的图书:)。了解如何[为这本书做贡献](contribute.md).
 {% endhint %}
 
 欢迎来到**内源模式**。
@@ -13,7 +12,7 @@
 
 [InnerSource Commons](http://innersourcecommons.org)多年来收集了这些模式，在本书中发布了最成熟的模式，社区成员对每个模式进行了评审，至少有一个已知的模式使用实例。
 
-在这篇介绍中，我们解释了[内源是什么](#内源是什么)，[内源模式是什么](#内源模式是什么)，以及[如何在你的组织中使用这些模式](#如何使用这些模式) 。
+在这篇介绍中，我们解释了[内源是什么](introduction.md#内源是什么)，[内源模式是什么](introduction.md#内源模式是什么)，以及[如何在你的组织中使用这些模式](introduction.md#如何使用这些模式) 。
 
 如果你已经在你的公司使用内源，并想把你的经验贡献给本书，我们很乐意[欢迎你的贡献](contribute.md)!
 
@@ -33,20 +32,20 @@
 
 模式可以为InnerSource Commons的参与者提供一种简明的信息分享方式，改善内源的实践。模式分为标题、问题陈述、背景、约束和解决方案，作为其主要部分。
 
-* ["什么是模式？"Youtube视频](http://bit.ly/innersource_patterns_videos) - 观看一组2-5分钟的Youtube视频，解释内源模式。
+* ["什么是模式？"Youtube视频](http://bit.ly/innersource\_patterns\_videos) - 观看一组2-5分钟的Youtube视频，解释内源模式。
 * [模式讨论网络研讨会](https://youtu.be/i-0IVhfRVFU) - 我们在2017-03-16举行了一次网络研讨会，现场讨论一个甜甜圈模式(进入24:30的讨论)。这是对我们所遵循的评审过程的说明。也可参见[2017年6月1日O'Reilly网络研讨会上的内源模式](http://www.oreilly.com/pub/e/3884) 。
 * [模式模板](../../meta/pattern-template.md) --查看一个内源模式的骨架，了解新模式的内容!
-* [内源模式介绍（2016年秋季峰会演讲）](https://drive.google.com/open?id=0B7_9iQb93uBQbnlkdHNuUGhpTXc) - *Tim Yao和Padma Sudarsan* (PDF)。详细的模式背景和例子 -- 详细了解为什么以及如何与我们的模式互动。也可参见[内源模式介绍(2017年秋季峰会)](https://drive.google.com/open?id=0B7_9iQb93uBQWmYwMFpyaGh4OFU) *Tim Yao和Bob Hanmer* (PDF)。
+* [内源模式介绍（2016年秋季峰会演讲）](https://drive.google.com/open?id=0B7\_9iQb93uBQbnlkdHNuUGhpTXc) - _Tim Yao和Padma Sudarsan_ (PDF)。详细的模式背景和例子 -- 详细了解为什么以及如何与我们的模式互动。也可参见[内源模式介绍(2017年秋季峰会)](https://drive.google.com/open?id=0B7\_9iQb93uBQWmYwMFpyaGh4OFU) _Tim Yao和Bob Hanmer_ (PDF)。
 
 ## 如何使用这些模式?
 
 模式的使用必须经过深思熟虑。它们不能被不加区分地应用。在大多数情况下，你需要根据你的情况来调整给定的解决方案；但模式中给出的信息，定义了背景（不可移动的约束）和力量（可以改变和相互平衡的约束），应该有助于你应用这些模式。请注意，你还需要确定是否有额外的约束（公司背景和公司力量）适用于你的特定公司/组织，必须添加到模式中（作为一种过滤器）。这些额外的制约因素可能需要额外的解决步骤来应用。
 
-模式的形式对于描述成熟的解决方案是很有用的，但它也可以用于*脑力激荡的新解决方案*，创建哪些尚未建立的模式。这是因为模式的解剖提供了一个以结构化方式思考问题的框架。你也可以创建一个*甜甜圈模式*（填写问题、背景、约束和结果等字段，但在解决方案留空），作为向InnerSource Commons社区寻求帮助的一种方式（找到一个成熟的解决方案或做一次集思广益的尝试）。
+模式的形式对于描述成熟的解决方案是很有用的，但它也可以用于_脑力激荡的新解决方案_，创建哪些尚未建立的模式。这是因为模式的解剖提供了一个以结构化方式思考问题的框架。你也可以创建一个_甜甜圈模式_（填写问题、背景、约束和结果等字段，但在解决方案留空），作为向InnerSource Commons社区寻求帮助的一种方式（找到一个成熟的解决方案或做一次集思广益的尝试）。
 
 ## 如何贡献?
 
-请参考: [为这本书做贡献](./contribute.md)
+请参考: [为这本书做贡献](contribute.md)
 
 ## 致谢
 
@@ -56,7 +55,7 @@
 
 本书的标题图片由[Sebastian Spier](https://spier.hu)创作，并改编自[Tony Hisgett - Alhambra 6](https://www.flickr.com/photos/hisgett/29345405788/)的图片，可根据[CC BY 2.0](https://creativecommons.org/licenses/by/2.0/)获得。
 
- **感谢所有的贡献者! 并祝内源日快乐 :)**
+**感谢所有的贡献者! 并祝内源日快乐 :)**
 
 ## Licensing
 

translation/zh/patterns/30-day-warranty.md renamed to book/zh/p/30-day-warranty-foo.md

@@ -1,81 +1,84 @@
 ---
 title: sebastian
-description: 当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
+description: >-
+  当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
 ---
 
-## Title
+# ✅ foo 30天保修
+
+### Title
 
 30天保修
 
-## Patlet
+### Patlet
 
 当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
 
-## 问题
+### 问题
 
 一个团队开发了一个在整个组织中使用的组件。 这个团队抵制接受或直接拒绝贡献（功能请求）。 这种行为阻碍了正常的项目研发，并导致了事态升级使得项目开发受到影响。
 
-## 上下文
+### 上下文
 
-- 团队依赖另一个团队接受他们的贡献，以便接收团队生产的组件能够被贡献团队使用。
-- 接收团队没有资源、知识、许可和/或倾向于自己编写贡献的组件/功能。
+* 团队依赖另一个团队接受他们的贡献，以便接收团队生产的组件能够被贡献团队使用。
+* 接收团队没有资源、知识、许可和/或倾向于自己编写贡献的组件/功能。
 
-## 约束
+### 约束
 
-- 由于过去的作弊历史，人们对贡献存在不信任：团队提交了半成品的贡献之后，通过提出后续的修复请求，使其可以在生产中使用。
-- 如果代码是由团队以外的人贡献的，团队自然会怀疑其他团队不知道如何编写符合接收团队期望的代码。
-- 每个团队首要考虑的是帮助自己的领导实现自己的目标。这样忠诚度会使这个问题的解决变得复杂。
-- 人们对承担非自己编写的代码的责任有一种自然的厌恶。
-- 贡献的代码在被代码库接纳之前需要进行大量的重写。
-- 人们担心贡献者在贡献被接纳之后无法提供修复错误的支持。
-- 团队担心贡献的代码会导致高额的维护成本，并担心如何控制这些维护成本。
-- 接收团队可能会担心，教别人如何贡献代码会暴露他们系统中的技术债务，并引发其他的伤害。
-- 接收团队可能不相信，无论他们提供何种程度的指导，都能得到可接受的代码。
-- 大家对衡量风险或证明风险在贡献中得到缓解缺乏信心；系统本身的脆弱性（可能没有办法完全测试和捕捉所有问题）。
+* 由于过去的作弊历史，人们对贡献存在不信任：团队提交了半成品的贡献之后，通过提出后续的修复请求，使其可以在生产中使用。
+* 如果代码是由团队以外的人贡献的，团队自然会怀疑其他团队不知道如何编写符合接收团队期望的代码。
+* 每个团队首要考虑的是帮助自己的领导实现自己的目标。这样忠诚度会使这个问题的解决变得复杂。
+* 人们对承担非自己编写的代码的责任有一种自然的厌恶。
+* 贡献的代码在被代码库接纳之前需要进行大量的重写。
+* 人们担心贡献者在贡献被接纳之后无法提供修复错误的支持。
+* 团队担心贡献的代码会导致高额的维护成本，并担心如何控制这些维护成本。
+* 接收团队可能会担心，教别人如何贡献代码会暴露他们系统中的技术债务，并引发其他的伤害。
+* 接收团队可能不相信，无论他们提供何种程度的指导，都能得到可接受的代码。
+* 大家对衡量风险或证明风险在贡献中得到缓解缺乏信心；系统本身的脆弱性（可能没有办法完全测试和捕捉所有问题）。
 
-## 解决方案
+### 解决方案
 
 通过建立一个**30天的保证期**来解决接收团队和贡献团队的担忧，保证期从贡献的代码投入生产时开始计算。在这个保证期内，贡献团队承诺向接收团队提供问题修复。
 
 请注意，保证期也可以是45、60或100天。持续时间可以根据项目的限制、项目的软件生命周期、对客户的承诺和其他因素而变化。
 
-此外，提供明确的[贡献指南](./base-documentation.md)，阐明接收团队和贡献团队的期望，也是有帮助的。
+此外，提供明确的[贡献指南](../../../translation/zh/patterns/base-documentation.md)，阐明接收团队和贡献团队的期望，也是有帮助的。
 
 ![30天保修](../../../assets/img/thirtydaywarranty.jpg)
 
-## 结果
+### 结果
 
-- 接收团队愿意接受贡献，并能分担初步改编/修复的工作量。
-- 增加透明度和公平性。
-- 使得维护工作不至于变得过于沉重。
+* 接收团队愿意接受贡献，并能分担初步改编/修复的工作量。
+* 增加透明度和公平性。
+* 使得维护工作不至于变得过于沉重。
 
-## 已知实例
+### 已知实例
 
-- 这在 PayPal 得到了成功的尝试和证明。
-- GitHub 内部使用这种模式，修改后的保证时间线为6周。
-- 微软推荐这种模式作为一个内部原则--团队设定自己的具体时间目标，与他们的需求和信心相匹配。
+* 这在 PayPal 得到了成功的尝试和证明。
+* GitHub 内部使用这种模式，修改后的保证时间线为6周。
+* 微软推荐这种模式作为一个内部原则--团队设定自己的具体时间目标，与他们的需求和信心相匹配。
 
-## 作者
+### 作者
 
-- Cedric Williams
+* Cedric Williams
 
-## 致谢
+### 致谢
 
-- Dirk-Willem van Gulik
-- Padma Sudarsan
-- Klaas-Jan Stol
-- Georg Grütter
+* Dirk-Willem van Gulik
+* Padma Sudarsan
+* Klaas-Jan Stol
+* Georg Grütter
 
-## 状态
+### 状态
 
 * 结构化
 * 在2017年春季内源峰会上起草；2017年7月18日审查。
 
-## 变体
+### 变体
 
-- 确保相互由依赖关系团队的合作，让他们成为一个社区，由一个以上的、以择优任命的"[trusted-committer](./trusted-committer.md)"（TCs）负责。
+* 确保相互由依赖关系团队的合作，让他们成为一个社区，由一个以上的、以择优任命的"[trusted-committer](../../../translation/zh/patterns/trusted-committer.md)"（TCs）负责。
 
-## 翻译校对
+### 翻译校对
 
 * **2022-12-01** 翻译[姜宁](https://github.com/willemjiang)
 * **2022-12-09** 校对[龙文选](https://github.com/hncslwx)

book/zh/toc.md

@@ -1,25 +1,15 @@
 # 目录
 
-<!--
-Do not edit toc.md directly!!!
-Instead edit toc_template.md
--->
-
-<!--
-  NOTE:
-  Paths in here are relative to this file, and not relative to the root specified in .gitbook.yaml.
--->
-
-* [介绍](./introduction.md)
-* [目录](./toc.md)
-* [模式探索](./explore-patterns.md)
-* [为这本书做贡献](./contribute.md)
+* [介绍](introduction.md)
+* [目录](toc.md)
+* [模式探索](explore-patterns.md)
+* [为这本书做贡献](contribute.md)
 
 ![内源模式脑图](../../pattern-categorization/innersource-program-mind-map.png)
 
-## 模式 <a id="p"></a>
+## 模式 <a href="#p" id="p"></a>
 
-* [30天保修](../../translation/zh/patterns/30-day-warranty.md) - 当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
+* [30天保修](p/30-day-warranty-foo.md) - 当接受来自自己团队以外的贡献时，人们自然不愿意为非本团队自己编写的代码负责。通过30天保证，贡献团队同意向接受团队提供错误修复，这将增加两个团队之间的信任度，使贡献更有可能被接受。
 * [Trusted Committer](../../translation/zh/patterns/trusted-committer.md) - 许多内源项目会发现自己处于这样一种情况：他们不断收到来自贡献者的反馈、功能和错误修正。 在这种情况下，项目维护者会想方设法对贡献者的工作进行认可和奖励，而不仅仅是对单一的贡献认可。
 * [不要吝啬对参与者的夸奖](../../translation/zh/patterns/praise-participants.md) - 及时感谢贡献者对内源项目贡献的时间和付出是很重要的。 这种模式不仅提供了有效地承认了贡献的指导，而且还吸引贡献者和其他人的进一步参与。
 * [专职的社群领导](../../translation/zh/patterns/dedicated-community-leader.md) - 选择同时具备沟通和技术能力的人领导社群，以确保成功推动内源倡议。