Forneça informações sobre que tipos de contribuições o seu projeto está procurando aqui. Por exemplo, isso pode incluir relatórios de bugs, ajuda para responder perguntas de usuários, melhorias na documentação, correções de bugs e implementações de novas funcionalidades.
Adicione informações sobre como enviar relatórios de bugs aqui. Isso deve incluir dicas sobre que tipo de informações o projeto precisará para reproduzir e corrigir problemas. Também pode incluir informações sobre configurações incorretas comuns que parecem ser bugs.
Inclua também informações sobre o que os colaboradores podem esperar em termos de tempo para a primeira resposta e o processo após isso.
Adicione informações sobre como enviar solicitações de features aqui. Inclua também informações sobre o que os colaboradores podem esperar em termos de tempo para a primeira resposta e o processo após isso.
Inclua informações sobre as melhores práticas de documentação que o seu projeto segue, bem como como criar documentação, verificações a serem executadas e como enviar as alterações feitas de volta para o projeto.
Esta seção deve conter informações sobre
Como acessar o código fonte do projeto;
Layout geral do projeto;
Quaisquer requisitos para o ambiente de desenvolvimento;
Esta seção deve deixar explícito o processo para se tornar um Colaborador Confiável, caso essa opção esteja aberta para os contribuidores.
Esta seção serve como um lembrete para os Trusted Committers existentes e uma explicação para os novos, detalhando como adicionar outras pessoas à equipe anfitriã. Idealmente, essa informação é idêntica para todos os projetos na organização, para que informações centrais possam ser vinculadas a partir daqui.
Como executar o conjunto de testes.
Esta seção deve conter uma breve descrição (3-5 frases) da missão do seu projeto. O objetivo é declarar sobre o que você planeja trabalhar e ajudar os contribuidores externos a entenderem mais ou menos quais tipos de recursos provavelmente serão bem-vindos para este projeto.
Veja também o capítulo de declaração de missão em Producing Open Source Software.
Esta seção deve conter uma breve documentação escrita para usuários iniciantes sobre como começar a usar o projeto. Além disso, documentação mais detalhada pode ser vinculada a partir daqui.
Esta seção pode listar qualquer uma ou todas as seguintes informações:
Uma lista de recursos, casos de uso que o software aborda.
Informações sobre os princípios de design que são usados para resolver compensações.
Links para documentação de nível de usuário mais detalhada.
Esta seção deve conter uma breve documentação sobre como obter ajuda para o projeto como usuário. Isso pode ser tão simples quanto direcionar os usuários para o rastreador de problemas se este for o método que seu projeto deseja usar para responder a perguntas. Também pode apontar para um canal de chat arquivado e pesquisável, alguma lista de discussão arquivada e pesquisável, ou algum fórum online para usuários.
Esta seção deve incluir informações sobre como entrar em contato com o projeto: Tipicamente, isso conterá links para canais de comunicação arquivados, pesquisáveis e linkáveis.
Este é um bom lugar para dar crédito aos Trusted Committers do projeto.
Também é um bom lugar para incluir informações sobre o que significa ser um Trusted Committer para este projeto - embora o ideal seja que todos os projetos em uma organização usem a mesma definição que é vinculada apenas a partir daqui. A razão para manter o link aqui é para que colegas que não têm ou têm pouca experiência em trabalhar e contribuir para projetos InnerSource tenham um link direto de volta para informações em toda a empresa dos projetos tecnológicos necessários para seu trabalho diário.
Esta seção deve documentar (ou vincular à documentação) tudo o que um contribuidor de primeira viagem precisa saber para começar. Normalmente, nem todos os tópicos abaixo serão cobertos. Foque no que difere em seu projeto do setup padrão e no que contribuidores anteriores acharam difícil de entender.
Encontrar o código-fonte.
Encontrar uma lista de problemas para os quais seu projeto precisa de ajuda - esses problemas podem ser técnicos e não técnicos. Geralmente você manterá esses problemas em um rastreador de problemas acessível aos contribuidores.
Links para documentação adicional, por exemplo, sobre a arquitetura do projeto, convenções gerais de codificação, convenções de teste...
Idealmente, você também inclui informações sobre como é o processo preferido para alterações no projeto: Os contribuidores devem primeiro abrir um problema e enviar uma proposta, ou eles podem enviar alterações imediatamente? O que é importante para você ao revisar as contribuições?
Além disso, você deve esboçar quaisquer valores de design que deseja seguir no projeto. Tornar esses valores explícitos frequentemente ajuda a resolver trade-offs mais rapidamente e mais facilmente. Além disso, ajuda a tornar transparentes as alterações em pressupostos anteriormente implícitos.
Com o tempo, você notará que esta seção crescerá substancialmente. Nesse caso, considere mover as informações para arquivos separados, como CONTRIBUTING.md e TESTING.md.
Para contribuições técnicas: Fazer alterações, construir o projeto e testar suas alterações.
Enviar suas alterações de volta para o projeto.