Translate project leader section into Chinese

project-leader/zh/01-introduction-zh.asciidoc

@@ -0,0 +1,17 @@
+== 项目负责人与 InnerSource
+
+完成本部分后，你将更好地了解 InnerSource 如何加快产品开发；我们还将介绍其与敏捷开发最佳实践的关系。
+
+
+为了实现敏捷性，组织努力建立自治团队。然而，在一个复杂、相互关联的世界中，某些依赖性是不可避免的。
+InnerSource 
+https://innersourcecommons.org/learn/learning-path/introduction/02/[提供了一种替代] "等待"、"建立变通办法 "和 "升级 "的方法： 需要修改依赖关系的团队可以伸出援手。
+InnerSource 促进了跨团队协作。它注重书面交流，即使在远程模式下也非常适合。
+
+在本节中，你将了解到敏捷开发和 InnerSource 使用类似的术语甚至技术，但在细节上却有很大不同。了解两者在文化和工具使用目的上的差异，将使你受益匪浅，而不是陷入常见的误解。
+
+你将了解 InnerSource 对能力规划的影响。此外，InnerSource 没有免费的午餐——托管团队需要时间来指导贡献者。我们还将探讨 InnerSource 带来的额外谈判可能性——保持 "投入与收益 "之间的平衡。
+
+让我们从一个简单的例子开始。想象一下，你正在开发一款新的可爱风音乐APP。为了了解用户与APP的交互情况，你开始收集一些交互日志。随着时间的推移，你在分析这些日志时会进行更深入的挖掘，并将学到的知识反馈到开发过程。现在，想象一下另一个将内容引入你的APP的团队也有一些需求——他们可能希望根据内容创作者接触到的用户数量来奖励他们。因此，他们也开始使用你收集的日志。但他们需要一些额外的分析步骤，而这是你一开始所没有想到的。他们现在面临着一个挑战：是建立一个变通办法，还是通过你的积压工作来优先处理他们的请求。有了 InnerSource，他们就有了第三种选择： 在你的帮助下自己进行更改。当然，这可能会比你自己修改要慢，但这仍然比等待你进行修改要快。</p>
+
+在理想的 InnerSource 组织中，你可以进一步扩大规模： 还记得上次必须在整个平台上进行横向关注点修改吗？如果采用“将其放入每个团队的Backlog”的方式，往往会感觉时间拖得很长；另一方面，它实质上是为这些团队提供一个实现修改的补丁，这会大大加快速度。在这种方法中，修改的复杂程度取决于组织的成熟度和代码的可维护性/模块化程度。

project-leader/zh/02-innersource-and-agile-zh.asciidoc

@@ -0,0 +1,75 @@
+== InnerSource 与敏捷
+
+你希望改进产品，更快地将其交付给客户，并让利益相关者满意。InnerSource 可帮助你的团队在高度互联的世界中实现价值并保持自主性。
+
+=== 互联世界中的自治团队
+
+组织试图快速向客户交付价值。一个常见的延迟原因是交付过程中的依赖关系。因此，组织更喜欢跨职能团队，涵盖客户沟通、设计、实施、测试和运营，从而消除昂贵的交接。为了实现高绩效，团队消除浪费并重复使用已有组件。从团队的角度来看，每个重复使用的组件都会给该团队增加一个其无法控制的依赖关系。这种优化的负面影响很明显：如果一个团队需要更改所使用的组件，则该团队依赖于另一个团队。为了能够实施这些计划，通常会安排冗长的路线图讨论，有时需要在全球范围内优化详细的优先级。在复杂的情况下以及在大型组织中，这会导致需要增加适应不断变化的业务需求的时间。对于非常受欢迎的核心组件，通常会收到非常多的请求，以至于一个核心组件团队无法实施对所有请求的响应。
+
+在传统组织中只有
+https://innersourcecommons.org/learn/learning-path/introduction/02/[两种方式来更改依赖] ：
+
+* 提交功能请求/错误报告，然后等待其他团队确定变更的优先级并实施。
+* 实现一个解决方法来避免错误或在本地提供所需的功能。
+
+如果这些方案都不成功，问题通常会升级，由更高层级来决定。
+
+这两种解决方案都不是特别令人满意。从开源的视角来看，有一个明显的解决方案：依赖组件的团队成为贡献者，并向该组件团队提供帮助。
+
+现在你可能会有这样的疑问：“这样做难道不会引起很大混乱，让人们会随意修改其他团队的代码库吗？”InnerSource 提供了一套角色和流程，使原本可能导致混乱的情况变得更加清晰：
+
+* 每个 InnerSource 项目都有一组职责明确的受信任提交者，他们的职责不仅仅是简单地审查代码，还要制定贡献规则。
+* 贡献以有组织的方式进行：
+** 尽早交流贡献意向，确保贡献符合项目的愿景和范围。
+** 尽早分享进展，项目主办团队就有机会指导贡献者，引导他们实现理想的设计和架构；这样就能避免在后期因拒绝贡献而产生的挫败感。
+** 决策和重要沟通异步进行，以便能够解决不同团队中人员的不同会议安排。因此，贡献团队获得了修复上游组件的自主权，而又不会牺牲所贡献组件的质量。
+
+此外，InnerSource 还为团队提供最佳实践，让团队在远程文化中轻松工作。
+
+=== InnerSource 方法的优点
+
+InnerSource 鼓励团队之间相互协作，而不是各自为政。就像在开源领域一样，这意味着要站在巨人的肩膀上：InnerSource 鼓励复用，而不是在本地重复构建每个组件。它提供了一条明确的途径，支持上游团队修复错误和实现功能，从而降低了重复使用的成本。
+
+就像在开源领域一样，InnerSource 培养了一种联合力量的思维： 所有业务部门和产品团队所需的基础组件都可以共同构建。因此，百舸争流：组织中某个部门的创新可以为整个公司创造效益。有了熟悉 InnerSource 的团队，所有团队都可以分担推进此类创新的重任，并从中受益，依赖于由此产生的组件和服务。
+
+InnerSource 为你的团队提供了主动性和工具，以解决阻碍向客户交付功能的问题。如果方法得当，核心组件和服务的维护工作可以由一个“虚拟 InnerSource 团队”以结构合理的方式共享，该团队的规模要大于任何特定的产品团队。
+
+在高级设置中，相关人员理解贡献者开发较简单功能的价值，这些功能可能不会直接惠及他们的客户-——但前提条件是，这可以让托管团队腾出时间来开发贡献者有业务需求的更复杂的变更。
+
+=== InnerSource 会取代敏捷吗？
+
+直接答案： 完全不是。恰恰相反，两者相辅相成：
+
+精心设计和经过充分测试的代码是所有敏捷团队的目标之一。在 InnerSource 设置中，团队成员以及团队外部贡献者的上岗都会变短。
+
+熟悉协作、避免分配任务的团队也能以灵活的方式处理外部贡献。此外，他们的思维方式和沟通方式也能很好地激励那些他们无法直接影响其优先级的贡献者。利用内在动力而不是指挥工作，意味着项目主办团队拥有与贡献者成功合作的工具。
+
+结对解决问题的团队已经习惯于尽早分享进展。从结对文化转向 InnerSource 有两个挑战：项目主办团队需要为支持贡献者安排时间，并将其纳入计划工作。此外，当跨越团队边界时，往往很难找到刚好匹配的时间段——在这种情况下，应辅之以异步协作。在 InnerSource 环境中，为了避免频繁的干扰，主办团队成员往往需要有意识地更严格地规划自己的一天。通常，最简单的方法是在一天中留出某些时间或每周留出一天用于指导贡献。在团队层面明确规定这一点，既能减轻工程师的压力，让他们努力实现自己的团队目标，又能帮助贡献者。结对的另一个挑战是，它允许结对人员一起快速行动，但这往往以为团队其他成员写下重要信息为代价。在 InnerSource 环境中，确实需要进行培训，以牢记将所有相关决策带回共享的沟通渠道，供团队和贡献者双方使用。从产品的角度来看，这确实会提高开发过程的透明度。这也意味着，原本可能只在工程层面做出的决策，现在对所有相关人员都是可见的。
+
+还记得上次你坚持要对产品进行完善的测试，最好是自动化测试，这样就可以在无需人工干预的情况下频繁部署产品了吗？现在，这一目标对 InnerSource 也有帮助：如果贡献者可以在本地检查他们的修改是否安全，那么贡献就会容易得多。测试还能确保托管团队在测试失败的情况下记得保留所贡献的功能。
+
+还记得上次你坚持让团队花时间遵循“让代码变得比你发看到它时更好”的目标吗？这种心态有助于 InnerSource 模型：它能确保代码的质量和凝聚力，即使有来自不同来源的多种贡献，也能保持较高水平。
+
+=== 来自敏捷团队的常见误解 
+
+InnerSource 和敏捷使用一些相同的工具，但目的不同。
+
+==== 语言重叠的影响
+
+问题跟踪：在敏捷团队中，用户故事是与客户的对话。通常它们会作为便签贴在白板上。但它们通常也存储在问题跟踪器中。因此，问题跟踪器主要被视为规划工具，本质上是白板上便签的替代品。在 InnerSource 中，问题跟踪器用于与客户进行对话，还用于在一个公共 InnerSource 组件上工作的受信任提交者和贡献者团队的成员之间进行通信。 InnerSource 中的问题比一般组织中的问题更加冗长和啰嗦。他们还跟踪变更的实施历史和详细设计决策。
+
+代码评审： 在传统组织中，代码审查通常是出于审计目的。
+
+当开发完成时，代码评审就完成了。在 InnerSource，代码变更在开发过程的早期就会共享，有时甚至只完成了一个粗略的草图。这样做的目的是寻求早期反馈和指导。这对那些日程安排繁多、没有时间结对编程的团队特别有帮助。团队通常都有一个愿望，那就是没有人是孤独前行的，但在现实中，这往往只是一个从未实现的愿望，特别是当贡献跨越团队界限时。
+
+InnerSource 中使用的工具可以将这一要求正式化，即任何变更都必须有不止一个人参与。
+
+注重书面沟通：InnerSource 的目标是让项目足够透明，以便非团队成员的开发人员能够理解项目决策并遵循软件创建过程。因此，所有沟通都需要放在每个对对话感兴趣的人都可以跟进的地方：书面的、公开的、可搜索的和可链接的。目标不是减少对他人的干扰——目标是使所有项目对话透明。
+
+因此，应避免直接消息和邮件。为了使每个人都能更轻松地进行后续对话，应在一个单独的沟通渠道中跟踪与一个 InnerSource 项目相关的消息：目标并非触达 InnerSource 项目团队中的每个人，而是为参与该项目的每个人找到一个共同的共享房间，他们可以在那里重点讨论该 InnerSource 项目。
+
+注重书面交流并不意味着不允许口头交流，仍然需要时间一起喝杯咖啡。此外，一起解决问题、与他人结对或亲自参加黑客马拉松对于快速找到解决方案也很有价值。团队需要确保所有项目相关决策都保存在每个人都可以访问的渠道中。这也可能意味着推迟重要的项目决策，直到每个人都休假回来，或者如果在另一个国家工作的人现在正在度假，则需要再等待一两天。这不仅与编码决策相关，还与总体项目任务、路线图和方向相关。如果没有这些信息，贡献者将很难理解哪些贡献将有很好的机会被接受。
+
+==== 信任的影响
+
+InnerSource 项目中的所有讨论对公司中的每个人都是可见的。指责、嘲笑嘲笑他人的错误，在背后谈论他们做错的事情，肯定会扼杀这种信任，并导致 InnerSource 项目的失败。这对于任何处于领导或榜样地位的人来说尤其重要。

project-leader/zh/03-capacity-planning-zh.asciidoc

@@ -0,0 +1,34 @@
+== InnerSource 与规划
+
+在 InnerSource 中，规划在两种重要情况下发挥着作用：
+
+贡献团队需要明白，处理上游代码通常比对他们自己熟悉的代码库进行类似的更改花费更多的时间。他们需要意识到这样一个事实：即使主办团队不必实施变革，他们仍然需要接受指导和审查。耗费的时间随所需更改的大小而增加。因此，与主办团队的早期沟通非常重要，特别是在发生较大变更的情况下。
+
+主办团队还需要了解指导和审查所需的时间。简单地告诉贡献团队他们可以将更改作为补丁提交并不会减少主办团队将更改为零的时间。此外，主办团队可能会发现自己处于一种罕见的情况，即他们被大量的拉取请求淹没。对于该事件，需要清楚地了解发送这些拉取请求的项目的业务优先级。当补丁不堪重负时，通常需要考虑共享组件的所有权。特别是定期参与并赢得主办团队信任的贡献者是获得“可信提交者”称号的良好候选人。
+
+不过，由于工作文化略有不同而产生的一些摩擦是不可避免的。此时明确设定期望值就非常重要。
+
+
+=== 设定期望
+
+想象一下以下情况：作为贡献者，你最终做出了所需的更改——可能需要主办团队的一点帮助。你自豪地提交了拉取请求。然后——什么也没发生。一天后——仍然没有反应。你开始想知道主办团队是否已经看到了该补丁。你想知道在哪里可以最好地向主办团队传达更新信息。这种沉默非常令人沮丧，尤其对于首次贡献者来说。对于这种情况有几种补救措施——无需编码知识，但至少需要一些基本的沟通技巧：
+
+* 明确主办团队的预期响应时间——例如在贡献文档中。
+* 一旦收到拉取请求，就告知收到实质性反馈所需的预期时间，而不是让贡献者等待。
+* 为贡献者提供与主办团队的沟通渠道，并在该渠道关注正在发生的沟通。
+
+这些任务都不需要编码技能，这强调了对具有编程知识之外的人员的需求。最好将负责这些任务的人员视为对 InnerSource 项目的承诺，并将他们也视为可信提交者。
+
+=== 小变更与大变更
+
+小的更改和补丁很容易处理——它们可以快速审查，并且在合并时通常不会带来很大的风险。帮助托管团队的方法之一是腾出时间将变更分成更小的块。不过，请确保传达了这些更改所需要的完整背景信息。
+
+通常，做出更大的变更需要尽早传达意图和目的，确保贡献团队和主办团队留出足够的时间来共同应对变更也是很有益的。这意味着设定团队优先级的人在确定变更优先级时需要超越自己的团队视角。然而，协调仍然可以相当独立地进行，因为通常只有贡献团队和主办团队参与。
+
+=== 围绕 InnerSource 项目扩大团队规模
+
+主办团队很少会遇到从贡献团队接收过多补丁的难题。在这种情况下，考虑将可信贡献者发展为可信提交者角色会有所帮助。除了帮助审核，新的可信提交者还可以帮助分流问题、指导新的贡献者等。
+
+当面对大量的贡献意向时，在优先考虑对贡献者的指导帮助时，还有一个因素需要考虑，那就是贡献者是否有兴趣与主办团队建立长期关系。指导所需的时间越长，贡献者就越有可能坚持更长时间。
+
+在实践中，与非常活跃的贡献者共享组件的所有权，已被证明能让新加入的可信贡献者在更长的时间内参与到项目中来。通常情况下，在最初的贡献动机得到满足之后，他们还会帮助保持组件的更新，并长期指导新的贡献者。