Pular para o conteúdo
codigoaberto.blog

Gerador de CONTRIBUTING.md para o seu projeto

Diga como o projeto recebe ajuda e copie ou baixe o CONTRIBUTING.md pronto, com os comandos de git já escritos com o seu repositório.

CONTRIBUTING completo

Como o seu projeto recebe ajuda

É a única parte obrigatória.

No formato dono/projeto. Entra nos comandos.

Quem contribui
opcional

Comandos, um por linha. Ex.: npm install.

opcional
opcional
Mensagens de commit
Regras do projeto
opcional

Dizer o prazo evita cobrança. Ex.: Costumo responder em até uma semana.

opcional

Discussões, chat, e-mail.

opcional

Se preencher (ex.: MIT), o arquivo diz que as contribuições seguem a licença do projeto. É costume de projetos abertos, sem fonte oficial: confirme com quem entende de licenças.

Suas escolhas ficam só neste navegador, para você não redigitar. Nada é enviado.

O que colocar no CONTRIBUTING.md?

Os passos para criar boas issues e pull requests, como preparar o ambiente e rodar os testes, o padrão de commits e o que esperar da revisão. O gerador monta tudo isso a partir do formulário.

O que o gerador escreve

O arquivo segue os pontos que a documentação do GitHub diz que um CONTRIBUTING deve cobrir: os passos para criar boas issues e pull requests, links para o código de conduta e as expectativas da comunidade. Do guia de boas práticas para mantenedores da Open Source Guides vêm o prazo de resposta e a ideia de que regras escritas tornam as recusas menos pessoais.

As seções são: Antes de começar, Como relatar um problema, Como propor uma mudança, Preparar o ambiente, Conferir antes de enviar, Mensagens de commit, Abrir o pull request, O que acontece depois e, se você marcar, Falhas de segurança e Licença das contribuições. Os comandos de git do arquivo são os mesmos do passo a passo da home, que foram executados em repositórios locais de exemplo.

Duas escolhas ficam por sua conta. A primeira é a licença das contribuições: a frase de que o código enviado segue a licença do projeto é um costume de projetos abertos, sem fonte oficial que tenhamos encontrado hoje regra prática, sem fonte oficial; o campo é opcional. A segunda é o padrão de commits: se o projeto usa Conventional Commits, o arquivo traz três exemplos e o link para a especificação.

Exemplo resolvido: o CONTRIBUTING do listaki

O que foi preenchido
  • Projeto listaki, repositório msouza/listaki, contribuição por fork.
  • Ambiente npm install, estilo npm run lint e testes npm test.
  • Commits no padrão Conventional Commits e issue antes de mudanças grandes.
  • Prazo de uma semana, dúvidas na aba Discussions e código de conduta marcado.

O arquivo sai com nove seções e sem avisos. Os dois comandos do fork saem com o usuário SEU-USUARIO como marcador e msouza como dono do original, que é o que o gerador sabe.

CONTRIBUTING.md

# Como contribuir com listaki Obrigado por querer ajudar. Este guia explica como propor uma mudança em listaki de um jeito que facilita a revisão. ## Antes de começar - Leia o [código de conduta](CODE_OF_CONDUCT.md). Ele vale para issues, pull requests e qualquer conversa do projeto.- Procure nas [issues](../../issues) se alguém já relatou ou propôs a mesma coisa.- Para mudanças grandes (uma funcionalidade nova, uma reorganização), abra uma issue e combine a ideia antes de escrever código. Para um erro de digitação ou um link quebrado, pode ir direto ao pull request. ## Como relatar um problema Abra uma [issue](../../issues/new) com: - o que você esperava que acontecesse e o que aconteceu;- os passos para repetir o problema, do começo ao fim;- a versão do projeto e do sistema que você usa;- a mensagem de erro completa, em texto (não em foto). Dúvidas gerais vão para a aba Discussions; defeitos e pedidos de funcionalidade vão para as issues. ## Como propor uma mudança 1. Faça um *fork* do repositório pelo botão **Fork** do GitHub.2. Clone o seu fork e entre na pasta:    ```bash   git clone https://github.com/SEU-USUARIO/listaki.git   cd listaki   ```3. Aponte o repositório original como `upstream`, para poder buscar as novidades dele:    ```bash   git remote add upstream https://github.com/msouza/listaki.git   ```4. Crie uma branch para a sua mudança (um nome curto que diga o que ela faz):    ```bash   git switch -c nome-da-sua-branch   ``` ## Preparar o ambiente ```bashnpm install``` ## Conferir antes de enviar Rode estes comandos e só envie quando passarem: ```bashnpm run lintnpm test``` ## Mensagens de commit Este projeto usa o padrão [Conventional Commits](https://www.conventionalcommits.org/pt-br/v1.0.0/): `tipo(escopo opcional): descrição`. Exemplos: ```textfix: corrige o link quebrado do READMEfeat(cli): adiciona o filtro por etiquetadocs: explica a instalação no Windows``` ## Abrir o pull request 1. Envie a branch para o seu fork e abra o pull request:    ```bash   git push -u origin nome-da-sua-branch   ```2. Na descrição, diga o que mudou e por quê. Se resolve uma issue, escreva `Closes #número`.3. Mantenha o pull request pequeno e com um assunto só: ele é revisado mais rápido.4. Se a revisão pedir ajustes, faça novos commits na mesma branch e envie de novo; o pull request se atualiza sozinho. ## O que acontece depois Costumo responder em até uma semana. Se passar disso, pode comentar de novo no mesmo pull request. ## Licença das contribuições Ao enviar uma contribuição, você concorda que ela seja distribuída sob a mesma licença do projeto (MIT).
Ler o guia: como escrever um CONTRIBUTING

Como usar o arquivo gerado

  1. Escolha se o projeto recebe contribuições por fork (qualquer pessoa) ou por branch (só quem tem acesso). Os comandos do arquivo mudam conforme a escolha.
  2. Informe o repositório no formato dono/projeto, os comandos de ambiente e de teste e o padrão de commits. Os comandos entram em blocos de código.
  3. Escreva o prazo de resposta e onde tirar dúvidas. Dizer o prazo evita cobrança e deixa claro o que a pessoa pode esperar.
  4. Copie ou baixe o CONTRIBUTING.md e coloque-o na raiz, em docs ou em .github. Depois faça o commit; o passo a passo mostra como.

Perguntas frequentes

Para que serve o CONTRIBUTING.md?

Diz como o projeto quer receber ajuda. A documentação do GitHub afirma que ele ajuda as pessoas a enviar pull requests bem formados e issues úteis e reduz trabalho rejeitado ou refeito. O GitHub mostra um link para o arquivo quando alguém abre uma issue ou um pull request.

Fork ou branch: qual escolher no gerador?

Escolha fork se o projeto recebe contribuições de qualquer pessoa, porque quem contribui não tem permissão de escrita no seu repositório. Escolha branch se só quem tem acesso de escrita contribui, como em um time. O texto e os comandos do arquivo mudam conforme a escolha.

Posso mudar o texto gerado?

Deve. O gerador entrega uma base com as seções mais comuns e os comandos de git já escritos com o seu repositório. Ajuste o que for específico do seu projeto antes de publicar, principalmente prazos e regras que só você sabe.

O que é a licença das contribuições?

É a frase que diz que quem contribui concorda em distribuir o código sob a licença do projeto. É um costume de projetos abertos, sem fonte oficial que encontramos hoje: por isso o campo é opcional e fica desligado. Confirme o texto com quem entende de licenças.

Onde coloco o arquivo gerado?

Na raiz do repositório, em docs ou em .github, com o nome CONTRIBUTING.md. Havendo mais de um, o GitHub procura primeiro em .github, depois na raiz e por último em docs. Com o nome CONTRIBUTING.md, o GitHub mostra ainda uma aba Contributing no repositório.

Fontes desta página

Abertas em 11/10/2026. Nenhuma das páginas mostra data.

  • Setting guidelines for repository contributors (GitHub Docs)
    A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
    O que lemos: O que é o arquivo CONTRIBUTING, onde pode ficar (na raiz, em docs ou em .github; havendo mais de um, o GitHub procura primeiro em .github, depois na raiz e por último em docs), como o GitHub o mostra ao abrir issue ou pull request e o que incluir.
    Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso.
  • Best Practices for Maintainers (Open Source Guides)
    A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0
    O que lemos: Documentar processos (visão, como contribuições são revisadas, prazos), aprender a dizer não com educação, apoiar-se na comunidade (rótulos para iniciantes, dividir responsabilidade), automatizar testes e modelos, e fazer pausas sem culpa.
    Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso.
  • About issue and pull request templates (GitHub Docs)
    A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 4.0 (conteúdo); MIT (código)
    O que lemos: Modelos de issue ficam em .github/ISSUE_TEMPLATE (.md ou formulários em .yml); modelos de pull request podem ficar na raiz, em docs ou em .github; ambos precisam estar na branch padrão.
    Como usamos: Texto próprio em português; os fatos e os comandos vêm da página, sem copiar trechos. Link e data em cada uso.
  • Conventional Commits 1.0.0 (conventionalcommits.org)
    A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 3.0
    O que lemos: As 16 regras numeradas (tipo, escopo, ! , descrição, corpo, rodapés, BREAKING CHANGE), a ligação entre feat e fix e os números MINOR e PATCH do SemVer, a lista de tipos recomendada pelo @commitlint/config-conventional e os exemplos. A versão exibida é a 1.0.0; a página não marca nenhuma versão mais nova.
    Como usamos: As regras são resumidas em português e citadas por número. Os trechos em inglês são curtos, de regras, com a fonte ao lado.

Continue por aqui

Os geradores, o passo a passo e os guias ficam a um clique.