コントリビューションガイド

当ガイドラインはコントリビューションを歓迎しています。

コントリビューションの種類

当プロジェクトでは、以下の形でのコントリビューションを受け付けています。

1. ガイドラインの内容改善：既存ガイドラインの修正、拡充
2. 新規ガイドラインの追加：新たなアクセシビリティ項目の提案
3. 事例や実装例の追加：具体的な実装方法や事例の共有
4. ドキュメントの改善：誤字脱字の修正、表現の改善など
5. バグ報告：技術的な問題の報告

コントリビューションの方法

1. Issueの作成

新しい提案や修正する場合は、まずIssueを作成してください。Issueは以下の2種類のテンプレートから選択できます。

• 機能リクエスト：新機能や改善案を提案する場合
• ドキュメント改善：ガイドラインの内容修正する場合

Issueのコメントを確認しつつ記載をお願いします。

2. Pull Requestの作成

コードやドキュメントの変更を提案する場合は、Pull Requestを作成してください。

Pull Requestのテンプレート

Pull Requestを作成する際は、テンプレートに従って以下の情報を記入してください。

• チケットURL：関連するIssueがある場合は記載（fix #番号の形式で記載するとマージ時に自動でクローズされる）
• ラベル：
  • 機能実装向け： enhancement
  • ガイドライン向け： documentation
• 概要：変更内容の説明
• 確認用URL：変更対象のページURLや該当箇所
• スクリーンショット：変更前後の状態が分かる画像（必要な場合）
• チェックリスト：必要な確認事項をチェック

3. レビュープロセス

Pull Requestは以下の流れでレビューされます。

1. CI/CD自動チェック（ビルドエラーやフォーマット違反がないか）
2. コードレビュー
3. レビュアーからのフィードバック対応
4. 承認とマージ

レビューを効率的に進めるため、レビューレベルを明示してください。

• ノールック：形式的な変更など、詳細なレビューが不要な場合
• 軽く目を通す：コードやドキュメントの小さな変更
• 動作確認：ローカル環境での動作確認が必要な変更
• 仕様確認：仕様の理解・確認が必要な変更
• 設計確認：設計観点からの確認が必要な変更

コントリビューションのガイドライン

ドキュメント関連

• Markdownの書式を統一すること
• 日本語の表現は一貫性を保つこと
• 実装例を示す場合は、アクセシブルな実装を心がけること
• 外部リソースを参照する場合は、出典を明記すること

コード関連

• ビルドが正常に実行できることを確認する
• テストがある場合はテストをパスすることを確認する
• 不要なデバッグコードを含めない
• コーディング規約に従う

リリースバージョンの定義

アクセシビリティガイドラインのバージョン管理は、セマンティックバージョニングの考え方を基本として、以下のようにバージョンを定義します。

メジャーバージョンリリース（X.0.0）

メジャーバージョンは、ガイドラインの大幅な変更や方針転換があった場合に更新されます。以下のような変更があった場合にメジャーバージョンを上げます。

• ガイドラインの基本方針や構造の変更
• 既存のガイドライン項目の大幅な変更や削除
• レベル分けの基準や考え方の変更
• 後方互換性のない変更

メジャーバージョンの更新は、十分な検討とレビューを経て行われ、通常は移行ガイドや変更点の詳細な説明が付随します。

マイナーバージョンリリース（X.Y.0）

マイナーバージョンは、既存のガイドラインを拡充する変更があった場合に更新されます。以下のような変更があった場合にマイナーバージョンを上げます。

• 新しいガイドライン項目の追加
• 既存ガイドラインの拡充（実装例の追加など）
• ガイドラインの構成の軽微な変更
• 新しいプラットフォームやテクノロジーへの対応追加
• 後方互換性を保った変更

マイナーバージョンの更新は、既存のガイドラインの有効性を損なわない形で行われます。

パッチバージョンリリース（X.Y.Z）

パッチバージョンは、技術的な修正や軽微な変更があった場合に更新されます。

• 誤字脱字の修正
• リンク切れの修正
• 表現の微調整
• ドキュメントのフォーマット修正
• その他の軽微な修正

バージョン更新の判断

バージョン更新の判断は、メンテナーで行います。（状況によってはコントリビューターとも協議します）