Esta página foi traduzida pela API Cloud Translation.

O processo RFC do TensorFlow

Cada novo recurso do TensorFlow começa como uma solicitação de comentário (RFC).

Uma RFC é um documento que descreve um requisito e as alterações propostas que irão resolvê-lo. Especificamente, a RFC irá:

Ser formatado de acordo com o modelo RFC .
Ser enviado como uma solicitação pull ao diretório community/rfcs .
Estar sujeito a discussão e uma reunião de revisão antes da aceitação.

O objetivo de uma solicitação de comentários (RFC) do TensorFlow é envolver a comunidade do TensorFlow no desenvolvimento, obtendo feedback de partes interessadas e especialistas e comunicando amplamente as alterações de design.

Como enviar uma RFC

Antes de enviar uma RFC, discuta seus objetivos com os colaboradores e mantenedores do projeto e obtenha feedback antecipado. Use a lista de discussão de desenvolvedores do projeto em questão (developers@tensorflow.org ou a lista do SIG relevante).
Elabore sua RFC.
- Leia os critérios de revisão de projeto
- Siga o modelo RFC .
- Nomeie seu arquivo RFC YYYYMMDD-descriptive-name.md , onde YYYYMMDD é a data de envio e descriptive-name está relacionado ao título de seu RFC. (Por exemplo, se o seu RFC for intitulado Parallel Widgets API , você poderá usar o nome de arquivo 20180531-parallel-widgets.md .
- Se você tiver imagens ou outros arquivos auxiliares, crie um diretório no formato YYYYMMDD-descriptive-name no qual armazenar esses arquivos.
Depois de escrever o rascunho da RFC, obtenha feedback dos mantenedores e contribuidores antes de enviá-lo.
Escrever código de implementação não é um requisito, mas pode ajudar a projetar discussões.
Recrute um patrocinador.
- Um patrocinador deve ser um mantenedor do projeto.
- Identifique o patrocinador na RFC, antes de postar o PR.
Você pode postar uma RFC sem patrocinador, mas se dentro de um mês após a publicação do PR ainda não houver patrocinador, ela será encerrada.
Envie seu RFC como uma solicitação pull para tensorflow/community/rfcs .
Inclua a tabela de cabeçalho e o conteúdo da seção Objetivo no comentário da sua solicitação pull, usando Markdown. Por exemplo, consulte este exemplo RFC . Inclua os identificadores do GitHub de coautores, revisores e patrocinadores.
No topo do PR, identifique quanto tempo durará o período de comentários. Isso deve ocorrer no mínimo duas semanas após a publicação do PR.
Envie um e-mail para a lista de discussão do desenvolvedor com uma breve descrição, um link para o PR e uma solicitação de revisão. Siga o formato dos mailings anteriores, como você pode ver neste exemplo .
O patrocinador solicitará uma reunião do comitê de revisão, no máximo duas semanas após a publicação do PR da RFC. Se a discussão estiver animada, espere até que esteja resolvida antes de ir para a revisão. O objetivo da reunião de revisão é resolver questões menores; o consenso deve ser alcançado antecipadamente sobre as questões principais.
A reunião poderá aprovar a RFC, rejeitá-la ou exigir alterações antes que ela possa ser considerada novamente. Os RFCs aprovados serão mesclados em community/rfcs e os RFCs rejeitados terão seus PRs fechados.

Participantes da RFC

Muitas pessoas estão envolvidas no processo RFC:

Autor da RFC – um ou mais membros da comunidade que escrevem uma RFC e estão comprometidos em defendê-la durante todo o processo
Patrocinador da RFC — um mantenedor que patrocina a RFC e a orientará durante o processo de revisão da RFC
comitê de revisão — um grupo de mantenedores que tem a responsabilidade de recomendar a adoção da RFC
Qualquer membro da comunidade pode ajudar fornecendo feedback sobre se a RFC atenderá às suas necessidades.

Patrocinadores RFC

Um patrocinador é o mantenedor do projeto responsável por garantir o melhor resultado possível do processo RFC. Isso inclui:

Defendendo o design proposto.
Orientar a RFC a aderir às convenções de design e estilo existentes.
Orientar o comitê de revisão para chegar a um consenso produtivo.
Se alterações forem solicitadas pelo comitê de revisão, certifique-se de que sejam feitas e busque a aprovação subsequente dos membros do comitê.
Se a RFC passar para a implementação:
- Garantir que a implementação proposta esteja de acordo com o design.
- Coordenar com as partes apropriadas para uma implementação bem-sucedida do terreno.

Comitês de revisão RFC

O comitê de revisão decide por consenso se aprova, rejeita ou solicita alterações. Eles são responsáveis por:

Garantir que os itens substanciais do feedback público tenham sido contabilizados.
Adicionando suas notas de reunião como comentários ao PR.
Fornecendo razões para suas decisões.

A constituição de um comité de revisão pode mudar de acordo com o estilo de governação e liderança particular de cada projecto. Para o TensorFlow principal, o comitê será composto por colaboradores do projeto TensorFlow que tenham experiência na área de domínio em questão.

Membros da comunidade e o processo RFC

O objetivo das RFCs é garantir que a comunidade seja bem representada e atendida por novas mudanças no TensorFlow. É responsabilidade dos membros da comunidade participar na revisão dos RFCs quando tiverem interesse no resultado.

Os membros da comunidade interessados em uma RFC devem:

Forneça feedback o mais rápido possível para permitir tempo adequado para consideração.
Leia atentamente os RFCs antes de fornecer feedback.
Seja civilizado e construtivo .

Implementando novos recursos

Depois que uma RFC for aprovada, a implementação poderá começar.

Se você estiver trabalhando em um novo código para implementar uma RFC:

Certifique-se de compreender o recurso e o design aprovado na RFC. Faça perguntas e discuta a abordagem antes de começar o trabalho.
Novos recursos devem incluir novos testes de unidade que verifiquem se o recurso funciona conforme o esperado. É uma boa ideia escrever esses testes antes de escrever o código.
Siga o guia de estilo de código do TensorFlow
Adicione ou atualize a documentação relevante da API. Faça referência à RFC na nova documentação.
Siga quaisquer outras diretrizes descritas no arquivo CONTRIBUTING.md no repositório do projeto para o qual você está contribuindo.
Execute testes unitários antes de enviar seu código.
Trabalhe com o patrocinador RFC para obter o novo código com sucesso.

Mantendo a fasquia alta

Embora encorajemos e celebremos cada colaborador, o nível de aceitação da RFC é mantido intencionalmente alto. Um novo recurso pode ser rejeitado ou precisar de revisão significativa em qualquer um destes estágios:

Conversas iniciais sobre design na lista de discussão relevante.
Falha em recrutar um patrocinador.
Objeções críticas durante a fase de feedback.
Falha em alcançar consenso durante a revisão do projeto.
Preocupações levantadas durante a implementação (por exemplo: incapacidade de alcançar compatibilidade com versões anteriores, preocupações com manutenção).

Se este processo estiver a funcionar bem, espera-se que os RFC falhem nas fases anteriores, e não nas posteriores. Uma RFC aprovada não é garantia de compromisso de implementação, e a aceitação de uma implementação proposta de RFC ainda está sujeita ao processo usual de revisão de código.

Se você tiver alguma dúvida sobre esse processo, sinta-se à vontade para perguntar na lista de discussão de desenvolvedores ou registrar um problema em tensorflow/community .