Update extensions-for-sustainable-growth.md to add reviewer

Author: node

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)