CONTRIBUTING.mdの機能リクエストプロセス
CONTRIBUTING.mdに機能リクエストプロセスを文書化。提案フォーマット、議論期間、RFCプロセス、機能リクエストがアイデアから実装に移行する方法をカバー。
Contribution Types
詳細な説明
機能リクエストプロセス
構造化された機能リクエストプロセスは、スコープクリープを防ぎ、コミュニティの意見を確保し、メンテナーが作業を効果的に優先順位付けするのに役立ちます。
機能提案フォーマット
## 機能の提案
### 提出前に
- 既存のissueとディスカッションで類似の提案を検索
- これがコアプロジェクトとプラグイン/拡張機能のどちらに属するか検討
### 提案フォーマット
**タイトル:** 明確で具体的なタイトル(「UXの改善」ではない)
**問題:** これはどのような問題を解決しますか?
**提案される解決策:** どのように機能すべきですか?
**検討された代替案:** どのような他のアプローチを検討しましたか?
**追加のコンテキスト:** モックアップ、他のツールからの例など
議論期間
重要な機能については、議論期間を要求:
機能提案は実装が開始される前に少なくとも7日間議論のためにオープンのままになります。これにより、コミュニティが意見を提供し、代替案を提案し、潜在的な問題を特定する時間が得られます。
RFCプロセス(大規模プロジェクト向け)
より正式さが必要なプロジェクト向け:
- ディスカッションを開く -- 機能をハイレベルで説明
- RFCを書く -- 関心がある場合、詳細なRFCドキュメントを作成
- レビュー期間 -- コミュニティとメンテナーのフィードバック用に14日間
- 決定 -- メンテナーが承認、変更リクエスト、または却下
- 実装 -- 承認されたRFCは実装に移行
優先順位付け
機能がどのように優先順位付けされるかを透明にする:
- 影響 -- 何人のユーザーがメリットを受けるか?
- 労力 -- 実装はどれくらい複雑か?
- 整合性 -- プロジェクトの方向性に合っているか?
- コミュニティサポート -- いくつのサムズアップがあるか?
機能の却下
すべての機能が受け入れられるわけではないこと、そしてそれは個人的なものではないことを説明:「プロジェクトの目標に合わない機能リクエストは却下する場合があります。これはアイデアが悪いという意味ではなく、別のプラグインまたはプロジェクトとしてより適している場合があります。」
ユースケース
機能リクエストが増加しているプロジェクトで、コミュニティの意見を抑制することなく、それらを評価、議論、優先順位付けするための構造化されたプロセスが必要な場合。