MDN/Contribute/Processes 以下を更新

- 2021/09/09 時点の英語版に同期
- 配下の2つの文書を新規翻訳

3 files changed, 273 insertions, 2 deletions

diff --git a/files/ja/mdn/contribute/processes/content_bug_triage/index.html b/files/ja/mdn/contribute/processes/content_bug_triage/index.html
new file mode 100644
index 0000000000..f2c0f30482
--- /dev/null
+++ b/files/ja/mdn/contribute/processes/content_bug_triage/index.html
@@ -0,0 +1,164 @@
+---
+title: MDN コンテンツのバグのトリアージ手順
+slug: MDN/Contribute/Processes/Content_bug_triage
+tags:
+  - MDN
+  - MDN Meta
+  - Meta
+  - Meta Docs
+  - Content bugs
+  - Process
+  - Triage
+translation_of: MDN/Contribute/Processes/Content_bug_triage
+---
+<p>{{MDNSidebar}}</p>
+
+<p>この文書では、コンテンツのバグをトリアージし、協力者が効果的に作業できるようにするための手順について説明します。</p>
+
+<h2 id="reporting_and_working_on_bugs">バグの報告と作業</h2>
+
+<p>誰でもコンテンツのバグを報告することができます。<a href="https://github.com/mdn/content/issues/new">https://github.com/mdn/content/issues/new</a> で "Content bug" の課題テンプレートを使って課題を書くか、MDN の各ページの下にある "Report a problem with this content on GitHub" リンクを使って報告してください。</p>
+
+<p>報告されたコンテンツバグは、<a href="https://github.com/mdn/content/issues">https://github.com/mdn/content/issues</a> にリストアップされ、最小限のプロセスで個人が作業できるように設計されています。<a href="/ja/docs/MDN/Contribute/Fixing_MDN_content_bugs">MDN のコンテンツバグの修正</a>で紹介されているプロセスを用いて、誰でもコンテンツのバグに取り組むことができます。</p>
+
+<h2 id="overall_triage_process">トリアージ手順の概要</h2>
+
+<p>トリアージの手順を簡単に説明すると、次のようになります。</p>
+
+<p>トリアージの準備</p>
+
+<ul>
+  <li>トリアージ担当者を決める — 誰が通常のトリアージを行うのか？</li>
+  <li>初期ラベルの設定 — 新しいバグが入ってきたらすぐに、トリアージが必要であることを示すために "needs-triage" ラベルをつけ (これは自動的に行われるはずです)、加えて "Content:" ラベルを付けて (たとえば "Content:HTML" など) どのトピック領域のものであるかを示してください。バグを発見したときに誰でもこれを行うことができますが、MDN コアチームはこれを積極的に監視しています。</li>
+  <li>トリアージの時間を確保する — 毎週、トリアージを行うための30分の定期的な時間を設定してください。</li>
+</ul>
+
+<p>課題ごとのトリアージ</p>
+
+<ul>
+  <li>チェックリスト — トリアージの準備ができているかどうかをチェックリストで確認します。</li>
+  <li>優先順位を設定 — 優先順位のルールに従います。</li>
+  <li>他の協力者がより簡単にバグの処理を始められるように、さらなる情報を提供します。</li>
+  <li>他のラベルを設定 — 作業する課題を選択するのに役立つラベルを他にも設定できます。</li>
+</ul>
+
+<p>古いバグをチェック — 既存のバグを見て、停滞しているバグやクローズが必要なバグなどがないか確認します。</p>
+
+<h2 id="triage_preparation">トリアージの準備</h2>
+
+<h3>トリアージ担当者の決定</h3>
+
+<p>MDN の各コンテンツ領域に寄せられたバグを定期的にトリアージするために、トリアージ担当者が必要です。現在、以下のようなトリアージ担当者が割り当てられています。</p>
+
+<ul>
+  <li>Accessibility — Eric Bailey?</li>
+  <li>CSS — Rachel Andrew</li>
+  <li>DevTools — Hamish Willee</li>
+  <li>HTML — Rachel Andrew</li>
+  <li>HTTP — Florian Scholz</li>
+  <li>JS — Florian Scholz</li>
+  <li>Learn — Chris Mills</li>
+  <li>Learn:CSS — Rachel Andrew</li>
+  <li>Learn:Express / Learn:Django — Hamish Willee</li>
+  <li>Media — Ruth John</li>
+  <li>Other — Ruth John</li>
+  <li>SVG — André Jaenisch</li>
+  <li>WebAPI — Ruth John</li>
+  <li>WebExt — Caitlin/WebExt team</li>
+</ul>
+
+<h3 id="set_initial_labels">初期ラベルの設定</h3>
+
+<p>新しい課題が提出されるとすぐに、 MDN のコアチームおよび支援を希望する他の誰もが、その課題に以下のラベルを追加します。
+
+<ul>
+  <li><code>needs-triage</code> — この課題が作業可能な状態にするために、適切なトリアージが必要であることを示します (これは自動的に行われます)。</li>
+  <li><code>Content:<em>&lt;area&gt;</em></code> — <code>Content:HTML</code> や <code>Content:CSS</code> など、この課題が関連するコンテンツのトピックを指定します。トリアージが特定の分野の課題を見つけられるようにするために必要です。</li>
+  <li><code>l10n-fr</code>, <code>l10n-zh</code>, <code>l10n-ja</code> — 提出された課題が、米国以外のアクティブなロケールに関係することを指定します。これらのロケールのチームがこれらの課題をピックアップし、トリアージを行います。</li>
+</ul>
+
+<h3 id="set_aside_triage_time">トリアージの時間を確保する</h3>
+
+<p>トリアージ担当者は、常に積極的にバグをトリアージする必要はありません。その代わりに、毎週 30 分程度の時間を確保して、自分の担当領域のバグをトリアージすることにしましょう。</p>
+
+<p>これは、同期ミーティングの一環として行う必要はなく、他の人と同じ時間に行う必要もありません。しかし、未処理のバグのバックログが増えすぎないようにするために、週に一度など、定期的に行う必要があります。</p>
+
+<h2 id="triage_process_for_each_issue">課題ごとのトリアージ手順</h2>
+
+<h3 id="checklist_to_determine_if_we_have_enough_information">十分な情報があるかどうかのチェックリスト</h3>
+
+<p>それぞれのバグについて、以下のチェックリストを実行し、誰かがそのバグの作業を開始するのに十分な情報が課題に含まれているかどうかを確認します。</p>
+
+<p>課題には以下が含まれていますか？</p>
+
+<ul>
+  <li>問題が発見された MDN の URL。</li>
+  <li>適切であれば、そのバグに関連するサンプルページやリポジトリーの URL。</li>
+  <li>問題が発見された MDN ページの具体的な見出し (問題を見つけるために必要な場合)。</li>
+  <li>何が問題であるかの明確な説明。</li>
+</ul>
+
+<p>これらの情報がない場合、トリアージ担当者は問題の提出者にこれらの詳細を提供するよう依頼し、これらの詳細が提供されるまで問題のトリアージを続けないようにしてください。</p>
+
+<h3 id="set_priority_measure">優先度指標の設定</h3>
+
+<p>各バグについて、(自分が興味を持っているトピックではなく) 最も重要な問題や領域に取り組みたい人のために、優先度の指標となるラベルを設定します。</p>
+
+<p>優先度のレベルは次の通りです。</p>
+
+<ul>
+  <li><code>P0</code> — あらゆる MDN doc の深刻な問題</li>
+  <li><code>P1</code> — 第一階層 MDN doc の主要な問題</li>
+  <li><code>P2</code> — 第一階層 MDN doc の主要でない問題</li>
+  <li><code>P3</code> — 第二階層 MDN doc の主要な問題</li>
+  <li><code>P4</code> — 第二階層 MDN doc の主要でない問題</li>
+</ul>
+
+<p>定義:</p>
+
+<ul>
+  <li>深刻な問題 — MDN の評判をひどく傷つけたり、ユーザーに害を与えたりする可能性があるもので、サイトのどこに表示されるかにかかわらず、できるだけ早く修正する必要があるもの。例としては、本番で使用されると深刻なセキュリティ問題を引き起こす可能性のあるコード例、マルウェア、冒涜、ポルノ、ヘイトスピーチなどの望ましくないコンテンツ、またはそのようなコンテンツへのリンクなどが挙げられます。</li>
+  <li>主要な問題 — ページの有用性に重大な影響を与える可能性があるもの。例えば、かなりの量の古い情報、複雑で重要なコード例が動作しない、かなりの量の文が散らかっていて理解しにくい、大量のリンク切れ、などが挙げられます。</li>
+  <li>主要でない問題 — 見た目は悪いが学習に影響を与えないもの、または学習にわずかな影響しか与えないもの。例えば — 誤字、悪い文法、リンク切れ、少量の古い情報や悪意のある散文、動作しない小さなコードスニペットなど。</li>
+</ul>
+
+<p>一般的に言えば、深刻な問題はすぐに修正されるべきであり、おそらく MDN のスタッフや人々によって処理されるでしょう。また、第一階層の問題は第二階層の問題よりも重要です。最優先の MDN 課題に取り組むことに興味がある人は、第一階層、第二階層の課題に移る前に、Tier 0 の課題があれば常にそれに取り組むべきです。</p>
+
+<div class="note notecard">
+  <h4>メモ</h4>
+  <p>第一階層と第二階層の定義については、<a href="/ja/docs/MDN/Contribute/Documentation_priorities">MDN 文書化の優先順位リスト</a>を参照してください。</p>
+</div>
+
+<h3 id="provide_further_information">さらなる情報の提供</h3>
+
+<p>他の協力者が問題を解決するのに役立つ更なる情報を提供することは、本当に有益です。私たちは、各バグのトリアージでは、最終的にバグを修正しようとする人を助けるために、トリアージ担当者がそのバグを修正するために取るべきいくつかのステップを素早く説明するために、最大 5 分の時間の余裕を持つことを推奨したいと思います。</p>
+
+<p>例:</p>
+
+<pre>この問題を修正する人は、以下のことが必要と思われます。
+
+* 見出し X の下の最初の段落を更新して、 Y の問題を修正する。
+* X の説明を追加
+* リンク X の互換性データを更新</pre>
+
+<h3 id="set_other_labels">その他のラベルの設定</h3>
+
+<p>次に、必要に応じてその他のラベルを設定します。</p>
+
+<ul>
+  <li><code>10 minute task</code>, <code>30 minute task</code>, <code>1 hour task</code>, <code>multiple hour task</code> — 自分が協力できる時間を基準にしてバグを探したい人もいるので、大まかな目安をつけて選択できるようにしたいと思います。これを見積もるのは難しいですし、人によってバグを修正するスピードが違うことは理解していますが、これはあくまでも大まかな目安と考えています。この指標を設定する際には、その分野で中程度の知識を持つ人がバグを修正するのにどれくらいの時間がかかるかを考えてみてください。</li>
+  <li><code>good first issue</code> — 問題の修正が非常に簡単で、システムに慣れてきたばかりの新人の練習問題として適している場合、このラベルを付けてください。</li>
+  <li><code>help wanted</code> — これは、オープンソースプロジェクトで何をすべきかを検索する際に人々が使用する非常に人気のあるラベルのようで、これは、トリアージに成功したバグには当然のこととして設定されています。</li>
+  <li><code>broken-link-internal</code>, <code>broken-link-external</code> — 存在しない内部ページへのリンクや、壊れた外部リンクが問題となっている場合に使用します。</li>
+  <li>トリアージのプロセスが完了したら、<strong><code>needs-triage</code> のラベルを外すことを忘れないでください。</strong></li>
+</ul>
+
+<h2 id="check_through_old_issues">古い課題のチェック</h2>
+
+<p>トリアージセッションの最後に、トピック領域でトリアージされた古い課題に目を通し、どの課題も不必要に停滞したり詰まったりしていないかどうかを確認します。</p>
+
+<ul>
+  <li>アサインされた課題がまだ残っている場合、アサインされた人が進捗しているかどうかを確認します。割り当てられてから 1 週間経っても何もしていない場合は、その課題にまだ取り組まなければならないのかどうか聞いてみましょう。さらに 1 週間経っても何もしていない場合は、割り当てを解除し、他の人が担当できるようにこの問題を再開することを伝えてください。</li>
+  <li>問題を修正するための PR が発行されているにもかかわらず、 1 週間もレビューされていない場合は、レビュー担当者に優しくピンを打って、作業ができるかどうか尋ねてください。</li>
+  <li>PR が 1 週間経ってもレビューのコメントに対応するのを待っている場合は、投稿者にレビューに対応できるかどうかを尋ねてください。さらに 1 週間が経過した場合は、時間があれば自分でレビューコメントを修正するか、時間がなければ PR を閉じてください。</li>
+</ul>
diff --git a/files/ja/mdn/contribute/processes/index.html b/files/ja/mdn/contribute/processes/index.html
index 0927b9c486..f79632726b 100644
--- a/files/ja/mdn/contribute/processes/index.html
+++ b/files/ja/mdn/contribute/processes/index.html
@@ -5,10 +5,9 @@ tags:
   - Landing
   - MDN Meta
   - Processes
-  - TopicStub
 translation_of: MDN/Contribute/Processes
 ---
-<div>{{MDNSidebar}}</div><div>{{IncludeSubnav("/ja/docs/MDN")}}</div>
+<div>{{MDNSidebar}}</div>
 
 <p>MDN 文書作成プロジェクトは非常に大規模です。カバーするべき莫大な数の技術があり、数百人の貢献者が世界中に散らばっています。秩序をもたらすために、従うべき標準の手順を定め、特定の文書化関連の作業を行うときにはこれに従います。ここでは、これらの手順についてのガイドを紹介します。</p>
 
diff --git a/files/ja/mdn/contribute/processes/short_surveys/index.html b/files/ja/mdn/contribute/processes/short_surveys/index.html
new file mode 100644
index 0000000000..e41025a2df
--- /dev/null
+++ b/files/ja/mdn/contribute/processes/short_surveys/index.html
@@ -0,0 +1,108 @@
+---
+title: 短いアンケートの実施プロセス
+slug: MDN/Contribute/Processes/Short_surveys
+tags:
+  - MDN
+  - MDN Meta
+  - Meta
+  - Meta Docs
+  - Process
+  - Surveys
+  - Short surveys
+---
+<p>{{MDNSidebar}}</p>
+
+<p>この文書では、 MDN での短いアンケートの実施プロセスを定義しています。</p>
+
+<h2 id="rationale_for_short_surveys">短いアンケートの根拠</h2>
+
+<p>2019 年から 2020 年にかけて、 MDN チームは MDN Web Developer Needs Assessment (Web DNA) を実施し、その結果を <a href="https://insights.developer.mozilla.org/">MDN Insights site</a> サイトで公開しました。これにより、とても有益な結果が得られ、この間、ブラウザーベンダーや標準化に関わる他の組織の活動を積極的に形成してきました。</p>
+
+<p>しかし、 Web DNA の運営には、さまざまな企業の膨大な労力とリソースが必要です。そこで私たちは、より小規模で焦点を絞った調査を行い、より簡単に実用的なデータを得られるような仕組みを提供したいと考えました。これにより、特定の問題を解決するための方向性を見出すことができます。</p>
+
+<p>メリット:</p>
+
+<ul>
+  <li>開発者にとっては、短時間でアンケートが完了するため、アンケート疲れが少ない。</li>
+  <li>特定のトピックについて迅速な判断を得るのに適している。</li>
+  <li>ステークホルダーが結果を得るまでの時間が短い。</li>
+  <li>毎月など、定期的に実施することができる。</li>
+  <li>MDN への来訪者の任意の割合を対象とすることができる。例えば、重要なものは来訪者の 50% に、通常のものは来訪者の 5% に公開できる。</li>
+</ul>
+
+<h2 id="survey_guidelines">調査ガイドライン</h2>
+
+<p>調査を提案したい人は、<a href="https://www.surveygizmo.com/s3/6306724/Short-survey-proposal-form">短いアンケート提案フォーム</a>にご記入ください。<a href="#survey_process">調査のプロセス</a>に沿って審査されます。</p>
+
+<p>調査の提案を適切にするためには、以下の点が必要です。</p>
+
+<ul>
+  <li>MDN の閲覧者が興味を持つもの。</li>
+  <li>ステークホルダーが喜んで取り組んだりフォローアップしたりするようなトピックであること。例えば、結果がウェブプラットフォームや MDN の改善に役立つか。</li>
+  <li>可能な限り具体的かつ詳細なものであり、実用化や対応が難しいハイレベルな質問は避ける。</li>
+  <li>質問数は3～5問以内で、回答にかかる時間は10分以内であること。</li>
+  <li>CSS、JavaScript、アクセシビリティ、ドキュメンテーションなど、明確なカテゴリーに属するもの。</li>
+  <li>調査対象者のプライバシーポリシーに記載されていない個人識別情報 (PII) を求めないこと (または提供される契約に不適切な PII を求めないこと)。</li>
+</ul>
+
+<h2 id="survey_process">調査プロセス</h2>
+
+<ol>
+  <li>投稿者は投稿フォームから、概要を記した企画書を提出します。
+    <ul>
+      <li>トピック。</li>
+      <li>カテゴリー。例えば CSS、JavaScript、アクセシビリティ、ドキュメンテーション...</li>
+      <li>調査の目的。</li>
+      <li>理想的なアンケートの実施日 (期間)。</li>
+      <li>調査結果に基づいて実行されるアクション。</li>
+      <li>質問と回答の選択肢。
+        <div class="note notecard">
+          <h4>メモ</h4>
+          <p>特定の種類のデータについては、そのデータが公表されることを意図しているのか、あるいは他の組織と共有されることを意図しているのかなどの意図とともに、法的な審査が必要となります。詳細は以下の<a href="#legal_requirements">法的要件</a>を参照してください。</p>
+        </div>
+      </li>
+      <li>MDNの中で調査に公開する割合の目安 (例: 3%)。既定の割合は 5% ですが、それ以上の割合を希望する場合は、明確な理由が必要です。例えば、現在多くの開発者に影響を与えている、文書化された重要なウェブプラットフォームのバグの解決策を知らせるためのデータを収集することを目的とした調査の場合、明確な証拠を提示できるのであれば、それは正当な理由になるでしょう。この正当化の根拠となる典型的な基準は、<a href="https://github.com/openwebdocs/project/blob/main/steering-committee/prioritization-criteria.md">OWD prioritization criteria</a> にあります。これらの基準は、MDN コンテンツの優先順位付けを知らせるために書かれたものですが、ここでも関連性があります。
+      <li>MDN のどの部分に表示するかを提案します (例: CSS ページ)。</li>
+    </ul>
+  <li>レビューチームは、提出されたものを 1 週間以内にレビューます。
+    <ul>
+      <li>必要であれば、さらなる情報提供を求めます。</li>
+      <li>提案の承認/否認を行います。どのアンケートをどのように実施するかについては、 MDN コンテンツチームが最終的な拒否権を持ちます。</li>
+      <li>P0、P1 のように、提案に優先度を適用します。これは、提案を積み重ねるための大まかな目安となります。</li>
+      <li>レビューチームは、ケースバイケースで選ばれた <a href="/ja/docs/MDN/MDN_Product_Advisory_Board">MDN 製品諮問委員会</a>のメンバー 3 名で構成されます。</li>
+    </ul>
+  </li>
+  <li>レビューチームは、提案者の最初の質問に基づいて、提案者と協力して最終的な調査票を作成し、合意します。</li>
+  <li>調査チームは、アンケートをデスクトップ、Android、iOS で徹底的にテストし、記入に不満を感じるようなレイアウトやレンダリングのエラーがないことを確認します。</li>
+  <li>レビューチームは、合意した日時に短いアンケートを実施します。</li>
+  <li>レビューチームは、調査を依頼した人やその他の関係者に調査結果とデータを提供します。</li>
+  <li>MDN は調査結果を <a href="https://insights.developer.mozilla.org/">insights.developer.mozilla.org</a> で公開します。</li>
+</ol>
+
+<h2 id="legal_requirements">法的要件</h2>
+
+<p>Mozilla はユーザーのプライバシーに深く配慮しています。そのため、私たちが実施する調査は、どのようなデータを収集するか、どのくらいの期間保存するか、どのように共有・公開するかについて、とても慎重に検討する必要があります。Mozilla の法務担当者は、調査の提案が Mozilla の要件を満たしているかどうかを確認したいと考えることがよくあります。</p>
+
+<ul>
+  <li>一般的に、あなたが収集したいと思うほとんどの情報については、法務部のレビューは必要ありません。これには、ユーザーの個人的な好みや意見、ブラウザの選択、職種などの情報が含まれます。</li>
+  <li>しかし、何らかの個人識別情報 (PII) を収集したり、情報を共有したり、情報を公開したりする場合には、法的な審査が必要となります。これには、氏名、年齢、住所、電子メールアドレス、性的指向、宗教など、誰かを特定したりプロファイリングしたりするのに使われる可能性のあるものが含まれます。</li>
+</ul>
+
+<p>良いガイドラインは、有用な結果を得るために最低限必要なデータ量を考え、必要以上のものを収集しないことです。</p>
+
+<p>また、以下の質問に対する答えも考えておきましょう。</p>
+
+<ul>
+  <li>そのデータにアクセスする必要があるのは誰ですか。データを第三者と共有する予定はありますか？その場合、誰とですか。</li>
+  <li>データを公開する予定はありますか？もしそうなら、どこで、どのような形で公開しますか。生データ、集約されたデータ、その両方ですか。</li>
+  <li>データをどのくらいの期間保存する予定ですか？それ以上の期間保存する必要があると明示されていない限り、データは 6 ヶ月後に削除されます。</li>
+  <li>データ収集のために、何らかの代替ツールを使用する予定はありますか。 Mozilla は、Survey Gizmo/Alchemer アカウントを使用してすべての作業を行う傾向にあります。</li>
+  <li>調査データにテレメトリーを付加する予定はありますか？</li>
+</ul>
+
+<p>Mozilla の MDN チームは、調査プロセスを所有し、調査の公開に責任を持ち、どの調査をどのように実施するかについて最終的な拒否権を持っています。私たちは、各アンケートのヘッダーページに、適切な法的通知とプライバシーステートメントが含まれるようにします。</p>
+
+<div class="note notecard">
+  <h4>メモ</h4>
+  <p>最初は、Mozilla 法務チームがすべてのアンケートを確認し、プロジェクトをよりよく理解し、順調に進んでいることを確認します。</p>
+</div>