Linux Foundation プロジェクト

このページには、Google シーズンのドキュメントで受け入れられているテクニカル ライティング プロジェクトの詳細が記載されています。

プロジェクトの概要

オープンソースの組織:
Linux Foundation
テクニカル ライター:
jaskiratsingh2000
プロジェクト名:
CHAOSS: CHAOSS コミュニティ全体のハンドブックを作成する
プロジェクトの期間:
標準の期間（3 か月）

プロジェクトの説明

プロジェクトの概要:

現在、CHAOSS コミュニティのワーキング グループは独自の作業方法を考案し、さまざまなプロセスをさまざまなレベルで文書化しています。 ワーキング グループには、Common Metrics WG、Diversity & Inclusion WG、Evolution、Risk、Value の各ワーキング グループがあり、それぞれ独自の参加方法と作業方法を設定し、さまざまなコミュニケーション方法と職場文化を適応させています。指標に応じたこれらのワーキング グループはそれぞれ異なる重点分野とバックグラウンドを持ち、それぞれのワーキング グループのカテゴリにおいてさまざまな研究開発を主導し、各カテゴリにおけるさまざまな研究開発を主導する適切な道筋を把握していますが、新規参加者および既存のコントリビューターのプロセスは、それぞれの作業への参加方法や正しい道筋を把握していない可能性があります。

その結果、CHAOSS コミュニティ内の事柄は標準化されていません。したがって、コミュニティ全体の労働文化の適切なプロセスと基本的な基礎知識を理解するために、コミュニティ ハンドブックの目的は、重要な情報を一元化し、CHAOSS プロジェクト全体でその情報の一部を標準化することです。重要な情報と標準化の部分では、主に CHAOSS が使用するプロセス、CHAOSS がコミュニティで働くことを達成する方法、新規参入者がコミュニティの基本に参加してそれに従う方法、新規参入者と既存メンバーが CHAOSS コミュニティ内でリーダーシップを活用するために従うべきプロセスと道筋について合意を得ています。

このハンドブックは、CHAOSS プロジェクトでの作業の進め方に関する、既存のコミュニティ メンバーと新規のコミュニティ メンバーの両方を対象とする手順マニュアルです。このプロジェクトには、ハンドブックのコンテンツを収集および整理するクリエイティブなコンポーネントと、ハンドブックの表現方法を定義する技術的なコンポーネントが含まれます。

そのニーズとは？

コミュニティ ハンドブックは、コミュニティの主なポリシーと手順が定義されているドキュメントで、コミュニティの使命、価値観、取り組みを概説しています。

このハンドブックでは、このコミュニティに新しく参加したメンバーにわかりやすい概要と仕組みを説明しています。現在、CHAOSS コミュニティ ハンドブックは GitHub リポジトリで公開されており、新規および既存のコミュニティ ユーザーのために、改良とリファクタリングを行う必要があります。したがって、この CHAOSS コミュニティ全体向けのハンドブックは、新規および既存のコミュニティ メンバーを次のようにサポートします。

  • CHAOSS コミュニティのポリシーを形式化して整理し、すべてを 1 か所にまとめる
  • コミュニティの概要、使命、ビジョン、リーダーシップについて伝える
  • CHAOSS コミュニティの実践について理解する
  • 投稿に関するガイドライン
  • プロジェクト ワークフローの定義
  • CHAOSS コミュニティ文化の概要
  • プログラム全般に関するよくある質問
  • メンターシップ

プロジェクトの説明:

コミュニティ ハンドブックは、特定のトピックに適切かつ詳細な情報を含む、さまざまな「セクション」に分かれています。セクションは、次のように分割できます。

  • はじめに
  • CHAOSS コミュニティ風
  • リーダーシップへの道
  • 用語
  • コンテンツ提供ガイドライン
    • デベロッパー
    • デザイナー
    • ライター
    • マーケティング担当者
  • 指標
  • CHAOSScon
  • CHAOSScast
  • 会議の動画
  • 一般的なよくある質問
  • メンターシップ
    • Google Summer of Code
    • アウトリーチ
    • ドキュメントの Google シーズン

詳細なプロジェクト成果物

1）概要:

このセクションは、CHAOSS コミュニティ ハンドブックの最初のページであり、ハンドブックの詳細、概要、使用方法が取り上げられます。次の内容が含まれます。

A.) これにはウェルカム メッセージと、CHAOSS コミュニティの簡単な説明が含まれ、ハンドブックの内容を理解しやすくなるでしょう。また、https://chaoss.community/chaoss-photo- album/ に掲載されている画像のコラージュも掲載します。これにより、コミュニティ内のさまざまな動きを取り上げることができます。B.) このページには、すべてのセクションの詳細が記載され、各セクションの説明と適切なリンクが 1 行で説明されています。 C.) ハンドブックの使用方法: ハンドブックの使用方法はすでに存在します（ shorturl.at/cqQU6 ）が、既存のハンドブックの使用方法を改良、リファクタリングし、ハンドブックのフローを含むマークダウンを改善します（誰かがハンドブックに関連することを追加、削除、議論したい場合にどうなるかを含めます。ハンドブック関連の事項については、コミュニケーション プロセスのフォローアップを行うこともあります）。ハンドブックのガイドライン（コミュニティ内での使用を含む）、ハンドブックへの貢献（変更、PR の作成、ハンドブックとスタイルガイドの変更のためのテンプレートなど）、ハンドブックに関するフィードバックの共有。[フィードバックの共有] には、ユーザーがフォローアップできるように GitLab の問題を提供または受け取れるようにテンプレートとさまざまな方法を含めます。

2）CHAOSS コミュニティ方式:

CHAOSS コミュニティの手法は、コミュニティの慣習やガイドラインを理解してもらううえで重要です。Workflows を使用することで、より強調して、最適な方法でコミュニティの実践の概要を説明することができます。このセクションの内容は次のとおりです。

A.) 一般的な価値: CHAOSS コミュニティ内でのサステナビリティ、オープン性、透明性への取り組みについて概説します。新しいユーザーや既存のユーザーがコミュニティ内で作業を行う際に、それらの価値をどのように理解し、考慮すべきかについて説明します。 B.) コミュニティ ガイドライン: 実際に CHAOSS コミュニティに参加して、基本的な規約に従うべき方法が記載されています。これは、コミュニティ内で従っている仕事文化を説明するものでもあります。（推奨事項と禁止事項）。コア コントリビューター/メンテナンス担当者のチェックリストのほか、メンテナンス担当者にどのように協力すべきか、どのようなチェックリストが用意されているのかを他のデベロッパーが把握できるようにします。 C.) ワーキング グループ: このページ（https://chaoss.community/participate/）には、ワーキング グループの説明、Repo リンク、ミーティング情報など、ワーキング グループに関する情報が含まれています。ただし、ハンドブックには、各ワーキング グループに参加する方法、指標を評価するプロセス、各 WG の職場文化を理解する方法、各ワーキング グループの中心的な貢献者になる方法などについて記載します。

3.）リーダーへの道:

オープンソース プロジェクトでリーダーシップを獲得することは、コミュニティが商業の世界で成功するために不可欠な場合があります。そこで、この点を考慮して以下をまとめます。

A.) 技術リーダー: これには、Repo メンテナンス担当者、ドキュメント ライター、ウェブサイト管理者 B のプロセスと責任が含まれます。）ガバナンス リーダーシップ: これには、取締役会メンバーと意思決定者 C への道筋が含まれます。）運営リーダー: ここにはコミュニティ マネージャー向けのプロセスが含まれます。

4）用語:

この用語は、CHAOSS コミュニティで頻繁に使用されている用語とその持ち物の説明に役立ちます。さらに、大文字の使用、略語、避けるべき言葉などの用語の使用ガイドラインも記載します。 含まれる規約は、CHAOSS プロジェクト、オープンソース コミュニティの健全性、コードレビュー、ワーキング グループ、オープンソース ソフトウェアの指標、共通指標、ダイバーシティ、インクルージョンの指標、進化作業グループ、リスク ワーキング グループ、バリュー ワーキング グループ、指標リリース、フォーカス エリアです。

5）投稿に関するガイドライン:

ほとんどのオープンソース コミュニティは、コントリビューションやボランティア活動に依存しているため、これがすべてのオープンソース コミュニティの主なコンテキストです。そのため、このコミュニティに新たに参加する人やユーザーが基本的な必要性と従うべきガイドラインを理解するのに役立ちます。これには、次の情報が含まれます。

A.) コミュニティのロードマップの理解: このトピックでは、CHAOSS コミュニティのロードマップの概要を説明します。このロードマップは、CHAOSS プロジェクト内のさまざまな取り組みを優先的に行うための方法やプロセスを把握するのに役立ちます。 B.) 開発、ドキュメント作成、設計、テストなど、実践的な取り組みに必要なものを説明する C）GitLab の仕組みについて簡単に説明する（D）。審査担当者/メンテナンス担当者向けガイド

このセクションには、以下の投稿カテゴリごとに「役割と責任」が記載されます。

a.) 設計: このサブセクションには、「カオス デザイン ワークフロー」と設計ガイドライン（コントリビューターが設計の分野で貢献する際に従うべき設計の原則、プロセス、使用するツール）が記載されます。 b.）開発: これには、コードベースに貢献するためのガイドが含まれます。これには、技術的要件、プロジェクト構造、プロジェクトの設定（Augur、Cregit、GremoireLab）が含まれます。c.）ドキュメント: ツールやスタイルガイドなどのドキュメント化のためのリソースが含まれます。 d.）アウトリーチ: これには、ブログの作成、ソーシャル ハンドルの使用、イベントやイベントの開催など、投稿者が CHAOSS コミュニティをアウトリーチの成長でサポートする方法が含まれます。

6. 指標

現在、CHAOSS コミュニティのウェブサイトには指標リリースの情報（https://chaoss.community/metrics/）が含まれており、ユーザーがそのウェブサイトで指標ウェブサイトを利用できるようにするためのプロセスを理解することは、より重要です。そのため、このセクションでは、ユーザーが独自の指標をリリースできるようにするためのプロセスと作業について理解するための情報を提供します。

7. チャットコン:

CHAOSScon に関する情報はすでに GitHub（https://github.com/chaoss/governance/blob/master/community-handbook/chaosscon.md）とウェブサイト（https://chaoss.community/CHAOSScon-2020-NA/）に掲載されていますが、ハンドブックに CHAOSScon のプロセスと管理方法を説明する詳細情報を追加する方が理にかなっています。 このハンドブックには以下の情報が含まれます。

A.) 組織委員会の詳細: CHAOSScon B の組織委員会への参加手続きを説明しています。）提案依頼プロセスの管理: 執筆者登録の管理、提案とドキュメントの提出、レビュー、承認プロセスなどが該当します。 C.) CHAOSScon プログラムの管理と公開（D）広告とマーケティングを管理する方法 E）スポンサーシップの提案とファンド（パッケージを含む）を処理する方法

8）CHAOSScast:

CHAOSScast に関する情報は https://github.com/chaoss/governance/blob/master/community-handbook/chaosscast.md に記載されています。また、このハンドブックに、参加、組織委員会、広告、マーケティング資料などの追加の詳細情報も記載されます。

9. 会議の動画:

これには、過去に開催され、YouTube で視聴可能な、会議のすべての動画と、過去に開催された参加者や議題などの説明が含まれます。

10）全般的なよくある質問:

ここには、コミュニティ内で寄せられる一般的な質問が含まれています。これは、新規および既存のコミュニティ メンバーが質問に答えるのに役立ちます。

11）Google Summer of Code:

このセクションには、Google Summer of Code に関する情報、利用条件、Google Summer of Code の CHAOSS コミュニティに参加する方法が記載されています。このセクションには、提案書、役割、責任の下書きを作成するための提案書も含まれています。 さらに、既存のコミュニティ メンバーが組織管理者やメンターとなるプロセスについて学ぶのに役立つ情報も含まれています。

  1. アウトリーチ性:

このセクションでは、Outreachy に関する情報と利用条件について説明します。また、Outreachy の CHAOSS コミュニティに参加する方法についても説明します。これには、組織管理者やメンターになるプロセスなど、役割と責任が含まれます。

  1. Google シーズン: ドキュメント:

このセクションには、GSoD に関する情報、利用条件、GSoD の CHAOSS コミュニティに参加する方法が記載されています。これには、組織管理者やメンターになるプロセスなど、役割と責任が含まれます。

プロジェクトの期待される成果:

ハンドブックは、どのようなコミュニティでも重要な役割を果たします。同様に、この CHAOSS コミュニティ全体向けのハンドブックによって、CHAOSS コミュニティ向けのドキュメントがより整理され、詳細になります。このコミュニティに参加したばかりの人も、すでにコミュニティ内のメンバーだった人も、CHAOSS コミュニティの基本や仕組みを簡単に理解できるようになります。 さらに、このハンドブックにより、CHAOSS コミュニティ内のさまざまなプロセスと、さまざまな職場文化への道が広がります。

技術的な詳細:

Gitbook プラットフォームは、チームがより効果的かつ効率的に作業するためのユーザー フレンドリーで共同作業的なプロジェクトであるため、ハンドブックの保守に使用することをおすすめします。GitBook プラットフォームの一部の機能:

  • WYSIWYG: 高性能で美しいテキスト エディタ
  • Markdown: マークダウン ショートカットの強力かつ生産的なサポート
  • リッチ埋め込み: 動画、コード スニペット、記事、音楽など、外部のウェブ コンテンツを埋め込みます
  • ライター向けのダッシュボード: ビジュアル編集をサポートするライター向けのインテリジェントなダッシュボード
  • 下書き: 新しい変更の下書きを作成し、非同期で共同編集する
  • サポート コメント: 変更案に関するディスカッションとレビュー
  • 作成履歴: すべてを追跡できます。変更を確認して元に戻す
  • 分析情報: トラフィック、評価、コンテンツの品質を追跡する分析情報にも対応しています。
  • GitHub の同期: ワークフローを維持し、ドキュメントを GitHub と同期する
  • ブランディングのカスタマイズ: カスタム ドメイン、カスタムロゴ、フォント、色、テーマ、ヘッダーなど

プラットフォームの一部を示す画像

  • shorturl.at/GNQR4
  • shorturl.at/gATZ8
  • shorturl.at/qrE57
  • shorturl.at/rFRX6
  • shorturl.at/eyLW1
  • shorturl.at/rwHS8

-- ハンドブックはどこでホストされますか。

このハンドブックは GitBook 自体でホストされ、GitHub はカスタム ドメイン、一般的なエラー、SEO のための適切なメカニズムを提供します。

カスタム ドメイン: CHAOSS コミュニティがカスタム ドメインでホストする場合、docs.chaoss.community のように表示されます。組織は、希望するサブドメインを構築するだけです。組織のドメインを設定するには、Gitbook プラットフォームで組織の設定に移動します。画像の例: shorturl.at/GNQR4

GitBook のスペースは、デフォルトで HTTPS が有効化された Google 独自の CDN を介して提供されます。証明書は LetsEncrypt によって発行されます。

サポート対象のドメイン:

  • サブドメイン: www.example.com
  • カスタム ドメイン: docs.example.com

-- 両プラットフォームで効果的に編集できるように、Gitbook を GitHub と同期するにはどうすればよいか？

GitHub との統合は非常に簡単です。GitBook のコンテンツの一部を変更すると、その編集内容が GitHub リポジトリに push されます。逆に、GitHub リポジトリに push された commit は、GitBook 内にインポートされます。

GitHub 統合を設定します。

  • GitBook プラットフォーム内のスペースで、[Integrations] タブ > [GitHub] をクリックします。
  • 組織にリンクされている GitHub アカウントへのアクセスを GitBook に許可します
  • 組織の GitHub に移動し、「HandBook」のリポジトリ（chaoss-handbook など）を作成します
  • 次に、GitBook プラットフォーム内の認証オプション内で接続する chaoss-handbook という名前のリポジトリを選択します。

これらのステップが完了すると、GitBook は Webhook を chaoss-handbook リポジトリに追加し、リポジトリが変更されるたびにコンテンツを取得できるようにします。GitBook に変更を加えると、新しいコメントが push されます。

これで、誰でも GitBook または GitHub リポジトリから編集を続行できます。

-- GitBook プラットフォームでページを編集する方法

GitBook プラットフォーム内の何かを編集したい場合は、招待または参加リンクを使用して GitBook プラットフォームに参加する必要があります。GitBook はビジュアル編集をサポートしており、ユーザーはページ内に直接記述できます。

下書きとは作成者のみがアクセスできる編集可能なバージョンのユーザー コンテンツで、書き始めると自動的に作成されます（エディターの最初の文字、新しいページの作成、写真のアップロードなど）。

下書きに加えた変更は下書きに正しく反映されるため、ユーザーは競合することなく、同じドキュメントに他のメンバーと同時に変更を加えることができます。これを非同期編集および競合解決と呼んでいます。

下書きの最初のバージョンは、すぐに公開されるとは限りません。作業を後で続行する場合や、コンテンツを「統合」する準備が整っていない場合は、[保存] を使用してください。

編集が終了したら、下書きを「統合」できます。これで、作成したコンテンツや変更内容がチームメンバーに公開されるか、一般公開されます。

画像の例: shorturl.at/gATZ8、shorturl.at/qrE57

-- コンテンツ構造:

目次: 各スペースには、ドキュメントの作成に必要な数のページを含めることができます。これらのページはすべて、画面の左側に目次と呼ばれます。目次では、新しいページの作成、ページ グループの追加、外部リンクの追加、パターンの追加、マークダウン（.md または .markdown）、HTML（.html）、Microsoft Word（.docx）などの外部ドキュメント（ウェブサイトやファイルなど）のインポートなど、ページを管理できます。

初期ページ: 最初のページは、ドキュメントのホームページまたはルートであり、基本的にはドキュメントのすべてのページのマスターとして機能します。ドキュメントとスペースのメイン エントランスであるため、このページを移動、削除したり、お子様を追加したり、グループにしたりすることはできません。

ページ: ページにはタイトルが表示されます。エディタの上部に説明が表示されます（省略可）。どのようなコンテンツでも作成したり追加したりできます。ページを下にドラッグ&ドロップすると、ページをネストできます。ページの子は非表示になりますが、折りたたむことができます。

外部リンク: これらのエントリは外部リンクであり、エディタにコンテンツはありません。その主な目的は、外部ウェブサイトへのリンクを提供することです。

バリエーション: バリエーションを作成することで、ドキュメントの代替コンテンツを作成できます。これは、API、ライブラリ、翻訳の複数のバージョンを文書化する場合に便利です。

画像の例: shorturl.at/eyLW1、shorturl.at/rFRX6

-- クライアントサイドでハンドブックはどのように表示されますか。

Chaoss コミュニティのハンドブックには、https://docs.chaoss.community のようなサブドメインからアクセスできます。ユーザー側では、このハンドブックの内容は次のようになります。

  • Mattermost ハンドブック - https://handbook.mattermost.com/
  • Linux Foundation Community Bridge のドキュメント - https://docs.linuxfoundation.org/docs/ その他

プロジェクトのタイムライン:

1）コミュニティの絆を深めるフェーズ（8 月 17 日～ 9 月 13 日）

A.) 第 1 ～ 4 週:

  • メンターとプロジェクトについて話し合う
  • プロジェクトのさまざまなセクションで必要な情報を調査、収集し、コミュニティに明確な質問をする
  • ハンドブックに使用するプラットフォームをコミュニティに明確化し（GitBook を推奨します）、その設定を行います
  • ドキュメントの問題への貢献

2）ドキュメント開発フェーズ（9 月 14 日～ 11 月 30 日）

A.) 第 5 週（9 月 14 日～ 9 月 20 日）

  • ドラフト」概要セクション

B.) 第 6 週（9 月 21 日～ 9 月 27 日）

  • 「The CHAOSS Community Way」セクションの下書き

C.) 第 7 週（9 月 28 日～ 10 月 4 日）

  • 「リーダーシップへの道」セクションの下書きを作成する
  • 「用語」セクションの下書きを作成

D.) 第 8 週（10 月 5 日～ 11 日）

  • コミュニティのロードマップの下書きの作成
  • デザインの貢献に関するガイドラインの下書き

E.) 第 9 週（10 月 12 日～ 18 日）

  • 下書きの開発セクション

F.) 第 10 週（10 月 19 日～ 10 月 25 日）

  • 文章作成とアウトリーチのセクションに関するガイドライン

G.) 第 11 週（10 月 26 日～ 11 月 1 日）

  • 下書きの指標セクション
  • CHAOSScon セクションの下書き

H.) 第 12 週（11 月 2 日～ 11 月 8 日）

  • ミーティング セクションの設計

  • コミュニティに関する一般的なよくある質問の下書き

    I.) 第 13 週（11 月 9 日～ 11 月 15 日）

  • GSoC ガイドラインの下書き

J.) 第 14 週（11 月 16 日～ 11 月 22 日）

  • アウトリーチ ガイドラインの下書き

K.) 第 15 週（11 月 23 日～ 11 月 29 日）

  • バッファ時間: ドキュメント全体の改良と改善

3.）評価フェーズ（11 月 30 日～ 12 月 5 日）

A.) 第 16 週:

  • プロジェクト レポートの下書きを作成する
  • プロジェクトの評価を入力する

コミュニティでの交流

1）コミュニティとの関わりとディスカッション。

2020 年 4 月から CHAOSS コミュニティでサーフィンをして、コミュニティのメンバーや、私の特定のプロジェクト メンター（Georg Link と Armstrong Foundjem）とさまざまな議論に関わっています。コミュニティ メンバーの関心が高まったそのような議論の一つが「Propose Gitbook as a platform for Hosting Community Handbook（コミュニティ ハンドブックをホストするためのプラットフォームとしての Gitbook の提案）」であり、CHAOSS アーカイブ メーリング リストのスレッドにあり、コミュニティ ハンドブックをホストするプラットフォームとしての Gitbook の提案というタイトルが付けられています。コミュニティの毎週の電話にも参加して、コミュニティに最新情報を発信しています。

2）このプロジェクトに必要な情報をどのように収集するか。

このプロジェクトでは、コミュニティ全体を対象としたハンドブックを用意し、ハンドブック内で参照する必要がある情報をコミュニティ メンバーから収集して議論できるようにする必要があります。上記のタイムラインを提案しましたので、それに基づいて、コミュニティの絆を深める期間に必要な情報について話し合い、収集できるようにいたします。

CHAOSS に従ってさまざまなセクションを調査し、メーリング リストのスレッドを確認していきます。要件に応じて、メンターやコミュニティに確認の質問をしてみます。

簡潔な話し合いのため、毎週の電話にも参加する予定です。

3.）進捗やプロジェクト期間中に生じた問題や疑問をコミュニティに常に知らせたいとお考えですか？

柔軟性と透明性を高めるために、メーリング リストでのディスカッションで疑念を質問できるよう、コミュニケーションを図るつもりです。

毎週の進捗状況はブログ投稿として共有し、スクラムのドキュメントや直面した課題をコミュニティ メーリング リスト自体で共有します。これにより、オープンソース組織内のより多くの対象者にリーチできます。

また、主要な問題について適切な提案や議論を行うため、毎週のコミュニティ ミーティングにも参加する予定です。

また、毎週実施できるタスクを記載した Trello ボードを作成することも計画しています。メンターはこのボードを使用して、現在取り組んでいる問題や機能について明確かつ簡潔に理解できます。

4）プロジェクトが行き詰まっていて、メンターがいない場合、どうしますか？

メンターの役割は生徒を正しい方向へ導くことであり、ループのあらゆる点を生徒に説明することではないと思います。プロジェクトの調査と実施はすべて、受講者の責任です。あくまでも、最後の手段としてメンターの助けを借りることのみに留めます。

ただし、サポートが必要な時はメンターが対応していない場合や、私が抱えている問題を CHAOSS コミュニティ内で共有します。私が直面したあらゆる課題を、誰かが手助けしてくれると確信しています。また、dev.to などのオンライン フォーラムや開発コミュニティでこの問題を共有します。

さらに、CHAOSS コミュニティの助けを呼ぶ週 1 回の電話に参加して、疑念を尋ねるようにしています。