Etiqueta básica para projetos open source

Antes de você começar a contribuir para um projeto open source, se pergunte o motivo de você querer fazer isso. Está tudo bem se a resposta para esta pergunta for só "Estou entediado e quero achar algo produtivo para fazer com meu tempo", mas você provavelmente consegue ir mais fundo que isso.

Razões ainda melhores podem incluir:

• Eu uso esta ferramenta o tempo todo e encontrei um bug nela/quero ajudar a melhorá-la.
• Quero ajudar outras pessoas a usar a ferramenta com mais sucesso.
• Quero ajudar outras pessoas a contribuir com o projeto com mais sucesso.
• Quero melhorar minhas habilidades.
• Quero demonstrar minhas habilidades publicamente como parte do meu curso da faculdade ou universidade.
• Quero demonstar minha habilidades publicamente para aumentar minhas chances de conseguir um emprego.

Algumas destas razões são egoístas, e está tudo bem — se você passar o seu tempo trabalhando em um projeto de graça, então é justo esperar conseguir algo disso. Além disso, ter razões claras para contribuir vão facilitar a escolha de no que trabalhar primeiro.

Algumas razões não tão boas para começar a contribuir:

• Quero alguém para conversar.
• Quero algumas pessoas para trollar/mandar.
• Quero mostrar o quão incrível eu sou.

Sua presença no projeto deve ser produtiva, e não deve impedir que as outras pessoas também sejam.

Nós poderíamos abreviar isto para "seja gentil". Este é nosso conselho número um para qualquer um que esteja começando a contribuir com projetos open source.

Seja gentil com os outros contribuidores, e este será um lugar mais feliz e produtivo. Isto inclui:

• Agradeça as pessoas se elas te ajudarem.
• Parabenize as pessoas quando for apropriado (por exemplo, se elas enviarem seu primeiro pull request, ou corrigirem um bug difícil)
• Sempre responda as pessoas de forma respeitosa, mesmo se você sentir que a resposta a pergunta delas seja um pouco óbvia, ou que elas estejam sendo repetitivas.
• Tente ajudar as pessoas a serem melhores na próxima vez, de forma solidária, e.g. durante revisões de pull requests ou quando você estiver respondendo perguntas. Dizer "isto está errado" ou "aqui está a resposta" nem de longe ajuda tanto quanto dizer "Isto está bom, mas acho que seria melhor se você tentasse fazer isso dessa forma, aqui está uma postagem de blog com mais ideias" ou "você pode achar a resposta aqui; também dê uma olhada neste link para respostas mais comuns"

Você e outros contribuidores estão (ou deveriam estar) aqui porque querem fazer contribuições positivas ao projeto, mas, além disso, você não pode assumir nada sobre eles. Isto inclui:

• Conhecimento do projeto e tecnologias usadas para construí-lo
• Gênero, sexualidade, idade, línguas faladas, localização, viés político, religião, ou outros atributos pessoais
• Experiências com projetos open source
• Confiança
• Expectativas
• Senso de humor

Portanto, você deve manter o que escreve o máximo possível dentro do assunto, se afastando de possíveis controvérsias de assuntos não relacionados como religião ou política, e ser solidário e respeitoso mesmo se você discorda de alguém, ou não gosta da decisão que eles fizeram.

Você também deve evitar qualquer xingamento / linguagem ofensiva no MDN, mesmo se não for direcionado a alguém específico. Isso não é necessário para a participação, e algumas pessoas são realmente sensíveis a isso.

Esteja ciente de que existem regras em qualquer OSP para proteger seus contribuidores de se sentirem desconfortáveis enquanto contribuem. Isto geralmente vem na forma de um arquivo CODE_OF_CONDUCT.md no GitHub.

Por exemplo, os repositórios do MDN são governados pelas amplas Diretrizes de participação na comunidade Mozilla. Geralmente, comportamento ligeiramente ofensivo nos repositórios do MDN (Tal qual constantemente estar fora do assunto, ser perturbador ou ser rude) geralmente será respondido com um aviso do repositório, seguido de um aviso final, e então um banimento temporário ou permanente. Problemas comportamentais mais sérios como discurso de ódio ou ameaças contra outro contribuidor não serão tolerados e, provavelmente, resultarão em um banimento instantâneo.

Se você receber qualquer coisa que faça você se sentir desconfortável, você sempre deve reportar usando os mecanismos fornecidos no código de conduta.

Pense sobre o que você quer fazer no projeto. Por exemplo, nós temos uma longa lista de issues(problemas) arquivada em https://github.com/mdn/content/issues, dividida por vários rótulos no GitHub com tempo estimado para corrigir, categorias de tecnologia, e mais. Um bom rótulo para procurar é o "good first issue" (Bom primeiro problema), que, no geral, são issues simples e boas para iniciantes começarem. Em breve, nós vamos começar a fazer uma triagem mais ampla de nossos problemas, adicionando novos rótulos como indicadores de prioridade. Tente escolher algumas issues que você ache que consegue lidar no tempo que você tem disponível, e peça para ser atribuído para elas.

Você também pode contribuir abrindo pull requests para resolver problemas com os quais você se deparou enquanto estava lendo os artigos do MDN.

Muito trabalho no MDN se resolve escrevendo documentação e exemplos de código, mas existem outras formas de contribuir também:

• Ajudar a triar issues que aparecerem.
• Ajudar a corrigir erros de digitação.
• Ajudar a melhorar a gramática e fazer as páginas serem mais compreensíveis.
• Ajudar a mentorar pessoas que estão tentando corrigir erros.

Toda correção é útil, não importa o quão pequena seja, e nós não iremos descartar nenhuma correção. No entanto, tente fazer com que as correções sejam produtivas. Nós gostaríamos de desaconselhar estes tipos de contribuições:

• Atualizar o estilo de código só porque "você gosta mais desse estilo".
• Atualizar o estilo de escrita só porque "você gosta mais desse estilo".
• Trocar páginas de Inglês Americano para Inglês Britânico.
• Adicionar ou remover um monte de pontuações quando na verdade não tem nada errado.
• Trocar o framework de testes que nós estamos usando por outro porque você prefere.

Em muitos casos, as coisas são como são em um OSP por uma razão. Você deve ler os guias de estilos deles se exitirem, e se você duvida que algo seja produtivo, sempre pergunte primeiro!

Bons OSPs sempre irão disponibilizar a documentação do contribuidor. Em nossos projetos no GitHub, geralmente está em um arquivo CONTRIBUTING.md no repositório, ou, as vezes, em um arquivo README.md no projeto. Sendo um projeto de documentação, o conteúdo do MDN tem um README e um bom conjunto de docs de contribuidor no site em si (veja Contribuindo para o MDN).

Não tenha medo de pedir ajuda, mas SEMPRE tente achar a resposta antes de perguntar. Desta forma você vai construir seu conhecimento do projeto e se tornar mais independente, e não sobrecarregue desnecessariamente os outros colaboradores.

Naturalmente, os docs não serão sempre perfeitos. Se for difícil encontrar uma explicação ou ela não estiver bem descrita, crie uma issue, ou crie um pull request para tentar corrigir isso você mesmo.

Sempre descubra onde é o melhor lugar para perguntar. Bons OSPs sempre irão deixar isso claro em seus docs (veja peça ajuda no MDN). Se você tiver dúvidas gerais, então use estes canais. Não crie uma issue no GitHub apenas para fazer uma pergunta, já que isso gera ruídos no projeto (veja "Faça progresso, não ruído" abaixo).

Pense com cuidado sobre como você lida com a comunicação no projeto — tenha certeza de que é útil, e que não faz o trabalho de outro contribuidor mais difícil. Submeter pull requests para corrigir bugs é ótimo, mas eles são realmente úteis e fáceis de revisar? Tudo bem registrar issues e se juntar a outras conversas, mas suas issues e comentários estão dentro do assunto ou só estão gerando ruído?

Como regra, faça:

• Discutir um tópico por issue — é mais fácil para manter as issues focadas e produtivas.
• Corrija uma issue por PR — pode ser um pouco mais de trabalho para você, mas é muito mais simples de revisar uma única correção.
• Contribua em outros tópicos se você tiver algo importante para apontar ou se você consegue responder a pergunta de alguém.
• Faça perguntas usando outros mecanismos como chat ou fóruns se você não tem certeza se algo é útil ou se tem uma pergunta simples.
• Leia o manual para tentar responder a questão você mesmo antes de perguntar.

Não:

• Complique issues tentando discutir múltiplos tópicos de uma vez, ou fazendo comentários fora do assunto.
• Tente abarrotar um único pull request com várias correções. Isso torna a revisão mais difícil, e cria suspeitas (algumas pessoas podem achar que você está tentando esconder algum código malicioso entre as alterações válidas).
• Abra várias issues fazendo perguntas vagas.
• Faça perguntas sem tentar resolver o problema sozinho antes.

OSPs são bem democráticas — muitas decisões são votadas, e você é amplamente livre para contribuir como desejar, contanto que você não impeça outros de contribuir.

Contudo, algumas coisas serão amplamente decididas por um grupo pequeno de contribuidores principais. Você está livre para se opor a qualquer decisão, mas, as vezes, um moderador vai tomar uma decisão que vai contra sua opinião. Você precisa respeitar e aceitar estas decisões.

É útil conhecer alguns moderadores do projeto, então você saberá quem é o melhor para pedir ajuda, por exemplo com pull requests ou discussões em issues.

Tenha em mente que muitas pessoas trabalhando em OSPs estão fazendo isso em seu tempo livre, sem pagamento, e todas as pessoas trabalhando em OSPs são, no geral, bem ocupadas. Se você está esperando por algo como uma revisão no seu pull request, ou uma resposta para sua pergunta, seja paciente.

É razoável esperar alguns dias e então chamar alguém de forma educada para perguntar se eles tiveram tempo de olhar isso. Se acontecer deles estarem ocupados, pode ser melhor esperar mais uma semana e então tentar falar com eles.

NÃO É razoável começar a exigir coisas, como uma resposta rápida.

Se alguém está esperando que você faça algo por eles, você deveria demonstrar a mesma cortesia, mas, ao mesmo tempo, tentar responder o quão prontamente você conseguir. Se você realmente não conseguir encontrar tempo, os avise e peça para que os mantenedores ajudem a encontrar alguém para fazer a tarefa.

• Como contribuir para o open source
• Lista mais geral do freeCodeCamp "Como contribuir para o open source"
• Começando a contribuir para o open source (en-US)