MDN コンテンツのバグのトリアージ手順

この文書では、コンテンツのバグをトリアージし、協力者が効果的に作業できるようにするための手順について説明します。

誰でもコンテンツのバグを報告することができます。https://github.com/mdn/content/issues/new で "Content bug" の課題テンプレートを使って課題を書くか、MDN の各ページの下にある "Report a problem with this content on GitHub" リンクを使って報告してください。

報告されたコンテンツバグは、https://github.com/mdn/content/issues にリストアップされ、最小限のプロセスで個人が作業できるように設計されています。MDN のコンテンツバグの修正で紹介されているプロセスを用いて、誰でもコンテンツのバグに取り組むことができます。

トリアージの手順を簡単に説明すると、次のようになります。

トリアージの準備

• トリアージ担当者を決める — 誰が通常のトリアージを行うのか？
• 初期ラベルの設定 — 新しいバグが入ってきたらすぐに、トリアージが必要であることを示すために "needs-triage" ラベルをつけ (これは自動的に行われるはずです)、加えて "Content:" ラベルを付けて (たとえば "Content:HTML" など) どのトピック領域のものであるかを示してください。バグを発見したときに誰でもこれを行うことができますが、MDN コアチームはこれを積極的に監視しています。
• トリアージの時間を確保する — 毎週、トリアージを行うための30分の定期的な時間を設定してください。

課題ごとのトリアージ

• チェックリスト — トリアージの準備ができているかどうかをチェックリストで確認します。
• 優先順位を設定 — 優先順位のルールに従います。
• 他の協力者がより簡単にバグの処理を始められるように、さらなる情報を提供します。
• 他のラベルを設定 — 作業する課題を選択するのに役立つラベルを他にも設定できます。

古いバグをチェック — 既存のバグを見て、停滞しているバグやクローズが必要なバグなどがないか確認します。

MDN の各コンテンツ領域に寄せられたバグを定期的にトリアージするために、トリアージ担当者が必要です。現在、以下のようなトリアージ担当者が割り当てられています。

• Accessibility — Eric Bailey?
• CSS — Rachel Andrew
• DevTools — Hamish Willee
• HTML — Rachel Andrew
• HTTP — Florian Scholz
• JS — Florian Scholz
• Learn — Chris Mills
• Learn:CSS — Rachel Andrew
• Learn:Express / Learn:Django — Hamish Willee
• Media — Ruth John
• Other — Ruth John
• SVG — André Jaenisch
• WebAPI — Ruth John
• WebExt — Caitlin/WebExt team

新しい課題が提出されるとすぐに、 MDN のコアチームおよび支援を希望する他の誰もが、その課題に以下のラベルを追加します。

• needs-triage — この課題が作業可能な状態にするために、適切なトリアージが必要であることを示します (これは自動的に行われます)。
• Content:<area> — Content:HTML や Content:CSS など、この課題が関連するコンテンツのトピックを指定します。トリアージが特定の分野の課題を見つけられるようにするために必要です。
• l10n-fr, l10n-zh, l10n-ja — 提出された課題が、米国以外のアクティブなロケールに関係することを指定します。これらのロケールのチームがこれらの課題をピックアップし、トリアージを行います。

トリアージ担当者は、常に積極的にバグをトリアージする必要はありません。その代わりに、毎週 30 分程度の時間を確保して、自分の担当領域のバグをトリアージすることにしましょう。

これは、同期ミーティングの一環として行う必要はなく、他の人と同じ時間に行う必要もありません。しかし、未処理のバグのバックログが増えすぎないようにするために、週に一度など、定期的に行う必要があります。

それぞれのバグについて、以下のチェックリストを実行し、誰かがそのバグの作業を開始するのに十分な情報が課題に含まれているかどうかを確認します。

課題には以下が含まれていますか？

• 問題が発見された MDN の URL。
• 適切であれば、そのバグに関連するサンプルページやリポジトリーの URL。
• 問題が発見された MDN ページの具体的な見出し (問題を見つけるために必要な場合)。
• 何が問題であるかの明確な説明。

これらの情報がない場合、トリアージ担当者は問題の提出者にこれらの詳細を提供するよう依頼し、これらの詳細が提供されるまで問題のトリアージを続けないようにしてください。

各バグについて、(自分が興味を持っているトピックではなく) 最も重要な問題や領域に取り組みたい人のために、優先度の指標となるラベルを設定します。

優先度のレベルは次の通りです。

• P0 — あらゆる MDN doc の深刻な問題
• P1 — 第一階層 MDN doc の主要な問題
• P2 — 第一階層 MDN doc の主要でない問題
• P3 — 第二階層 MDN doc の主要な問題
• P4 — 第二階層 MDN doc の主要でない問題

定義:

• 深刻な問題 — MDN の評判をひどく傷つけたり、ユーザーに害を与えたりする可能性があるもので、サイトのどこに表示されるかにかかわらず、できるだけ早く修正する必要があるもの。例としては、本番で使用されると深刻なセキュリティ問題を引き起こす可能性のあるコード例、マルウェア、冒涜、ポルノ、ヘイトスピーチなどの望ましくないコンテンツ、またはそのようなコンテンツへのリンクなどが挙げられます。
• 主要な問題 — ページの有用性に重大な影響を与える可能性があるもの。例えば、かなりの量の古い情報、複雑で重要なコード例が動作しない、かなりの量の文が散らかっていて理解しにくい、大量のリンク切れ、などが挙げられます。
• 主要でない問題 — 見た目は悪いが学習に影響を与えないもの、または学習にわずかな影響しか与えないもの。例えば — 誤字、悪い文法、リンク切れ、少量の古い情報や悪意のある散文、動作しない小さなコードスニペットなど。

一般的に言えば、深刻な問題はすぐに修正されるべきであり、おそらく MDN のスタッフや人々によって処理されるでしょう。また、第一階層の問題は第二階層の問題よりも重要です。最優先の MDN 課題に取り組むことに興味がある人は、第一階層、第二階層の課題に移る前に、Tier 0 の課題があれば常にそれに取り組むべきです。

他の協力者が問題を解決するのに役立つ更なる情報を提供することは、本当に有益です。私たちは、各バグのトリアージでは、最終的にバグを修正しようとする人を助けるために、トリアージ担当者がそのバグを修正するために取るべきいくつかのステップを素早く説明するために、最大 5 分の時間の余裕を持つことを推奨したいと思います。

例:

この問題を修正する人は、以下のことが必要と思われます。

* 見出し X の下の最初の段落を更新して、 Y の問題を修正する。
* X の説明を追加
* リンク X の互換性データを更新

次に、必要に応じてその他のラベルを設定します。

• 10 minute task, 30 minute task, 1 hour task, multiple hour task — 自分が協力できる時間を基準にしてバグを探したい人もいるので、大まかな目安をつけて選択できるようにしたいと思います。これを見積もるのは難しいですし、人によってバグを修正するスピードが違うことは理解していますが、これはあくまでも大まかな目安と考えています。この指標を設定する際には、その分野で中程度の知識を持つ人がバグを修正するのにどれくらいの時間がかかるかを考えてみてください。
• good first issue — 問題の修正が非常に簡単で、システムに慣れてきたばかりの新人の練習問題として適している場合、このラベルを付けてください。
• help wanted — これは、オープンソースプロジェクトで何をすべきかを検索する際に人々が使用する非常に人気のあるラベルのようで、これは、トリアージに成功したバグには当然のこととして設定されています。
• broken-link-internal, broken-link-external — 存在しない内部ページへのリンクや、壊れた外部リンクが問題となっている場合に使用します。
• トリアージのプロセスが完了したら、needs-triage のラベルを外すことを忘れないでください。

トリアージセッションの最後に、トピック領域でトリアージされた古い課題に目を通し、どの課題も不必要に停滞したり詰まったりしていないかどうかを確認します。

• アサインされた課題がまだ残っている場合、アサインされた人が進捗しているかどうかを確認します。割り当てられてから 1 週間経っても何もしていない場合は、その課題にまだ取り組まなければならないのかどうか聞いてみましょう。さらに 1 週間経っても何もしていない場合は、割り当てを解除し、他の人が担当できるようにこの問題を再開することを伝えてください。
• 問題を修正するための PR が発行されているにもかかわらず、 1 週間もレビューされていない場合は、レビュー担当者に優しくピンを打って、作業ができるかどうか尋ねてください。
• PR が 1 週間経ってもレビューのコメントに対応するのを待っている場合は、投稿者にレビューに対応できるかどうかを尋ねてください。さらに 1 週間が経過した場合は、時間があれば自分でレビューコメントを修正するか、時間がなければ PR を閉じてください。