Merge pull request #440 from InnerSourceCommons/jp-translation-improvement

Japanese translation improvement

Author: yuhattor

.gitbook.yaml

@@ -1,5 +1,6 @@
 root : ./
 
 structure:
-  readme: book/en/introduction.md
-  summary: book/en/toc.md
+  readme: book/jp/introduction.md
+  summary: book/jp/toc.md
+  

book/jp/contribute.md

@@ -15,7 +15,7 @@
 ここでは、あなたがコントリビュートできるいくつかの方法を紹介します。
 
 1. この本で気づいたスペルやフォーマットなどの不具合を修正する
-1. 既存のパターンの内容を改善する（例えば、_既知の例_としてパターンを使用している方法についての短い説明を追加する）
+1. 既存のパターンの内容を改善する（例えば、 _既知の例_ としてパターンを使用している方法についての短い説明を追加する）
 1. 新しいパターンを投稿し、あなたの組織でインナーソースに関する課題をどのように克服したかを説明する
 
 上記の(1)と(2)については、本書の各ページの上部にある **Edit on GitHub** のリンクを押すだけです。この操作では、私たちの GitHub リポジトリ内のそれぞれのファイルに直接移動し、各ページであなたの変更を提案することができます。

book/jp/introduction.md

@@ -48,7 +48,7 @@
 ほとんどの場合、与えられたソリューションを自分達の状況に合わせる必要がありますが、パターンで与えられている情報、コンテキスト（動かせない制約）とフォース（変更可能な制約、相互にバランスをとる制約）の定義は、ソリューションを適用するのに役立つはずです。 またパターンに追加すべき項目として、あなたの特定の企業/組織に適用さる追加の制約があるかを決定する必要があることにも注意してください。
 これらの追加の制約のためには、追加のソリューションステップを適用する必要があるかもしれません。
 
-パターンのフォーマットは実績のあるソリューションを記述するのに便利ですが、パターンがまだ確立されていない新しいソリューションに関する_ブレインストーミング_にも使用できます。これは、パターンの構造が、構造化された方法で問題について考えるためのフレームワークになっているからです。
+パターンのフォーマットは実績のあるソリューションを記述するのに便利ですが、パターンがまだ確立されていない新しいソリューションに関する _ブレインストーミング_ にも使用できます。これは、パターンの構造が、構造化された方法で問題について考えるためのフレームワークになっているからです。
 
 また、インナーソース・コモンズのコミュニティに助けを求める方法として、ドーナツ・パターン（問題、状況、フォース、結果の状態のフィールドを記載し、ソリューションの欄は空白にする）を作ることもできます。(実証済みのソリューションを見つけるために、または試してみるためにブレインストーミングを実施します)
 

book/jp/toc.md

@@ -34,7 +34,7 @@ Instead edit toc_template.md
 * [スタンダード・ベース・ドキュメンテーション](../../translation/japanese/patterns/base-documentation.md) - インナーソースプロジェクトへの新しいコントリビューターは、誰がプロジェクトを維持し、何に取り組み、どのようにコントリビューションすればよいかを理解するのに苦労しています。README.md/CONTRIBUTING.md のような標準ファイルでドキュメントを提供することで、新しいコントリビューターのためのセルフサービスなプロセスを可能にし、よくある質問に対する答えを自分自身で見つけることができるようにします。
 * [リポジトリアクティビティスコア](../../translation/japanese/patterns/repository-activity-score.md) - 潜在的なコントリビューターは、彼らの助けを必要とするアクティブなインナーソースプロジェクトを見つけたいと思っています。各プロジェクトのリポジトリのアクティビティスコアを計算することで、プロジェクトのランク付けされたリストを作成することができます (参考: インナーソースポータル )、そのため、潜在的コントリビューターは、彼らがコントリビュートしたいプロジェクトをより簡単に決定できます。
 * [レビュー委員会](../../translation/japanese/patterns/review-committee.md) - インナーソースの作業モデルは、開発者と管理者のための、より伝統的なアプローチからの抜本的な変革です。インナーソースイニシアチブとそれに参加するビジネスユニットのすべてのシニアマネージャーの間のインタフェースとしてレビュー委員会を確立することにより、マイクロマネジメントを助長することなく、監視と制御の一定レベルを与えるように、イニシアチブに慣れ親しみ、それをサポートできるようになる可能性が高くなります。
-* [信頼されたコミッター (トラステッドコミッター)](../../translation/japanese/patterns/trusted-committer.md) - 多くのInnerSourceプロジェクトは、コントリビューターからフィードバック、機能、バグフィックスを一貫して受け取る状況にあります。このような状況で、プロジェクトのメンテナーは、単一のコントリビューションを越えてコントリビューターの仕事を認識し、報酬を与える方法を模索します。
+* [トラステッドコミッター](../../translation/japanese/patterns/trusted-committer.md) - 多くのInnerSourceプロジェクトは、コントリビューターからフィードバック、機能、バグフィックスを一貫して受け取る状況にあります。このような状況で、プロジェクトのメンテナーは、単一のコントリビューションを越えてコントリビューターの仕事を認識し、報酬を与える方法を模索します。
 * [共通要件](../../translation/japanese/patterns/common-requirements.md) - 共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。
 * [基本原則ガイダンスの文書化](../../translation/japanese/patterns/document-your-guiding-principles.md) - 「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープンソースのバックグラウンドがない人々にはうまく機能しません。 解決策として、インナーソースの最も重要な原則を文書化し広く公開しましょう。
 * [実験として始める](../../translation/japanese/patterns/start-as-experiment.md) - インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。

translation/japanese/patterns/30-day-warranty.md

@@ -71,7 +71,7 @@
 
 ## 同種の例
 
-- 複数の、功績至上主義的に任命された"[信頼されたコミッター(トラステッドコミッター)](./trusted-committer.md)"が責任を持つことで、依存するチームの協力をコミュニティ化することで保証する。
+- 複数の、功績至上主義的に任命された[トラステッドコミッター](./trusted-committer.md)が責任を持つことで、依存するチームの協力をコミュニティ化することで保証する。
 
 ## 翻訳の履歴
 

translation/japanese/patterns/base-documentation.md

@@ -41,9 +41,9 @@
 * プロジェクトを修正するために必要なドキュメント - またはそれへのリンク
 * プロジェクトにコントリビュートする方法に関するドキュメント - またはそれへのリンク
 * プロジェクトがどのようなアクセス可能なパブリックもしくはアーカイブのコミュニケーションチャネルを用いているかを説明する "Getting involved" セクション。このリンクには、プロジェクトのイシュー・トラッカーへのリンクだけでなく、さらなるディスカッションメディアへのリンクも含めるべきです。
-* プロジェクトを支える ["信頼されたコミッター(トラステッドコミッター)"](./trusted-committer.md)が誰であるかを説明する "Who we are" のセクション。これらの人々と個人的に連絡を取る代わりに、上記の公開コミュニケーションチャンネルを使用して連絡を取るべきであるという説明も必要です。
+* プロジェクトを支える [トラステッドコミッター](./trusted-committer.md)が誰であるかを説明する "Who we are" のセクション。これらの人々と個人的に連絡を取る代わりに、上記の公開コミュニケーションチャンネルを使用して連絡を取るべきであるという説明も必要です。
 * プロジェクトが貢献者を信頼されるコミッターにするための基準（もしそのような道があるならば）の説明です。
-* コントリビューターがそのプロジェクトにおける "信頼されたコミッター" になるための基準及び、そのパスが存在するならばそのパス
+* コントリビューターがそのプロジェクトにおけるトラステッドコミッターになるための基準及び、そのパスが存在するならばそのパス
 
 ### CONTRIBUTING.md
 
@@ -64,7 +64,7 @@
 ## 結果の状況
 
 * コントリビューターがスピードを上げるまでの時間が大幅に短縮されます
-* ["信頼されたコミッター(トラステッドコミッター)"](./trusted-committer.md) が初歩の質問に答える時間が大幅に短縮され、他の作業に時間を割くことができるようになります
+* [トラステッドコミッター](./trusted-committer.md) が初歩の質問に答える時間が大幅に短縮され、他の作業に時間を割くことができるようになります
 * 誤った理解や、同じ方向を向いていないことによるエスカレーションが大幅に削減されます
 
 ## 事例

translation/japanese/patterns/communication-tooling.md

@@ -28,7 +28,7 @@
 
 * プロジェクトは、ホストチームのメンバーだけでなく、ダウンストリームユーザーやコントリビューターもフォローできるように、構造化されたコミュニケーション、意思決定、進捗追跡が透過的に行われる独自のイシュートラッカーを持っている必要があります。
 * プロジェクトは、あまり厳密でない構造を持つ1つ以上のディスカッションチャンネルを持つべきです。一般的に、これはメーリングリスト、オンラインフォーラム、あるいはアーカイブされたチャットチャンネルになります。通常、プロジェクトのためのチャンネルは1つで十分ですが、トラフィックが増えすぎた場合は、プロジェクトの使用に関する議論とプロジェクトの開発に関する議論を分けることが有用です。
-* さらに、プロジェクトは["信頼されたコミッター(トラステッドコミッター)"](./trusted-committer.md) の間で機密のやりとりができるプライベートチャンネルを一つ持つべきです - たとえば、ホストチームにさらに "信頼されたコミッター" を追加するなどです。このチャンネルは、デフォルトではオープンで、非常に稀な状況下でのみ非公開になるように、細心の注意を払って使用されるべきです。
+* さらに、プロジェクトは[トラステッドコミッター](./trusted-committer.md) の間で機密のやりとりができるプライベートチャンネルを一つ持つべきです - たとえば、ホストチームにさらにトラステッドコミッターを追加するなどです。このチャンネルは、デフォルトではオープンで、非常に稀な状況下でのみ非公開になるように、細心の注意を払って使用されるべきです。
 
 文章での共有のチャンネル以外でもコミュニケーションは可能ですが、できるだけ多くの情報を非同期チャンネルにつなぐべきです。
 

translation/japanese/patterns/contracted-contributor.md

@@ -52,7 +52,7 @@
 
 正式な契約は、コントリビューターやコミュニティにとっても有益です。
 
-- 安定したコントリビューターのグループがあれば、そのうちの何人かが最終的に[信頼されたコミッター(トラステッドコミッター)](./trusted-committer.md) のロールに到達する可能性が高くなります。
+- 安定したコントリビューターのグループがあれば、そのうちの何人かが最終的に[トラステッドコミッター](./trusted-committer.md) のロールに到達する可能性が高くなります。
 - 正式な契約は、インナーソースの活動への参加に関連するコンフリクトを解決するための基礎を提供します。(注: 調停は、対応する文化を持つ一部の企業のみに成功する可能性が高いことにご注意ください)
 
 ## 事例

translation/japanese/patterns/core-team.md

@@ -54,7 +54,7 @@
 
 これらの各項目は、健全な製品エコシステムにとって非常に重要であるにもかかわらず、貢献として優先されることはまずないでしょう。
 コアチームは少人数の、フルタイムまたはパートタイムで構成することができます。その選択は、必要な作業量、リソースの利用可能性、組織の文化に依存します。最も重要な考慮点は、組織が他のチームと同じように権限を与え、責任を負わせることができるようにチームを編成することです。
-その中心的な役割から、コアチームのメンバーはほぼ常に "**信頼されたコミッター(トラステッドコミッター)**" の役割も果たすべきです (この概念については、[ラーニングパス][tc-learning-path]と [パターン][tc-pattern] を参照してください)。"信頼されたコミッター" の役割は、他のメンバーがプロジェクトに貢献したり利用したりするのを促進することに主眼が置かれていますが、コアチームのメンバーは定期的にプロジェクトにも貢献します。コアチームには、貢献を決定するような独自のビジネスアジェンダはありません。彼らは、他の人がプロジェクトを利用し貢献するために何が最も役に立つかを考えて、取り組むべきことを決定します。
+その中心的な役割から、コアチームのメンバーはほぼ常に**トラステッドコミッター**の役割も果たすべきです (この概念については、[ラーニングパス][tc-learning-path]と [パターン][tc-pattern] を参照してください)。トラステッドコミッター の役割は、他のメンバーがプロジェクトに貢献したり利用したりするのを促進することに主眼が置かれていますが、コアチームのメンバーは定期的にプロジェクトにも貢献します。コアチームには、貢献を決定するような独自のビジネスアジェンダはありません。彼らは、他の人がプロジェクトを利用し貢献するために何が最も役に立つかを考えて、取り組むべきことを決定します。
 
 この目標を継続的にリマインドさせるためには、コアチームに定期的に以下の項目を報告してもらうのがよいでしょう。
 

translation/japanese/patterns/document-your-guiding-principles.md

@@ -85,9 +85,9 @@
 1. これは構造化された文書に取って代わるものではありません。しかし一方で、構造化されたドキュメントを収集するための出発点として機能もします。
 1. すべてを文書化し、組織全体がアクセスできるようにするというルールには例外があります。人に関する議論やセキュリティに関する議論は機密事項であり、人前で行うべきではありません。
 
-(6) **信頼されたコミッター(トラステッドコミッター)** に対するリワード
+(6) **トラステッドコミッター** に対するリワード
 
-すべての貢献(ソースコード、ドキュメント、バグレポート、議論への意見、ユーザーサポート、マーケティングなど) は歓迎され、リワードの対象になります。プロジェクトをサポートする人は、["信頼されたコミッター(トラステッドコミッター)"](./trusted-committer.md)としてプロジェクトに招待され、全ての "信頼されたコミッター" のリストは公開されます。
+すべての貢献(ソースコード、ドキュメント、バグレポート、議論への意見、ユーザーサポート、マーケティングなど) は歓迎され、リワードの対象になります。プロジェクトをサポートする人は、[トラステッドコミッター](./trusted-committer.md)としてプロジェクトに招待され、全てのトラステッドコミッターのリストは公開されます。
 
 ## 結果の状況