Todos podem contribuir com o OpenXLA, e valorizamos as contribuições de todos. Existem várias maneiras de contribuir, incluindo:
Responder perguntas em fóruns de discussão do OpenXLA (openxla-discuss)
Melhorar ou expandir a documentação do OpenXLA
Contribuir para a base de código do OpenXLA
Contribuir de qualquer uma das maneiras acima para o ecossistema mais amplo de bibliotecas criadas no OpenXLA
O projeto OpenXLA segue as diretrizes da comunidade de código aberto do Google.
Antes de começar
Assine o Contrato de Licença de Colaborador
As contribuições para este projeto precisam ser acompanhadas por um Contrato de Licença de Colaborador (CLA, na sigla em inglês). Você (ou seu empregador) retém os direitos autorais da sua contribuição. Isso simplesmente nos dá permissão para usar e redistribuir suas contribuições como parte do projeto.
Se você ou seu empregador atual já assinou o CLA do Google, mesmo que tenha sido para um projeto diferente, provavelmente não será necessário fazer isso de novo.
Acesse <https://cla.developers.google.com/> para ver seus contratos atuais ou assinar um novo.
Revise o Código de Conduta
Esse projeto segue o código de conduta do Tensorflow.
Processo de contribuição
Guia do desenvolvedor
Se quiser conferir um guia sobre como configurar um ambiente de desenvolvimento para o OpenXLA, incluindo como receber código, criá-lo, executar testes e enviar mudanças, consulte o Guia para desenvolvedores.
Padrões de código
Estilo de programação: seguimos o guia de estilo de código do Google. Consulte especificamente os guias C/C++ e Python. Todos os códigos enviados precisam estar em conformidade com esses guias de estilo.
Mudanças compactas: seguimos as práticas de engenharia do Google. Mais especificamente, consulte o guia sobre como criar mudanças compactas. Isso vai aumentar muito a velocidade com que você pode mesclar o código, para melhorar a capacidade de análise e reduzir a probabilidade de efeitos colaterais não intencionais da mudança. Mesmo que você tenha uma grande mudança, há muitas estratégias para dividi-la em alterações mais incrementais.
Cobertura de teste: todas as mudanças precisam incluir os testes de unidade adequados. Os testes de unidade não devem depender de tempos específicos de hardware (CPU, GPU etc.) e precisam fazer uso livre de simulações e simulações para fazer testes determinísticos e focados. As mudanças que buscam ampliar o código existente que atualmente é difícil de testar precisam fazer as melhorias adequadas para a testabilidade.
Todas as mudanças precisam incluir os resultados de comparativo de mercado adequados no título da mudança para garantir que os benefícios sejam claramente entendidos.
Em caso de dúvida sobre as convenções no código, é sempre uma boa ideia examinar o código preexistente e tentar seguir os padrões em vigor no OpenXLA.
Processo de análise
Todos os envios, inclusive dos membros do projeto, precisam ser revisados. Usamos as solicitações de envio do GitHub para essa finalidade. Consulte a Ajuda do GitHub (em inglês) para mais informações sobre como usar solicitações de envio.
O código precisa seguir todos os padrões listados acima antes da revisão. Elas não são opcionais, e é fundamental que o remetente verifique se o código está em conformidade antes de solicitar a revisão para garantir a aceitação das mudanças em tempo hábil.
Todos os testes precisam ser aprovados. Se você descobrir que um teste está corrompido e o problema não está relacionado ao seu ambiente de build ou às suas alterações, entre em contato com os mantenedores.
Tente evitar a deformação do escopo durante o processo de revisão. Essa responsabilidade é tanto do requerente quanto do revisor. Se uma alteração começar a ficar muito grande, considere dividi-la em várias alterações.
Antes que uma mudança seja mesclada, ela vai passar por testes internos que usam código interno do Google e de outros fornecedores de hardware. Isso poderá adicionar etapas extras ao processo de revisão se houver falhas em testes internos que nossa CI pública não detectar. O Googler que revisar sua alteração informará as falhas de teste interno e descreverá o que precisa ser corrigido.
Perguntas frequentes
"Essa mudança de infraestrutura não tem relação com meu RP. Por que eu deveria fazer isso?"
A equipe do XLA não tem uma equipe de infraestrutura dedicada. Portanto, cabe a todos nós criar bibliotecas auxiliares e evitar dívidas técnicas. Consideramos que ele é uma parte regular das mudanças no XLA, e esperamos que todos participem. Geralmente, criamos a infraestrutura conforme necessário ao escrever o código.
Os revisores do XLA podem pedir que você crie alguma infraestrutura (ou faça uma grande alteração em um RP) junto com um PR que você escreveu. Essa solicitação pode parecer desnecessária ou ortogonal em relação à mudança que você está tentando fazer. Isso provavelmente se deve a uma incompatibilidade entre suas expectativas sobre a quantidade de infraestrutura que você precisa criar e as expectativas do avaliador para isso.
Não há problema em ter uma incompatibilidade de expectativas. Isso é esperado quando você é iniciante em um projeto (e às vezes até acontece com velhos chapéus). É provável que os projetos em que você trabalhou no passado tenham expectativas diferentes. Isso também é normal e esperado! Isso não significa que nenhum desses projetos tenha a abordagem errada, eles são apenas diferentes. Convidamos você a aceitar solicitações de infraestrutura junto a todos os outros comentários de revisão para saber o que esperamos deste projeto.
"Posso abordar seu comentário em uma divulgação futura?"
Uma pergunta frequente com relação a solicitações de infraestrutura (ou outras solicitações grandes) em PRs é se a alteração precisa ou não ser feita no PR original ou se ela pode ser feita como um acompanhamento em uma PR futura.
Em geral, o XLA não permite que os autores de RP abordem comentários de avaliações com um PR de acompanhamento. Quando um revisor decide que algo precisa ser abordado em um determinado RP, geralmente esperamos que os autores a façam isso nesse PR, mesmo que o que for solicitado for uma grande mudança. Esse padrão se aplica externamente e também dentro do Google.
Há alguns motivos para o XLA adotar essa abordagem.
Confiança:conquistar a confiança do revisor é um componente importante. Em um projeto de código aberto, os colaboradores podem aparecer ou desaparecer à vontade. Depois que aprovamos um RP, os revisores não têm como garantir que os acompanhamentos prometidos sejam realmente realizados.
Impacto sobre outros desenvolvedores: se você enviou um PR em uma parte específica do XLA, é muito provável que outras pessoas estejam analisando a mesma parte. Se aceitarmos débito técnico no seu RP, todos que estiverem consultando esse arquivo serão afetados por essa dívida até que o acompanhamento seja enviado.
Largura de banda do revisor:o adiamento de uma mudança para um acompanhamento impõe vários custos aos revisores já sobrecarregados. Os revisores provavelmente vão esquecer do que se tratava o primeiro RP enquanto aguardavam o acompanhamento, tornando a próxima mais difícil. Além disso, os revisores terão que acompanhar os acompanhamentos esperados, garantindo que eles realmente aconteçam. Se a alteração puder ser feita de modo que seja verdadeiramente ortogonal em relação à RP original para que outro revisor possa analisá-la, a largura de banda será um problema menor. Em nossa experiência, isso raramente acontece.