@@ -58,7 +58,6 @@
 
 ![Brief picture of README.md and CONTRIBUTING.md content](../../../patterns/2-structured/project-setup/assets/base\_docs\_drawing.png)
 
-
 様々なオープンソースプロジェクトにおいて、 `README.md` の書き方や、 `CONTRIBUTING.md` ファイルにどのような情報を含めるべきかについての良い例がたくさんあります。[How to write a readme that rocks](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a), [Open Source Guide from GitHub](https://opensource.guide/) や書籍 [Producing Open Source](https://producingoss.com/en/producingoss.html)などのページには、どのような情報を提供すべきなのかについての貴重な情報が掲載されています。Producing Open Source には、良い README を書くための章はありませんが、[Getting Started chapter](https://producingoss.com/en/producingoss.html#starting-from-what-you-have) には、ホストチームのメンバー、ユーザー、コントリビューターが必要とするもののかなり広範なリストがあります。インナーソースのプロジェクトは、おそらく最初からこれらの側面のすべてをカバーする必要がはありませんが、リスト自体は README.md がカバーできるものを想起するために有効です。
 このパターンには、すぐに始められるように、2つの非常に基本的なテンプレートが付属しています。[README-template.md](../templates/README-template.md) と [CONTRIBUTING-template.md](../templates/CONTRIBUTING-template.md) をご参照ください
 
 
@@ -4,7 +4,7 @@
 
 ## Patlet  
 
-イントラネットのウェブサイトを作成し、特定のインナーソースプロジェクトのニーズを、時間とスキルの要件を明示した「ギグ」としてリストアップすることで、マーケットプレイスを確立する。 
+イントラネットのウェブサイトを作成し、特定のインナーソースプロジェクトのニーズを、時間とスキルの要件を明示した「ギグ」としてリストアップすることで、マーケットプレイスを確立する。
 これにより、管理者がインナーソースのコントリビューションを行うための承認を与え可能性が増え、従業員の時間のコミットメントと専門的な利点をよりよく理解することができます。
 
 ## 問題
@@ -46,7 +46,7 @@
 
 ギグを受けたい人は、まずギグの所有者が、その従業員がギグを完了するために必要なスキルと割り当てられた時間を有しているかどうかを判断する必要があります。
 
-ギグを通じたコントリビューションの透明性は、コントリビューターの評判を高め(あるいは下げ)、コントリビューションの質が高くなる可能性を高めるのに役立ちます。 また、ギグを完成させることで、その分野の専門性を証明することができます。 
+ギグを通じたコントリビューションの透明性は、コントリビューターの評判を高め(あるいは下げ)、コントリビューションの質が高くなる可能性を高めるのに役立ちます。 また、ギグを完成させることで、その分野の専門性を証明することができます。
 
 マーケットプレイスに投稿されるギグの内容は、グループイベントの運営、レポートの作成、メンターへの依頼など、ハードスキル、ソフトスキルの両方を含むことができます。
 
@@ -56,7 +56,6 @@
 
 インナーソースギグマーケットプレイスは、インナーソースのプロジェクトの数だけでなく、それに関わる社員の数も大幅に増加させます。 ギグマーケットプレイスの自主的な性質は、社員が実行する作業のレベルを選択し、会社全体でパートナーとなることができるようにすることで、社員の仕事の満足度を高めています。 社員は、自分が何にサインアップしているか、そしてその経験から何を期待できるかを正確に理解することができます。 マネージャーは、インナーソースプロジェクトに関する従業員の時間的コミットメントをより適切に推定および追跡し、個々の取り組みを認識し、特定のスキルセットを検証する方法としてギグの成果を使用することができます。 またマネージャーは、社員がギグマーケットプレイスで利用可能な仕事にピボットできるようにすることで、従業員が経験しているかもしれない既存のダウンタイムを活用することができます。 ギグマーケットプレイスでのやり取りによって生成されたデータは、すべての部署で雇用とトレーニングの決定を促進するのにも役立っています。
 
-
 インナーソースポータルのパターンと組み合わせて使用すると、ギグマーケットプレイスは、ギグが関連するプロジェクトのコードリポジトリとドキュメントへのリンクに加えて、より細かいレベルのコンテキストと詳細を提供することができます。
 
 ## 事例
 
@@ -40,6 +40,7 @@
 **開発プロセスとツール (DP)**
 
 インナーソースプロジェクトは、コントリビューターがアクティブになって参加するときに成長します。 結果として、コントリビューションを容易にすることは、純粋な技術的目標とバランスを取る必要があります。
+
 * DP-0：各チームが独自の開発プロセスやツールに従っています。 しかしそれらは、開発チームの外部で知識や成果物を共有するように設定されていません。開発チームはサイロ化されています。
 * DP-1: 開発チームは、内部で共有リポジトリを使用します。しかし一部のチームは、企業標準ではないCIツールを使用して、独自のCIプロセスを開発しています。コードレビューのプロセスは定義されていませんが、プロジェクトチーム内部で行っているところもあります。
 * DP-2: 組織は、集合知のための共有リポジトリを後援し、推進しています。チームによっては、企業の定めたCIツールを使って、独自のCIプロセスを開発しています。CIの環境があるり、またコードレビュープロセスが定義されており、いくつかのプロジェクトで使用されています。コードレビューが外部のチームメンバによって行われることもあります。
@@ -76,8 +77,9 @@
 
 サイロをなくすには、同僚がオープンにフィードバックを共有することに対する抵抗をなくす必要があります。それをサポートする簡単な方法のひとつは、階層を越えて同じコミュニケーション原則を使用することです。
 
-理想的には、組織の誰もが知っている適切なコミュニケーション・チャネルを持つことになります。チャネルは、異なるターゲット(お知らせ、ユーザーサポート、開発チャネル、インフラ・ディスカッシ	ョンなど)に焦点を当てます。
+理想的には、組織の誰もが知っている適切なコミュニケーション・チャネルを持つことになります。チャネルは、異なるターゲット(お知らせ、ユーザーサポート、開発チャネル、インフラ・ディスカッションなど)に焦点を当てます。
 インナーソースプロジェクトが成熟するにつれて確立するベストプラクティスには以下のようなものがあります。
+
 * ネチケットガイドラインの採用
 * 新しいインナーソースプロジェクトごとに実証済みの（アーカイブされ、一般にアクセス可能で、検索可能な）標準チャネルの開設
 
 
@@ -46,7 +46,7 @@
 
 > Andy さん、先日はアップデートを手伝っていただきまして本当にありがとうございました！
 Andy さんの活動の中で修正していただいた _rcs-viewer_ は、おかげさまでより良いものになり、組織の皆さんがその恩恵を享受しています。
-お忙しい中とは存じますが、このような配慮があるからこそ、RCSプロジェクトは会社全体のために機能しています。 
+お忙しい中とは存じますが、このような配慮があるからこそ、RCSプロジェクトは会社全体のために機能しています。
 改めまして、誠にありがとうございます！
 
 ## 結果の状況