Skip to content
This repository has been archived by the owner on Nov 15, 2022. It is now read-only.

Latest commit

 

History

History
67 lines (40 loc) · 4.62 KB

CONTRIBUTING.md

File metadata and controls

67 lines (40 loc) · 4.62 KB
Raw

Contribuindo para a Vitrine Social

Obrigado por se interessar em contribuir com o Vitrine Social, você pode contribuir em uma das seguintes formas:

  • Notificando um Bug
  • Discutindo sobre melhorias para o fonte
  • Enviando correções
  • Sugerindo melhorias e novas features

Nós trabalhamos usando o GitHub

Toda a gestão do projeto é feita no Github, isso inclui a manutenção do código, o controle de issues e avaliação das sugestões de melhorias (através de pull requests).

Usamos Github Flow

Pull requests são a melhor forma de sugerir mudanças no projeto (usamos o Github Flow). Sua contribuição será bem vinda 😃.

  1. Faça um fork do repositório e crie sua branch a partir da master.
  2. Se adicionou código que precise de testes, crie novos testes.
  3. Se mudou alguma API, atualize a documentação.
  4. Garanta que os testes estão passando.
  5. Tenha certeza que o seu código passa no lint.
  6. Crie o pull request !

Fluxo das Issues / Como Achar Issues para Atuar

Hoje estamos usando as labels e processo do Coderockr Way, elas são diferentes das labels padrões do GitHub, então para evitar confusão na hora de contribuir com uma tarefa, considere as seguintes labels:

  • Stage: Backlog: são issues que acabaram de ser criadas, ou que ainda não foram assumidas por ninguém, caso esteja querendo ajudar implementando uma issue, basta pegar uma com essa label
  • Stage: Analysis e Stage: In progress: são issues que já estão em execução, alguêm está analisando ou codificando ela.
  • Stage: Review: quando é aberto um pull request e o mesmo está pronto para ser avaliado pelos outros membros, a issue estará com essa label. Caso queria ajudar na revisão dos códigos aqui é o lugar.
  • Stage: Testing: depois do merge as issues são movidas para essa etapa, um dos membros irá testar a alteração para identificar se ainda falta algo, ou se pode ser concluída.

Esse fluxo fica mais claro olhando nosso Waffle.

Também classificamos as issues por Category, sendo que uma issue pode estar em mais de uma categoria:

  • Category: Frontend: para issues que devem ser feitas no frontend, normalmente exigindo alterações nos arquivos da pasta frontend e exigindo conhecimento de JavaScript e React.
  • Category: Backend: quando a issue precisa que algo no backend seja feito, alterando os arquivos da pasta server, aqui é necessário ter conhecimento de Go e provavelmente de PostgreSQL.

Além disso tentamos informar qual a dificuldade da tarefa (Level: Easy, Level: Medium e Level: Hard), o tipo (Type: Bug, Type: Improvement e Type: New Feature) e a prioridade (Priority: Lowest, Priority: Low, Priority: Medium, Priority: High e Priority: Highest).

Reporte Bugs pelo Github:Issues

Nós usamos o GitHub:Issues para controlar nossos bugs públicos. Registre um bug abrindo uma nova issue; é fácil.

Padrões de Código

Go (Backend)

Usamos as regras padrões da linguagem Go, para garantir pode executar o comando make lint

JavaScript (Frontend)

Para os fontes em JavaScript estamos usamos ECMA6 com uma extensão do lint do Airbnb, para mais detalhes clique aqui.

Para garantir pode rodar npm run lint dentro da pasta frontend

Atualize a Documentação

Sempre que forem feitas alterações nas APIs, a documentação em api.apib deve ser atualizada.

Após terminar de documentar execute o comando make docs-build para atualizar a documentação e faça um commit com o api.apib e index.html com eles.

Referências

Este documento foi adaptado do seguinte exemplo: briandk/CONTRIBUTING.md