Como manipulamos solicitações pull na Elastic

A execução de tarefas na Elastic é um esforço colaborativo.

Nossos engenheiros trabalham ininterruptamente (como se espera de uma empresa distribuída) desenvolvendo novos produtos e recursos. Trata-se de um volume insano de trabalho, que exige a máxima atenção aos mínimos detalhes. E mesmo sendo cuidadosos ao extremo, não somos perfeitos, e em qualquer projeto de código-fonte aberto tão complexo quanto os nossos, ainda assim precisamos da ajuda da comunidade para melhorar sempre.

No artigo sobre solução de problemas pequenos porém importantes com a iniciativa «Fix-It Fridays», tratamos de como as contribuições de nossa comunidade são a mola propulsora de nosso sucesso contínuo no desenvolvimento de nossos produtos. Um dos grandes benefícios de sermos um projeto de código-fonte aberto é que temos uma ampla comunidade de desenvolvedores saindo à caça de falhas e ávidos por uma oportunidade de exterminá-las.

Se você for um novo membro na comunidade e quiser enviar sua primeira solicitação pull (PR) ou tiver dúvidas sobre como funciona o processo, veio ao lugar certo! Nesta postagem, vamos dar uma visão geral de como funcionam as solicitações pull para o Elastic, qual é o processo quando recebemos uma e como evitar erros comuns que podem evitar que a sua contribuição seja implementada.

Enfim, como enviar uma solicitação pull?

Antes de enviar uma PR, você precisa criar um fork em um repositório do GITHUB e fazer suas alterações de código. Normalmente isso é feito em sua própria conta do GitHub, que cria uma cópia do repositório de origem para você. Todos os nossos projetos residem em seu próprio repositório do GitHub. Uma lista completa de nossos repositórios está disponível na página de organização do Elastic no GitHub. 

Depois que você criar um fork de um repositório e alterou o código, precisará decidir se quer criar uma PR para fazer push das alterações sugeridas para a ramificação mestre do repositório do produto. Por exemplo, o repositório do Elasticsearch exibido a seguir. Para simplificar, vamos mostrar exemplos do repositório do Elasticsearch ao longo desta postagem.

Quando você clicar em “New pull request” (Nova solicitação pull), aparecerá o nosso modelo de solicitação pull.

Esse modelo conterá orientações que facilitarão a passagem da sua PR pela primeira revisão, por isso leia-o atentamente porque cada produto tem seu próprio conjunto de critérios e documentação. O modelo conterá orientações que facilitarão a passagem da sua PR pela primeira revisão.

Evite a todo custo estes erros comuns durante o envio:

• Envio de duplicatas - Primeiro, procure PRs abertas que já abordem a falha que o seu código está tentando corrigir. Duplicatas normalmente são negadas.
• Não inclusão de testes - Uma PR que inclui alterações de código deve incluir um teste que ilustra o comportamento do novo código. O ideal é que esse teste reproduza o problema que a PR está corrigindo de maneira que falhe sem o código e passe quando o código for aplicado.
• Somente ramificação mestre - Confira se qualquer PR que altere o código foi feita com base na ramificação mestre no diretório relevante.

Depois que você cumprir todos os requisitos descritos no modelo, clique em “Create Pull Requests” (Criar solicitações pull). Agora é com a gente.

Triagem e identificação

Nossa primeira etapa é garantir que a PR cumpra os requisitos de uma boa solicitação (como mencionado anteriormente) e, em caso afirmativo, marcar a PR com uma identificação para que ela caia nas mãos certas para uma investigação mais apurada. As identificações podem ser >bug, >feature etc. Depois que a solicitação pull tiver uma identificação, ela será atribuída à subequipe apropriada para ser manipulada. A partir daí, o tratamento da solicitação será de responsabilidade da equipe encarregada dessa área.

Início do processo

Depois que a PR for identificada, ela será escolhida por um de nossos desenvolvedores. Tentaremos contatar o solicitante assim que possível, e pedimos sua paciência ao enviar a PR porque a manipulação apropriada da solicitação pode demorar devido ao nível e à profundidade das solicitações recebidas sem parar. 

Envio de alterações na documentação

Nota: Também recebemos muitas PRs que modificam ou solicitam alterações em nossos documentos. Esse processo é bem mais simples do que as alterações de código — basta clicar em “edit” (editar) na página de documentos do Elastic, fazer as alterações e enviar a solicitação. Não é necessário aplicar fork em um projeto, nem testes. Identificamos essas PRs como “>doc” e as manipulamos o mais rapidamente possível.

Em geral há mais trabalho a ser feito

Uma PR geralmente precisa ser adaptada antes de estar pronta para ser mesclada. Nesse momento, a PR se torna um espaço colaborativo em que uma discussão é feita, alterações são propostas e mais commits são feitos.

Durante o processo de revisão, executamos testes com base na PR, e os resultados podem ser vistos no GitHub. Às vezes, o teste falha quando as alterações na PR são aplicadas, mesmo se os testes enviados funcionaram. Só que ainda não chegamos ao fim. Vamos ajudar o contribuidor a corrigir o código contribuído para que todos os testes passem.

Estilo de código, assim como convenções de código e nomenclatura, são aspectos que verificamos nesta etapa. Os usuários que enviam solicitações pull devem esperar que seu código passará por pelo menos uma rodada de revisão. O código nunca está perfeito (nem mesmo o nosso!) e pronto para ser mesclado logo que é enviado — por isso espere alguma colaboração pelo caminho.

Quanto tempo levará para fazer commit em minha PR?

As PRs variam no tempo que se leva para manipulá-las. Uma simples linha de código pode ser manipulada rapidamente, mas alterações complexas no código passarão por várias rodadas de revisão. Se você achar que sua PR está parada por muito tempo sem qualquer ação, poderá fazer ping no tíquete como lembrete para que ainda esteja ativa.

Commit do código

Quando tudo estiver pronto, os revisores adicionarão um comentário com a ação de aprovação — que poderá ser um comentário LGTM ("Parece bom para mim") ou outro texto qualquer nessas linhas. Depois que a PR for aceita, um desenvolvedor do Elastic mesclará a solicitação pull com a ramificação mestre e fará a retroportabilidade da alteração para as ramificações de desenvolvimento conforme necessário.

Então, é assim que funciona — de forma resumida. É claro que as solicitações pull variam. O processo pode ser simples ou difícil. A única maneira de conhecer o processo a fundo é arregaçar as mangas e por a mão na massa.

Pronto para enviar sua primeira PR? Dê uma olhada nos repositórios do Elastic disponíveis no GitHub, familiarize-se com as orientações e experimente. Se tiver outras dúvidas sobre o processo, acesse os nossos fóruns de discussão, crie um tópico e teremos prazer em ajudar.