CONTRIBUTING.mdのバグレポートガイドライン

バグレポートガイドライン

良いバグレポートはメンテナーの時間を節約し、より速い修正につながります。コントリビューティングガイドの明確なバグ報告セクションは、コントリビューターが提供すべき情報の期待を設定します。

必要な情報

すべてのバグレポートに含めるべきものを定義：

## バグの報告

以下を含めてください：
1. **概要** -- バグを説明する1文
2. **再現手順** -- 問題を引き起こす正確な手順
3. **期待される動作** -- 何が起こるべきか
4. **実際の動作** -- 実際に何が起こるか
5. **環境** -- OS、ブラウザ、Nodeバージョンなど
6. **スクリーンショット/ログ** -- 該当する場合

GitHub Issueテンプレート

.github/ISSUE_TEMPLATE/bug_report.mdを作成：

name: Bug Report
description: バグを報告する
labels: ["bug", "triage"]
body:
  - type: textarea
    id: description
    attributes:
      label: バグの説明
      description: バグの明確な説明
    validations:
      required: true
  - type: textarea
    id: steps
    attributes:
      label: 再現手順
      description: バグを引き起こす正確な手順
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: 期待される動作
    validations:
      required: true

重大度レベル

報告者が重大度を分類するのを助ける：

レベル	説明	例
Critical	アプリケーションのクラッシュまたはデータ損失	ログイン時にアプリがクラッシュ
Major	機能が壊れている、回避策なし	設定を保存できない
Minor	機能が壊れている、回避策あり	エクスポートは失敗するがコピーは動作
Trivial	外観上の問題	ボタンが2pxずれている

トリアージプロセス

バグが報告された後に何が起こるかを説明：「メンテナーは1週間以内に新しいバグをトリアージし、重大度ラベルを割り当て、修正、担当者割り当て、または追加情報のリクエストを行います。」

重複の処理

報告者にまず既存のissueを検索するよう依頼し、重複がどのように処理されるかを説明：「バグが重複の場合、元のissueへのリンク付きでクローズします。これは却下ではなく、1つの場所ですべてのレポートを追跡するのに役立ちます。」