Com o #HacktoberFest sendo uma coisa, tem havido um influxo de desenvolvedores tentando desesperadamente contribuir para seus projetos de código aberto favoritos. Infelizmente, muitas dessas solicitações de pull têm sido uma perda de tempo, com os mantenedores incapazes de usar as contribuições. Os mantenedores não querem perder seu tempo revisando PRs ruins, e os colaboradores não querem perder seu tempo escrevendo código que nunca chegará à produção.
Vamos dar uma olhada em algumas armadilhas comuns que os desenvolvedores são vítimas ao trabalhar em um projeto de código aberto. Como uma observação lateral, recentemente abrimos o código-fonte do front-end Qvault , então dê uma olhada nisso se você quiser ajudar.
1. As solicitações de pull devem lidar com uma coisa
Não abra um PR como este:
- Correção do bug # 543
- Adiciona novas regras de linting
- Inclui o recurso # 456
Seu PR deve fazer uma coisa . Pequenas diferenças diminuem a carga cognitiva do revisor e tornam mais fácil colocar seu código no branch principal. Se você tem problemas com vários problemas em um projeto, abra vários PRs.
2. Não quebre a consistência
Este acontece com mais frequência comigo em meus próprios projetos. Desenvolvedores bem-intencionados abrem solicitações pull com qualquer um dos seguintes aborrecimentos:
- Omitindo ponto-e-vírgula em um projeto que os prefere
- Usando espaços em um projeto que claramente usa guias
- Apresentando snake_case em um repo camelCase
Ao contribuir para um projeto existente, use o estilo existente. Ninguém dá a mínima para sua preferência no debate “ tabs vs espaços ” no contexto desta solicitação pull.
Se você acha que o estilo precisa mudar, consulte os pontos 1 e 3.
3. Não comece a trabalhar sem aprovação
Se você entrar em um repositório Github e encontrar algo de que não goste, não abra imediatamente uma solicitação pull. Siga estas etapas:
- Já existe um problema registrado? Se não, faça um.
- Se houver um problema, entre em contato com os mantenedores (apenas comente sobre o problema) e deixe-os saber que você deseja trabalhar nele e dê uma rápida visão geral de como você o tratará.
- Supondo que você tenha a aprovação deles, comece a trabalhar em seu RP.
Isso ajudará a mitigar a criação de PRs inúteis que nunca serão aceitos com base em uma premissa falha.
4. Não reabra problemas / soluções conhecidos
Algumas bases de código têm milhares de problemas abertos, pegue o projeto de linguagem Go ou o repositório nocode como exemplo. Ninguém quer ler sua edição duplicada ou revisar sua solicitação de pull duplicada. Certifique-se de que não haja um problema aberto ou fechado para o que você está tentando resolver.
5. Esmagar esses compromissos
Nem todo projeto exigirá (ou se importará) com a compactação de commits . Dito isso, não há projetos que não exijam a eliminação de commits. Para ficar no lado seguro, dê a eles uma abóbora.
6. Seja significativo
A reformulação da documentação e outras mudanças frívolas fazem você parecer esses idiotas . Este exemplo particularmente atroz não tem apenas como escopo mudanças inúteis na documentação, mas na verdade torna a documentação pior .