Adding the initial Japanese translation

.github/workflows/book.yml

@@ -5,6 +5,7 @@ on:
     branches:
       - "main"
       - "book-staging"
+      - "japanese-translation-v1"
 
 jobs:
   book-toc-generation:

book/generate_toc.rb

@@ -83,6 +83,19 @@ def generate_patterns_overview(patterns)
 new_toc_content = open(TOC_TEMPLATE_FILE).readlines().join()
 new_toc_content = new_toc_content.gsub(/<<PATTERS_HERE>>/,toc_snippet)
 
+
+## Generate list of patterns in Japanese and sort them by name
+patterns_jp = Dir["../translation/japanese/patterns/*.md"]
+pattern_overview_jp = generate_patterns_overview(patterns_jp)
+pattern_overview_jp = pattern_overview_jp.sort.to_h
+
+toc_snippet_jp = pattern_overview_jp.map{|title, values| "    * [#{title}](#{values[:file]}) - #{values[:patlet]}"}
+toc_snippet_jp = toc_snippet_jp.join("\n")
+
+## Inject the list of patterns in Japanese into the ToC template
+new_toc_content = new_toc_content.gsub(/<<TRANSLATION_HERE>>/,toc_snippet_jp)
+
+
 ## Write the new ToC to file
 File.write(TOC_FILE, new_toc_content)
 

book/toc.md

@@ -52,3 +52,32 @@ Instead edit toc_template.md
 
 * [This book on GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
 * [InnerSource Commons](http://innersourcecommons.org)
+
+## Translation<a id="p"></a>
+
+* Japanese
+  * [イントロダクション](../translation/japanese/introduction.md)
+  * [パターンの一覧](../translation/japanese/explore-patterns.md)
+  * [この本へのコントリビューション](../translation/japanese/contribute.md)
+  * パターン
+    * [30日の保証期間](../translation/japanese/patterns/30-day-warranty.md) - 自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。
+    * [RFCを用いたチーム横断的な意思決定の透明化](../translation/japanese/patterns/transparent-cross-team-decision-making-using-rfcs.md) - 高い参加率を達成し、関係者全員にとって最良の意思決定を行いたいインナーソースプロジェクトは、ソフトウェアのライフサイクル全体を通して参加型のシステムを構築する方法を見つける必要があります。内部のRFC(Requests for Comments)ドキュメントを公開することで、設計プロセスの早い段階から議論を行うことができ、関係者全員が高いコミットメントを持ってソリューションを構築できる可能性が高まります。
+    * [イシュートラッカーの使い方を多様化する](../translation/japanese/patterns/issue-tracker.md) - インナーソースのホストチームは、計画や進捗だけでなく、変更の背景も透明化することができていません。これは、プロジェクトのイシュートラッカーのユースケースを増やし、ブレーンストーミング、実装の議論、機能設計にも使えるようにすることで解決することができます。
+    * [インナーソースポータル](../translation/japanese/patterns/innersource-portal.md) - 潜在的なコントリビューターは、彼らが興味を持っているインナーソースプロジェクトを簡単に見つけることができません。すべての利用可能なインナーソースプロジェクトの情報をインデックス化するイントラネットのウェブサイトを作成することにより、あなたはコントリビューターが彼らに興味があるかもしれないプロジェクトについて知ることができ、インナーソースプロジェクトのオーナーは、外部のオーディエンスを引き付けることができます。
+    * [インナーソースライセンス](../translation/japanese/patterns/innersource-license.md) - 同じ組織に属する2つの法人は、ソフトウェアのソースコードを互いに共有したいと考えていますが、法的責任や会社間の会計処理の観点からの影響を懸念しています。
+    * [ギグマーケットプレイス](../translation/japanese/patterns/gig-marketplace.md) - イントラネットのウェブサイトを作成し、特定のインナーソースプロジェクトのニーズを、時間とスキルの要件を明示した「ギグ」としてリストアップすることで、マーケットプレイスを確立する。 これにより、管理者がインナーソースのコントリビューションを行うための承認を与え可能性が増え、従業員の時間のコミットメントと専門的な利点をよりよく理解することができます。
+    * [クロスチームプロジェクト評価](../translation/japanese/patterns/crossteam-project-valuation.md) - 会社の収益に直接的な影響を提供していないクロスチームのインナーソースプロジェクトの価値を評価して社内に売り込むことは困難です。 ここでは、あなたのプロジェクトの価値を明確に表現し、それを大きくするためのデータ駆動型の方法を紹介します
+    * [コアチーム](../translation/japanese/patterns/core-team.md) - インナーソースのプロジェクトが広く必要とされていても、プロジェクトが難しいためにコントリビューションや活用に支障をきたす場合があります。プロジェクトの基本的な項目を専門に担当するコアチームを設立してください。コアチームの作業により、コントリビューターは自分のシナリオに価値をもたらす機能を追加し、使用することができます。
+    * [コミュニケーションツーリング](../translation/japanese/patterns/communication-tooling.md) - インナーソースのプロジェクトは、開発チームの外で使用されていますが、ユーザーはヘルプを得たり、プロジェクトチームと連絡を取ったりするのに苦労しています。 このアイデアは、ディスカッションが可視化され、アーカイブされ、検索可能になることを可能にする標準的なコミュニケーションツールを設定し、文書化することです。
+    * [コントラクトコントリビューター](../translation/japanese/patterns/contracted-contributor.md) - インナーソースにコントリビュートしたい社員がいますが、彼らの直属の上司はその活動に抵抗を示しています。正式な契約と合意をすることによって救済することができるかもしれません。
+    * [コントリビューションの功労を称える](../translation/japanese/patterns/praise-participants.md) - インナーソースのコントリビューションの後、その時間と努力に対してコントリビューターに感謝することは重要です。 このパターンは、コントリビューションを効果的に認めるだけでなく、コントリビューターや他の人たちのさらなる関与を引き出すためのガイダンスを提供します。
+    * [サービス対ライブラリ](../translation/japanese/patterns/service-vs-library.md) - DevOps環境のチームは、サービスのダウンタイムに対応する責任が誰にあるのかが曖昧になるため、チームの境界を越えて共通のコードベースで作業することに消極的になる場合があります。解決策としては、同じサービスを独立した環境で展開し、サービスダウン時のエスカレーション・チェーンを別々に構築するか、多くの共有コードを1つのライブラリに集約し、その上で共同作業を行うことが挙げられます。
+    * [スタンダード・ベース・ドキュメンテーション](../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/common-requirements.md) - 共有リポジトリにある共通のコードは、それを使いたいすべてのプロジェクトチームのニーズを満たしていません。これは、要件の調整とリファクタリングによって解決されます。
+    * [基本原則ガイダンスの文書化](../translation/japanese/patterns/document-your-guiding-principles.md) - 「オープンソースのベストプラクティスを組織内に適用する」という通常のインナーソースの説明は、オープンソースのバックグラウンドがない人々にはうまく機能しません。 解決策として、インナーソースの最も重要な原則を文書化し広く公開しましょう。
+    * [実験として始める](../translation/japanese/patterns/start-as-experiment.md) - インナーソースイニシアチブを期間限定の実験として開始し、インナーソースに慣れていないマネージャーがイニシアチブを承認およびサポートしやすくします。
+    * [成熟度モデル](../translation/japanese/patterns/maturity-model.md) - チームはインナーソースを採用し始めました。このプラクティスは、複数の部門に広がっています。しかし、インナーソースプロジェクトを構成する概念への理解は様々です。解決策は、チームがセルフチェックを経て、まだ気づいていないパターンやプラクティスを発見できるよう、成熟度モデルを提供することです。
+    * [正式なコミュニティリーダー](../translation/japanese/patterns/dedicated-community-leader.md) - インナーソースの取り組みを成功させるために、コミュニケーションとテクニカルの両方のスキルを持つ人をコミュニティのリーダーとして選ぶ。

book/toc_template.md

@@ -32,3 +32,12 @@ Instead edit toc_template.md
 
 * [This book on GitHub](https://github.com/InnerSourceCommons/InnerSourcePatterns)
 * [InnerSource Commons](http://innersourcecommons.org)
+
+## Translation<a id="p"></a>
+
+* Japanese
+  * [イントロダクション](../translation/japanese/introduction.md)
+  * [パターンの一覧](../translation/japanese/explore-patterns.md)
+  * [この本へのコントリビューション](../translation/japanese/contribute.md)
+  * パターン
+<<TRANSLATION_HERE>>

translation/japanese/contribute.md

@@ -0,0 +1,32 @@
+# この本にコントリビュートするには
+
+この本をもっと良くしたいですか？ 素敵ですね、やりましょう！
+
+インナーソース・パターンブックは[オープンソースプロジェクト](https://github.com/InnerSourceCommons/InnerSourcePatterns)ですので、どんな形でのコントリビューションでも、そしてどんな些細なことでもかまいません！
+文法やスペルの修正やデザインの改善から、あなたの職場で行われたインナーソースの経験に基づいた全く新しいパターンの提案まで、私たちはどんなコントリビューションでも喜んで歓迎します！
+あなたがオープンソースプロジェクトにコントリビュートしたことがない場合でも大丈夫ご心配なく。インナーソース・パターンのコミュニティはフレンドリーな人々のグループですので、コントリビュートするのに安全な場所です。
+
+## 始める前に
+
+インナーソース・パターンとこの本のソースは、GitHub のリポジトリで保管されています。そのため、この本の編集や提案を行うには、GitHub のユーザーアカウントが必要です。もしまだそれを持っていないなら、[github.com](https://github.com) で無料のアカウントを作成してください。
+
+## コントリビュートするさまざまな方法
+
+ここでは、あなたがコントリビュートできるいくつかの方法を紹介します。
+
+1. この本で気づいたスペルやフォーマットなどの不具合を修正する
+1. 既存のパターンの内容を改善する（例えば、_既知の例_としてパターンを使用している方法についての短い説明を追加する）
+1. 新しいパターンを投稿し、あなたの組織でインナーソースに関する課題をどのように克服したかを説明する
+
+上記の(1)と(2)については、本書の各ページの上部にある **Edit on GitHub** のリンクを押すだけです。この操作では、私たちの GitHub リポジトリ内のそれぞれのファイルに直接移動し、各ページであなたの変更を提案することができます。
+
+(3) については、[インナーソース・パターン](https://github.com/InnerSourceCommons/InnerSourcePatterns) リポジトリをクローンし、あなたの提案するパターンを新しいファイルに追加する必要があります。このような大きなコントリビュートする場合は、私たちの [CONTRIBUTING.md(英語)](../../CONTRIBUTING.md) と [Contributor Handbook(英語)](../../meta/contributor-handbook.md) を確認してください。
+
+## コントリビューションにかかるライセンス
+
+このリポジトリのコンテンツは [CC-BY-SA-4.0](../../LICENSE.txt) の下でライセンスされています。このリポジトリにコントリビュートすることは、私たち(そして他のすべての人)に対して、このライセンスに従ってあなたのコントリビューション物を使用する権利を与えることになります。
+
+## 翻訳の履歴
+
+- **2022-05-23** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
+- **2022-06-15** - レビュー [@johtani](https://github.com/johtani)

translation/japanese/explore-patterns.md

@@ -0,0 +1,23 @@
+# パターンを探る
+
+とても素晴らしいことに、インナーソース・コモンズのコミュニティから、どんどんパターンが寄稿されています！
+
+さて、ではどのように特定の自分の状況に役立つパターンを読者は簡単に見つけられるでしょうか？
+そこで私たちはこのマインドマップを提供します。このマインドマップは、**インナーソースプログラムのさまざまなフェーズと、それぞれのフェーズで現れる可能性のある課題に基づいてパターンを分類しています。**
+
+![インナーソース・パターンのマインドマップ](../../pattern-categorization/innersource-program-mind-map.png)
+
+## このマインドマップを改善する
+
+もし、このマインドマップを何かおかしいと感じた場合、その問題点と修正すべき点を記述した[イシューを作成](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues)してください。
+
+さらに、これらのパターンの発見性を向上させるための他のアイデアや、このマインドマップをより良くしたい場合は、[パターン分類](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/pattern-categorization/README.md)アプローチのドキュメントを確認し、[この本へのコントリビューション](../../book/contribute.md)の方法も確認してみてください。
+
+## リファレンス
+
+このようにパターンを分類するアイデアは、Tim Yao さん、Bob Hanmer さん、Padma Sudarsanshi さんによる[Thoughts on an InnerSource Pattern Language](https://drive.google.com/file/d/13AY8glCOdpLOVuz7cVD6QOB8d2xbHCS1/view) (2018) の記述を大まかに元にしています。具体的な内容はそのスライドデックの15ページ目をご覧ください。
+
+## 翻訳の履歴
+
+- **2022-05-23** - 翻訳 [Yuki Hattori](https://github.com/yuhattor)
+- **2022-06-15** - レビュー [@johtani](https://github.com/johtani)