最近、ゼロから始まるオープンソースプロジェクトに参加し、数回の会議を経て正式にグループ分けを行い、第一段階の機能実装に入る準備をしています。以前から 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を最終化する前に答えたい質問と、実装段階で解決される質問の2つのセクションに分けることができます。
## 欠点
この提案の潜在的な欠点は何ですか？ユーザーや既存のシステムへの影響は何ですか？
## 採用戦略
提案が受け入れられた場合、現在のシステムでの採用の道筋を説明します。統合戦略は何ですか？
## アクションプラン
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 文書を作成することが皆にとって難しいため、製品の開発サイクルが長くなることもあります。最終的に皆が合意するワークフローが最も適したワークフローです。
もし私の記事が良いと思ったら、コーヒーを一杯買ってください#
