Quer contribuir para o roadmap-cc? Estamos abertos a sugestões, melhorias,
soluções de bugs e qualquer outra contribuição que você tenha a nos apresentar.
Para realizar sua contribuição, entre em contato conosco através de uma
nova issue e siga os passos da sessão de Como sugerir uma nova feature, melhoria ou correçāo de bug?. Essa é a melhor forma
para você nos contactar formalmente, mas também usamos o discord, ferramenta
open source que você pode entrar em contato para ter uma resposta mais rápida
e informal por lá. Contudo, reforçamos que o discord é uma ferramenta de teor
informal, precisamos centralizar todas as issues no repositório para manter
a transparência e coerência das features.
Ao criar uma nova issue, você terá dois templates que poderão ser usados para preencher as informações que esperamos da sua issue. Qualquer informação que ajude a entender melhor sua issue, poderá ser feita nela.
É sugerido que você não implemente sua solução até receber um feedback de um mantedor, pois eles saberão informar se a sua alteração é viável para a versão atual. Para mais detalhes, você poderá checar a sessão de Como contribuir?.
Ao ser avaliado, mantedores irão adicionar as labels que melhor descrevam a sua issue. Temos as seguintes labels que serão utilizadas:
| tags | quando utilizar |
|---|---|
| documentação | precisa melhorar uma documentação |
| bug | funcionalidade está retornando valor inesperado |
| duplicada | já foi sugerida em outra issue |
| codificação | é uma issue que envolve codificar |
| good first issue | é uma issue simples para iniciantes |
| invalido | algo que você acha estar incerto no projeto |
| necessita atenção | poderá ser um problema futuramente |
| projeto | envolve projetar ideias para novas tasks |
| em andamento | quando alguém está resolvendo aquela issue |
| standby | está parada por hora |
| sugestão | poderia ser feito essa melhoria |
| wontfix | alguma interface que não esteja funcionando |
Por fim, um mantedor avaliará a sua issue e verá a possibilidade de executar na versão atual ou congelar sua issue para a próxima versão. Se a issue for adicionada ao projeto, será possível ver ela no taskboard das próximas ações.
O repositório tem a aba issue com as principais atividades que precisamos de contribuição. Se você deseja resolver uma issue, certifique-se que ela não esteja com a label standby. Essa label, indica que a issue não será implementada na versão atual. Verifique, também, se a issue já não está sendo solucionada. Para isso, basta verificar se a tag em andamento está marcada na issue.
Para os iniciantes que quiserem ingressar em alguma issue é recomendado que ele filtre as issues com a tag good first issue. Nela você verá issues mais simples de serem resolvidas.
Para resolver uma issue, pedimos ao contribuidor que crie um fork do repositório como mostra o gif abaixo:
Isso é importante, pois ajuda a movimentar o repositório e ajuda a propagar que você está contribuindo para um projeto open source 😄.
Pedimos que ao iniciar uma resolução de issue, certifique-se que a issue foi marcada com a label em andamento por um mantedor. Assim é possível filtrar as issues que não estão sendo resolvidas.
Ao finalizar sua contribuição, realize o Pull Request para a branch development. Nela mantemos sempre uma versão de desenvolvimento que, ao final das implementações esperadas para aquela versão, será lançada para produção na branch master.
Ao ser avaliado, o PR passará por um revisor do repositório e ele poderá realizar sugestões de melhorias, e, após avaliado, o código passará a fazer parte do repositório.
-
Padronização nos nomes das branchs:
<num_issue>-<breve-descricao-da-issue>
Por exemplo:26-adiciona_readme -
Branchs seguras: Temos duas branchs principais, a
mastere adevelopment.
É a partir da development que criamos as novas branchs as quais desenvolvemos novas features, realizamos correção de bugs e toda a alteração referente a versão atual do repositório. Ao finalizar a modificação que queremos realizar, criamos um pull request para que seja avaliado o código. Só depois de avaliado a alteração vai para a branchdevelopment. Finalmente, quando uma versão do projeto estiver finalizada os próprios maintainers irão mesclar amaster.
Obs: Tomamos essa decisão para garantir que a branch master sempre contenha uma
versão completa, estável e funcional.
Pedimos que realizem as mensagens de commit em português.
Cada versão nossa, tem o seguinte formato:
MAJOR.MINOR.PATCH
Por exemplo: 1.0.0
Alteramos a versão Maior(MAJOR), quando fazemos mudanças incompatíveis na API existente,
Alteramos a versão Menor(MINOR), quando adicionamos funcionalidades mantendo compatibilidade com o que existe,
Alteramos a versão de Correção(PATCH), quando corrigimos falhas mantendo a compatibilidade.
Nos baseamos no SemVer, verifique o link para mais informações.
Para visualizar as versões disponíveis, veja as tags do nosso repositório.