他の改善点のアイデアがある、またはこのプロジェクトに貢献したいですか？こちらをご覧ください！
Author
世界保健機関におけるオープンソース
世界保健機関（WHO）が、国連で初めてオープンソース・プログラム・オフィス（OSPO）を設置した機関であることをご存知ですか？大企業や学術機関、政府機関にもOSPOは存在しますが、WHOのOSPOはその種のものとしては初めてのものでした。
GitHubは2020年以来、WHOと協力しており、インナーソースソフトウェア開発プロセスの強化とOSPOの設立を支援しています。WHOには、さまざまなグループによる100以上のオープンソース・リポジトリがあり、WHOの任務のひとつは、オープンソースのエコシステムが安全で信頼性が高く、メンテナンスが行き届いている（つまり健全である）ことを確認することです。彼らがこの任務を確実に果たすためには、何がうまくいっているのか、何を改善する必要があるのか、何に注意を払う必要があるのかをチェックするための測定可能な方法が必要でした。
私たちのソーシャル・インパクト・スキル・ベースド・ボランティア・プログラムの一環として、私たちはボランティアでこのプロジェクトに取り組みました。このダッシュボードを構築する中で、私たちは同様のプロジェクトに適用できるベストプラクティスをいくつか特定しただけでなく、オープンソースプロジェクトにおける一般的なコラボレーションのベストな方法も特定しました。
ダッシュボードの戦略と課題
ダッシュボード戦略を構築するための最初のステップは、質問に答えることでした：”健全であるとはどういうことか？”私たちは、オープンソース・コミュニティの健全性をグローバルに理解するためのメトリクス、メトリクス・モデル、ソフトウェアを作成するLinux Foundation の CHAOSS プロジェクトを調べました。そして、WHOのOSPOが関心を持っているものをリストアップし、実際に計算可能なものと照らし合わせました。
このようなダッシュボードを構築する際、一般的に直面する以下のような課題があります：
- 経費：メトリクスを開発する際には、特にダッシュボードを設計する際に効率的に読み込めるように、利用されるデータ量を考慮しなければならない。
- データストレージ：プロジェクトの依存関係を最小限に抑えたかったため、一度計算されたメトリクスの保存方法を工夫することになりました。
- レート制限: GitHub の API からデータを取得するには、どのツールにも制限があります。必要なデータを取得する際に特定のレート制限に遭遇したため、データ取得のアプローチ方法や取得できる情報量を見直す必要がありました。
- 保守性：小規模なチームにとって、ツールの習得、使用、セットアップ、長期的な保守が容易であることは重要です。
ワークフローとアーキテクチャ
どのように取り組んだか
オープンソースプロジェクトでの共同作業は、非同期作業、期待事項の文書化、進捗状況の把握など、成功のための作業方法を見つけることを意味します。このダッシュボードを構築している間、私たち全員が確実に説明責任を果たせるように助けてくれたものがいくつかありました：
- GitHubのIssuesは、個々のコントリビューターの作業を追跡し、どのようにビルドするかという新しいアイデアを提起し、将来の改善点をメモするのに役立ちました。
- ペアプログラミングは、私たちが共同作業をしたり、進行中の作業についてフィードバックを得たりすることを可能にし、プロセス全体を楽しいものにしてくれました。
- WHOチームとの毎月の同期は、フィードバックを集めるだけでなく、彼らが何を作っているのか、それが私たちにとってどのように役立つのかを確認するチャンスでもありました。例えば、あるフィードバック・セッションで、一部のメンテナにだけレポのサブセットを表示する必要があると聞いたので、ダッシュボードにトピック・フィルターを追加しました。
- 組み込みのカスタマイズ機能により、WHOオーナーは今後ダッシュボードを簡単に管理・変更できるようになり、他のオープンソースプロジェクトにも使用できるようになりました。
4つのステップでアーキテクチャを構築
アーキテクチャの設計を開始したとき、実際には2つの別々のアプリケーションに分けて構築しました。データを生成する Typescript Backend プロジェクトと、アプリケーションの UI をレンダリングする NextJS/React プロジェクトです。ビルド時には、GitHub Actions を介して関数のパイプラインを実行します。そのパイプラインは
- GitHub API（特に GraphQL API）からデータを取得します。
- データを変換し、必要な形に集約します。
- バックエンドが入力するJSONファイルにデータ出力をダンプします。
- データは次のJS静的サイトビルドに読み込まれ、サイトがGitHub Pagesにビルドされるとフロントエンドに表示されます。これがこのプロジェクトの秘策です。中小規模の組織では、ビルド/ロード時にすべてのデータがすでに入力されているため、サイトの読み込みが速いのです。
これはかなりシンプルなワークフローの一例に過ぎませんが、時には小さくて強大なものが最良の選択肢となることもあります。また、非常に迅速にリリースすることができました。
オープンソースで構築するための3つのベストプラクティス
このプロジェクトは、オープンソース・プロジェクト全般に適用できるベスト・プラクティスを特定するのに役立ちました。これを3つの要点に凝縮するとすれば、「オープンにビルドする」、「みんなのために構成する」、「適切なコミュニティ・ブランディングを採用する」ということです。
1.オープンにビルドする
オープンソースに関しては、最初からこの方法で構築したいものです。こうすることで、プロジェクトを管理しやすい断片に分割することができます。あなたは中核となる作業に集中し、コミュニティはプロジェクトに慣れ親しんでいる間に比較的簡単に成果を上げることができます。
コミュニティを円滑に運営するためには、強固なコーディング・プラクティスとセキュリティに関するルールを確立し、実施することが不可欠です。このプロジェクトでは、LintersとFormattersを使用することで、私たちが望むスタイルを実施しました。リポジトリにルールを定め、誰でもメインブランチにプッシュできるようにするのはやめましょう！
オープンでビルドするということは、やっていることすべてが公開されるということを忘れないでください。これは、素晴らしいアイデアに満ちた多様なコミュニティから、素晴らしい知識のプールにアクセスできることを意味します。それらを利用しましょう！そして、人々が貢献することで、なぜそのような方法がとられたのかという歴史的な背景を知ることができます。すべてを公開することの注意点は、あなたが行った仕事を誰に見られても問題ないことを確認する必要があるということです。
2.誰でも使えるように設定する
このダッシュボードが完成したら、技術的なバックグラウンドを持たない人でも使えるようにする必要があります。これを確実にするために、プロジェクトをフォークできるように構築し、YAMLの1つのファイルを編集して、そこからプロジェクトを実行できるようにしました。この1つのファイルはディレクトリのルートにあるフロントエンドとバックエンドのコンフィギュレーションを制御するので、誰でもプロジェクトをフォークして変更を加えることができます。この方法で構築することの利点は、アップストリームで将来変更を加えても、コンフリクトを解決するボタンをクリックする必要がないということです。
構成は難しいものなので、自分のプロジェクトにうまくフィットし、それを使うすべての人にとってうまくいくものを見つけることが重要です。
3.適切なコミュニティ・ブランディングを採用する
オープンソースはコミュニティが中心であるため、そのコミュニティがあなたとあなたのプロジェクトの両方をどう思っているかが重要です。ポジティブなブランドイメージを維持するためには、問題やコードリクエストに対して積極的に対応することが重要です。あなたのプロジェクトについて質問してくる人たちに対応しましょう！また、Issueを頻繁にリリースすることは、あなたのプロジェクトが活動的で、レスポンスが良いことを示すのに役立ちます。
READMEのような適切なコミュニティヘルプファイルを含めること。行動規範、セキュリティ・ポリシー、サポート・リソースなどの追加文書も、プロジェクトの健全性とブランディングに役立ちます。
プロジェクトを完了したからといって、それで終わりというわけではありません！このようなブログ記事を書いたり、カンファレンスで講演をしたり、デモを行ったりして、あなたが一生懸命取り組んだ素晴らしい仕事を共有し、コミュニティの育成に役立てましょう。
私たちの次の課題
オープンソースのメトリックス・ダッシュボードを構築することの素晴らしい点は、何がうまくいっているのか、そしてどのような将来の改良をすでに計画し始めることができるのかを確認できることです。次の目標は
- データベース・サポートの追加。
- どのデータを取得し、何を表示するかをさらにカスタマイズします。
- UIを改良します。
- 新しいデータをアンロックし、時系列で傾向を見ます。
- プロジェクトのすべての依存関係とコンポーネントを見直します。
今後の課題
このプロジェクトは、オープンソースに貢献し、世界的に良い影響を与えている組織に、私たちのスキルを使って恩返しをする素晴らしい方法でした。同じようなことに興味がある方は、For Good First Issueに掲載されている同様の機会をチェックして、より良い未来へのコミットメントにご協力ください！
The post How to build an open source metrics dashboard appeared first on The GitHub Blog.
