rfcs
1.0.0
Muitas mudanças, incluindo correções de bugs e melhorias na documentação, podem ser implementadas e revisadas por meio do fluxo de trabalho normal de pull request do GitHub.
Algumas mudanças, porém, são "substanciais" e pedimos que sejam submetidas a um processo de design e produzam um consenso entre a equipe principal do React.
O processo "RFC" (solicitação de comentários) tem como objetivo fornecer um caminho consistente e controlado para que novos recursos entrem no projeto.
Lista RFC ativa
Para aceitar sua solicitação pull, precisamos que você envie um CLA. Você só precisa fazer isso uma vez, então se você fez isso para outro projeto de código aberto do Facebook, você está pronto para prosseguir. Se você estiver enviando uma solicitação pull pela primeira vez, informe-nos que concluiu o CLA e poderemos verificar com seu nome de usuário do GitHub.
Complete seu CLA aqui.
Você deve considerar usar este processo se pretende fazer alterações "substanciais" no React ou em sua documentação. Alguns exemplos que se beneficiariam de uma RFC são:
Um novo recurso que cria uma nova área de superfície de API e exigiria um sinalizador de recurso se fosse introduzido.
A remoção de recursos já enviados como parte do canal de lançamento.
A introdução de novos usos ou convenções idiomáticas, mesmo que não incluam alterações de código no próprio React.
Algumas alterações não requerem uma RFC:
Reformular, reorganizar ou refatorar
Adição ou remoção de avisos
Adições que melhoram estritamente os critérios de qualidade objetivos e numéricos (aceleração, melhor suporte ao navegador)
Adições que provavelmente serão notadas apenas por outros implementadores do React, invisíveis para os usuários do React.
É difícil escrever uma RFC que seja aceita. No entanto, isso não deve desencorajá-lo de escrever um.
O React tem uma área de superfície de API muito limitada e cada recurso precisa funcionar perfeitamente com todos os outros recursos. Mesmo entre os membros da equipe que trabalham no React em tempo integral todos os dias, desenvolver e ganhar contexto suficiente para escrever uma boa RFC leva mais de um ano.
Na prática, os RFCs do React servem a dois propósitos:
Os RFCs do React Team são enviados pelos membros do React Team após extenso design, discussão e experimentação (às vezes, de vários meses ou de vários anos). Na prática, eles constituem a maioria das RFCs que foram fundidas até agora. O objetivo dessas RFCs é visualizar o design para a comunidade e fornecer uma oportunidade para feedback. Lemos todos os comentários sobre as RFCs que publicamos, respondemos às perguntas e, às vezes, incorporamos o feedback na proposta. Como nosso tempo é limitado, não tendemos a escrever uma RFC para um recurso React, a menos que estejamos muito confiantes de que ela se adapta ao design. Embora possa parecer que a maioria dos RFCs do React Team são facilmente aceitos, na prática é porque 98% das ideias foram deixadas na sala de edição. Os 2% restantes sobre os quais nos sentimos muito confiantes e sobre os quais temos consenso da equipe são aqueles que anunciamos como RFCs para feedback da comunidade.
Os RFCs da comunidade podem ser enviados por qualquer pessoa. Na prática, a maioria dos RFCs comunitários não são mesclados. Os motivos mais comuns pelos quais rejeitamos uma RFC é que ela apresenta lacunas ou falhas de design significativas, não funciona de forma coesa com todos os outros recursos ou não se enquadra em nossa visão do escopo do React. No entanto, a fusão não é o único critério de sucesso para uma RFC. Mesmo quando o design da API não corresponde à direção que gostaríamos de seguir, consideramos as discussões sobre RFC muito valiosas para pesquisa e inspiração. Nem sempre revisamos as RFCs da comunidade em tempo hábil, mas sempre que começamos a trabalhar em uma área relacionada, verificamos as RFCs dessa área e revisamos os casos de uso e as preocupações postadas pelos membros da comunidade. Quando você envia uma RFC, seu objetivo principal não deve ser necessariamente fundi-la no React como está, mas gerar uma discussão rica com os membros da comunidade. Se sua proposta for aceita posteriormente, ótimo. Mas mesmo que isso não aconteça, não será em vão. A discussão resultante geralmente informa a próxima proposta no mesmo espaço do problema, seja ela proveniente da comunidade ou da equipe React. Muitos autores de bibliotecas estão lendo as discussões, então as RFCs geralmente levam à experimentação da comunidade e a soluções para o usuário.
Aplicamos o mesmo nível de rigor tanto aos RFCs da equipe React quanto aos RFCs da comunidade. A principal diferença entre eles está na fase de design: os RFCs do React Team tendem a ser enviados no final do processo de design, enquanto os RFCs da comunidade tendem a ser enviados no início, como forma de iniciá-lo.
Resumindo, para adicionar um recurso importante ao React, geralmente primeiro o RFC é mesclado no repositório RFC como um arquivo markdown. Nesse ponto, o RFC está 'ativo' e pode ser implementado com o objetivo de eventual inclusão no React.
Bifurque o repositório RFC http://github.com/reactjs/rfcs
Copie 0000-template.md para text/0000-my-feature.md (onde 'my-feature' é descritivo. Não atribua um número RFC ainda).
Preencha o RFC. Tenha cuidado com os detalhes: RFCs que não apresentam motivação convincente, demonstram compreensão do impacto do design ou são hipócritas sobre as desvantagens ou alternativas tendem a ser mal recebidas .
Envie uma solicitação pull. Como uma solicitação pull, a RFC receberá feedback de design da comunidade em geral, e o autor deverá estar preparado para revisá-lo em resposta.
Construa consenso e integre feedback. As RFCs que contam com amplo apoio têm muito mais probabilidade de progredir do que aquelas que não recebem comentários.
Eventualmente, a equipe decidirá se o RFC é candidato para inclusão no React. Observe que uma revisão em equipe pode levar muito tempo e sugerimos que você peça aos membros da comunidade que a revisem primeiro.
RFCs candidatos à inclusão no React entrarão em um “período de comentários finais” com duração de 3 dias corridos. O início deste período será sinalizado com um comentário e tag no pull request das RFCs.
Uma RFC pode ser modificada com base no feedback da equipe e da comunidade. Modificações significativas podem desencadear um novo período final para comentários.
Uma RFC pode ser rejeitada pela equipe após a discussão pública ser resolvida e os comentários terem sido feitos resumindo a justificativa para a rejeição. Um membro da equipe deve então fechar a solicitação pull associada às RFCs.
Uma RFC pode ser aceita no final do período final para comentários. Um membro da equipe mesclará a solicitação pull associada às RFCs e, nesse ponto, a RFC se tornará 'ativa'.
Depois que um RFC se torna ativo, os autores podem implementá-lo e enviar o recurso como uma solicitação pull para o repositório React. Tornar-se 'ativo' não é um carimbo e, em particular, ainda não significa que o recurso será finalmente mesclado; isso significa que a equipe principal concordou com isso em princípio e está disposta a fundi-lo.
Além disso, o facto de um determinado RFC ter sido aceite e estar “activo” não implica nada sobre a prioridade atribuída à sua implementação, nem se alguém está actualmente a trabalhar nele.
Modificações nas RFCs ativas podem ser feitas em PRs de acompanhamento. Nós nos esforçamos para escrever cada RFC de forma que reflita o design final do recurso; mas a natureza do processo significa que não podemos esperar que cada RFC mesclada reflita realmente qual será o resultado final no momento do próximo grande lançamento; portanto, tentamos manter cada documento RFC sincronizado com o recurso de idioma conforme planejado, rastreando essas alterações por meio de solicitações pull de acompanhamento para o documento.
O autor de uma RFC não é obrigado a implementá-la. Obviamente, o autor da RFC (como qualquer outro desenvolvedor) pode publicar uma implementação para revisão após a aceitação da RFC.
Se você estiver interessado em trabalhar na implementação de uma RFC 'ativa', mas não conseguir determinar se alguém já está trabalhando nela, sinta-se à vontade para perguntar (por exemplo, deixando um comentário sobre o problema associado).
Atualmente, a equipe React não pode se comprometer a revisar as RFCs em tempo hábil. Ao enviar uma RFC, seu objetivo principal deve ser solicitar feedback da comunidade e gerar uma discussão rica. A equipe React reavalia a lista atual de projetos e prioridades a cada vários meses. Mesmo que uma RFC seja bem projetada, muitas vezes não podemos nos comprometer a integrá-la imediatamente. No entanto, achamos muito valioso revisitar as RFCs abertas a cada poucos meses e ver se algo chama nossa atenção. Sempre que começamos a trabalhar em um novo espaço de problema, também verificamos o trabalho e a discussão anteriores em quaisquer RFCs relacionados e nos envolvemos com eles.
Lemos todos os RFCs algumas semanas após o envio. Se acharmos que o design se adapta bem ao React e estivermos prontos para avaliá-lo, tentaremos revisá-lo mais cedo. Se estivermos hesitantes sobre o design ou se não tivermos informações suficientes para avaliá-lo, deixaremos o assunto em aberto até que receba feedback suficiente da comunidade. Reconhecemos que é frustrante não receber uma revisão oportuna, mas você pode ter certeza de que nenhum trabalho realizado em uma RFC será em vão.
O processo RFC do React deve sua inspiração ao processo Yarn RFC, ao processo Rust RFC e ao processo Ember RFC.
Nós o alteramos no passado em resposta aos comentários e estamos abertos a alterá-lo novamente, se necessário.
