Incorporated the review

Co-authored-by: bakisunsan <[email protected]>

Author: yuhattor

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

@@ -4,38 +4,39 @@
 
 ## Patlet  
 
-インナーソースプロジェクトは多くの貢献を受けており、メンテナンスが難しくなっています。メンテナは、プロジェクトのコア部分から離れた拡張機構を提供することで、最小のコストとメンテナンスオーバーヘッドでプロジェクトの能力をスケールアップすることを可能にします。
+インナーソースプロジェクトは多くのコントリビューションを受けており、メンテナンスが難しくなっています。メンテナは、プロジェクトのコア部分から離れた拡張機構を提供することで、最小のコストとメンテナンスオーバーヘッドでプロジェクトの能力をスケールアップすることを可能にします。
 
 ## 問題
 
-成熟したインナーソースリポジトリへの貢献が急速に増えると、コードレビューやメンテナンスの負担が増大します。これにより、大量のコードレビューのバックログが生じたり、新しい機能の貢献が早期に拒否されたりする結果となります。
+成熟したインナーソースリポジトリへのコントリビューションが急速に増えると、コードレビューやメンテナンスの負担が増大します。これにより、大量のコードレビューのバックログが生じたり、新しい機能のコントリビューションが早期に拒否されたりする結果となります。
 
 ホストチームは、新しい機能のリリースをより早く行い、イノベーションと実験を奨励しつつ、リポジトリを適切にメンテナンスするためにはどのようにすればよいのでしょうか？
 
 ## ストーリー
 
 特定のドメインスペース内での最高のイノベーションを一つの共通スタックに集め、共通のインフラストラクチャの再利用を可能にし、標準的なユーザーエクスペリエンスを提供することを目指す戦略的なプロジェクトが存在します。インナーソースを通じて、組織内の各チームは、そのドメインスペース内で働きながら、共通のコードベースにイノベーションを貢献する機会を得ます。
 
-しかし、複数の開発者からの並行した貢献が多くなると、コードベースのメンテナンスが難しくなります。これにより、プロジェクトのメンテナには、コード品質の基準を担保し、さまざまな形式のコミュニケーションを通じてコミュニティを支えるという大きな負担がかかります。
+しかし、複数の開発者からの並行したコントリビューションが多くなると、コードベースのメンテナンスが難しくなります。
+それは、プロジェクトのメンテナはコードの品質基準に対するオーナーシップを引き受けることになり、さまざまな形式のコミュニケーションを通じてコミュニティを支えるという大きな負担がかかるからです。
 
 プロジェクトのメンテナは以下のようなリスクに直面しています:
 
-- コントリビューターからのプルリクエストのバックログが絶えず存在する。
-- 職業の不満: メンテナの時間の大部分がコミュニティサポートの支援に使われてしまい、新しいことに挑戦する時間がない。
-- 成果感の欠如: 提供されたすべての機能が適切なユーザー需要を満たすわけではなく、それによって採用が進むわけでもない。
-- リリースに時間がかかる: コードベースに多くの機能があると、テストに時間がかかる。
-- メンテナンス活動の増加: 新しい機能が追加されると、バグが増えます。
+- コントリビューターからのプルリクエストのバックログが絶えず存在する
+- 職業の不満: メンテナの時間の大部分がコミュニティサポートの支援に使われてしまい、新しいことに挑戦する時間がない
+- 成果感の欠如: 提供されたすべての機能が適切なユーザー需要を満たすわけではなく、それによって結果的に採用されるとは限らな
+- リリースに時間がかかる: コードベースに多くの機能があると、テストに時間がかかる
+- メンテナンス活動の増加: 新しい機能が追加されると、バグが増える
 
-可能性のあるユーザーがその機能を自分のユースケースに適用する機会を得る前に、新しい機能の貢献が成熟するまでに多くの時間が費やされています。もし新しい機能がユースケースを満たさなければ、求められていたコード品質基準を達成するために費やした全ての時間が無駄になります。
+可能性のあるユーザーがその機能を自分のユースケースに適用する機会を得る前に、新しい機能のコントリビューションが成熟するまでに多くの時間が費やされています。もし新しい機能がユースケースを満たさなければ、求められていたコード品質基準を達成するために費やした全ての時間が無駄になります。
 
 ## 状況
 
-- 戦略的なインナーソースコードベースが、多数の従業員からの新機能の貢献で急速にスケールアップしています。
-- レビュアーと貢献の比率により、プルリクエストのバックログが増加しています。これにより、新機能のリリースがコミュニティに対して遅くなっています。
+- 戦略的なインナーソースコードベースが、多数の従業員からの新機能のコントリビューションで急速にスケールアップしています。
+- レビュアーとコントリビューションの比率により、プルリクエストのバックログが増加しています。これにより、新機能のリリースがコミュニティに対して遅くなっています。
 - コードベースの品質が劣化し、ユーザーエクスペリエンスが悪化しています。
-- コードベースのメンテナが負荷を感じ、貢献の増加とコミュニティサポートの増加に対応できなくなっています。
+- コードベースのメンテナが負荷を感じ、コントリビューションの増加とコミュニティサポートの増加に対応できなくなっています。
 - 提供された機能の一部はユーザーに採用されず、完全に不活動になる可能性があります。しかし、それらが使用されていないにもかかわらず、これらの機能は依然としてメンテナンスのオーバーヘッドを増やしています。
-- 組織は、新しい機能の貢献を品質基準を保持するために厳しく対応している一方で、コミュニティがアイデアを探求する前に大量の投資を行っています。
+- 組織は、新しい機能のコントリビューションを品質基準を保持するために厳しく対応している一方で、コミュニティがアイデアを探求する前に大量の投資を行っています。
 - 次の2つのシナリオのどちらかでパターンが適用されます:
    - メンテナがプロジェクトの範囲を絞り込むために、自身で新しい機能のアイデアを拒否することにより、コミュニティのイノベーションを阻害し、さらなる拡大を制限しています。
    - バックログを減らすために、新しい機能が十分なドキュメンテーション、ハードニング、テストなしにリリースされ、ユーザー体験が悪化します。これにより、コードベースのサイズが大きくなり、依存関係が大きくなり、メンテナンスが難しくなります。
@@ -61,7 +62,7 @@
    - テンプレートから開発された拡張機能の例を追加します。これにより、プロジェクトの開発者は、どのようにして良いパターンの拡張機能を書くべきかを理解することができます。
    - レビューをバイパスして拡張機能を作成する寄稿者の要件を緩和し、リリースや実験を早めることを許可します。
 2. **疎結合:** 機能を含むモジュラーなコンポーネントを持つことで、拡張機能への変更がメインコードベースや他の拡張機能の品質に影響を与えない疎結合を可能にすることができます。
-3. **依存性管理:** 各拡張は、それが構築されるプライマリリポジトリのバージョン範囲をピン留めするように注意する必要があります（他の依存関係と同じように）。また、それがプライマリリポジトリの依存関係をシャドーする他の依存関係の使用についても注意深くなければなりません。選択した依存関係のバージョンがプライマリリポジトリの選択したバージョンと互換性があるようにします。プライマリリポジトリとの任意の競合は、拡張のテストフレームワークで捉えられます。
+3. **依存性管理:** 各拡張は、それが構築されるプライマリリポジトリのバージョン範囲をピン留めするように注意する必要があります（他の依存関係と同じように）。また、それがプライマリリポジトリの依存関係をシャドーする他の依存関係の使用についても注意深くなければなりません。選択した依存関係のバージョンがプライマリリポジトリの選択したバージョンと互換性があるようにします。プライマリリポジトリとの任意の競合は、拡張のテストフレームワークで検出できます。
 4. **テスト戦略:** 拡張機能を個別に、または組み合わせてテストする方法は？
    - **拡張機能を個別にテストする:** 拡張機能のテンプレートは、拡張機能の開発者が追加した機能をテストするためのテストフレームワークを提供します。これには、ユニットテスト、ランタイムパフォーマンステスト、品質テストのフレームワークが含まれることがあります。
    - **拡張機能をプライマリリポジトリと組み合わせてテストする:** 拡張機能の開発者は、プライマリリポジトリの特定のバージョンに対して自分の拡張機能をテストするための良好なパターンの方法を持つべきで、これにはプライマリリポジトリのメンテナの関与は必要ありません。
@@ -82,7 +83,7 @@
 - 拡張機能は、プライマリプロジェクトの全てのユーザーによって反復可能な方法で発見できます。コードがまだメインリポジトリに存在していないとしても、それが価値がないわけではありません。
 - メンテナの負担は、拡張機能がプライマリプロジェクトで重要なギャップを埋めていることを示すまで軽減されます。
 - コアプロジェクトの共通コード（例えば、ベースクラスやユーティリティ関数）は、プロジェクトの領域を拡張する新しい開発の出発点となります。これにより、革新的な作業を後から移植する必要がなくなり、プロジェクトにとって新しい機能を開発する全体的な負担を軽減します。
-- 開発者は、彼らのコードベースのためのコミュニティのメンテナンスとコミュニティ構築に貢献し、関与し続ける可能性が高くなります。これは全体のプロジェクトエコシステムの健康にも良い影響を与えます。
+- 開発者は、彼らのコードベースのためのコミュニティのメンテナンスとコミュニティ構築にコントリビューションし、関与し続ける可能性が高くなります。これは全体のプロジェクトエコシステムの健康にも良い影響を与えます。
 
 ## 結果の状況
 
@@ -95,11 +96,11 @@
 
 ## 事例
 
-* **IBM社**は、[インナーソース AIライブラリ](https://youtu.be/Lz-tIc2cyRM)を拡大するためにこの解決策を採用しています。拡張機能を使用することで、開発者はAIライブラリに更に多くのアルゴリズムを追加し、彼らの革新を企業内のコミュニティと共有することができます。コアライブラリには、採用されて検証された戦略的なアルゴリズムのみが含まれており、これにより我々は貢献をスケールするにつれてそれらをより簡単に維持することができます。
+* **IBM社**は、[インナーソース AIライブラリ](https://youtu.be/Lz-tIc2cyRM)を拡大するためにこの解決策を採用しています。拡張機能を使用することで、開発者はAIライブラリに更に多くのアルゴリズムを追加し、彼らの革新を企業内のコミュニティと共有することができます。コアライブラリには、採用されて検証された戦略的なアルゴリズムのみが含まれており、これにより我々はコントリビューションをスケールするにつれてそれらをより簡単に維持することができます。
 
 ## エイリアス
 
-スケールでの貢献管理のための拡張
+スケールでのコントリビューション管理のための拡張
 
 ## ステータス