Que bom que você resolveu contribuir conosco. Obrigado! Neste guia vamos explicar como funcionam os nossos processos internos e como podemos trabalhar juntos da melhor forma possível.
Existem diversas formas de contribuir com o projeto:
- Reportando bugs
- Indicando melhorias
- Pedindo recursos
- Discutindo as issues
- Fazendo pull requests
- Outras formas de contribuir
Se encontrou um bug no frontend você pode reportá-lo usando a ferramenta de issues do GitHub. Porém antes de enviar seu bug é importante fazer as seguintes verificações:
- Atualize seu repositório local no branch
mastermais recente. Talvez seu bug já tenha sido corrigido na versão mais recente; - Verifique se o bug já foi reportado por outra pessoa fazendo uma busca pelas issues.
Se o bug realmente não foi resolvido ou acolhido então está na hora de criar uma nova issue. Siga o template fornecido.
Se você encontrou alguma falha de segurança não use as issues para reportar o
bug. Escreva o seu report diretamente para o endereço de e-mail
issuesdesegurana@sme.prefeitura.sp.gov.br . Ele será analisado, validado e corrigido de
acordo com as necessidades. Pedimos que não torne a falha pública para
segurança de todos que utilizam a plataforma em seu estado atual.
Outra ótima forma de contribuir é indicando melhorias ao código e em como ele está estruturado. Se você tem qualquer ideia de como podemos melhorar alguma abordagem na solução de problemas, refatoração de código, melhoria em algum recurso ou qualquer outra coisa relacionada, siga estes passos:
- Certifique-se de que sua ideia já não esteja sendo abordada dentro do conjuntos de issues issues do GitHub;
- Defenda a sua ideia e explique de forma convincente porque ela deve ser
acolhida. Eis algumas questões a considerar:
- Você realmente esta propondo uma ideia só ou um conjunto de ideias?
- Qual é o problema que sua ideia resolve?
- Por que sua sugestão é melhor do que o que já existe no código?
- Realmente vale a pena demandar tempo para implementar sua ideia dentro de nossas prioridades?
Tendo passado pelo crivo de todos estes questionamentos basta criar uma nova issue descrevendo as melhorias e usando o label melhorias.
Tendo em vista o que estamos construindo junto com a comunidade, novos recursos tem baixa prioridade no nosso fluxo. Vale a pena enviar sua sugestão de recurso apenas se:
- O recurso em questão resolve um problema que não é resolvido por nada que já exista no projeto;
- O recurso resolve um problema real validado por pessoas que estão em contato direto com a utilização da plataforma: secretários, gestores, professores, alunos, etc.
Um exemplo de um bom recurso implementado para o i-Educar é o módulo do censo escolar que visa resolver todo o processo de exportação de dados para o censo escolar com apenas alguns cliques, otimizando de forma radical este processo que antes poderia demorar semanas envolvendo o trabalho de muitas pessoas.
Para criar seu pedido de recurso basta criar uma nova issue usando o label recurso.
Antes de partirmos para o código em si é muito importante discutirmos com a comunidade como cada issue será abordada. Toda e qualquer questão deve ser colocada em discussão para que qualquer pessoa que deseje solucionar aquele problema tenha o máximo de informações para executar uma solução.
Idealmente todas as issues devem ter um plano de ação claro antes que qualquer código seja escrito. Sabemos que muitas vezes isto não é possível, sendo necessário explorar e analisar melhor o que foi indicado. Nestes casos, publique todas as suas descobertas nas discussões indicando caminhos e recebendo o feedback da comunidade a respeito do que está sendo proposto.
Issues que estão em processo de discussão devem receber o label discussão indicando que aquela issue precisa dos inputs e feedbacks dos membros da comunidade. Nós te encorajamos a participar o máximo possível mas fique atento ao nosso código de conduta antes de realizar qualquer interação com os outros membros da comunidade.
Depois de ter um plano de ação relativamente claro você deve estar pronto para contribuir com código. Para isso faça um fork do i-Educar e trabalhe em cima de um branch diferente de master implementando suas soluções. Para saber mais sobre pull requests e como eles funcionam, veja este link.
Antes de abrir seu PR (pull request) certique-se que:
- O código realmente resolve um problema real (de preferência baseado em alguma issue levantada);
- Seu PR resolve uma issue apenas. Se você quiser fazer mais de uma coisa, divida em vários PRs;
- Seu código é funcional (ou algo próximo disso). Providencie testes se possível;
- Seus commits englobam bem as funcionalidades desenvolvidas. Evite espalhar o desenvolvimento de um recurso em múltiplos commits;
- Se for inevitável criar vários commits intermediários, por favor execute um squash antes de abrir seu PR;
- As mensagens de seus commits são claras e descrevem bem o trabalho. Para maiores dicas sobre como escrever mensagens de commit adequadas, veja este guia.
Caso seu PR não atenda a uma destas demandas ele poderá ser fechado. Isto inclui PRs que tentam resolver problemas reais mas que contém código cheio de erros ou soluções incompletas. Para que a nossa lista de PRs não fique poluída, dificultando o trabalho de outros membros da comunidade que podem ajudar revisando as mudanças, pedimos que PRs sejam abertos quando sua solução estiver a mais completa possível. Por isso é imprescindível usar a discussão nas issues para a criação de soluções mais assertivas.
PRs que realizam apenas mudanças cosméticas como remoção de espaços em branco, ajustes de indentação, etc., não serão aceitos. Nós valorizamos um código bem escrito e queremos padronizar nossas práticas, mas PRs que não entregarem nenhuma melhoria na estabilidade, funcionalidade, testabilidade do projeto ou compatibilidade com os padrões sendo adotados (PSR-2) serão fechados. Para entender melhor sobre esta decisão veja esta discussão.
Se você não trabalha com código mas quer ajudar existem muitas outras formas de contribuir:
- Ajude com a documentação do projeto nossa wiki;
- Fale sobre o prato aberto e o pátio digital nas suas redes sociais, blogs, etc. Espalhe a palavra;
- Crie material promocional como apresentações, screencasts, mídia para compartilhamento em redes sociais, etc;
- Viu alguma discussão que te interessa e onde você pode acrescentar mesmo sem conhecimento técnico? Não se acanhe e participe também nas issues do GitHub.
Este documento foi escrito com o auxílio de outros documentos similares utilizados em outras comunidades. Destacamos:
... dentre outros!