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

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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 .

  6. 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.

  7. 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 .