rfcs
1.0.0
De nombreuses modifications, y compris des corrections de bogues et des améliorations de la documentation, peuvent être mises en œuvre et examinées via le flux de travail normal des demandes d'extraction GitHub.
Certains changements sont cependant « substantiels », et nous demandons qu'ils soient soumis à un certain processus de conception et produisent un consensus au sein de l'équipe principale de React.
Le processus « RFC » (demande de commentaires) est destiné à fournir un chemin cohérent et contrôlé pour que les nouvelles fonctionnalités entrent dans le projet.
Liste RFC active
Afin d'accepter votre pull request, nous avons besoin que vous soumettiez un CLA. Vous ne devez le faire qu'une seule fois, donc si vous l'avez fait pour un autre projet open source Facebook, vous êtes prêt à partir. Si vous soumettez une pull request pour la première fois, faites-nous simplement savoir que vous avez terminé le CLA et nous pourrons vérifier avec votre nom d'utilisateur GitHub.
Complétez votre CCT ici.
Vous devriez envisager d'utiliser ce processus si vous avez l'intention d'apporter des modifications « substantielles » à React ou à sa documentation. Voici quelques exemples qui bénéficieraient d’une RFC :
Une nouvelle fonctionnalité qui crée une nouvelle surface d'API et qui nécessiterait un indicateur de fonctionnalité si elle était introduite.
La suppression des fonctionnalités déjà livrées dans le cadre de la version release.
L'introduction de nouveaux usages ou conventions idiomatiques, même s'ils n'incluent pas de modifications de code dans React lui-même.
Certaines modifications ne nécessitent pas de RFC :
Reformuler, réorganiser ou refactoriser
Ajout ou suppression d'avertissements
Ajouts qui améliorent strictement les critères de qualité objectifs et numériques (accélération, meilleure prise en charge du navigateur)
Les ajouts ne seront probablement remarqués que par les autres implémenteurs de React, invisibles pour les utilisateurs de React.
Il est difficile d'écrire une RFC qui serait acceptée. Néanmoins, cela ne devrait pas vous décourager d’en écrire un.
React a une surface d'API très limitée et chaque fonctionnalité doit fonctionner de manière transparente avec toutes les autres fonctionnalités. Même parmi les membres de l’équipe qui travaillent quotidiennement à temps plein sur React, il faut plus d’un an pour monter en puissance et obtenir suffisamment de contexte pour rédiger un bon RFC.
En pratique, les RFC React répondent à deux objectifs :
Les RFC de l'équipe React sont soumises par les membres de l'équipe React après une conception, une discussion et une expérimentation approfondies (parfois sur plusieurs mois ou plusieurs années). En pratique, ils constituent la majorité des RFC qui ont fusionné jusqu’à présent. Le but de ces RFC est de prévisualiser la conception pour la communauté et de fournir une opportunité de commentaires. Nous lisons tous les commentaires sur les RFC que nous publions, répondons aux questions et intégrons parfois les commentaires dans la proposition. Comme notre temps est limité, nous n'avons pas tendance à rédiger une RFC pour une fonctionnalité React à moins que nous soyons convaincus qu'elle correspond à la conception. Même s'il semble que la plupart des RFC de l'équipe React soient facilement acceptées, dans la pratique, c'est parce que 98 % des idées ont été laissées en salle de montage. Les 2 % restants sur lesquels nous sommes très confiants et sur lesquels il existe un consensus au sein de l'équipe sont ceux que nous annonçons en tant que RFC pour les commentaires de la communauté.
Les RFC communautaires peuvent être soumises par n’importe qui. En pratique, la plupart des RFC communautaires ne sont pas fusionnées. Les raisons les plus courantes pour lesquelles nous rejetons une RFC sont qu'elle présente des lacunes ou des défauts de conception importants, qu'elle ne fonctionne pas de manière cohérente avec toutes les autres fonctionnalités ou qu'elle ne correspond pas à notre vision de la portée de React. Cependant, la fusion n’est pas le seul critère de réussite d’une RFC. Même lorsque la conception de l'API ne correspond pas à la direction que nous aimerions prendre, nous trouvons les discussions RFC très utiles pour la recherche et l'inspiration. Nous n'examinons pas toujours les RFC de la communauté en temps opportun, mais chaque fois que nous commençons à travailler sur un domaine connexe, nous vérifions les RFC de ce domaine et examinons les cas d'utilisation et les préoccupations que les membres de la communauté ont publiés. Lorsque vous envoyez une RFC, votre objectif principal ne doit pas nécessairement être de la fusionner telle quelle dans React, mais de générer une discussion riche avec les membres de la communauté. Si votre proposition est acceptée plus tard, c'est parfait. Mais même si ce n’est pas le cas, ce ne sera pas en vain. La discussion qui en résulte éclaire souvent la proposition suivante dans le même espace problématique, qu'elle provienne de la communauté ou de l'équipe React. De nombreux auteurs de bibliothèques lisent les discussions, de sorte que les RFC conduisent souvent à des expérimentations communautaires et à des solutions en matière d'espace utilisateur.
Nous appliquons le même niveau de rigueur aux RFC de l’équipe React et aux RFC communautaires. La principale différence entre eux réside dans la phase de conception : les RFC de l'équipe React ont tendance à être soumises à la fin du processus de conception, tandis que les RFC de la communauté ont tendance à être soumises au début afin de le lancer.
En bref, pour ajouter une fonctionnalité majeure à React, on commence généralement par fusionner le RFC dans le dépôt RFC en tant que fichier de démarque. À ce stade, la RFC est « active » et peut être implémentée dans le but d’être éventuellement incluse dans React.
Forkez le dépôt RFC http://github.com/reactjs/rfcs
Copiez 0000-template.md dans text/0000-my-feature.md (où « ma-fonctionnalité » est descriptif. N'attribuez pas encore de numéro RFC).
Remplissez le RFC. Soyez attentif aux détails : les RFC qui ne présentent pas de motivation convaincante, ne démontrent pas une compréhension de l'impact de la conception ou qui ne sont pas sincères quant aux inconvénients ou aux alternatives ont tendance à être mal reçues .
Soumettez une pull request. En tant que pull request, la RFC recevra les commentaires de conception de la communauté dans son ensemble, et l'auteur doit être prêt à la réviser en réponse.
Établissez un consensus et intégrez les commentaires. Les RFC qui bénéficient d'un large soutien sont beaucoup plus susceptibles de progresser que celles qui ne reçoivent aucun commentaire.
Finalement, l'équipe décidera si la RFC est candidate à l'inclusion dans React. Notez qu'une révision en équipe peut prendre beaucoup de temps et nous vous suggérons de demander aux membres de la communauté de la réviser en premier.
Les RFC candidates à l'inclusion dans React entreront dans une « période de commentaires finaux » d'une durée de 3 jours calendaires. Le début de cette période sera signalé par un commentaire et une balise sur la pull request des RFC.
Une RFC peut être modifiée en fonction des commentaires de l'équipe et de la communauté. Des modifications significatives peuvent déclencher une nouvelle période de commentaires finaux.
Une RFC peut être rejetée par l'équipe une fois que le débat public est réglé et que des commentaires ont été formulés résumant la justification du rejet. Un membre de l’équipe doit alors fermer la demande d’extraction associée aux RFC.
Une RFC peut être acceptée à la fin de sa période de commentaires finale. Un membre de l'équipe fusionnera les demandes d'extraction associées aux RFC, auquel cas la RFC deviendra « active ».
Une fois qu'une RFC devient active, les auteurs peuvent l'implémenter et soumettre la fonctionnalité sous forme de demande d'extraction au référentiel React. Devenir « actif » n’est pas une formalité, et en particulier ne signifie toujours pas que la fonctionnalité sera finalement fusionnée ; cela signifie que l'équipe de base en a accepté le principe et est disposée à la fusionner.
De plus, le fait qu'une RFC donnée ait été acceptée et soit « active » n'implique rien sur la priorité attribuée à sa mise en œuvre, ni sur le fait que quelqu'un y travaille actuellement.
Les modifications des RFC actives peuvent être effectuées dans les PR de suivi. Nous nous efforçons d'écrire chaque RFC de manière à refléter la conception finale de la fonctionnalité ; mais la nature du processus signifie que nous ne pouvons pas nous attendre à ce que chaque RFC fusionnée reflète réellement ce que sera le résultat final au moment de la prochaine version majeure ; par conséquent, nous essayons de garder chaque document RFC quelque peu synchronisé avec la fonctionnalité linguistique comme prévu, en suivant ces modifications via des demandes d'extraction de suivi vers le document.
L'auteur d'une RFC n'est pas obligé de la mettre en œuvre. Bien entendu, l'auteur de la RFC (comme tout autre développeur) est invité à publier une implémentation pour examen une fois la RFC acceptée.
Si vous êtes intéressé à travailler sur l'implémentation d'une RFC « active », mais que vous ne parvenez pas à déterminer si quelqu'un d'autre y travaille déjà, n'hésitez pas à le demander (par exemple en laissant un commentaire sur le problème associé).
Actuellement, l’équipe React ne peut pas s’engager à examiner les RFC en temps opportun. Lorsque vous soumettez une RFC, votre objectif principal doit être de solliciter les commentaires de la communauté et de générer une discussion riche. L'équipe React réévalue la liste actuelle des projets et des priorités tous les plusieurs mois. Même si une RFC est bien conçue, nous ne pouvons souvent pas nous engager à l'intégrer immédiatement. Cependant, nous trouvons très utile de revoir les RFC ouvertes tous les quelques mois et de voir si quelque chose attire notre attention. Chaque fois que nous commençons à travailler sur un nouvel espace problématique, nous veillons également à vérifier les travaux et discussions antérieurs dans toutes les RFC associées, et à dialoguer avec eux.
Nous lisons toutes les RFC quelques semaines après leur soumission. Si nous pensons que la conception correspond bien à React et si nous sommes prêts à l'évaluer, nous essaierons de la revoir plus tôt. Si nous hésitons sur la conception ou si nous n'avons pas suffisamment d'informations pour l'évaluer, nous la laisserons ouverte jusqu'à ce qu'elle reçoive suffisamment de commentaires de la communauté. Nous reconnaissons qu'il est frustrant de ne pas recevoir une évaluation en temps opportun, mais vous pouvez être sûr qu'aucun du travail que vous consacrez à une RFC n'est vain.
Le processus RFC de React doit son inspiration au processus Yarn RFC, au processus Rust RFC et au processus Ember RFC.
Nous l'avons modifié par le passé en réponse à vos commentaires, et nous sommes disposés à le modifier à nouveau si nécessaire.
