最近、ゼロから始まるオープンソースプロジェクトに参加し、数回の会議を経て正式にグループ分けを行い、第一段階の機能実装に入る準備をしています。以前から RFC プロセスに興味があったので、Discord グループで RFC プロセスを推進しました。
TL;DR: 実際の製品がない開発段階では RFC を使用するのは適しておらず、製品があるオープンソースプロジェクトで使用するのが適しており、皆が合意するワークフローが良いワークフローです。
RFC とは#
RFC（Request for Comments）は意見請求とも呼ばれ、多くのオープンソースプロジェクトには独自の RFC ワークフローがあります。
Rust
Bytecodealliance
Reactjs
VueJS
Ethereum
オープンソースプロジェクトでRFC 駆動開発を実行する利点は、変更が透明に議論され、合意を得ることができることで、最終的には定義された RFC 文書に基づいて変更を実装することです。
私自身も初めて RFC プロセスを実装し、いくつかのプロセスに関する記事を参考にした後、Discord で皆と共有しました（推し進める、チームは RFC プロセスに非常に興味を持っていましたが、どのように実行すればよいかわからず、RFC を実行している友人と議論し、他の会社のプロセスを共有し、最終的に皆が議論できるテンプレートを起草しました。
RFC 駆動開発
Gatsby RFC プロセス
起草のディスカッション#
なぜ RFC を使用するのか#
「RFC」（意見請求）プロセスは、製品（新機能など）への変更に対して一貫した制御された道を提供することを目的としており、すべてのメンバーがプロジェクトの方向性に自信を持てるようにします。
バグ修正やドキュメント改善を含む多くの変更は、通常の GitHub プルリクエストワークフローを通じて実装およびレビューできます。
ただし、一部の変更は「重要」であり、これらは設計プロセスを経て、製品コミュニティの間で合意を得ることを求めます。
RFC テンプレート#
---
name: RFC
about: このプロジェクトのアイデアを提案する
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC: [あなたのトピックタイトル]
## 概要
提案された機能または変更の短く簡潔な説明。これは提案の高レベルな理解を提供するために使用されるべきです。
## 動機
この提案を行う背景と理由を説明します。解決すべき問題は何ですか？どのようなユースケースをサポートしますか？期待される結果は何ですか？
## 提案の概要 / 詳細設計
初期段階のRFCの場合、問題に対処する方法のスケッチを提供し、具体的な出発点に議論を集中させるのに役立てます。
より詳細なRFCの場合、このセクションには他の人が提案を理解し評価するために十分な情報が含まれている必要があります。アーキテクチャの議論、設計の詳細の説明、選択の理由を含む主要なポイントと設計上の考慮事項をカバーする必要があります。
### コンポーネント図
可能であればコンポーネント図を提供します。
### シーケンス図
可能であればシーケンス図を提供します。
### クラス図
提案に価値と理解を追加する場合はクラス図を提供します。
### OpenAPI仕様
提案がAPIを含む場合はOpenAPI仕様を含めます。
## 理由と代替案
提案された設計を選択した理由と、それに伴うトレードオフを議論します。さらに、考慮された代替案とそれらが却下された理由を説明します。
## 未解決の質問
まだ解決されていない設計の側面や、さらなる議論が必要な側面を議論します。RFCを最終化する前に回答を期待する質問と、実装段階で解決される質問に分けることができます。
## 欠点
この提案の潜在的な欠点は何ですか？ユーザーや既存のシステムへの影響は何ですか？
## 採用戦略
提案が受け入れられた場合、現在のシステムでの採用の道筋を説明します。統合戦略は何ですか？
## アクションプラン
RFCが承認された後に完了する必要がある主要なアクションをリストします。可能であれば、議論、レビュー、承認の日付も含めてください。
- [ ] デザインディスカッション YYYY-MM-DD
- [ ] RFCレビュー YYYY-MM-DD
- [ ] RFC承認 YYYY-MM-DD
RFC ドラフトテンプレート#
---
name: RFC
about: このプロジェクトのアイデアを提案する
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFCタイトル
## 概要
変更の簡潔な一段落の説明を提供します。
## 動機
このRFCの背後にある動機を説明します。現在の状態は何で、この変更がどのように有益ですか？どのようなユースケースをサポートしますか？期待される結果は何ですか？
## 提案の概要
この段階では、提案は完全に形成されている必要はありません。スケッチがあれば議論を中心にするのに十分です。提案された解決策を高レベルで詳細に説明します。新しい概念や用語が導入される場合は、ここで定義します。
## 未解決の質問
設計のどの部分がまだ不明確または解決が必要ですか？このRFCを完全な提案に進める前に、コミュニティとの議論を通じて解決したいことは何ですか？
## トレードオフ
この提案の潜在的なトレードオフや影響は何ですか？他のシステムの領域にどのように影響しますか？
## 未解決の質問
提案のどの部分が未決定（TBD）ですか？
RFC フローの議論#
-
ディスカッションから RFC へ: リポジトリのディスカッションセクションでオープンなディスカッションスレッドを開始します。合意に達した後、スレッドの著者が RFC を起草します。RFC が準備できたら、開発を開始し、プルリクエストで終了します。
-
ドラフト RFC からプルリクエストへ: 提案者がドラフト RFC を作成し、ドラフトプルリクエストとして提出することでプロセスを開始します。議論と改良の後、プルリクエストが正式にレビューされ、マージされるか閉じられます。
-
統合アプローチ: ディスカッションセクションで予備的な議論を開始します。アイデアがある程度明確で具体的になったら、RFC を起草し、プルリクエストとして提出して詳細な議論と正式なレビューを行います。これにより、議論のオープンな性質と RFC およびプルリクエストプロセスの構造化された形式が組み合わさります。
結論#
前述の通り、私はゼロから設計討論を行うオープンソースプロジェクトに参加しています。私たちの最初の会議のスタイルは FigmaJam を使用して製品のアイデアを考え、議論することでした。その後、Google ドキュメントを使用して開発する必要がある機能を記録しました。製品が実装段階に入る準備をしているため、皆が議論したポイントは、仕様が正式に決定されていないことに加え、既存の Google ドキュメント版の仕様と UIUX が GitHub の操作プロセスに必ずしも精通していないという要因です。私たちは投票を行い、最終的に皆が Google ドキュメントと FigmaJam を主要な開発文書として使用することを決定しました。主に開発初期に RFC 文書を作成することは皆にとって難しいため、製品の開発サイクルが長くなる可能性があります。最終的に皆が合意するワークフローが最も適したワークフローです。
もし私の記事が良いと思ったら、コーヒーを一杯買ってください#
