From d7390663af1d1048d8015d202ecb4eaefdf9d718 Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Fri, 10 Sep 2021 02:06:30 +0900 Subject: MDN/Contribute/Processes 以下を更新 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 2021/09/09 時点の英語版に同期 - 配下の2つの文書を新規翻訳 --- .../processes/content_bug_triage/index.html | 164 +++++++++++++++++++++ files/ja/mdn/contribute/processes/index.html | 3 +- .../contribute/processes/short_surveys/index.html | 108 ++++++++++++++ 3 files changed, 273 insertions(+), 2 deletions(-) create mode 100644 files/ja/mdn/contribute/processes/content_bug_triage/index.html create mode 100644 files/ja/mdn/contribute/processes/short_surveys/index.html (limited to 'files/ja') 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 +--- +

{{MDNSidebar}}

+ +

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

+ +

バグの報告と作業

+ +

誰でもコンテンツのバグを報告することができます。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 のコンテンツバグの修正で紹介されているプロセスを用いて、誰でもコンテンツのバグに取り組むことができます。

+ +

トリアージ手順の概要

+ +

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

+ +

トリアージの準備

+ + + +

課題ごとのトリアージ

+ + + +

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

+ +

トリアージの準備

+ +

トリアージ担当者の決定

+ +

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

+ + + +

初期ラベルの設定

+ +

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

+ +

トリアージの時間を確保する

+ +

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

+ +

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

+ +

課題ごとのトリアージ手順

+ +

十分な情報があるかどうかのチェックリスト

+ +

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

+ +

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

+ + + +

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

+ +

優先度指標の設定

+ +

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

+ +

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

+ + + +

定義:

+ + + +

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

+ +
+

メモ

+

第一階層と第二階層の定義については、MDN 文書化の優先順位リストを参照してください。

+
+ +

さらなる情報の提供

+ +

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

+ +

例:

+ +
この問題を修正する人は、以下のことが必要と思われます。
+
+* 見出し X の下の最初の段落を更新して、 Y の問題を修正する。
+* X の説明を追加
+* リンク X の互換性データを更新
+ +

その他のラベルの設定

+ +

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

+ + + +

古い課題のチェック

+ +

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

+ + 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 --- -
{{MDNSidebar}}
{{IncludeSubnav("/ja/docs/MDN")}}
+
{{MDNSidebar}}

MDN 文書作成プロジェクトは非常に大規模です。カバーするべき莫大な数の技術があり、数百人の貢献者が世界中に散らばっています。秩序をもたらすために、従うべき標準の手順を定め、特定の文書化関連の作業を行うときにはこれに従います。ここでは、これらの手順についてのガイドを紹介します。

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 +--- +

{{MDNSidebar}}

+ +

この文書では、 MDN での短いアンケートの実施プロセスを定義しています。

+ +

短いアンケートの根拠

+ +

2019 年から 2020 年にかけて、 MDN チームは MDN Web Developer Needs Assessment (Web DNA) を実施し、その結果を MDN Insights site サイトで公開しました。これにより、とても有益な結果が得られ、この間、ブラウザーベンダーや標準化に関わる他の組織の活動を積極的に形成してきました。

+ +

しかし、 Web DNA の運営には、さまざまな企業の膨大な労力とリソースが必要です。そこで私たちは、より小規模で焦点を絞った調査を行い、より簡単に実用的なデータを得られるような仕組みを提供したいと考えました。これにより、特定の問題を解決するための方向性を見出すことができます。

+ +

メリット:

+ + + +

調査ガイドライン

+ +

調査を提案したい人は、短いアンケート提案フォームにご記入ください。調査のプロセスに沿って審査されます。

+ +

調査の提案を適切にするためには、以下の点が必要です。

+ + + +

調査プロセス

+ +
    +
  1. 投稿者は投稿フォームから、概要を記した企画書を提出します。 +
      +
    • トピック。
      • +
    • カテゴリー。例えば CSS、JavaScript、アクセシビリティ、ドキュメンテーション...
      • +
    • 調査の目的。
      • +
    • 理想的なアンケートの実施日 (期間)。
      • +
    • 調査結果に基づいて実行されるアクション。
      • +
    • 質問と回答の選択肢。 +
      +

      メモ

      +

      特定の種類のデータについては、そのデータが公表されることを意図しているのか、あるいは他の組織と共有されることを意図しているのかなどの意図とともに、法的な審査が必要となります。詳細は以下の法的要件を参照してください。

      +
      +
      • +
    • MDNの中で調査に公開する割合の目安 (例: 3%)。既定の割合は 5% ですが、それ以上の割合を希望する場合は、明確な理由が必要です。例えば、現在多くの開発者に影響を与えている、文書化された重要なウェブプラットフォームのバグの解決策を知らせるためのデータを収集することを目的とした調査の場合、明確な証拠を提示できるのであれば、それは正当な理由になるでしょう。この正当化の根拠となる典型的な基準は、OWD prioritization criteria にあります。これらの基準は、MDN コンテンツの優先順位付けを知らせるために書かれたものですが、ここでも関連性があります。 +
    • MDN のどの部分に表示するかを提案します (例: CSS ページ)。
      • +
    +
  2. レビューチームは、提出されたものを 1 週間以内にレビューます。 +
      +
    • 必要であれば、さらなる情報提供を求めます。
      • +
    • 提案の承認/否認を行います。どのアンケートをどのように実施するかについては、 MDN コンテンツチームが最終的な拒否権を持ちます。
      • +
    • P0、P1 のように、提案に優先度を適用します。これは、提案を積み重ねるための大まかな目安となります。
      • +
    • レビューチームは、ケースバイケースで選ばれた MDN 製品諮問委員会のメンバー 3 名で構成されます。
      • +
    +
    3. +
  3. レビューチームは、提案者の最初の質問に基づいて、提案者と協力して最終的な調査票を作成し、合意します。
    4. +
  4. 調査チームは、アンケートをデスクトップ、Android、iOS で徹底的にテストし、記入に不満を感じるようなレイアウトやレンダリングのエラーがないことを確認します。
    5. +
  5. レビューチームは、合意した日時に短いアンケートを実施します。
    6. +
  6. レビューチームは、調査を依頼した人やその他の関係者に調査結果とデータを提供します。
    7. +
  7. MDN は調査結果を insights.developer.mozilla.org で公開します。
    8. +
+ + + +

Mozilla はユーザーのプライバシーに深く配慮しています。そのため、私たちが実施する調査は、どのようなデータを収集するか、どのくらいの期間保存するか、どのように共有・公開するかについて、とても慎重に検討する必要があります。Mozilla の法務担当者は、調査の提案が Mozilla の要件を満たしているかどうかを確認したいと考えることがよくあります。

+ + + +

良いガイドラインは、有用な結果を得るために最低限必要なデータ量を考え、必要以上のものを収集しないことです。

+ +

また、以下の質問に対する答えも考えておきましょう。

+ + + +

Mozilla の MDN チームは、調査プロセスを所有し、調査の公開に責任を持ち、どの調査をどのように実施するかについて最終的な拒否権を持っています。私たちは、各アンケートのヘッダーページに、適切な法的通知とプライバシーステートメントが含まれるようにします。

+ +
+

メモ

+

最初は、Mozilla 法務チームがすべてのアンケートを確認し、プロジェクトをよりよく理解し、順調に進んでいることを確認します。

+
-- cgit v1.2.3-54-g00ecf