rfcs
1.0.0
Muchos cambios, incluidas correcciones de errores y mejoras en la documentación, se pueden implementar y revisar a través del flujo de trabajo normal de solicitud de extracción de GitHub.
Sin embargo, algunos cambios son "sustanciales" y pedimos que se sometan a un proceso de diseño y produzcan un consenso entre el equipo central de React.
El proceso "RFC" (solicitud de comentarios) tiene como objetivo proporcionar una ruta consistente y controlada para que nuevas características ingresen al proyecto.
Lista RFC activa
Para aceptar su solicitud de extracción, necesitamos que envíe un CLA. Solo necesitas hacer esto una vez, así que si lo hiciste para otro proyecto de código abierto de Facebook, estás listo. Si envía una solicitud de extracción por primera vez, infórmenos que completó el CLA y podremos verificarlo con su nombre de usuario de GitHub.
Completa tu CLA aquí.
Debería considerar utilizar este proceso si tiene la intención de realizar cambios "sustanciales" en React o su documentación. Algunos ejemplos que se beneficiarían de un RFC son:
Una nueva función que crea una nueva superficie de API y, si se introduce, requeriría una marca de función.
La eliminación de funciones que ya se incluyeron como parte del canal de lanzamiento.
La introducción de nuevos usos idiomáticos o convenciones, incluso si no incluyen cambios de código en React.
Algunos cambios no requieren un RFC:
Reformular, reorganizar o refactorizar
Adición o eliminación de advertencias.
Adiciones que mejoran estrictamente los criterios de calidad numéricos y objetivos (aceleración, mejor soporte del navegador)
Es probable que las adiciones solo sean notadas por otros implementadores de React, invisibles para los usuarios de React.
Es difícil escribir un RFC que sea aceptado. Sin embargo, esto no debería disuadirte de escribir uno.
React tiene una superficie de API muy limitada y cada función debe funcionar a la perfección con todas las demás funciones. Incluso entre los miembros del equipo que trabajan en React a tiempo completo todos los días, avanzar y obtener suficiente contexto para escribir un buen RFC lleva más de un año.
En la práctica, los RFC de React tienen dos propósitos:
Los RFC del equipo React son enviados por los miembros del equipo React después de un diseño, discusión y experimentación extensos (a veces, de varios meses o años). En la práctica, comprenden la mayoría de los RFC que se fusionaron hasta ahora. El propósito de estos RFC es obtener una vista previa del diseño para la comunidad y brindar una oportunidad para recibir comentarios. Leemos cada comentario sobre los RFC que publicamos, respondemos preguntas y, en ocasiones, incorporamos los comentarios a la propuesta. Dado que nuestro tiempo es limitado, no solemos escribir un RFC para una función de React a menos que estemos muy seguros de que se ajusta al diseño. Aunque podría parecer que la mayoría de los RFC del equipo React son aceptados fácilmente, en la práctica se debe a que el 98% de las ideas quedaron en la sala de montaje. El 2% restante sobre el que nos sentimos muy seguros y sobre el que tenemos consenso del equipo son los que anunciamos como RFC para recibir comentarios de la comunidad.
Cualquiera puede enviar RFC comunitarios . En la práctica, la mayoría de los RFC comunitarios no se fusionan. Las razones más comunes por las que rechazamos un RFC es que tiene importantes lagunas o defectos de diseño, no funciona de manera coherente con todas las demás características o no entra en nuestra visión del alcance de React. Sin embargo, fusionarse no es el único criterio de éxito para un RFC. Incluso cuando el diseño de la API no coincide con la dirección que nos gustaría tomar, consideramos que las discusiones sobre RFC son muy valiosas para la investigación y la inspiración. No siempre revisamos los RFC de la comunidad de manera oportuna, pero cada vez que comenzamos a trabajar en un área relacionada, verificamos los RFC en esa área y revisamos los casos de uso y las inquietudes que los miembros de la comunidad han publicado. Cuando envía un RFC, su objetivo principal no debe ser necesariamente fusionarlo en React tal como está, sino generar una rica discusión con los miembros de la comunidad. Si su propuesta luego es aceptada, genial. Pero incluso si no es así, no será en vano. La discusión resultante a menudo informa la siguiente propuesta en el mismo espacio del problema, ya sea que provenga de la comunidad o del equipo React. Muchos autores de bibliotecas están leyendo las discusiones, por lo que los RFC a menudo conducen a experimentación comunitaria y soluciones en el espacio de usuario.
Aplicamos el mismo nivel de rigor tanto a los RFC del equipo React como a los RFC comunitarios. La principal diferencia entre ellos está en la fase de diseño: los RFC del equipo React tienden a enviarse al final del proceso de diseño, mientras que los RFC comunitarios tienden a enviarse al principio como una forma de iniciarlo.
En resumen, para agregar una característica importante a React, generalmente primero se fusiona el RFC en el repositorio de RFC como un archivo de rebajas. En ese momento, el RFC está "activo" y puede implementarse con el objetivo de su eventual inclusión en React.
Bifurca el repositorio RFC http://github.com/reactjs/rfcs
Copie 0000-template.md a text/0000-my-feature.md (donde 'my-feature' es descriptivo. No asigne un número RFC todavía).
Complete el RFC. Preste atención a los detalles: los RFC que no presentan una motivación convincente, no demuestran comprensión del impacto del diseño o no son sinceros acerca de los inconvenientes o alternativas tienden a ser mal recibidos .
Envíe una solicitud de extracción. Como solicitud de extracción, el RFC recibirá comentarios de diseño de la comunidad en general y el autor debe estar preparado para revisarlo en respuesta.
Genere consenso e integre la retroalimentación. Los RFC que cuentan con un amplio apoyo tienen muchas más probabilidades de lograr avances que aquellos que no reciben ningún comentario.
Eventualmente, el equipo decidirá si el RFC es candidato para su inclusión en React. Tenga en cuenta que una revisión en equipo puede llevar mucho tiempo y le sugerimos que solicite a los miembros de la comunidad que la revisen primero.
Los RFC que sean candidatos para su inclusión en React entrarán en un "período de comentarios finales" que durará 3 días calendario. El comienzo de este período se señalará con un comentario y una etiqueta en la solicitud de extracción de RFC.
Un RFC se puede modificar según los comentarios del equipo y la comunidad. Las modificaciones significativas pueden desencadenar un nuevo período de comentarios finales.
El equipo puede rechazar un RFC después de que se haya resuelto la discusión pública y se hayan hecho comentarios que resuman los motivos del rechazo. Luego, un miembro del equipo debe cerrar la solicitud de extracción asociada a los RFC.
Se podrá aceptar un RFC al cierre de su período de comentarios finales. Un miembro del equipo fusionará la solicitud de extracción asociada a los RFC, momento en el cual el RFC se volverá "activo".
Una vez que un RFC se activa, los autores pueden implementarlo y enviar la función como una solicitud de extracción al repositorio de React. Convertirse en "activo" no es un sello de goma y, en particular, todavía no significa que la función finalmente se fusionará; significa que el equipo central lo ha aceptado en principio y está dispuesto a fusionarlo.
Además, el hecho de que un determinado RFC haya sido aceptado y esté "activo" no implica nada sobre qué prioridad se asigna a su implementación, ni si alguien está trabajando actualmente en él.
Las modificaciones a los RFC activos se pueden realizar en los RP de seguimiento. Nos esforzamos por redactar cada RFC de manera que refleje el diseño final de la función; pero la naturaleza del proceso significa que no podemos esperar que cada RFC fusionado refleje realmente cuál será el resultado final en el momento del próximo lanzamiento importante; por lo tanto, intentamos mantener cada documento RFC algo sincronizado con la función de idioma según lo planeado, rastreando dichos cambios a través de solicitudes de seguimiento del documento.
El autor de un RFC no está obligado a implementarlo. Por supuesto, el autor del RFC (como cualquier otro desarrollador) puede publicar una implementación para su revisión después de que el RFC haya sido aceptado.
Si está interesado en trabajar en la implementación de un RFC 'activo', pero no puede determinar si alguien más ya está trabajando en él, no dude en preguntar (por ejemplo, dejando un comentario sobre el tema asociado).
Actualmente, el equipo de React no puede comprometerse a revisar los RFC de manera oportuna. Cuando envía un RFC, su objetivo principal debe ser solicitar comentarios de la comunidad y generar una discusión enriquecedora. El equipo React reevalúa la lista actual de proyectos y prioridades cada varios meses. Incluso si un RFC está bien diseñado, a menudo no podemos comprometernos a integrarlo de inmediato. Sin embargo, nos parece muy valioso volver a visitar los RFC abiertos cada pocos meses y ver si hay algo que nos llame la atención. Cada vez que comenzamos a trabajar en un nuevo espacio problemático, también nos aseguramos de verificar el trabajo y la discusión previos en cualquier RFC relacionado, e interactuar con ellos.
Leemos todos los RFC a las pocas semanas de su presentación. Si creemos que el diseño se ajusta bien a React y si estamos listos para evaluarlo, intentaremos revisarlo antes. Si tenemos dudas sobre el diseño o si no tenemos suficiente información para evaluarlo, lo dejaremos abierto hasta que reciba suficientes comentarios de la comunidad. Reconocemos que es frustrante no recibir una revisión oportuna, pero puede estar seguro de que nada del trabajo que realiza en un RFC es en vano.
El proceso RFC de React debe su inspiración al proceso Yarn RFC, al proceso Rust RFC y al proceso Ember RFC.
Lo hemos cambiado en el pasado en respuesta a los comentarios y estamos abiertos a cambiarlo nuevamente si es necesario.
