Unified translation of "Trusted Committer" - jp

Author: yuhattor

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

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

translation/japanese/patterns/base-documentation.md

@@ -41,9 +41,9 @@
 * プロジェクトを修正するために必要なドキュメント - またはそれへのリンク
 * プロジェクトにコントリビュートする方法に関するドキュメント - またはそれへのリンク
 * プロジェクトがどのようなアクセス可能なパブリックもしくはアーカイブのコミュニケーションチャネルを用いているかを説明する "Getting involved" セクション。このリンクには、プロジェクトのイシュー・トラッカーへのリンクだけでなく、さらなるディスカッションメディアへのリンクも含めるべきです。
-* プロジェクトを支える [信頼されたコミッター - Trusted Committer](./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)としてプロジェクトに招待され、全ての "信頼されたコミッター" のリストは公開されます。
 
 ## 結果の状況
 

translation/japanese/patterns/innersource-portal.md

@@ -47,7 +47,7 @@
 
 * インナーソースポータルにアクセスした人は、すべての利用可能なプロジェクトを見るだけでなく、プロジェクト名、使用中の技術、コントリビューター名、スポンサー事業部などの様々な条件に基づいて、特定のプロジェクトを検索することができるようになっています。
 * インナーソースポータルを通じて表示される情報は、常にインナーソースプロジェクトのオーナーの完全な制御下にある必要があります。プロジェクトリポジトリ自体に格納されている特定のデータファイルまたはメタデータから直接この情報をソーシングすることによって実現されるのが好ましいです。
-* プロジェクトのオーナーは、プロジェクト名、信頼されたコミッターの名前、簡単な説明とコードリポジトリまたは任意のサポートドキュメントへのリンクを含むそれらのデータファイル内のプロジェクトに関するすべての関連情報を含める必要があります。
+* プロジェクトのオーナーは、プロジェクト名、"信頼されたコミッター(トラステッドコミッター)" の名前、簡単な説明とコードリポジトリまたは任意のサポートドキュメントへのリンクを含むそれらのデータファイル内のプロジェクトに関するすべての関連情報を含める必要があります。
 * (*オプション)ほとんどの組織は、ポータルをイントラネットでのみ利用できるようにすることを選択しますが、いくつかの組織は、ポータルを公共のインターネット上で利用できるようにすることを選択しました。後者は、例えばブランディングや採用の目的で、ポータルにインナーソースのアプローチに関する追加情報を表示したい組織にとって興味深いものになるでしょう。
 
 ポータルを立ち上げる際には、ポータル内に表示されるプロジェクトの数を増やすために、インナーソースのデータファイルやコードリポジトリへのメタデータの追加を促進するコミュニケーションキャンペーンを検討する必要があります。

translation/japanese/patterns/maturity-model.md

@@ -178,8 +178,8 @@
 インナーソースにはいくつかの明示的な役割があります。初期の段階では、これらの役割を採用しなくても一部のパターンを使用できる場合がありますが、明示的な役割のタイトルを使用してプロジェクト内でコミュニケーションする方が簡単になります。
 
 * RO-0: インナーソースの採用を支援する特定の役割はありません。開発者、アナリスト、テスターなど一般的な開発の役割のみが存在します。
-* RO-1: 時折、一部の個人やチームが他のプロジェクトにコントリビュートします。これらは技術的なコントリビューションであり、ユーザー/コントリビューターの役割が見られます。 チームによっては、少なくとも一人のメンバーが、他の開発チームのメンバーに開発プロセスを説明する技術的なリファレンスであることが確認されています。このメンバーは信頼されたコミッターの役割をカバーするための候補者となりえます。
-* RO-2: 「インナーソースオフィス」が存在します。このオフィサーの役割は、プロセスなどを含むガバナンスとサポートを担当します。教育のニーズを特定し、これが組織に確実に提供されるようにします。 またインナーソースプロジェクトへの取り組みにおいて組織を主導および指導します。 これはインナーソースのビジョンとロードマップを定義する、最初の正式なステップです。そして「信頼されたコミッター」の役割は開発チームのメンバーだけでなく、外部のコントリビューターにとっての連絡先/参照先にもなっています。コミュニティにコントリビュートする方法を説明する標準的なプロセスがあり、コントリビューターの役割が存在します。またもう一つの役割として「データサイエンティスト」が存在します。この役割はインナーソースの成長を測定するために必要な、インナーソースアクティビティの履歴管理を担当します。信頼されたコミッターの役割がより技術的な役割に進化していくと、「コミュニティマネージャー」の役割が生まれてきます。コミュニティマネージャーはコミュニティの活性化を担当し、新しい開発者/ユーザー（コントリビューター/コミュニティメンバー）を引き付けて維持する主な責任を負います。
+* RO-1: 時折、一部の個人やチームが他のプロジェクトにコントリビュートします。これらは技術的なコントリビューションであり、ユーザー/コントリビューターの役割が見られます。 チームによっては、少なくとも一人のメンバーが、他の開発チームのメンバーに開発プロセスを説明する技術的なリファレンスであることが確認されています。このメンバーは "信頼されたコミッター(トラステッドコミッター)" の役割をカバーするための候補者となりえます。
+* RO-2: 「インナーソースオフィス」が存在します。このオフィサーの役割は、プロセスなどを含むガバナンスとサポートを担当します。教育のニーズを特定し、これが組織に確実に提供されるようにします。 またインナーソースプロジェクトへの取り組みにおいて組織を主導および指導します。 これはインナーソースのビジョンとロードマップを定義する、最初の正式なステップです。そして "信頼されたコミッター(トラステッドコミッター)" の役割は開発チームのメンバーだけでなく、外部のコントリビューターにとっての連絡先/参照先にもなっています。コミュニティにコントリビュートする方法を説明する標準的なプロセスがあり、コントリビューターの役割が存在します。またもう一つの役割として「データサイエンティスト」が存在します。この役割はインナーソースの成長を測定するために必要な、インナーソースアクティビティの履歴管理を担当します。"信頼されたコミッター(トラステッドコミッター)" の役割がより技術的な役割に進化していくと、「コミュニティマネージャー」の役割が生まれてきます。コミュニティマネージャーはコミュニティの活性化を担当し、新しい開発者/ユーザー（コントリビューター/コミュニティメンバー）を引き付けて維持する主な責任を負います。
 * RO-3: 「エバンジェリスト」は組織内を移動し、現在の作業、インナーソースの機能とその方法を他の人に知らせ、他の人がイニシアチブを理解して参加できるように支援します。この段階では「非技術的なコントリビューター」の存在も出現します。
 
 ## 結果の状況

translation/japanese/patterns/praise-participants.md

@@ -16,7 +16,7 @@
 
 ## 状況
 
-* あなたはインナーソースプロジェクトの [信頼されたコミッター](./trusted-committer.md) あるいはメンテナーです。
+* あなたはインナーソースプロジェクトの ["信頼されたコミッター(トラステッドコミッター)"](./trusted-committer.md) あるいはメンテナーです。
 * あなたは、コントリビューターのコミュニティを大切にし、それを維持・発展させたいと考えています。
 
 ## 組織に働く力学