rfcs
1.0.0
Viele Änderungen, darunter Fehlerbehebungen und Dokumentationsverbesserungen, können über den normalen GitHub-Pull-Request-Workflow implementiert und überprüft werden.
Einige Änderungen sind jedoch „wesentlich“, und wir bitten darum, diese einem kleinen Designprozess zu unterziehen und einen Konsens im React-Kernteam zu erzielen.
Der „RFC“-Prozess (Request for Comments) soll einen konsistenten und kontrollierten Weg für die Aufnahme neuer Funktionen in das Projekt bieten.
Aktive RFC-Liste
Um Ihre Pull-Anfrage anzunehmen, müssen Sie eine CLA einreichen. Sie müssen dies nur einmal tun. Wenn Sie dies also bereits für ein anderes Facebook-Open-Source-Projekt getan haben, können Sie loslegen. Wenn Sie zum ersten Mal eine Pull-Anfrage einreichen, teilen Sie uns einfach mit, dass Sie die CLA abgeschlossen haben, und wir können dies mit Ihrem GitHub-Benutzernamen abgleichen.
Füllen Sie hier Ihren CLA aus.
Sie sollten die Verwendung dieses Prozesses in Betracht ziehen, wenn Sie beabsichtigen, „wesentliche“ Änderungen an React oder seiner Dokumentation vorzunehmen. Einige Beispiele, die von einem RFC profitieren würden, sind:
Eine neue Funktion, die eine neue API-Oberfläche erstellt und bei deren Einführung ein Feature-Flag erforderlich wäre.
Das Entfernen von Funktionen, die bereits im Rahmen des Release-Kanals ausgeliefert wurden.
Die Einführung neuer Redewendungen oder Konventionen, auch wenn diese keine Codeänderungen an React selbst beinhalten.
Für einige Änderungen ist kein RFC erforderlich:
Umformulierung, Reorganisation oder Refactoring
Hinzufügen oder Entfernen von Warnungen
Ergänzungen, die strikt objektive, numerische Qualitätskriterien verbessern (Beschleunigung, bessere Browserunterstützung)
Ergänzungen, die wahrscheinlich nur von anderen Implementierern von React bemerkt werden und für Benutzer von React unsichtbar sind.
Es ist schwierig, einen RFC zu schreiben, der akzeptiert wird. Dennoch sollte Sie das nicht davon abhalten, eines zu schreiben.
React verfügt über eine sehr begrenzte API-Oberfläche und jede Funktion muss nahtlos mit allen anderen Funktionen zusammenarbeiten. Selbst unter den Teammitgliedern, die jeden Tag Vollzeit an React arbeiten, dauert es mehr als ein Jahr, sich hochzuarbeiten und genügend Kontext zu gewinnen, um einen guten RFC zu schreiben.
In der Praxis dienen React RFCs zwei Zwecken:
React-Team-RFCs werden von React-Team-Mitgliedern nach ausführlicher (manchmal mehrmonatiger oder mehrjähriger) Entwurfs-, Diskussions- und Experimentierphase eingereicht. In der Praxis stellen sie den Großteil der bisher zusammengelegten RFCs dar. Der Zweck dieser RFCs besteht darin, der Community eine Vorschau des Designs vorzustellen und Gelegenheit für Feedback zu bieten. Wir lesen jeden Kommentar zu den von uns veröffentlichten RFCs, beantworten Fragen und integrieren das Feedback manchmal in den Vorschlag. Da unsere Zeit begrenzt ist, neigen wir nicht dazu, einen RFC für eine React-Funktion zu schreiben, es sei denn, wir sind sehr sicher, dass sie zum Design passt. Auch wenn es so aussieht, als würden die meisten React-Team-RFCs leicht akzeptiert, liegt das in der Praxis daran, dass 98 % der Ideen auf dem Boden des Schneideraums liegen blieben. Die restlichen 2 %, bei denen wir sehr zuversichtlich sind und über die wir uns im Team einig sind, sind diejenigen, die wir als RFCs für Community-Feedback bekannt geben.
Community-RFCs können von jedem eingereicht werden. In der Praxis werden die meisten Community-RFCs nicht zusammengeführt. Der häufigste Grund, warum wir einen RFC ablehnen, ist, dass er erhebliche Designlücken oder -mängel aufweist, nicht kohärent mit allen anderen Funktionen funktioniert oder aus unserer Sicht nicht in den Geltungsbereich von React fällt. Allerdings ist die Zusammenführung nicht das einzige Erfolgskriterium für einen RFC. Selbst wenn das API-Design nicht der Richtung entspricht, die wir einschlagen möchten, finden wir RFC-Diskussionen für Recherche und Inspiration sehr wertvoll. Wir überprüfen Community-RFCs nicht immer rechtzeitig, aber wenn wir mit der Arbeit an einem verwandten Bereich beginnen, überprüfen wir die RFCs in diesem Bereich und überprüfen die Anwendungsfälle und Bedenken, die die Community-Mitglieder gepostet haben. Wenn Sie einen RFC senden, sollte Ihr primäres Ziel nicht unbedingt darin bestehen, ihn unverändert in React einzubinden, sondern eine intensive Diskussion mit den Community-Mitgliedern anzustoßen. Wenn Ihr Vorschlag später angenommen wird, ist das großartig. Aber selbst wenn nicht, wird es nicht umsonst sein. Die daraus resultierende Diskussion fließt häufig in den nächsten Vorschlag im selben Problembereich ein, unabhängig davon, ob er von der Community oder vom React-Team kommt. Viele Bibliotheksautoren lesen die Diskussionen, daher führen RFCs oft zu Community-Experimenten und Userland-Lösungen.
Wir wenden sowohl bei React-Team-RFCs als auch bei Community-RFCs die gleiche Strenge an. Der Hauptunterschied zwischen ihnen liegt in der Entwurfsphase: React-Team-RFCs werden in der Regel am Ende des Entwurfsprozesses eingereicht, während Community-RFCs eher zu Beginn eingereicht werden, um ihn anzukurbeln.
Kurz gesagt, um eine wichtige Funktion zu React hinzuzufügen, muss man normalerweise zuerst den RFC als Markdown-Datei in das RFC-Repository einbinden. Zu diesem Zeitpunkt ist der RFC „aktiv“ und kann mit dem Ziel einer eventuellen Aufnahme in React implementiert werden.
Forken Sie das RFC-Repo http://github.com/reactjs/rfcs
Kopieren Sie 0000-template.md nach text/0000-my-feature.md (wobei „my-feature“ beschreibend ist. Weisen Sie noch keine RFC-Nummer zu).
Füllen Sie den RFC aus. Achten Sie auf die Details: RFCs, die keine überzeugende Motivation präsentieren, kein Verständnis für die Auswirkungen des Designs zeigen oder unaufrichtig über die Nachteile oder Alternativen sind, werden in der Regel schlecht angenommen .
Senden Sie eine Pull-Anfrage. Als Pull-Request erhält der RFC Design-Feedback von der größeren Community, und der Autor sollte bereit sein, es als Reaktion darauf zu überarbeiten.
Schaffen Sie einen Konsens und integrieren Sie Feedback. RFCs, die eine breite Unterstützung haben, machen viel eher Fortschritte als solche, die keine Kommentare erhalten.
Letztendlich wird das Team entscheiden, ob der RFC ein Kandidat für die Aufnahme in React ist. Beachten Sie, dass eine Teamüberprüfung lange dauern kann. Wir empfehlen daher, dass Sie zuerst Mitglieder der Community bitten, sie zu überprüfen.
Für RFCs, die Kandidaten für die Aufnahme in React sind, beginnt eine „letzte Kommentarfrist“ von drei Kalendertagen. Der Beginn dieses Zeitraums wird mit einem Kommentar und einem Tag auf der RFC-Pull-Anfrage signalisiert.
Ein RFC kann basierend auf dem Feedback des Teams und der Community geändert werden. Wesentliche Änderungen können eine neue Schlusskommentarfrist auslösen.
Ein RFC kann vom Team abgelehnt werden, nachdem die öffentliche Diskussion abgeschlossen ist und Kommentare mit einer Zusammenfassung der Gründe für die Ablehnung abgegeben wurden. Ein Mitglied des Teams sollte dann die mit dem RFC verknüpfte Pull-Anfrage schließen.
Ein RFC kann am Ende seiner letzten Kommentierungsfrist akzeptiert werden. Ein Teammitglied führt die mit dem RFC verknüpfte Pull-Anfrage zusammen, woraufhin der RFC „aktiv“ wird.
Sobald ein RFC aktiv wird, können Autoren ihn implementieren und die Funktion als Pull-Request an das React-Repository senden. „Aktiv“ zu werden ist kein Stempel und bedeutet insbesondere noch nicht, dass die Funktion letztendlich zusammengeführt wird; es bedeutet, dass das Kernteam dem grundsätzlich zugestimmt hat und bereit ist, es zusammenzuführen.
Darüber hinaus bedeutet die Tatsache, dass ein bestimmter RFC akzeptiert wurde und „aktiv“ ist, nichts darüber, welche Priorität seiner Implementierung zugewiesen wird und auch nicht, ob derzeit jemand daran arbeitet.
Änderungen an aktiven RFCs können in Folge-PRs vorgenommen werden. Wir bemühen uns, jeden RFC so zu schreiben, dass er das endgültige Design der Funktion widerspiegelt. Aufgrund der Natur des Prozesses können wir jedoch nicht erwarten, dass jeder zusammengeführte RFC tatsächlich das Endergebnis zum Zeitpunkt der nächsten Hauptversion widerspiegelt. Daher versuchen wir, jedes RFC-Dokument wie geplant einigermaßen synchron mit der Sprachfunktion zu halten und solche Änderungen über nachfolgende Pull-Anfragen an das Dokument zu verfolgen.
Der Autor eines RFC ist nicht verpflichtet, diesen zu implementieren. Natürlich kann der RFC-Autor (wie jeder andere Entwickler auch) eine Implementierung zur Überprüfung posten, nachdem der RFC akzeptiert wurde.
Wenn Sie daran interessiert sind, an der Implementierung für einen „aktiven“ RFC zu arbeiten, aber nicht feststellen können, ob bereits jemand anderes daran arbeitet, können Sie gerne nachfragen (z. B. indem Sie einen Kommentar zum zugehörigen Problem hinterlassen).
Derzeit kann sich das React-Team nicht dazu verpflichten, RFCs zeitnah zu überprüfen. Wenn Sie einen RFC einreichen, sollte Ihr Hauptziel darin bestehen, Community-Feedback einzuholen und eine intensive Diskussion anzustoßen. Das React-Team bewertet alle paar Monate die aktuelle Liste der Projekte und Prioritäten neu. Selbst wenn ein RFC gut konzipiert ist, können wir uns oft nicht dazu verpflichten, ihn sofort zu integrieren. Wir finden es jedoch sehr wertvoll, die offenen RFCs alle paar Monate noch einmal durchzugehen und zu sehen, ob uns etwas auffällt. Wann immer wir mit der Arbeit an einem neuen Problembereich beginnen, stellen wir außerdem sicher, dass wir prüfen, ob es bereits Arbeiten und Diskussionen in allen zugehörigen RFCs gibt, und uns mit ihnen befassen.
Wir lesen alle RFCs innerhalb weniger Wochen nach der Einreichung. Wenn wir der Meinung sind, dass das Design gut zu React passt und wir bereit sind, es zu bewerten, werden wir versuchen, es früher zu überprüfen. Wenn wir hinsichtlich des Designs zögern oder nicht über genügend Informationen verfügen, um es zu bewerten, lassen wir es offen, bis es genügend Community-Feedback erhält. Wir wissen, dass es frustrierend ist, nicht rechtzeitig eine Bewertung zu erhalten, aber Sie können sicher sein, dass die Arbeit, die Sie in einen RFC gesteckt haben, nicht umsonst ist.
Der RFC-Prozess von React verdankt seine Inspiration dem Yarn RFC-Prozess, dem Rust RFC-Prozess und dem Ember RFC-Prozess.
Wir haben es in der Vergangenheit als Reaktion auf Feedback geändert und sind bei Bedarf jederzeit bereit, es erneut zu ändern.
