Merge pull request #722 from node/patch-zh

Translate 3 patterns into Chinese

translation/zh/patterns/extensions-for-sustainable-growth.md

@@ -0,0 +1,117 @@
+## Title
+
+通过扩展实现可持续增长
+
+## Patlet
+
+InnerSource 项目收到了太多的贡献，这会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以用最小的成本和维护开销扩展项目功能。
+
+## 问题
+
+随着对成熟 InnerSource 代码库的贡献数量迅速增加，代码评审和维护的负担也随之加重。这将导致大量代码评审任务积压或过早拒绝新功能贡献。
+
+项目团队如何才能更快地发布新功能、鼓励创新和实验，同时又能很好地维护代码库呢？
+
+## 故事
+
+有一个战略性项目，旨在将某一领域内的最佳创新集合到一个通用栈中，从而实现通用基础架构的重复使用，并提供标准的用户体验。通过 InnerSource，组织内从事该领域工作的各个团队都有机会开展合作，并将自己的创新成果贡献给通用代码库。
+
+然而，当多位开发者同时进行大量并行贡献时，代码库的维护变得愈发复杂。这种情况给项目维护者带来了巨大的挑战。他们不仅要肩负确保代码质量的重任，还需要通过多种沟通渠道积极促进社区的健康发展。
+
+项目维护人员面临职业倦怠的风险，原因如下：
+
+- 待评审的贡献者 PR 不断积压。
+- 工作不满意： 维护者的大部分时间都花在社区支持上，没有创新的空间。
+- 缺乏成就感： 并非所有贡献的功能都有足够的用户需求，并因此被采用。
+- 发布耗时： 代码库中的功能越多，测试时间就越长。
+- 维护活动增加： 随着新功能的增加，会出现更多错误。
+
+我们常常在新功能正式发布前，投入大量时间对其进行完善和优化。然而，这种做法存在一定风险：如果这些精心打造的功能最终无法满足潜在用户的实际需求，那么我们为追求卓越代码质量所付出的努力可能就会付诸东流。
+
+## 上下文
+
+- 一个具有战略意义的 InnerSource 代码库正随着多名员工对新功能的贡献而迅速扩展。
+- 评审人员与贡献者的比例悬殊导致 PR 积压越来越多，这拖慢了向社区发布新功能的速度。
+- 代码库质量下降，用户体验受到负面影响。
+- 代码库维护人员不堪重负，无法及时应对大量贡献和社区支持的增加。
+- 一些贡献的功能没有得到用户的采用，甚至可能完全处于休眠状态。然而，即使这些功能未被使用，它们仍然会增加维护开销。
+- 组织正在投入巨资强化新功能的贡献，以便在社区探索这些想法之前保持质量标准。
+- 这种模式适用于任何一种情况：
+   - 维护者发现自己经常拒绝新功能提议，以控制项目规模。然而，这可能会抑制社区创新，限制项目的发展潜力。
+   - 为了减少项目积压，新功能在没有完整文档、加固或测试的情况下就被发布，造成了糟糕的用户体验。这也在扩大代码库的规模，增大依赖关系图，使其难以维护。
+
+## 约束
+
+- 维护者和产品所有者希望允许扩展、鼓励创新和试验，但又不过于限制贡献，同时还要保持良好的代码和质量标准，以保证用户体验。
+- 为达到产品标准，需要花费大量时间对功能进行加固和全面测试，但产品所有者可能希望在投入时间使功能成熟之前，允许更快地发布新的创新，供采用产品的用户探索。
+- 维护者希望鼓励社区分享将产品功能与其他用例相结合的创新，而不给主代码库增加更多的依赖性。
+
+## 解决方案
+
+允许[扩展/插件](https://en.wikipedia.org/wiki/Extensibility)进入大规模的 InnerSource 代码库，可以减轻代码库维护者的维护负担，并允许更快地发布新功能供采用产品及探索。这就将功能的维护工作转移给了扩展所有者，并允许主代码库支持已被更广泛采用且更具战略性的功能。
+
+扩展机制为潜在的核心功能提供了一个有效的筛选渠道。它不仅充当了新功能的孵化器，还为社区创造了一个自然的强化环境。这种方式使得大量功能完善和优化工作能够在一个更加开放和灵活的环境中自然进行，避免了在耗时耗力的正式评审过程中进行这些工作。
+
+为了使扩展模式取得成功，在架构上有一些注意事项需要牢记：
+
+1. **易于创建：** 为了获得社区参与，扩展需要易于创建。
+   - 创建一个初始扩展的代码库模板，作为新扩展的起点。这允许扩展在新代码库中添加新功能，与核心项目分开。该模板应提供与主代码库相同的模块化结构，并包含打包和发布扩展的框架。
+   - 确保随着主代码库的变更，模板得到良好维护。主代码库维护人员负责更新模板以确保其与主项目兼容。遵循良好的版本控制约定，例如 [semver](https://semver.org/)，可以使这更容易遵循。
+   - 建议主代码库的维护团队提供详细的指南，阐明如何在新版本发布时，基于旧版本的模板对扩展进行更新。
+   - 添加从模板开发的示例扩展，项目开发人员可以参考这些扩展来了解如何编写模式良好的扩展。
+   - 放宽对贡献者创建扩展的要求，绕过评审，以实现更快的发布或试验。
+2. **低耦合：** 拥有包含功能的模块化组件可以允许松散耦合，其中扩展的更改不会影响主代码库或其他扩展的质量。
+3. **依赖管理：** 每个扩展都应谨慎地指定其所依赖的主代码库版本范围，就如同处理其他依赖项一样。在选择其他依赖项时，也要特别注意与主代码库的依赖关系，确保所选版本与指定的主代码库版本相兼容。这种做法不仅能够保证扩展的稳定性，还能通过扩展的测试框架有效地捕获与主代码库之间可能存在的任何冲突。
+4. **测试策略：** 如何单独和组合测试扩展？
+   - **单独测试扩展：** 扩展模板将提供一个测试框架，供扩展开发人员用来测试添加的功能。这可以包括单元测试、运行时性能和质量测试的框架。
+   - **与主代码库结合测试扩展：** 扩展开发人员有一种模式良好的方法，可以针对主代码库的特定版本测试其扩展，而无需主代码库维护人员的参与。
+   - **与其他扩展结合测试扩展：** 为每个扩展提供全面的测试框架可能会显得过于繁重。如果扩展之间保持适度的松散耦合，冲突的可能性本来就较低。然而，若用户在组合使用扩展时遇到冲突，他们可以直接向相关扩展的维护者报告问题，由这些专业人士来解决兼容性问题。值得注意的是，当扩展发展到生命周期的后期阶段，并有机会被合并到主代码库时，它将与库的其他部分一起进行全面测试。在这个关键阶段，所有潜在的依赖冲突必须得到彻底解决，以确保整个系统的稳定性和一致性。
+5. **可发现性和可用性：**
+   - 通过显示用户已创建并希望共享以供产品使用的扩展的发布页面，使扩展易于被发现。
+   - 允许在主项目中注册扩展，以便用户可以在原始项目中利用扩展，从而保持相同的用户体验。
+6. **扩展的生命周期和可维护性：** 建立扩展从创建到移植到主代码库的生命周期，以及明确的所有权准则。
+   - 扩展创建者继续维护扩展，提供任何支持并修复缺陷。任何未维护的扩展都不会从发布页面列出。
+   - 创建何时可以将扩展移植到主代码库的标准，例如内部产品对扩展的采用以及对该功能的需求。
+   - 扩展到主代码库的移植过程将遵循库维护人员制定的更严格的代码评审指南。
+
+![可扩展软件架构](../../../assets/img/extensions-for-sustainable-growth/extensions-for-sustainable-growth.png)
+
+遵循这些原则可确保：
+
+- 开发人员无需编写大量[样板](https://en.wikipedia.org/wiki/Boilerplate_code)代码，即可为项目生态系统添加新功能。
+- 主项目的所有用户都能以可重复的方式发现扩展功能；代码还没有合并入主库并不意味着它没有价值。
+- 维护者的负担会减轻，直到扩展证明它填补了主项目中的重要空白。
+- 核心项目的通用代码（如基类和实用功能）可以作为扩展项目领域的新开发的起点。这就避免了事后移植创新工作的需要，从而减轻了为项目开发新功能的总体负担。
+- 开发人员更有可能为他们的代码库做出贡献，并继续参与维护和社区建设，这也有利于整个项目生态系统的健康发展。
+
+## 结果背景
+
+- 项目能够通过增加新功能来扩展，同时不会增加主项目代码库的维护成本。
+- 更快地发布新功能供社区探索，鼓励创新和试验。
+- 将耗时且成本高昂的代码审查和功能完善过程推迟到功能已经证明其实用价值之后， 以有效降低企业的投入。
+- 可能引入的一个后置问题——如果扩展无法完成一个完整的生命周期，会怎么样？
+   - 如果一个扩展在一段时间内没有被采用，也无法围绕它建立一个支持维护的社区，那么就需要扩展所有者在他们希望的任何时间内继续维护它。如果扩展没有得到维护，就会被取消发布。
+   - 如果扩展开发者无法继续维护其项目，而社区中的其他开发者希望继续支持该扩展，他们可以继续维护该扩展。
+
+## 已知实例
+
+* **IBM 公司**采用了这一解决方案来扩展[InnerSource 人工智能类库](https://youtu.be/Lz-tIc2cyRM)。扩展库为开发人员提供了一个灵活的平台，使他们能够通过添加新算法来丰富人工智能类库的功能。这不仅促进了技术创新，还为公司内部社区创造了分享和交流的机会。与此同时，核心库保持精简，仅包含经过充分验证和广泛采用的关键算法。这种结构设计确保了在项目规模不断扩大、贡献者增多的情况下，核心库仍然易于维护和管理。
+
+## 别名
+
+管理大规模贡献的扩展
+
+## 状态
+
+结构化
+
+## 作者
+
+- Sukriti Sharma, IBM
+- Alexander Brooks, IBM
+- Gabe Goodhart, IBM
+
+## 翻译校对
+
+- **2024-10-10** 翻译[Chris Yang](https://github.com/node)
+- **2024-10-12** 校对[姜宁](https://github.com/willemjiang)

translation/zh/patterns/group-support.md

@@ -0,0 +1,91 @@
+## Title
+
+小组支持
+
+## Patlet
+
+如果某个团队或个人不再支持 InnerSource 项目怎么办？
+由一群感兴趣的个人组成小组来保持项目活跃。
+
+## 问题
+
+* 即便是一个广受欢迎的 InnerSource 项目也可能陷入孤立的困境。
+* 当前没有明确的出路。
+
+## 故事
+
+一个 UI 组件类库，在全公司有 50 多个项目使用。
+该类库的开发团队在资源耗尽后，宣布解散。
+起初，没有人注意到，但过了一段时间，每当有人问“谁负责它”时，得不到答案。
+接下来会怎么样？
+新的团队会避免使用它吗？
+该项目是否会停滞不前，直到其用户最终被迫转向其他项目？
+如果一个完美且有价值的项目出现这种情况，那将是多么令人遗憾！
+
+## 上下文
+
+* 广受欢迎的 InnerSource 项目。
+* 作为一个构件时的依赖项使用（比如 代码模块）。
+* 没有活跃的开发者提供支持。
+* 公司无法指派团队提供支持。
+
+## 约束
+
+* 没有人在日常工作中被指派负责这项工作。
+* 每个人都很忙。
+* 项目迁移的成本很高。
+
+## 解决方案
+
+面向全公司征集感兴趣的志愿者，组成一个 [可信任提交者][] 小组来支持该项目。
+可能需要根据提交或使用的历史记录联系特定的个人。
+重要的一点是要有足够的数量，这样每个人的负担可以相对较小。
+
+该小组成立后，应确定或创建[标准基础文档][]和[沟通工具][]。
+
+团队应尽全力从以下方面管理项目：
+
+* **维护**.  如果项目在标准用例中完全失效，那就修复它。
+随着项目使用的依赖关系和框架的不断发展，及时更新项目。
+* **新人上手**.  如果有人对如何使用项目有疑问，确保他们能得到合理的答复。
+* **更新**.  如果有人想在项目中添加新功能，请为他们提供必要的设计和技术支持，以便他们实现该新功能，使其既能为自己所用，又能为项目增光添彩。
+及时评审收到的 PR。
+
+由于该小组由志愿者组成，因此重要的是要传达提供“尽力而为”的支持。
+因此，这种支持模式不太适合像实时 API 这类运行时关键的生产项目。
+它更适合在构建时使用的项目，例如类库/包/模块。
+该小组预计不会为其他人实现任何新功能。
+
+## 结果背景
+
+* 对 InnerSource 项目有些微弱的支持。
+* 从长远来看，小组支持可能会在某个时候再次解散。如果该项目长期持续下去，那么就利用这段稳定的小组支持期，找到一种长期支持的方式（比如 [核心小组][]）。
+
+## 理由
+
+人们通常都愿意提供帮助。
+如果有人邀请某个人是否愿意加入成为[可信任提交者][]，通常会有很多人回答“是的”。
+感受到自己是集体的一员，并在组织结构上体现和被赋予一定的责任，通常会激励人们尽最大努力，很多时候这就已经足够了。
+
+## 已知实例
+
+* WellSky
+
+## 状态
+
+结构化
+
+## 作者
+
+[Russell R. Rutledge][]
+
+[Russell R. Rutledge]: https://github.com/rrrutledge
+[标准基础文档]: ./base-documentation.md
+[沟通工具]: ./communication-tooling.md
+[可信任提交者]: ./trusted-committer.md
+[核心小组]: ./core-team.md
+
+## 翻译校对
+
+- **2024-10-10** 翻译[Chris Yang](https://github.com/node)
+- **2024-10-12** 校对[姜宁](https://github.com/willemjiang)

translation/zh/patterns/release-process.md

@@ -0,0 +1,74 @@
+## Title
+
+标准发布流程
+
+## Patlet
+
+如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。
+
+## 问题
+
+当一个团队决定是否使用 InnerSource 项目时，他们的考虑因素之一是他们是否可以长期依赖于该项目。更换他们正在使用的工具/项目是有成本的，因此他们只希望在必要时进行这些投资，并获得切实的收益。
+
+开源项目的通常做法是按版本发步，并在发行说明中记录破坏性变更和新功能，同时发布二进制文件或 Docker 镜像链接。对于 InnerSource 项目、模块等来说，这种做法可能不那么透明，或没有很好的文档化/可见性。
+
+缺乏明确的发布制品或规范的发布流程的 InnerSource 项目往往会削弱团队间的信任。在这种情况下，其他团队难以预知下一个版本的发布时间，也无法准确把握可能出现的破坏性变更。
+
+## 上下文
+
+大型组织会生产大量的内部软件，其中很多软件都可以被整个公司的团队重复使用。运维工具、软件库和基础设施即代码（IaC）模块就是这类软件的常见例子。然而，大多数大型企业不会发布内部软件供公司其他团队使用。出现这种情况的原因可能是他们太忙，没有时间提供文档，或者没有意识到项目对其他人的价值。
+
+应该有一个内部或公共代码库来存储源代码，但团队缺乏一个让外部团队使用软件的流程。
+
+随着组织的发展和更多内部软件的编写，这种模式的价值也在增加。
+
+## 约束
+
+### 对于没有集中式 CI/CD 系统的组织来说很困难
+
+对于没有为工程师提供集中式 CI/CD 系统的组织而言，自动化构建和发布流程可能具有挑战性。团队可能需要建立自己的工具（Jenkins、Drone 等）。在没有 CI/CD 系统的情况下，仍然可以制作制品和发行说明，但可能需要在本地构建软件，并手动上传到托管制品的工具。
+
+### 增加了发布发行说明的负担
+
+除了构建源代码之外，如果无法自动生成 git 提交列表，编写发行说明可能会很枯燥。除了编写更多发布细节之外，还需要其他人手动完成。
+
+### 没有地方来托管制品增加了难度
+
+如果公司没有提供一个集中位置来存储制品（jar、npm 模块等）和 docker 镜像，工程师可能需要自己决定在哪里适合存储各版本软件。 GitHub 等工具可以提供此功能，但是，如果公司不使用这些流行工具之一，这可能会造成负担。
+
+## 解决方案
+
+通过提供清晰的**发行说明**和已发布的制品，可以增强人们的信心，让他们相信你发布的是值得信赖的优质产品。。
+
+以下是实现这一目标的关键要素：
+
+- 代码库中包含一个 CI/CD 流水线配置，可[自动化执行发布流程](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks)
+- 由 CI/CD 系统来生成制品（二进制、docker 镜像、jar 等等）
+- 发布的版本有清晰的标签，和[语义化的版本标记](https://github.com/semantic-release/semantic-release)
+- 发布内容包括新功能说明、错误修复和所有的“破坏性变更”。
+
+[这里](https://github.com/jaegertracing/jaeger/releases) 提供了一个高质量发行说明的范例。
+
+## 结果背景
+
+接触到您项目的团队会看到已发布的发行说明，并对您的工具充满信心。已发布的制品也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。
+
+发行说明也是[表扬参与者](praise-participants.md)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](base-documentation.md)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。
+
+## 已知实例
+
+* Comcast （多个项目）
+* GitHub （多个项目）
+
+## 作者
+
+David Grizzanti
+
+## 状态
+
+结构化
+
+## 翻译校对
+
+* **2024-10-08** 翻译[Chris Yang](https:github.com/node)
+* **2024-10-12** 校对[姜宁](https://github.com/willemjiang)