rfcs
1.0.0
バグ修正やドキュメントの改善を含む多くの変更は、通常の GitHub プル リクエスト ワークフローを通じて実装およびレビューできます。
ただし、一部の変更は「大幅」であるため、これらについては少し設計プロセスを経て、React コア チーム間で合意を形成するようお願いしています。
「RFC」（コメント要求）プロセスは、プロジェクトに新機能を導入するための一貫した制御されたパスを提供することを目的としています。
アクティブな RFC リスト
プル リクエストを受け入れるには、CLA を送信する必要があります。これを行う必要があるのは 1 回だけなので、別の Facebook オープンソース プロジェクトでこれを行ったことがある場合は、そのままで大丈夫です。初めてプル リクエストを送信する場合は、CLA を完了したことをお知らせください。GitHub ユーザー名でクロスチェックを行うことができます。
ここで CLA を完了してください。
React またはそのドキュメントに「大幅な」変更を加えたい場合は、このプロセスの使用を検討する必要があります。 RFC から恩恵を受ける例としては、次のようなものがあります。
新しい API サーフェス領域を作成する新機能。導入する場合は機能フラグが必要です。
リリース チャネルの一部としてすでに出荷されている機能の削除。
React 自体のコード変更が含まれていない場合でも、新しい慣用的な使用法や規則が導入される。
一部の変更には RFC が必要ありません。
言い換え、再構成、またはリファクタリング
警告の追加または削除
客観的で数値的な品質基準を厳密に改善する追加 (スピードアップ、ブラウザーサポートの改善)
追加は他の React 実装者のみが気づく可能性が高く、React ユーザーには見えません。
受け入れられる RFC を書くのは困難です。それでも、だからといって書くことを思いとどまる必要はありません。
React の API 領域は非常に限られており、各機能は他のすべての機能とシームレスに動作する必要があります。 React に毎日フルタイムで取り組んでいるチーム メンバーであっても、準備を整えて適切な RFC を書くのに十分なコンテキストを獲得するには 1 年以上かかります。
実際には、React RFC は次の 2 つの目的を果たします。
React チームの RFC は、広範な (場合によっては複数か月または複数年にわたる) 設計、議論、実験を経て、React チームのメンバーによって提出されます。実際には、これらはこれまでにマージされた RFC の大部分を構成します。これらの RFC の目的は、コミュニティ向けに設計をプレビューし、フィードバックの機会を提供することです。私たちは公開した RFC に関するすべてのコメントを読み、質問に回答し、場合によってはフィードバックを提案に組み入れます。時間が限られているため、React 機能が設計に適合していると確信できない限り、React 機能の RFC を作成することはありません。ほとんどの React Team RFC が簡単に受け入れられるように見えるかもしれませんが、実際には、アイデアの 98% が編集室のフロアに残されているためです。私たちが非常に自信を持っており、チームの合意を得ている残りの 2% は、コミュニティからのフィードバックのために RFC として発表するものです。
コミュニティ RFC は誰でも提出できます。実際には、ほとんどのコミュニティ RFC はマージされません。私たちが RFC を拒否する最も一般的な理由は、その RFC に重大な設計ギャップや欠陥があること、他のすべての機能と連携して動作しないこと、または React の範囲に関する私たちの見解に当てはまらないことです。ただし、マージされることだけが RFC の成功基準ではありません。 API 設計が私たちが目指す方向性と一致しない場合でも、RFC の議論は研究とインスピレーションにとって非常に価値があると考えています。私たちは常にコミュニティの RFC をタイムリーにレビューするわけではありませんが、関連分野の作業を開始するときは常に、その分野の RFC をチェックし、コミュニティのメンバーが投稿したユースケースと懸念事項をレビューします。 RFC を送信するときの主な目標は、必ずしも RFC をそのまま React にマージすることではなく、コミュニティのメンバーと充実したディスカッションを生み出すことです。後であなたの提案が受け入れられれば、それは素晴らしいことです。しかし、たとえそうでなかったとしても、それは無駄ではありません。多くの場合、コミュニティからのものか React チームからのものかに関係なく、議論の結果、同じ問題領域での次の提案が得られます。多くのライブラリ作成者がディスカッションを読んでいるため、RFC はコミュニティの実験やユーザーランド ソリューションにつながることがよくあります。
私たちは、React チーム RFC とコミュニティ RFC の両方に同じレベルの厳密さを適用します。両者の主な違いは設計段階にあります。React チーム RFC は設計プロセスの最後に提出される傾向があるのに対し、コミュニティ RFC は設計プロセスを開始する方法として最初に提出される傾向があります。
つまり、主要な機能を React に追加するには、通常、まず RFC をマークダウン ファイルとして RFC リポジトリにマージします。その時点で RFC は「アクティブ」となり、最終的には React に組み込まれることを目標に実装される可能性があります。
RFC リポジトリ http://github.com/reactjs/rfcs をフォークします。
0000-template.md text/0000-my-feature.mdにコピーします (「my-feature」は説明的なものです。まだ RFC 番号を割り当てないでください)。
RFC に記入します。細部に注意を払う:説得力のある動機を示さない、設計の影響への理解を示さない、または欠点や代替案について不誠実な RFC は、あまり受け入れられない傾向があります。
プルリクエストを送信します。 RFC はプル リクエストとして、より大きなコミュニティから設計のフィードバックを受け取ることになり、作成者はそれに応じて改訂する準備ができている必要があります。
コンセンサスを構築し、フィードバックを統合します。幅広いサポートを得ている RFC は、コメントを受け取らない RFC よりも進歩する可能性がはるかに高くなります。
最終的に、チームは RFC が React に含められる候補であるかどうかを決定します。チームのレビューには時間がかかる場合があるので、最初にコミュニティのメンバーにレビューを依頼することをお勧めします。
React に含める候補の RFC は、3 暦日続く「最終コメント期間」に入ります。この期間の開始は、RFC プル リクエストのコメントとタグで通知されます。
RFC は、チームやコミュニティからのフィードバックに基づいて変更できます。大幅な変更があった場合は、新たに最終コメント期間が設けられる場合があります。
RFC は、公開討論が終了し、拒否の理由を要約するコメントが作成された後、チームによって拒否される場合があります。その後、チームのメンバーは、RFC に関連するプル リクエストを閉じる必要があります。
RFC は、最終コメント期間の終了時に受理される場合があります。チーム メンバーは、RFC に関連するプル リクエストをマージし、その時点で RFC が「アクティブ」になります。
RFC がアクティブになると、作成者はそれを実装し、プル リクエストとして機能を React リポジトリに送信できます。 「アクティブ」になることはゴム印ではありません。特に、機能が最終的にマージされることを意味するわけではありません。これは、コアチームが原則的にそれに同意し、合併することに同意していることを意味します。
さらに、特定の RFC が受け入れられ、「アクティブ」であるという事実は、その実装にどのような優先順位が割り当てられているか、また誰かが現在その RFC に取り組んでいるかどうかについては何も意味しません。
アクティブな RFC への変更は、フォローアップ PR で行うことができます。私たちは、機能の最終設計を反映する方法で各 RFC を書くよう努めています。しかし、プロセスの性質上、マージされたすべての RFC が次のメジャー リリースの時点で最終結果がどうなるかを実際に反映するとは期待できません。したがって、私たちは計画どおりに各 RFC ドキュメントを言語機能とある程度同期させ、ドキュメントへのフォローアップ プル リクエストを通じてそのような変更を追跡するように努めます。
RFC の作成者には、RFC を実装する義務はありません。もちろん、RFC 作成者 (他の開発者と同様) は、RFC が承認された後、レビューのために実装を投稿することを歓迎します。
「アクティブな」RFC の実装に取り組むことに興味があるが、他の誰かが既にそれに取り組んでいるかどうか判断できない場合は、お気軽に質問してください (関連する問題についてコメントを残すなど)。
現在、React チームは RFC をタイムリーにレビューすることに取り組むことができません。 RFC を提出するときの主な目標は、コミュニティからのフィードバックを求め、充実した議論を生み出すことです。 React チームは、プロジェクトと優先順位の現在のリストを数か月ごとに再評価します。 RFC が適切に設計されていたとしても、多くの場合、それをすぐに統合することはできません。ただし、オープンな RFC を数か月ごとに再確認し、何か目に留まるものがないか確認することは非常に価値があると考えています。新しい問題領域に取り組み始めるときは、関連する RFC での以前の作業と議論を必ず確認し、それらに関与します。
私たちは提出から数週間以内にすべての RFC を読みます。デザインが React によく適合すると考え、評価する準備ができている場合は、より早くレビューしようとします。デザインに迷った場合、またはデザインを評価するのに十分な情報がない場合は、コミュニティから十分なフィードバックが得られるまで公開したままにします。タイムリーなレビューを受け取れないのはもどかしいことだと私たちは認識していますが、RFC に費やした作業はどれも無駄ではないと確信できます。
React の RFC プロセスは、Yarn RFC プロセス、Rust RFC プロセス、Ember RFC プロセスからインスピレーションを受けています。
過去にもフィードバックに応じて変更しましたが、必要に応じて再度変更することに前向きです。
