From c37fe3f5fed7be4fe1b8bca74e27e7c401c6924f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Mon, 30 Sep 2024 18:18:52 +0800
Subject: [PATCH 01/23] Create release-process.md

---
 translation/zh/patterns/release-process.md | 75 ++++++++++++++++++++++
 1 file changed, 75 insertions(+)
 create mode 100644 translation/zh/patterns/release-process.md

diff --git a/translation/zh/patterns/release-process.md b/translation/zh/patterns/release-process.md
new file mode 100644
index 000000000..339526146
--- /dev/null
+++ b/translation/zh/patterns/release-process.md
@@ -0,0 +1,75 @@
+## Title
+
+标准发布流程
+
+## Patlet
+
+如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。
+
+## 问题
+
+When a team is deciding whether to use an InnerSource project, one of their considerations is whether they can rely on the given project for an extended period. Switching the tools/projects that they are using has a cost, so they only want to make those investments when necessary and has tangible benefits.
+
+It is common practice for Open Source projects to have versioned releases, with notes documenting breaking changes, and new features along with either a published binary or link to a Docker image. This practice may not be as transparent or well documented/visible for InnerSource projects, modules, etc.
+
+InnerSource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, etc.
+
+## 上下文
+
+Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of this type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy to provide documentation or don't realize the projects value to others.
+
+An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams.
+
+As an organization grows and more internal software is written, the value of this pattern grows.
+
+## 约束
+
+### 对于没有中心化 CI/CD 系统的组织来说很困难
+
+For organizations that don't provide engineers a centralized CI/CD system, automating a build and release process can be challenging. The team may need to stand up their own tool (Jenkins, Drone, etc). Without a CI/CD system, builds and release notes can still be produced, however, it may require a local build of the software and manual upload to whichever tool is hosting build artifacts.
+
+### 增加了发布发行说明的负担
+
+In addition to building your source code, writing release notes can be tedious without the ability to auto-generate a list of git commits. This would be left for someone to do manually, in addition to writing more high level details on a release.
+
+### 没有位置来托管制品增加了难度
+
+If a company does not provide a centralized location for storing build artifacts (jars, npm modules, etc.) and docker images, engineers may be left deciding for themselves where is appropriate to store versioned software. Tools like GitHub provide this for you, however, if a company is not using one of these popular tools, this could pose a burden.
+
+## 解决方案
+
+By providing clear **release notes** and a published artifact you increase people's confidence that you are publishing a quality product that they can rely on.
+
+The following are key elements to achieve this:
+
+- A CI/CD pipeline is located within your repository that [automates the release process](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks)
+- Build artifacts are generated by the CI/CD system (binary, docker image, jar, etc)
+- Releases are clearly labeled and tagged with [semantic versioning](https://github.com/semantic-release/semantic-release)
+- Releases include notes on New Features, Bug Fixes, and any "Breaking Changes"
+
+A good example of quality release notes can be found [here](https://github.com/jaegertracing/jaeger/releases).
+
+## 结果背景
+
+Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
+接触到您项目的团队会看到发布的发布说明，并对您的工具充满信心。发布的工件也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。
+
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+发行说明也是[表扬参与者](raise-participants.md)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](base-documentation.md)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。
+
+## 已知实例
+
+* Comcast （多个项目）
+* GitHub （多个项目）
+
+## 作者
+
+David Grizzanti
+
+## 状态
+
+结构化
+
+## 翻译校对
+
+* **2022-12-08** 翻译[Chris杨振涛](https:github.com/node)

From 6083aa6016d401eb59a7441d11c3b328d3f0201b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Tue, 8 Oct 2024 15:14:32 +0800
Subject: [PATCH 02/23] finish release-process.md translation work

---
 translation/zh/patterns/release-process.md | 44 +++++++++++-----------
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/translation/zh/patterns/release-process.md b/translation/zh/patterns/release-process.md
index 339526146..ed388cb3b 100644
--- a/translation/zh/patterns/release-process.md
+++ b/translation/zh/patterns/release-process.md
@@ -8,53 +8,51 @@
 
 ## 问题
 
-When a team is deciding whether to use an InnerSource project, one of their considerations is whether they can rely on the given project for an extended period. Switching the tools/projects that they are using has a cost, so they only want to make those investments when necessary and has tangible benefits.
+当一个团队决定是否使用 InnerSource 项目时，他们的考虑因素之一是他们是否可以长期依赖于该项目。更换他们正在使用的工具/项目是有成本的，因此他们只希望在必要时进行这些投资，并获得切实的收益。
 
-It is common practice for Open Source projects to have versioned releases, with notes documenting breaking changes, and new features along with either a published binary or link to a Docker image. This practice may not be as transparent or well documented/visible for InnerSource projects, modules, etc.
+开源项目的通常做法是按版本发步，并在发行说明中记录破坏性变更和新功能，同时发布二进制文件或 Docker 镜像链接。对于 InnerSource 项目、模块等来说，这种做法可能不那么透明，或没有很好的文档化/可见性。
 
-InnerSource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, etc.
+没有发布制品或发布流程的 InnerSource 项目会降低信任度。团队不知道何时会发布下一个版本，何时会引入破坏性变更等。
 
 ## 上下文
 
-Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of this type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy to provide documentation or don't realize the projects value to others.
+大型组织会生产大量的内部软件，其中很多软件都可以被整个公司的团队重复使用。运维工具、软件库和基础设施即代码（IaC）模块就是这类软件的常见例子。然而，大多数大型企业不会发布内部软件供公司其他团队使用。出现这种情况的原因可能是他们太忙，没有时间提供文档，或者没有意识到项目对其他人的价值。
 
-An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams.
+应该有一个内部或公共代码库来存储源代码，但团队缺乏一个让外部团队使用软件的流程。
 
-As an organization grows and more internal software is written, the value of this pattern grows.
+随着组织的发展和更多内部软件的编写，这种模式的价值也在增加。
 
-## 约束
+## 约束 
 
-### 对于没有中心化 CI/CD 系统的组织来说很困难
+### 对于没有集中式 CI/CD 系统的组织来说很困难
 
-For organizations that don't provide engineers a centralized CI/CD system, automating a build and release process can be challenging. The team may need to stand up their own tool (Jenkins, Drone, etc). Without a CI/CD system, builds and release notes can still be produced, however, it may require a local build of the software and manual upload to whichever tool is hosting build artifacts.
+对于没有为工程师提供集中式 CI/CD 系统的组织而言，自动化构建和发布流程可能具有挑战性。团队可能需要建立自己的工具（Jenkins、Drone 等）。在没有 CI/CD 系统的情况下，仍然可以制作制品和发行说明，但可能需要在本地构建软件，并手动上传到托管制品的工具。
 
 ### 增加了发布发行说明的负担
 
-In addition to building your source code, writing release notes can be tedious without the ability to auto-generate a list of git commits. This would be left for someone to do manually, in addition to writing more high level details on a release.
+除了构建源代码之外，如果无法自动生成 git 提交列表，编写发行说明可能会很枯燥。除了编写更多发布细节之外，还需要其他人手动完成。
 
-### 没有位置来托管制品增加了难度
+### 没有地方来托管制品增加了难度
 
-If a company does not provide a centralized location for storing build artifacts (jars, npm modules, etc.) and docker images, engineers may be left deciding for themselves where is appropriate to store versioned software. Tools like GitHub provide this for you, however, if a company is not using one of these popular tools, this could pose a burden.
+如果公司没有提供一个集中位置来存储制品（jar、npm 模块等）和 docker 镜像，工程师可能需要自己决定在哪里适合存储各版本软件。 GitHub 等工具可以提供此功能，但是，如果公司不使用这些流行工具之一，这可能会造成负担。
 
 ## 解决方案
 
-By providing clear **release notes** and a published artifact you increase people's confidence that you are publishing a quality product that they can rely on.
+通过提供清晰的**发行说明**和已发布的制品，可以增强人们的信心，让他们相信你发布的是值得信赖的优质产品。。
 
-The following are key elements to achieve this:
+以下是实现这一目标的关键要素：
 
-- A CI/CD pipeline is located within your repository that [automates the release process](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks)
-- Build artifacts are generated by the CI/CD system (binary, docker image, jar, etc)
-- Releases are clearly labeled and tagged with [semantic versioning](https://github.com/semantic-release/semantic-release)
-- Releases include notes on New Features, Bug Fixes, and any "Breaking Changes"
+- 代码库中包含一个 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)
+- 发布内容包括新功能说明、错误修复和所有的“破坏性变更”。
 
-A good example of quality release notes can be found [here](https://github.com/jaegertracing/jaeger/releases).
+[这里](https://github.com/jaegertracing/jaeger/releases) 提供了一个高质量发行说明的范例。
 
 ## 结果背景
 
-Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
-接触到您项目的团队会看到发布的发布说明，并对您的工具充满信心。发布的工件也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。
+接触到您项目的团队会看到已发布的发行说明，并对您的工具充满信心。已发布的制品也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 发行说明也是[表扬参与者](raise-participants.md)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](base-documentation.md)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。
 
 ## 已知实例
@@ -72,4 +70,4 @@ David Grizzanti
 
 ## 翻译校对
 
-* **2022-12-08** 翻译[Chris杨振涛](https:github.com/node)
+* **2022-12-08** 翻译 [Chris Yang](https:github.com/node) 

From 7573adcfce7989bff58b4e4353e9923b54b6c756 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Thu, 10 Oct 2024 11:58:20 +0800
Subject: [PATCH 03/23] Create group-support.md

---
 translation/zh/patterns/group-support.md | 91 ++++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 translation/zh/patterns/group-support.md

diff --git a/translation/zh/patterns/group-support.md b/translation/zh/patterns/group-support.md
new file mode 100644
index 000000000..a31687c9a
--- /dev/null
+++ b/translation/zh/patterns/group-support.md
@@ -0,0 +1,91 @@
+## Title
+
+群体支持
+
+## Patlet
+
+如果某个团队或个人不再支持 InnerSource 项目怎么办？
+由一群感兴趣的个人组成小组来保持项目活跃。
+
+## 问题
+
+* 一个流行的 InnerSource 项目成为孤立项目。
+* 当前没有明确的出路。
+
+## 故事
+
+A library of UI widgets is used by over 50 projects throughout the company.
+The funding for the team that owns the library runs out and the team disbands.
+At first, no one notices, but after a while whenever someone asks "who owns it" there isn't an answer.
+What will happen next?
+Will new teams shy away from using it?
+Will the project stagnate and linger until its users eventually are forced to move on to something else?
+What a shame if that were to happen to a perfectly good and useful project!
+
+## 上下文
+
+* Popular InnerSource project.
+* Consumed as a build-time dependency (e.g. code module).
+* No one is actively supporting it.
+* The company cannot assign a team to support.
+
+## 约束
+
+* No one is assigned by their day job to work on it.
+* Everyone is busy.
+* High cost to migrate off the project.
+
+## 解决方案
+
+Call for interested volunteers from anywhere in the company to form a group of [Trusted Committer][]s to support the project.
+You may need to reach out to specific individuals based on commit or usage history.
+It is important that there are enough so that the burden on each can be reasonably small.
+
+When forming, this group should identify or create [Standard Base Documentation][] and [Communication Tooling][].
+
+The group should do its best to manage these aspects of the project:
+
+* **Maintenance**.  If the project is flat-out broken for the standard use case, then fix it.
+Keep the project up-to-date as the dependencies and frameworks it uses continue to evolve.
+* **Onboarding**.  If someone has a question about how to use the project, make sure they get a reasonable answer.
+* **Updates**.  If someone wants to add new feature to the project, give them the design and technical support necessary for them to build it so that it both works for them and is a good addition to the project.
+Review incoming pull requests in a timely manner.
+
+Since this group is comprised of volunteers, it is important to communicate that support is "best effort" only.
+Accordingly, this model of support is not well-suited for run-time critical, production projects like live APIs.
+It is better suited for projects that are consumed at build-time like libraries/packages/modules.
+The group is not expected to implement any new functionality for others.
+
+## 结果背景
+
+* There is some fragile support for the InnerSource project.
+* In the long-term the group support is likely to dissolve again at some point. If the project continues in the long run, then use this period of stable group support to find a long-lived way to support it (e.g. [Core Team][]).
+
+## 理由
+
+People generally want to help.
+If there is personal outreach for someone to join as a [Trusted Committer][], there are generally a number of people that will say "yes".
+Feeling part of a group and being given some structure and responsibility generally motivates people to try their best, which many times ends up being enough.
+
+## 已知实例
+
+* WellSky
+
+## 状态
+
+结构化
+
+## 作者
+
+[Russell R. Rutledge][]
+
+[Russell R. Rutledge]: https://github.com/rrrutledge
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
+[Trusted Committer]: ../2-structured/trusted-committer.md
+[Core Team]: ../2-structured/core-team.md
+
+## 翻译校对
+
+2024-10-10 翻译 [Chris Yang](https://github.com/node)
+

From ae88c43c79677dc7b355f689936bb290cdec75a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Thu, 10 Oct 2024 12:03:09 +0800
Subject: [PATCH 04/23] Create extensions-for-sustainable-growth.md

---
 .../extensions-for-sustainable-growth.md      | 116 ++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 translation/zh/patterns/extensions-for-sustainable-growth.md

diff --git a/translation/zh/patterns/extensions-for-sustainable-growth.md b/translation/zh/patterns/extensions-for-sustainable-growth.md
new file mode 100644
index 000000000..59a53c0cd
--- /dev/null
+++ b/translation/zh/patterns/extensions-for-sustainable-growth.md
@@ -0,0 +1,116 @@
+## Title
+
+进一步扩展可持续增长
+
+## Patlet
+
+InnerSource 项目收到了太多贡献，会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以以最小的成本和维护开销扩展项目功能。
+
+## 问题
+
+As the number of contributions to a mature InnerSource repository rapidly increases, it adds more burden on code reviews and maintenance. This results in a large code review backlog or premature rejection of new feature contributions.
+
+How can the host team allow for faster release of new features, encouraging innovation and experimentation; while also keeping the repository well maintained?
+
+## 故事
+
+There is a strategic project that aims to collect the best innovations within a domain space to one common stack, allowing reuse of a common infrastructure and providing a standard user experience. Through InnerSource, various teams in the organization that work within the domain space get an opportunity to collaborate and contribute their innovations to the common codebase.
+
+However, a large number of contributions in parallel from several developers is making maintenance of the codebase difficult. This is adding a huge burden on the project maintainers who assume ownership over the code quality standards and enable the community through various forms of communication.
+
+Project maintainers are at risk of burnout due to:
+
+- Everlasting backlog of pull requests from contributors that need to be reviewed.
+- Job dissatisfaction: Majority of maintainers' time spent in community support leaves no room for innovation.
+- Perceived lack of accomplishment: Not all contributed features have adequate user demand and result in consequent adoption.
+- Time consuming releases: More features in the codebase results in long running tests.
+- Increase in maintenance activities: More bugs raised as new capabilities are added.
+
+A lot of time is spent on maturing every new feature contribution, before potential users even get an opportunity to explore the feature for their use cases. If it turns out that new feature isn't fulfilling the use case, then all that time spent on achieving the desired code quality standards are waste.
+
+## 上下文
+
+- A strategic InnerSource codebase is scaling rapidly with new feature contributions from several employees.
+- The ratio of reviewers to contributions results in a growing backlog of pull requests. This is slowing down release of new features to the community.
+- Quality of the codebase is degrading and user experience is adversely impacted.
+- Maintainers of the codebase are burdened and cannot keep up with the influx of contributions and increased community support.
+- Some of the contributed features are not gaining adoption by users, and might even turn fully dormant. However even though they are unused, these features are still adding to the maintenance overhead.
+- Organization is investing heavily in hardening of new feature contributions to retain quality standards before the ideas are explored by the community.
+- The pattern applies in either scenario:
+   - Maintainers find themselves rejecting new feature ideas to narrow down the scope of the project. This is hampering innovation in the community and restricting further expansion.
+   - To reduce backlog, new features are getting released without thorough documentation, hardening, or testing, creating a poor user experience. This is also bloating the size of the codebase, adding a huge dependency graph and making it difficult to maintain.
+
+## 约束
+
+- Maintainers and product owners want to allow for expansion, encourage innovation and experimentation without being overly restrictive on contributions, while also keeping good code and quality standards for user experience.
+- A large amount of time goes into hardening and thorough testing of features to meet product standards, but product owners may want to allow for faster release of new innovations for adopting products to explore before investing time in maturing the capabilities.
+- Maintainers want to encourage the community to share innovations that combine product capabilities with other use-cases without adding more dependencies to the primary repository.
+
+## 解决方案
+
+Allowing [extensions/plugins](https://en.wikipedia.org/wiki/Extensibility) to high-scale InnerSource codebases can relieve the maintenance burden on repository maintainers and allow faster release of new features for adopting products to explore. This shifts maintenance of capabilities to extension owners and allows the primary repository to support capabilities that have been adopted more widely and are more strategic.  
+
+Extensions provide a filter for new capabilities that may eventually move into the core of the project. Extensions also act as an incubation and community hardening environment, allowing for much of that hardening to happen organically rather than in a costly review process.
+
+In order for the extensions model to be successful, there are few architectural considerations to keep in mind:
+
+1. **Easy to create:** To obtain community participation, extensions need to be easy to create.
+   - Create a repository template that extensions should use as a starting point. This allows the extensions to add their new features in new repositories, separate from the core project. The template should provide the same modular structure as the primary repository, and include the framework to package and release extensions.
+      - Ensure that as the primary repository changes, the template(s) are well-maintained. The primary repository maintainers are responsible for updating the template(s) to ensure it is compatible with the main project. Following good versioning conventions, e.g., [semver](https://semver.org/), makes this easier to follow.
+      - It is further recommended that the primary repository maintainers provide guidance on how to update extensions based on older versions of the template as newer versions are released.
+   - Add example extension(s) developed from the template, which project developers can reference to understand how to write a well-patterned extension.
+   - Loosen the requirements for contributors to create extensions by bypassing reviews to allow for faster release or experimentation.
+2. **Loose coupling:** Having modular components that contain functionality can allow loose coupling, where changes to extensions do not impact the quality of the main codebase or other extensions.
+3. **Dependency management:**  Each extension should be careful to pin the version range of the primary repository that it is built against (the same way it would any other dependency) and should be careful in its use of other dependencies that shadow dependencies of the primary repository such that the versions it chooses for those dependencies are compatible with the primary repository versions selected. Any conflicts with primary repository will be caught in the test framework for the extension.
+4. **Testing strategy:** How to test extensions both individually and in combination?
+   - **Testing extension individually:** Extensions template will provide a test framework to be used by the extension developers to test the capability added. This can include a framework for unit tests, runtime performance and quality tests.
+   - **Testing extension in combination with primary repository:** Extension developers have a well-patterned method for testing their extension against specific versions of the primary repository without involvement from the primary repository's maintainers.
+   - **Testing extension in combination with other extensions:** Providing a test framework for this scenario could result in being excessive especially if there are a large number of extensions that are still being explored by users and unlikely to be all used in combination. If a user runs into conflicts while using extensions in combination (which should be unlikely with sufficient loose coupling), the user can raise an issue to the respective extension owners who will sort it out. As an extension reaches later phases of the lifecycle and gets merged into the primary repository, it would be tested in combination with rest of library and any dependency conflicts will have to be resolved at the time.
+5. **Discoverability and Usability:**
+   - Make extensions easily discoverable with a publishing page showing the extensions that users have created and want to share for product usage.
+   - Allow registration of extensions with the primary project for users to leverage extensions alongside the original project, thus keeping the same user experience.
+6. **Lifecycle of extensions and maintainability:** Establish the lifecycle for extensions from creation to porting into the primary codebase, along with clear ownership guidelines.
+   - Extension creators continue maintaining the extension, providing any support and fixing defects. Any extension left unmaintained will be unlisted from the publishing page.
+   - Create criteria for when an extension can be ported to the primary repository, such as adoption of the extension by internal products and demand for the feature.
+   - Porting process of the extension to the primary repository will follow more stringent code review guidelines as set by library maintainers.
+
+![Software architecture with extensions](../../assets/img/extensions-for-sustainable-growth/extensions-for-sustainable-growth.png)
+
+Following these principles ensures that:
+
+- Developers can add new features to a project's ecosystem without requiring them to write large amounts of [boilerplate](https://en.wikipedia.org/wiki/Boilerplate_code) code.
+- Extensions are discoverable in a repeatable manner by all users of the primary project; just because code doesn't live in the main repository yet does not mean it is not valuable.
+- The maintainer burden is reduced until an extension has demonstrated that it fills an important gap in the primary project.
+- The core project's common code (e.g. base classes and utility functions) can be a starting point for new development that extends project's domain. This avoids the need to port innovative work after-the-fact, thus reducing the overall burden of developing novel features for the project.
+- Developers are more likely to contribute and stay involved in maintenance and building communities for their codebase, which is also good for the health of the overall project ecosystem.
+
+## 结果背景
+
+- The project is able to scale with the addition of new features, without adding maintenance overhead on the primary project repository.
+- Faster release of new features for the community to explore, encouraging innovation and experimentation.
+- Reduced the costly code review and feature hardening process until the feature is able to prove its utility. This has cost savings benefits for the organization.
+- A post problem that can be introduced - what happens if an extension can not complete the full lifecycle?
+   - If an extension is not adopted over a period of time and could not build a community around it to support maintenance, it would be up to the extension owner to continue maintaining it for however long they want to. If an extension is left unmaintained, it would be unpublished.
+   - If an extension developer is unable to further maintain their project, and other developers in the community want to continue supporting it, they may maintain the extension going forward.
+
+## 已知实例
+
+* **IBM Corporation** has adopted this solution to scale [InnerSource AI libraries](https://youtu.be/Lz-tIc2cyRM). Using extensions, developers are able to extend AI libraries with more algorithms and share their innovations with the company-internal community. The core libraries only contain strategic algorithms that have been adopted and validated, keeping them easier to maintain as we scale contributions.
+
+## 别名
+
+管理大规模贡献的扩展
+
+## 状态
+
+结构化
+
+## 作者
+
+- Sukriti Sharma, IBM
+- Alexander Brooks, IBM
+- Gabe Goodhart, IBM
+
+## 翻译校对
+
+- 2024-10-10 翻译 [Chris Yang](https://github.com/node)

From 2ee720242d4c28943b575163833491736fbf8891 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Thu, 10 Oct 2024 23:05:27 +0800
Subject: [PATCH 05/23] Fnished group-support.md translation

---
 translation/zh/patterns/group-support.md | 68 ++++++++++++------------
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/translation/zh/patterns/group-support.md b/translation/zh/patterns/group-support.md
index a31687c9a..bfbb1539a 100644
--- a/translation/zh/patterns/group-support.md
+++ b/translation/zh/patterns/group-support.md
@@ -1,6 +1,6 @@
 ## Title
 
-群体支持
+小组支持
 
 ## Patlet
 
@@ -14,58 +14,58 @@
 
 ## 故事
 
-A library of UI widgets is used by over 50 projects throughout the company.
-The funding for the team that owns the library runs out and the team disbands.
-At first, no one notices, but after a while whenever someone asks "who owns it" there isn't an answer.
-What will happen next?
-Will new teams shy away from using it?
-Will the project stagnate and linger until its users eventually are forced to move on to something else?
-What a shame if that were to happen to a perfectly good and useful project!
+一个 UI 组件类库，在全公司有 50 多个项目使用。
+该类库的开发团队在资源耗尽后，宣布解散。
+起初，没有人注意到，但过了一段时间，每当有人问“谁负责它”时，得不到答案。
+接下来会怎么样？
+新的团队会避免使用它吗？
+该项目是否会停滞不前，直到其用户最终被迫转向其他项目？
+如果一个完美且有价值的项目出现这种情况，那将是多么令人遗憾！
 
 ## 上下文
 
-* Popular InnerSource project.
-* Consumed as a build-time dependency (e.g. code module).
-* No one is actively supporting it.
-* The company cannot assign a team to support.
+* 广受欢迎的 InnerSource 项目。
+* 作为一个构件时的依赖项使用（比如 代码模块）。
+* 没有活跃的开发者提供支持。
+* 公司无法指派团队提供支持。
 
 ## 约束
 
-* No one is assigned by their day job to work on it.
-* Everyone is busy.
-* High cost to migrate off the project.
+* 没有人在日常工作中被指派负责这项工作。
+* 每个人都很忙。
+* 项目迁移的成本很高。
 
 ## 解决方案
 
-Call for interested volunteers from anywhere in the company to form a group of [Trusted Committer][]s to support the project.
-You may need to reach out to specific individuals based on commit or usage history.
-It is important that there are enough so that the burden on each can be reasonably small.
+面向全公司征集感兴趣的志愿者，组成一个 [可信任提交者][] 小组来支持该项目。
+可能需要根据提交或使用的历史记录联系特定的个人。
+重要的一点是要有足够的数量，这样每个人的负担可以相对较小。
 
-When forming, this group should identify or create [Standard Base Documentation][] and [Communication Tooling][].
+该小组成立后，应确定或创建[标准基础文档][]和[沟通工具][]。
 
-The group should do its best to manage these aspects of the project:
+团队应尽全力从以下方面管理项目：
 
-* **Maintenance**.  If the project is flat-out broken for the standard use case, then fix it.
-Keep the project up-to-date as the dependencies and frameworks it uses continue to evolve.
-* **Onboarding**.  If someone has a question about how to use the project, make sure they get a reasonable answer.
-* **Updates**.  If someone wants to add new feature to the project, give them the design and technical support necessary for them to build it so that it both works for them and is a good addition to the project.
-Review incoming pull requests in a timely manner.
+* **维护**.  如果项目在标准用例中完全失效，那就修复它。
+随着项目使用的依赖关系和框架的不断发展，及时更新项目。
+* **新人上手**.  如果有人对如何使用项目有疑问，确保他们能得到合理的答复。
+* **更新**.  如果有人想在项目中添加新功能，请为他们提供必要的设计和技术支持，以便他们实现该新功能，使其既能为自己所用，又能为项目增光添彩。
+及时评审收到的 PR。
 
-Since this group is comprised of volunteers, it is important to communicate that support is "best effort" only.
-Accordingly, this model of support is not well-suited for run-time critical, production projects like live APIs.
-It is better suited for projects that are consumed at build-time like libraries/packages/modules.
-The group is not expected to implement any new functionality for others.
+由于该小组由志愿者组成，因此重要的是要传达提供“尽力而为”的支持。
+因此，这种支持模式不太适合像实时 API 这类运行时关键的生产项目。
+它更适合在构建时使用的项目，例如类库/包/模块。
+该小组预计不会为其他人实现任何新功能。
 
 ## 结果背景
 
-* There is some fragile support for the InnerSource project.
-* In the long-term the group support is likely to dissolve again at some point. If the project continues in the long run, then use this period of stable group support to find a long-lived way to support it (e.g. [Core Team][]).
+* 对 InnerSource 项目有些微弱的支持。
+* 从长远来看，小组支持可能会在某个时候再次解散。如果该项目长期持续下去，那么就利用这段稳定的小组支持期，找到一种长期支持的方式（比如 [核心小组][]）。
 
 ## 理由
 
-People generally want to help.
-If there is personal outreach for someone to join as a [Trusted Committer][], there are generally a number of people that will say "yes".
-Feeling part of a group and being given some structure and responsibility generally motivates people to try their best, which many times ends up being enough.
+人们通常都愿意提供帮助。
+如果有人邀请某个人是否愿意加入成为[可信任提交者][]，通常会有很多人回答“是的”。
+感受到自己是集体的一员，并在组织结构上体现和被赋予一定的责任，通常会激励人们尽最大努力，很多时候这就已经足够了。
 
 ## 已知实例
 

From 7d28d826ee599ac8f6d0662763462943d892da36 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 09:27:36 +0800
Subject: [PATCH 06/23] Finished extensions-for-sustainable-growth.md
 translation

---
 .../extensions-for-sustainable-growth.md      | 135 +++++++++---------
 1 file changed, 68 insertions(+), 67 deletions(-)

diff --git a/translation/zh/patterns/extensions-for-sustainable-growth.md b/translation/zh/patterns/extensions-for-sustainable-growth.md
index 59a53c0cd..f1ed8f421 100644
--- a/translation/zh/patterns/extensions-for-sustainable-growth.md
+++ b/translation/zh/patterns/extensions-for-sustainable-growth.md
@@ -1,101 +1,102 @@
 ## Title
 
-进一步扩展可持续增长
+通过扩展实现可持续增长
 
 ## Patlet
 
-InnerSource 项目收到了太多贡献，会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以以最小的成本和维护开销扩展项目功能。
+InnerSource 项目收到了太多的贡献，这会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以用最小的成本和维护开销扩展项目功能。
 
 ## 问题
 
-As the number of contributions to a mature InnerSource repository rapidly increases, it adds more burden on code reviews and maintenance. This results in a large code review backlog or premature rejection of new feature contributions.
+随着对成熟 InnerSource 代码库的贡献数量迅速增加，代码评审和维护的负担也随之加重。这将导致大量代码评审任务积压或过早拒绝新功能贡献。
 
-How can the host team allow for faster release of new features, encouraging innovation and experimentation; while also keeping the repository well maintained?
+项目团队如何才能更快地发布新功能、鼓励创新和实验，同时又能很好地维护代码库呢？
 
 ## 故事
 
-There is a strategic project that aims to collect the best innovations within a domain space to one common stack, allowing reuse of a common infrastructure and providing a standard user experience. Through InnerSource, various teams in the organization that work within the domain space get an opportunity to collaborate and contribute their innovations to the common codebase.
+有一个战略性项目，旨在将某一领域内的最佳创新集合到一个通用栈中，从而实现通用基础架构的重复使用，并提供标准的用户体验。通过 InnerSource，组织内从事该领域工作的各个团队都有机会开展合作，并将自己的创新成果贡献给通用代码库。
 
-However, a large number of contributions in parallel from several developers is making maintenance of the codebase difficult. This is adding a huge burden on the project maintainers who assume ownership over the code quality standards and enable the community through various forms of communication.
+然而，来自多个开发人员的大量并行贡献给代码库的维护带来了困难。这给项目维护者增加了巨大的负担，因为他们要承担起代码质量标准的责任，并通过各种形式的交流来促进社区的发展。
 
-Project maintainers are at risk of burnout due to:
+项目维护人员面临职业倦怠的风险，原因如下：
 
-- Everlasting backlog of pull requests from contributors that need to be reviewed.
-- Job dissatisfaction: Majority of maintainers' time spent in community support leaves no room for innovation.
-- Perceived lack of accomplishment: Not all contributed features have adequate user demand and result in consequent adoption.
-- Time consuming releases: More features in the codebase results in long running tests.
-- Increase in maintenance activities: More bugs raised as new capabilities are added.
+- 待评审的贡献者 PR 不断积压。
+- 工作不满意： 维护者的大部分时间都花在社区支持上，没有创新的空间。
+- 缺乏成就感： 并非所有贡献的功能都有足够的用户需求，并因此被采用。
+- 发布耗时： 代码库中的功能越多，测试时间就越长。
+- 维护活动增加： 随着新功能的增加，会出现更多错误。
 
-A lot of time is spent on maturing every new feature contribution, before potential users even get an opportunity to explore the feature for their use cases. If it turns out that new feature isn't fulfilling the use case, then all that time spent on achieving the desired code quality standards are waste.
+在潜在用户有机会根据自己的用例探索新功能之前，我们就已经花费了大量时间来完善每一个新功能。如果结果证明新功能不能满足用例，那么为达到理想的代码质量标准所花费的时间就都白费了。
 
 ## 上下文
 
-- A strategic InnerSource codebase is scaling rapidly with new feature contributions from several employees.
-- The ratio of reviewers to contributions results in a growing backlog of pull requests. This is slowing down release of new features to the community.
-- Quality of the codebase is degrading and user experience is adversely impacted.
-- Maintainers of the codebase are burdened and cannot keep up with the influx of contributions and increased community support.
-- Some of the contributed features are not gaining adoption by users, and might even turn fully dormant. However even though they are unused, these features are still adding to the maintenance overhead.
-- Organization is investing heavily in hardening of new feature contributions to retain quality standards before the ideas are explored by the community.
-- The pattern applies in either scenario:
-   - Maintainers find themselves rejecting new feature ideas to narrow down the scope of the project. This is hampering innovation in the community and restricting further expansion.
-   - To reduce backlog, new features are getting released without thorough documentation, hardening, or testing, creating a poor user experience. This is also bloating the size of the codebase, adding a huge dependency graph and making it difficult to maintain.
+- 一个具有战略意义的 InnerSource 代码库正随着多名员工对新功能的贡献而迅速扩展。
+- 评审人员与贡献者的比例悬殊导致 PR 积压越来越多，这拖慢了向社区发布新功能的速度。
+- 代码库质量下降，用户体验受到负面影响。
+- 代码库维护人员不堪重负，无法及时应对大量贡献和社区支持的增加。
+- 一些贡献的功能没有得到用户的采用，甚至可能完全处于休眠状态。然而，即使这些功能未被使用，它们仍然会增加维护开销。
+- 组织正在投入巨资强化新功能的贡献，以便在社区探索这些想法之前保持质量标准。
+- 这种模式适用于任何一种情况：
+   - 维护者发现自己拒绝了新功能的想法，以缩小项目的范围。这阻碍了社区的创新，限制了进一步扩展。
+   - 为了减少项目积压，新功能在没有完整文档、加固或测试的情况下就被发布，造成了糟糕的用户体验。这也在扩大代码库的规模，增大依赖关系图，使其难以维护。
 
 ## 约束
 
-- Maintainers and product owners want to allow for expansion, encourage innovation and experimentation without being overly restrictive on contributions, while also keeping good code and quality standards for user experience.
-- A large amount of time goes into hardening and thorough testing of features to meet product standards, but product owners may want to allow for faster release of new innovations for adopting products to explore before investing time in maturing the capabilities.
-- Maintainers want to encourage the community to share innovations that combine product capabilities with other use-cases without adding more dependencies to the primary repository.
+- 维护者和产品所有者希望允许扩展、鼓励创新和试验，但又不过于限制贡献，同时还要保持良好的代码和质量标准，以保证用户体验。
+- 为达到产品标准，需要花费大量时间对功能进行加固和全面测试，但产品所有者可能希望在投入时间使功能成熟之前，允许更快地发布新的创新，供采用产品的用户探索。
+- 维护者希望鼓励社区分享将产品功能与其他用例相结合的创新，而不给主代码库增加更多的依赖性。
 
 ## 解决方案
 
-Allowing [extensions/plugins](https://en.wikipedia.org/wiki/Extensibility) to high-scale InnerSource codebases can relieve the maintenance burden on repository maintainers and allow faster release of new features for adopting products to explore. This shifts maintenance of capabilities to extension owners and allows the primary repository to support capabilities that have been adopted more widely and are more strategic.  
-
-Extensions provide a filter for new capabilities that may eventually move into the core of the project. Extensions also act as an incubation and community hardening environment, allowing for much of that hardening to happen organically rather than in a costly review process.
-
-In order for the extensions model to be successful, there are few architectural considerations to keep in mind:
-
-1. **Easy to create:** To obtain community participation, extensions need to be easy to create.
-   - Create a repository template that extensions should use as a starting point. This allows the extensions to add their new features in new repositories, separate from the core project. The template should provide the same modular structure as the primary repository, and include the framework to package and release extensions.
-      - Ensure that as the primary repository changes, the template(s) are well-maintained. The primary repository maintainers are responsible for updating the template(s) to ensure it is compatible with the main project. Following good versioning conventions, e.g., [semver](https://semver.org/), makes this easier to follow.
-      - It is further recommended that the primary repository maintainers provide guidance on how to update extensions based on older versions of the template as newer versions are released.
-   - Add example extension(s) developed from the template, which project developers can reference to understand how to write a well-patterned extension.
-   - Loosen the requirements for contributors to create extensions by bypassing reviews to allow for faster release or experimentation.
-2. **Loose coupling:** Having modular components that contain functionality can allow loose coupling, where changes to extensions do not impact the quality of the main codebase or other extensions.
-3. **Dependency management:**  Each extension should be careful to pin the version range of the primary repository that it is built against (the same way it would any other dependency) and should be careful in its use of other dependencies that shadow dependencies of the primary repository such that the versions it chooses for those dependencies are compatible with the primary repository versions selected. Any conflicts with primary repository will be caught in the test framework for the extension.
-4. **Testing strategy:** How to test extensions both individually and in combination?
-   - **Testing extension individually:** Extensions template will provide a test framework to be used by the extension developers to test the capability added. This can include a framework for unit tests, runtime performance and quality tests.
-   - **Testing extension in combination with primary repository:** Extension developers have a well-patterned method for testing their extension against specific versions of the primary repository without involvement from the primary repository's maintainers.
-   - **Testing extension in combination with other extensions:** Providing a test framework for this scenario could result in being excessive especially if there are a large number of extensions that are still being explored by users and unlikely to be all used in combination. If a user runs into conflicts while using extensions in combination (which should be unlikely with sufficient loose coupling), the user can raise an issue to the respective extension owners who will sort it out. As an extension reaches later phases of the lifecycle and gets merged into the primary repository, it would be tested in combination with rest of library and any dependency conflicts will have to be resolved at the time.
-5. **Discoverability and Usability:**
-   - Make extensions easily discoverable with a publishing page showing the extensions that users have created and want to share for product usage.
-   - Allow registration of extensions with the primary project for users to leverage extensions alongside the original project, thus keeping the same user experience.
-6. **Lifecycle of extensions and maintainability:** Establish the lifecycle for extensions from creation to porting into the primary codebase, along with clear ownership guidelines.
-   - Extension creators continue maintaining the extension, providing any support and fixing defects. Any extension left unmaintained will be unlisted from the publishing page.
-   - Create criteria for when an extension can be ported to the primary repository, such as adoption of the extension by internal products and demand for the feature.
-   - Porting process of the extension to the primary repository will follow more stringent code review guidelines as set by library maintainers.
-
-![Software architecture with extensions](../../assets/img/extensions-for-sustainable-growth/extensions-for-sustainable-growth.png)
-
-Following these principles ensures that:
-
-- Developers can add new features to a project's ecosystem without requiring them to write large amounts of [boilerplate](https://en.wikipedia.org/wiki/Boilerplate_code) code.
-- Extensions are discoverable in a repeatable manner by all users of the primary project; just because code doesn't live in the main repository yet does not mean it is not valuable.
-- The maintainer burden is reduced until an extension has demonstrated that it fills an important gap in the primary project.
-- The core project's common code (e.g. base classes and utility functions) can be a starting point for new development that extends project's domain. This avoids the need to port innovative work after-the-fact, thus reducing the overall burden of developing novel features for the project.
-- Developers are more likely to contribute and stay involved in maintenance and building communities for their codebase, which is also good for the health of the overall project ecosystem.
+允许[扩展/插件](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)代码，即可为项目生态系统添加新功能。
+- 主项目的所有用户都能以可重复的方式发现扩展功能；代码还没有存入主资源库并不意味着它没有价值。
+- 维护者的负担会减轻，直到扩展证明它填补了主项目中的重要空白。
+- 核心项目的通用代码（如基类和实用功能）可以作为扩展项目领域的新开发的起点。这就避免了事后移植创新工作的需要，从而减轻了为项目开发新功能的总体负担。
+- 开发人员更有可能为他们的代码库做出贡献，并继续参与维护和社区建设，这也有利于整个项目生态系统的健康发展。
 
 ## 结果背景
 
-- The project is able to scale with the addition of new features, without adding maintenance overhead on the primary project repository.
-- Faster release of new features for the community to explore, encouraging innovation and experimentation.
-- Reduced the costly code review and feature hardening process until the feature is able to prove its utility. This has cost savings benefits for the organization.
-- A post problem that can be introduced - what happens if an extension can not complete the full lifecycle?
-   - If an extension is not adopted over a period of time and could not build a community around it to support maintenance, it would be up to the extension owner to continue maintaining it for however long they want to. If an extension is left unmaintained, it would be unpublished.
-   - If an extension developer is unable to further maintain their project, and other developers in the community want to continue supporting it, they may maintain the extension going forward.
+- 项目能够通过增加新功能来扩展，同时不会增加主项目代码库的维护成本。
+- 更快地发布新功能供社区探索，鼓励创新和试验。
+- 减少了成本高昂的代码评审和功能加固过程，直到功能能够证明其实用性，这将为企业节省成本。
+- 可能引入的一个后置问题——如果扩展无法完成一个完整的生命周期，会怎么样？
+   - 如果一个扩展在一段时间内没有被采用，也无法围绕它建立一个支持维护的社区，那么就需要扩展所有者在他们希望的任何时间内继续维护它。如果扩展没有得到维护，就会被取消发布。
+   - 如果扩展开发者无法继续维护其项目，而社区中的其他开发者希望继续支持该扩展，他们可以继续维护该扩展。
 
 ## 已知实例
 
-* **IBM Corporation** has adopted this solution to scale [InnerSource AI libraries](https://youtu.be/Lz-tIc2cyRM). Using extensions, developers are able to extend AI libraries with more algorithms and share their innovations with the company-internal community. The core libraries only contain strategic algorithms that have been adopted and validated, keeping them easier to maintain as we scale contributions.
+* **IBM 公司**采用了这一解决方案来扩展[InnerSource 人工智能类库](https://youtu.be/Lz-tIc2cyRM)。通过使用扩展库，开发人员能够用更多算法扩展人工智能类库，并与公司内部社区分享他们的创新成果。核心库只包含已被采用和验证的战略算法，因此在我们扩大贡献时更易于维护。
 
 ## 别名
 

From b0b2b68b94fc46115beff0b17ee91693f1ba9af8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 09:37:06 +0800
Subject: [PATCH 07/23] Update extensions-for-sustainable-growth.md to fix img
 uri

---
 translation/zh/patterns/extensions-for-sustainable-growth.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/translation/zh/patterns/extensions-for-sustainable-growth.md b/translation/zh/patterns/extensions-for-sustainable-growth.md
index f1ed8f421..eb13680f2 100644
--- a/translation/zh/patterns/extensions-for-sustainable-growth.md
+++ b/translation/zh/patterns/extensions-for-sustainable-growth.md
@@ -75,7 +75,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
    - 扩展到主代码库的移植过程将遵循库维护人员制定的更严格的代码评审指南。
   
 
-![可扩展软件架构](.../.../assets/img/extensions-for-sustainable-growth/extensions-for-sustainable-growth.png)
+![可扩展软件架构](../../../assets/img/extensions-for-sustainable-growth/extensions-for-sustainable-growth.png)
 
 遵循这些原则可确保：
 

From 8528fa438ca086b976d5c321197c41b8de7e5e2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 09:40:57 +0800
Subject: [PATCH 08/23] Update extensions-for-sustainable-growth.md to fix
 markdown format issue

---
 translation/zh/patterns/extensions-for-sustainable-growth.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/translation/zh/patterns/extensions-for-sustainable-growth.md b/translation/zh/patterns/extensions-for-sustainable-growth.md
index eb13680f2..59613745c 100644
--- a/translation/zh/patterns/extensions-for-sustainable-growth.md
+++ b/translation/zh/patterns/extensions-for-sustainable-growth.md
@@ -73,7 +73,6 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
    - 扩展创建者继续维护扩展，提供任何支持并修复缺陷。任何未维护的扩展都不会从发布页面列出。
    - 创建何时可以将扩展移植到主代码库的标准，例如内部产品对扩展的采用以及对该功能的需求。
    - 扩展到主代码库的移植过程将遵循库维护人员制定的更严格的代码评审指南。
-  
 
 ![可扩展软件架构](../../../assets/img/extensions-for-sustainable-growth/extensions-for-sustainable-growth.png)
 

From 9beeb64ef4d6aa7d7834a6db9e2da32b7019f0bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 09:43:01 +0800
Subject: [PATCH 09/23] Update group-support.md to improve markdown format

---
 translation/zh/patterns/group-support.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/translation/zh/patterns/group-support.md b/translation/zh/patterns/group-support.md
index bfbb1539a..68a5d69d7 100644
--- a/translation/zh/patterns/group-support.md
+++ b/translation/zh/patterns/group-support.md
@@ -88,4 +88,3 @@
 ## 翻译校对
 
 2024-10-10 翻译 [Chris Yang](https://github.com/node)
-

From cc2767c9242cbcb5bb297390dc489610228eaa6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 09:44:04 +0800
Subject: [PATCH 10/23] Update release-process.md to delete unnecessary spaces

---
 translation/zh/patterns/release-process.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/translation/zh/patterns/release-process.md b/translation/zh/patterns/release-process.md
index ed388cb3b..a82d24b08 100644
--- a/translation/zh/patterns/release-process.md
+++ b/translation/zh/patterns/release-process.md
@@ -22,7 +22,7 @@
 
 随着组织的发展和更多内部软件的编写，这种模式的价值也在增加。
 
-## 约束 
+## 约束
 
 ### 对于没有集中式 CI/CD 系统的组织来说很困难
 
@@ -70,4 +70,4 @@ David Grizzanti
 
 ## 翻译校对
 
-* **2022-12-08** 翻译 [Chris Yang](https:github.com/node) 
+* **2022-12-08** 翻译 [Chris Yang](https:github.com/node)

From 5a989e7da32cc8b41d3b90897ca9636992133052 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 09:47:35 +0800
Subject: [PATCH 11/23] Update release-process.md to fix typo

---
 translation/zh/patterns/release-process.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/translation/zh/patterns/release-process.md b/translation/zh/patterns/release-process.md
index a82d24b08..5f98234e1 100644
--- a/translation/zh/patterns/release-process.md
+++ b/translation/zh/patterns/release-process.md
@@ -53,7 +53,7 @@
 
 接触到您项目的团队会看到已发布的发行说明，并对您的工具充满信心。已发布的制品也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。
 
-发行说明也是[表扬参与者](raise-participants.md)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](base-documentation.md)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。
+发行说明也是[表扬参与者](praise-participants.md)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](base-documentation.md)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。
 
 ## 已知实例
 

From 12ac3ec08fab657f68c32fd5cedb8c381a780398 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 09:54:58 +0800
Subject: [PATCH 12/23] Update group-support.md to fix inner link issue

---
 translation/zh/patterns/group-support.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/translation/zh/patterns/group-support.md b/translation/zh/patterns/group-support.md
index 68a5d69d7..ce7a97b49 100644
--- a/translation/zh/patterns/group-support.md
+++ b/translation/zh/patterns/group-support.md
@@ -80,10 +80,10 @@
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/base-documentation.md
-[Communication Tooling]: ../2-structured/communication-tooling.md
-[Trusted Committer]: ../2-structured/trusted-committer.md
-[Core Team]: ../2-structured/core-team.md
+[标准基础文档]: ../base-documentation.md
+[沟通工具]: ../communication-tooling.md
+[可信任提交者]: ../trusted-committer.md
+[核心小组]: ../core-team.md
 
 ## 翻译校对
 

From 74b053ccf633d080dba963c1af02fff769b0b1f3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 09:58:29 +0800
Subject: [PATCH 13/23] Update group-support.md to fix link issue again

---
 translation/zh/patterns/group-support.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/translation/zh/patterns/group-support.md b/translation/zh/patterns/group-support.md
index ce7a97b49..5a31c57d8 100644
--- a/translation/zh/patterns/group-support.md
+++ b/translation/zh/patterns/group-support.md
@@ -80,10 +80,10 @@
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[标准基础文档]: ../base-documentation.md
-[沟通工具]: ../communication-tooling.md
-[可信任提交者]: ../trusted-committer.md
-[核心小组]: ../core-team.md
+[标准基础文档]: ./base-documentation.md
+[沟通工具]: ./communication-tooling.md
+[可信任提交者]: ./trusted-committer.md
+[核心小组]: ./core-team.md
 
 ## 翻译校对
 

From eed8cc39f1bf105ede1248d6ad6939dc1f6481db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 10:06:32 +0800
Subject: [PATCH 14/23] Update extensions-for-sustainable-growth.md to improve
 MD format

---
 translation/zh/patterns/extensions-for-sustainable-growth.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/translation/zh/patterns/extensions-for-sustainable-growth.md b/translation/zh/patterns/extensions-for-sustainable-growth.md
index 59613745c..7b2b6c757 100644
--- a/translation/zh/patterns/extensions-for-sustainable-growth.md
+++ b/translation/zh/patterns/extensions-for-sustainable-growth.md
@@ -67,8 +67,8 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
    - **与主代码库结合测试扩展：** 扩展开发人员有一种模式良好的方法，可以针对主代码库的特定版本测试其扩展，而无需主代码库维护人员的参与。
    - **与其他扩展结合测试扩展：** 为此场景提供测试框架可能会导致过度，特别是如果用户仍在探索大量扩展并且不太可能全部组合使用。如果用户在组合使用扩展时遇到冲突（如果有足够的松散耦合，这种情况应该不太可能发生），用户可以向相应的扩展所有者提出问题，由他们来解决。当扩展到达生命周期的后期阶段并合并到主代码库时，它将与库的其余部分结合进行测试，并且当时必须解决所有的依赖项冲突。
 5. **可发现性和可用性：**
-  - 通过显示用户已创建并希望共享以供产品使用的扩展的发布页面，使扩展易于被发现。
-  - 允许在主项目中注册扩展，以便用户可以在原始项目中利用扩展，从而保持相同的用户体验。
+   - 通过显示用户已创建并希望共享以供产品使用的扩展的发布页面，使扩展易于被发现。
+   - 允许在主项目中注册扩展，以便用户可以在原始项目中利用扩展，从而保持相同的用户体验。
 6. **扩展的生命周期和可维护性：** 建立扩展从创建到移植到主代码库的生命周期，以及明确的所有权准则。
    - 扩展创建者继续维护扩展，提供任何支持并修复缺陷。任何未维护的扩展都不会从发布页面列出。
    - 创建何时可以将扩展移植到主代码库的标准，例如内部产品对扩展的采用以及对该功能的需求。

From 89c96884a18faeb6da3723f6fee4cf7f139a74c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 15:36:20 +0800
Subject: [PATCH 15/23] Improve based on review comments

---
 .../zh/patterns/extensions-for-sustainable-growth.md   | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/translation/zh/patterns/extensions-for-sustainable-growth.md b/translation/zh/patterns/extensions-for-sustainable-growth.md
index 7b2b6c757..b9685c8f4 100644
--- a/translation/zh/patterns/extensions-for-sustainable-growth.md
+++ b/translation/zh/patterns/extensions-for-sustainable-growth.md
@@ -57,15 +57,15 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 1. **易于创建：** 为了获得社区参与，扩展需要易于创建。
    - 创建一个初始扩展的代码库模板，作为新扩展的起点。这允许扩展在新代码库中添加新功能，与核心项目分开。该模板应提供与主代码库相同的模块化结构，并包含打包和发布扩展的框架。
    - 确保随着主代码库的变更，模板得到良好维护。主代码库维护人员负责更新模板以确保其与主项目兼容。遵循良好的版本控制约定，例如 [semver](https://semver.org/)，可以使这更容易遵循。
-   - 进一步建议主代码库维护者提供相关介绍，以指导如何在新版本发布时基于旧版本模板更新扩展。
+   - 建议主代码库的维护团队提供详细的指南，阐明如何在新版本发布时，基于旧版本的模板对扩展进行更新。
    - 添加从模板开发的示例扩展，项目开发人员可以参考这些扩展来了解如何编写模式良好的扩展。
    - 放宽对贡献者创建扩展的要求，绕过评审，以实现更快的发布或试验。
 2. **低耦合：** 拥有包含功能的模块化组件可以允许松散耦合，其中扩展的更改不会影响主代码库或其他扩展的质量。
-3. **依赖管理：** 每个扩展都应小心固定其构建的主代码库的版本范围（与任何其他依赖项相同），并且在使用其他依赖项时应小心主存储库的依赖项，以便为这些依赖项选择的版本与所选的主代码库版本兼容。与主代码库的任何冲突都将在扩展的测试框架中捕获。
+3. **依赖管理：** 每个扩展都应谨慎地指定其所依赖的主代码库版本范围，就如同处理其他依赖项一样。在选择其他依赖项时，也要特别注意与主代码库的依赖关系，确保所选版本与指定的主代码库版本相兼容。这种做法不仅能够保证扩展的稳定性，还能通过扩展的测试框架有效地捕获与主代码库之间可能存在的任何冲突。
 4. **测试策略：** 如何单独和组合测试扩展？
    - **单独测试扩展：** 扩展模板将提供一个测试框架，供扩展开发人员用来测试添加的功能。这可以包括单元测试、运行时性能和质量测试的框架。
    - **与主代码库结合测试扩展：** 扩展开发人员有一种模式良好的方法，可以针对主代码库的特定版本测试其扩展，而无需主代码库维护人员的参与。
-   - **与其他扩展结合测试扩展：** 为此场景提供测试框架可能会导致过度，特别是如果用户仍在探索大量扩展并且不太可能全部组合使用。如果用户在组合使用扩展时遇到冲突（如果有足够的松散耦合，这种情况应该不太可能发生），用户可以向相应的扩展所有者提出问题，由他们来解决。当扩展到达生命周期的后期阶段并合并到主代码库时，它将与库的其余部分结合进行测试，并且当时必须解决所有的依赖项冲突。
+   - **与其他扩展结合测试扩展：** 为每个扩展提供全面的测试框架可能会显得过于繁重。如果扩展之间保持适度的松散耦合，冲突的可能性本来就较低。然而，若用户在组合使用扩展时遇到冲突，他们可以直接向相关扩展的维护者报告问题，由这些专业人士来解决兼容性问题。值得注意的是，当扩展发展到生命周期的后期阶段，并有机会被合并到主代码库时，它将与库的其他部分一起进行全面测试。在这个关键阶段，所有潜在的依赖冲突必须得到彻底解决，以确保整个系统的稳定性和一致性。
 5. **可发现性和可用性：**
    - 通过显示用户已创建并希望共享以供产品使用的扩展的发布页面，使扩展易于被发现。
    - 允许在主项目中注册扩展，以便用户可以在原始项目中利用扩展，从而保持相同的用户体验。
@@ -79,7 +79,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 遵循这些原则可确保：
 
 - 开发人员无需编写大量[样板](https://en.wikipedia.org/wiki/Boilerplate_code)代码，即可为项目生态系统添加新功能。
-- 主项目的所有用户都能以可重复的方式发现扩展功能；代码还没有存入主资源库并不意味着它没有价值。
+- 主项目的所有用户都能以可重复的方式发现扩展功能；代码还没有合并入主库并不意味着它没有价值。
 - 维护者的负担会减轻，直到扩展证明它填补了主项目中的重要空白。
 - 核心项目的通用代码（如基类和实用功能）可以作为扩展项目领域的新开发的起点。这就避免了事后移植创新工作的需要，从而减轻了为项目开发新功能的总体负担。
 - 开发人员更有可能为他们的代码库做出贡献，并继续参与维护和社区建设，这也有利于整个项目生态系统的健康发展。
@@ -88,7 +88,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 
 - 项目能够通过增加新功能来扩展，同时不会增加主项目代码库的维护成本。
 - 更快地发布新功能供社区探索，鼓励创新和试验。
-- 减少了成本高昂的代码评审和功能加固过程，直到功能能够证明其实用性，这将为企业节省成本。
+- 将耗时且成本高昂的代码审查和功能完善过程推迟到功能已经证明其实用价值之后， 以有效降低企业的投入。
 - 可能引入的一个后置问题——如果扩展无法完成一个完整的生命周期，会怎么样？
    - 如果一个扩展在一段时间内没有被采用，也无法围绕它建立一个支持维护的社区，那么就需要扩展所有者在他们希望的任何时间内继续维护它。如果扩展没有得到维护，就会被取消发布。
    - 如果扩展开发者无法继续维护其项目，而社区中的其他开发者希望继续支持该扩展，他们可以继续维护该扩展。

From b59992766d2ae752fb6ff5b8eb19d1427fa0844b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 15:37:59 +0800
Subject: [PATCH 16/23] Update group-support.md to improve based review
 comments

---
 translation/zh/patterns/group-support.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/translation/zh/patterns/group-support.md b/translation/zh/patterns/group-support.md
index 5a31c57d8..c6517a985 100644
--- a/translation/zh/patterns/group-support.md
+++ b/translation/zh/patterns/group-support.md
@@ -9,7 +9,7 @@
 
 ## 问题
 
-* 一个流行的 InnerSource 项目成为孤立项目。
+* 即便是一个广受欢迎的 InnerSource 项目也可能陷入孤立的困境。
 * 当前没有明确的出路。
 
 ## 故事

From 212c63597b243fb55243cac59507e6789640565e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 15:39:17 +0800
Subject: [PATCH 17/23] Update release-process.md to improve based review
 comments

---
 translation/zh/patterns/release-process.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/translation/zh/patterns/release-process.md b/translation/zh/patterns/release-process.md
index 5f98234e1..5f83888d4 100644
--- a/translation/zh/patterns/release-process.md
+++ b/translation/zh/patterns/release-process.md
@@ -12,7 +12,7 @@
 
 开源项目的通常做法是按版本发步，并在发行说明中记录破坏性变更和新功能，同时发布二进制文件或 Docker 镜像链接。对于 InnerSource 项目、模块等来说，这种做法可能不那么透明，或没有很好的文档化/可见性。
 
-没有发布制品或发布流程的 InnerSource 项目会降低信任度。团队不知道何时会发布下一个版本，何时会引入破坏性变更等。
+缺乏明确的发布制品或规范的发布流程的 InnerSource 项目往往会削弱团队间的信任。在这种情况下，其他团队难以预知下一个版本的发布时间，也无法准确把握可能出现的破坏性变更。
 
 ## 上下文
 

From c507418830c335cc26a988e57d69adeba4d4a012 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 15:48:46 +0800
Subject: [PATCH 18/23] Update extensions-for-sustainable-growth.md to add
 reviewer

---
 .../patterns/extensions-for-sustainable-growth.md   | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/translation/zh/patterns/extensions-for-sustainable-growth.md b/translation/zh/patterns/extensions-for-sustainable-growth.md
index b9685c8f4..c5063fa09 100644
--- a/translation/zh/patterns/extensions-for-sustainable-growth.md
+++ b/translation/zh/patterns/extensions-for-sustainable-growth.md
@@ -16,7 +16,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 
 有一个战略性项目，旨在将某一领域内的最佳创新集合到一个通用栈中，从而实现通用基础架构的重复使用，并提供标准的用户体验。通过 InnerSource，组织内从事该领域工作的各个团队都有机会开展合作，并将自己的创新成果贡献给通用代码库。
 
-然而，来自多个开发人员的大量并行贡献给代码库的维护带来了困难。这给项目维护者增加了巨大的负担，因为他们要承担起代码质量标准的责任，并通过各种形式的交流来促进社区的发展。
+然而，当多位开发者同时进行大量并行贡献时，代码库的维护变得愈发复杂。这种情况给项目维护者带来了巨大的挑战。他们不仅要肩负确保代码质量的重任，还需要通过多种沟通渠道积极促进社区的健康发展。
 
 项目维护人员面临职业倦怠的风险，原因如下：
 
@@ -26,7 +26,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 - 发布耗时： 代码库中的功能越多，测试时间就越长。
 - 维护活动增加： 随着新功能的增加，会出现更多错误。
 
-在潜在用户有机会根据自己的用例探索新功能之前，我们就已经花费了大量时间来完善每一个新功能。如果结果证明新功能不能满足用例，那么为达到理想的代码质量标准所花费的时间就都白费了。
+我们常常在新功能正式发布前，投入大量时间对其进行完善和优化。然而，这种做法存在一定风险：如果这些精心打造的功能最终无法满足潜在用户的实际需求，那么我们为追求卓越代码质量所付出的努力可能就会付诸东流。
 
 ## 上下文
 
@@ -37,7 +37,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 - 一些贡献的功能没有得到用户的采用，甚至可能完全处于休眠状态。然而，即使这些功能未被使用，它们仍然会增加维护开销。
 - 组织正在投入巨资强化新功能的贡献，以便在社区探索这些想法之前保持质量标准。
 - 这种模式适用于任何一种情况：
-   - 维护者发现自己拒绝了新功能的想法，以缩小项目的范围。这阻碍了社区的创新，限制了进一步扩展。
+   - 维护者发现自己经常拒绝新功能提议，以控制项目规模。然而，这可能会抑制社区创新，限制项目的发展潜力。
    - 为了减少项目积压，新功能在没有完整文档、加固或测试的情况下就被发布，造成了糟糕的用户体验。这也在扩大代码库的规模，增大依赖关系图，使其难以维护。
 
 ## 约束
@@ -50,7 +50,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 
 允许[扩展/插件](https://en.wikipedia.org/wiki/Extensibility)进入大规模的 InnerSource 代码库，可以减轻代码库维护者的维护负担，并允许更快地发布新功能供采用产品及探索。这就将功能的维护工作转移给了扩展所有者，并允许主代码库支持已被更广泛采用且更具战略性的功能。
 
-扩展为最终可能进入项目核心的新功能提供了一个过滤器。扩展还充当了孵化和社区加固环境的角色，使许多加固工作能够有机地进行，而不是在代价高昂的评审过程中进行。
+扩展机制为潜在的核心功能提供了一个有效的筛选渠道。它不仅充当了新功能的孵化器，还为社区创造了一个自然的强化环境。这种方式使得大量功能完善和优化工作能够在一个更加开放和灵活的环境中自然进行，避免了在耗时耗力的正式评审过程中进行这些工作。
 
 为了使扩展模式取得成功，在架构上有一些注意事项需要牢记：
 
@@ -95,7 +95,7 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 
 ## 已知实例
 
-* **IBM 公司**采用了这一解决方案来扩展[InnerSource 人工智能类库](https://youtu.be/Lz-tIc2cyRM)。通过使用扩展库，开发人员能够用更多算法扩展人工智能类库，并与公司内部社区分享他们的创新成果。核心库只包含已被采用和验证的战略算法，因此在我们扩大贡献时更易于维护。
+* **IBM 公司**采用了这一解决方案来扩展[InnerSource 人工智能类库](https://youtu.be/Lz-tIc2cyRM)。扩展库为开发人员提供了一个灵活的平台，使他们能够通过添加新算法来丰富人工智能类库的功能。这不仅促进了技术创新，还为公司内部社区创造了分享和交流的机会。与此同时，核心库保持精简，仅包含经过充分验证和广泛采用的关键算法。这种结构设计确保了在项目规模不断扩大、贡献者增多的情况下，核心库仍然易于维护和管理。
 
 ## 别名
 
@@ -113,4 +113,5 @@ InnerSource 项目收到了太多的贡献，这会导致维护变得困难。
 
 ## 翻译校对
 
-- 2024-10-10 翻译 [Chris Yang](https://github.com/node)
+- **2024-10-10** 翻译[Chris Yang](https://github.com/node)
+- **2024-10-12** 校对[姜宁](https://github.com/willemjiang)

From 948f56323980c53788d44390382542fef8e003ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 15:49:23 +0800
Subject: [PATCH 19/23] add reviewer

---
 translation/zh/patterns/group-support.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/translation/zh/patterns/group-support.md b/translation/zh/patterns/group-support.md
index c6517a985..691d9fa78 100644
--- a/translation/zh/patterns/group-support.md
+++ b/translation/zh/patterns/group-support.md
@@ -87,4 +87,5 @@
 
 ## 翻译校对
 
-2024-10-10 翻译 [Chris Yang](https://github.com/node)
+- **2024-10-10** 翻译[Chris Yang](https://github.com/node)
+- **2024-10-12** 校对[姜宁](https://github.com/willemjiang)

From d452882a58ce2ed0b3427ff0bc6b3da13088cecc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Chris=20=28Gentle=29=20Y=E6=9D=A8?= <nodexy@gmail.com>
Date: Sat, 12 Oct 2024 15:50:30 +0800
Subject: [PATCH 20/23] add reviewer

---
 translation/zh/patterns/release-process.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/translation/zh/patterns/release-process.md b/translation/zh/patterns/release-process.md
index 5f83888d4..c10ad2208 100644
--- a/translation/zh/patterns/release-process.md
+++ b/translation/zh/patterns/release-process.md
@@ -70,4 +70,5 @@ David Grizzanti
 
 ## 翻译校对
 
-* **2022-12-08** 翻译 [Chris Yang](https:github.com/node)
+* **2024-10-08** 翻译[Chris Yang](https:github.com/node)
+* **2024-10-12** 校对[姜宁](https://github.com/willemjiang)

From 474ea647e83a5b238fadb3e7de23d4f94e56879f Mon Sep 17 00:00:00 2001
From: Sebastian Spier <github@spier.hu>
Date: Sat, 12 Oct 2024 14:33:03 +0200
Subject: [PATCH 21/23] Generating Chinese TOC (#723)

* Writing updated toc.md for the en book
* Writing updated toc.md for the zh book
---
 book/en/toc.md | 2 +-
 book/zh/toc.md | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/book/en/toc.md b/book/en/toc.md
index 758daed2d..0027209d1 100644
--- a/book/en/toc.md
+++ b/book/en/toc.md
@@ -34,7 +34,7 @@ Instead edit toc_template.md
 * [InnerSource Portal](../../patterns/2-structured/innersource-portal.md) - Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and InnerSource project owners to attract an outside audience.
 * [Issue Tracker Use Cases](../../patterns/2-structured/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.
 * [Maturity Model](../../patterns/2-structured/maturity-model.md) - Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.
-* [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 engenders further engagement from the contributor and others.
+* [Praise Participants](../../patterns/2-structured/praise-participants.md) - When you receive an InnerSource contribution, it's important to thank the contributor for their time and effort. Extending your gratiutude not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others. Praising contributors' positive contributions to your InnerSource project motivates those contributors (and their managers) to continue investing in the effort.
 * [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 InnerSource Portal), so that potential contributors can more easily determine which project they want to contribute to.
 * [Review Committee](../../patterns/2-structured/review-committee.md) - The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarize themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.
 * [Service vs. Library](../../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.
diff --git a/book/zh/toc.md b/book/zh/toc.md
index c427e995a..367bd7ddb 100644
--- a/book/zh/toc.md
+++ b/book/zh/toc.md
@@ -31,13 +31,16 @@ Instead edit toc_template.md
 * [内源门户网站](../../translation/zh/patterns/innersource-portal.md) - 潜在的贡献者很难找到他们感兴趣的内源项目。你可以通过创建一个索引所有可用的内源项目信息的内部网站，可以让贡献者了解他们可能感兴趣的项目，也可以让内源项目的负责人发展外部受众。
 * [利用RFC进行透明的跨团队决策](../../translation/zh/patterns/transparent-cross-team-decision-making-using-rfcs.md) - 内源项目如果想实现高参与率，并为每个参与者做出最好的决定，就需要想办法在整个软件生命周期中建立易于参与式的环境。发布内部征求意见稿（RFC）文件，可以在设计过程的早期就进行讨论，并促进在参与各方在高参与度下建立解决方案的机会。
 * [基准级的文档](../../translation/zh/patterns/base-documentation.md) - 内源项目的新贡献者很难搞清楚谁在维护这个项目，该做什么，以及如何贡献。在标准文件中提供文档，如README.md/CONTRIBUTING.md，可以为新的贡献者提供一个自助服务流程，这样他们就可以自己找到最常见问题的答案。
+* [小组支持](../../translation/zh/patterns/group-support.md) - 如果某个团队或个人不再支持 InnerSource 项目怎么办？ 由一群感兴趣的个人组成小组来保持项目活跃。
 * [成熟度模型](../../translation/zh/patterns/maturity-model.md) - 各个团队已经开始采用内源。这种做法正在向多个部门蔓延。然而，人们对什么是内源项目的理解各不相同。解决方案是提供一个成熟度模型，让团队通过自我检查，发现他们还没有意识到的模式和做法。
 * [服务 vs. 库](../../translation/zh/patterns/service-vs-library.md) - 由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
+* [标准发布流程](../../translation/zh/patterns/release-process.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/crossteam-project-valuation.md) - 要推销跨团队的内源项目的价值是很难的，因为这些项目并没有对公司的收入产生直接影响。 这里有一个数据驱动的方法来展示和凸显你的项目价值。
+* [通过扩展实现可持续增长](../../translation/zh/patterns/extensions-for-sustainable-growth.md) - InnerSource 项目收到了太多的贡献，这会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以用最小的成本和维护开销扩展项目功能。
 * [问题追踪器使用案例](../../translation/zh/patterns/issue-tracker.md) - 内源东道主团队不仅没有使计划和进展，而且也没有将变化背景信息变透明。这可以通过增加项目问题跟踪器的使用案例来解决，它也可以为头脑风暴、实施讨论和功能设计服务。
 * [零工市场](../../translation/zh/patterns/gig-marketplace.md) - 建立一个市场，创建一个内部网站，将特定的内源项目需求列为 "任务"，并提出明确的时间和技能要求。 这将使管理人员能够更好地了解员工的时间承诺和专业利益，从而增加获得批准做出内源贡献的可能性。
 

From cb62658d07a88d19d3910af39994d3edca21a030 Mon Sep 17 00:00:00 2001
From: Sebastian Spier <github@spier.hu>
Date: Sat, 12 Oct 2024 16:53:15 +0200
Subject: [PATCH 22/23] Board report 2024-08 (#709)

Board report 2024-08
---
 meta/boardreports/2024-05.md |  3 ++
 meta/boardreports/2024-08.md | 63 ++++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+)
 create mode 100644 meta/boardreports/2024-05.md
 create mode 100644 meta/boardreports/2024-08.md

diff --git a/meta/boardreports/2024-05.md b/meta/boardreports/2024-05.md
new file mode 100644
index 000000000..709c10b05
--- /dev/null
+++ b/meta/boardreports/2024-05.md
@@ -0,0 +1,3 @@
+# InnerSource Patterns WG - Report for Board Meeting 2024-05
+
+The Patterns WG did not submit a report to this Board Meeting, due to a lack of time.
diff --git a/meta/boardreports/2024-08.md b/meta/boardreports/2024-08.md
new file mode 100644
index 000000000..1bec6296e
--- /dev/null
+++ b/meta/boardreports/2024-08.md
@@ -0,0 +1,63 @@
+# InnerSource Patterns WG - Report for Board Meeting 2024-08
+
+## Meta
+
+* Reporting Period: 2024-05..2024-07
+* [merged PRs](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls?q=is%3Apr+closed%3A2024-05..2024-07+is%3Amerged)
+* [opened issues](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues?q=is%3Aissue+created%3A2024-05..2024-07+is%3Aopen)
+
+## Engagement
+
+NOTE: no comparison to previous quarter as we did not submit a report then.
+
+The [patterns book][] is the way InnerSource practices are captured and shared. Recent web analytics:
+
+* total traffic on the patterns book (tracking_id: `G-QL1S8MW5D9`)
+  * 15,021 views total
+  * 1,897 users
+* Most popular patterns:
+  * Core Team
+  * Maturity Model
+  * InnerSource Portal
+  * 30 Day Warranty
+  * Standard Base Documentation
+* traffic for translations:
+  * Japanese (/v/ja) - no data in Google Analytics. no idea why.
+  * Chinese (/v/zh) - 545
+  * Brazilian Portuguese (/v/pt-br) - 358
+  * Galician (/v/gl) - 68
+
+## Changes
+
+Changes are contributed via the [InnerSourcePatterns][] repository:
+
+* new patterns:
+  * [Code of Conduct](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/code-of-conduct.md) - thank you [rmarting](https://github.com/rmarting)
+  * [InnerSource Hackathon](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/innersource-hackathon.md) - thank you [spriya-m](https://github.com/spriya-m)
+  * [Trusted Committer and Contributor Retrospectives](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/cross-team-retrospectives.md) - thank you [MaineC](https://github.com/MaineC)
+  * especially exciting because the first two came from new or infrequent contributors
+* translations
+  * nothing new
+* additions of Known Instances (applications of our patterns in the wild)
+  * GitHub to new Code of Conduct pattern. Thank you @zkoppert
+* some additions to the glossary. still very few entries in the glossary, however we now [published](https://patterns.innersourcecommons.org/appendix/glossary) it in the patterns book. maybe that we motivate us to extend it.
+* would like to do one round of cleanup of old PRs/issues that are unlikely to still be implemented as they are stale for too long
+
+## Things to come
+
+* (still) toying with the idea to add [Adopters pages](https://innersourcecommons.gitbook.io/innersource-patterns-staging/v/adopters-test/adopters/adopters) to our book. Goal: showcase the organizations and the patterns they use more prominently in our book. Looking for feedback! More [details here](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/623).
+* Some PRs are stuck. Reason is mostly that I (@spier) have less time to review things or communication with the contributor stopped somewhere
+
+## Trusted Committers (Community)
+
+* Last [Trusted Committer][] added was [@yuhattor](https://github.com/yuhattor) (added 2022-07-21)
+* Trusted Committer candidates in the pipeline: No
+* Finding new contributors and further trusted committers continues to be the main challenge of the InnerSource Patterns project
+
+## Next Goals
+
+Same as previous Board report.
+
+[patterns book]: https://patterns.innersourcecommons.org/
+[InnerSourcePatterns]: https://github.com/InnerSourceCommons/InnerSourcePatterns/
+[Trusted Committer]: https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/TRUSTED-COMMITTERS.md

From e1bfb69c55e19273e024b4f2f2bbe55ff4ca1f60 Mon Sep 17 00:00:00 2001
From: Shanmugapriya M <97021994+spriya-m@users.noreply.github.com>
Date: Tue, 5 Nov 2024 21:37:32 +0100
Subject: [PATCH 23/23] Address review comments for InnerSource Hackathon
 pattern (#721)

Addressing reviewing comments by Sally Deering in innersource-hackathon.md
---
 patterns/1-initial/innersource-hackathon.md | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md
index d1af739e8..c1884954b 100644
--- a/patterns/1-initial/innersource-hackathon.md
+++ b/patterns/1-initial/innersource-hackathon.md
@@ -14,12 +14,14 @@ The company wants to adopt InnerSource as software development methodology but o
 
 ### Scenario 1: Challenges in scaling beyond the early adopters
 
-The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like:
+The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams.
 
-* not familiar with InnerSource and being ignorant to know about it
+Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like:
+
+* not familiar with InnerSource or open source practices
 * not enough time to prioritize InnerSource, given the regular work deliverables
-* relunctance to changing ways of working when everything works well already
-* perception that InnerSource requires more work and responsibilities
+* reluctance to changing ways of working when everything works well already
+* unclear return on investment for the upfront setup costs that an InnerSource project takes
 
 ### Scenario 2: Challenges in getting contributions and building community around InnerSource projects