O Facebook decidiu adotar um novo processo de Pedido de Comentários (RFC) para ajudar a orientar o desenvolvimento do React e suavizar o caminho da ideia à implementação.
O novo procedimento pede que grandes mudanças no React passem por um processo de verificação antes do desenvolvimento ocorrer. Os exemplos incluem:
- Um novo recurso que cria uma nova área de superfície da API e exigiria uma marca de funcionalidade se fosse inserida.
- A remoção de funcionalidades que já foram enviadas como parte do canal de lançamento (release).
- A introdução de um novo uso idiomático ou convenções, mesmo que não incluam alterações de código no próprio React.
Lista retirada do arquivo README do Processo RFC.
Como parte do processo, os desenvolvedores precisarão criar um documento RFC, enviar um pull request para o repositório RFC e incorporar o feedback da comunidade em sua proposta. As decisões finais sobre a aceitação ou não da RFC são responsabilidade do equipe principal do React.
Isso parece ser uma formalização de um costume que o projeto React tinha adotado informalmente. Uma pesquisa do projeto React no GitHub mostra que há muitos problemas que começam pela RFC com diferentes níveis de discussão.
O Facebook dá crédito ao processo Rust RFC como inspiração para o seu processo; as páginas iniciais da RFC têm o mesmo conteúdo e procedimentos. Claro, as RFCs não são novas e são a base de grande parte do trabalho realizado pela Internet Engineering Task Force (IETF).
Uma vantagem de usar um processo de RFC para projetos de código aberto é que as pessoas se sentem mais incluídas, diz Juan Pablo Buritica:
Não encontrei uma maneira melhor de gerar a sensação de pertencimento em equipes do que a inclusão das pessoas na tomada de decisões. Se estamos envolvidos em decisões importantes, nosso trabalho tem o potencial de ser mais impactante, e isso dá uma sensação de propósito. Ao dar aos membros da equipe a oportunidade de comentar sobre as decisões propostas por outros, as RFCs se tornam excelentes ferramentas para inclusão e permitem a participação que pode resultar em impacto no trabalho.
O processo de RFC deve economizar tempo tanto para os mantenedores do código aberto quanto para aqueles que desejam contribuir. Fazendo uma grande mudança em uma base de código e enviando um pull request apenas para que o mantenedor rejeite é uma perda de tempo. Jeff Geerling diz que grandes mudanças sem discussão é uma das razões pelas quais ele rejeita os pull requests:
Tive PRs onde a arquitetura do projeto inteiro ou a arquitetura de teste foi trocada. Nunca traria algo assim para o código, a menos que tenha sido minuciosamente discutido (e aprovado) em uma discussão primeiro. Geralmente, há uma razão (muitas razões, na verdade) sobre o porquê das coisas serem como elas são.
A lista atual de documentos na RFC, até agora, inclui alguns escritos pelos membros da equipe principal do React.