Guideline de contribuição

Neste projeto, estamos usando o Github Flow integrado com o Forking Wokflow.

Preparação

• Faça o fork do projeto.
• Clone o seu projeto
  

$ git clone [email protected]:<github_user>/CocoaHeadsApp.git

• Sincronize o branch master
  

$ git pull origin master

• Adicione o projeto original como upstream remote
  

$ git remote add upstream [email protected]:CocoaHeadsBrasil/CocoaHeadsApp.git

• Atualize a tabela do seu repositório
  

$ git fetch --all

• Sincronize o branch master do projeto original
  

$ git checkout -b cocoaheads/master upstream/master

Desenvolvimento

• Mude para o master do seu fork e crie um novo branch com a sua feature
  

$ git checkout master; git checkout -b feature_name

• Faça todas as alterações necessárias

Publicação

• Quando a feature estiver pronta para publicação, atualize a tabela do seu repositório
  

$ git fetch --all

• Atualize o branch master do projeto original
  

$ git checkout cocoaheads/master; git pull upstream master

• Rebase seu branch master
  

$ git checkout master; git rebase cocoaheads/master

• Push seu branch master para seu fork
  

$ git push origin master

*Caso necessário (uma vez que o histório do git é remodelo no `rebase`), você pode forçar a atualização*
``` $ git push -f origin master ``` - `Rebase` o branch da sua feature
``` $ git checkout feature_name; git rebase master ``` - `Push` o branch da sua feature para seu fork
``` $ git push origin feature_name ```
*Caso necessário (uma vez que o histório do git é remodelo no `rebase`), você pode forçar a atualização*
``` $ git push -f origin feature_name ``` - Crie um novo [`Pull Request`](https://github.com/CocoaHeadsBrasil/CocoaHeadsApp/pull/new/master)

Features do projeto

Todo o desenvolvimento do app está concentrado no github. Portanto, para gerenciá-lo, usamos issues, labels e milestones.

Issues

Workflow

1. Quando uma nova issue é criada, ela entra in review. Assim, os participantes do projeto podem conversar a respeito e colaborar com a proposta.
2. Uma prosposta pode ser negada (Declined) ou transformada em item do backlog do projeto (Onboard).
3. As issues em onboard podem começar a serem desenvolvidas (In progress).
4. Quando o desenvolvimento da feature é completado, o desenvolvedor pode criar um pull request e associar à issue (Waiting PR review).
5. Os demais participantes do projeto podem revisar os pull requests (In PR review).
6. Quando for feito o merge, aquela issue é encerrada (Delivered).

Labels

Progresso

• In review: Propostas que estão abertas para discussão se será implementado ou não
• Declined: Dado as conversas na issue, a funcionalidade/refatoração foi negada (e a issue é fechada).
• Onboard: Proposta que foi "aceita" e pode entrar em uma das milestones do projeto. Nesse ponto, a conversação na issue é bloqueada
• In progess: Issue que está em desenvolvimento por 1 ou mais pessoas (que devem ser associadas à issue)
• Waiting PR review: Uma indicação de que o issue foi finalizada e precisa passar por review de PR.
• In PR review: O PR está sendo avaliado por 1 ou mais pessoas
• Delivered: PR foi aceito (e a issue é fechada)

Informativo

• Code base enhancement: Propostas que visam uma melhor implementação ou estrutura de código
• Product enhancement: Propostas de novas funcionalidades para o produto
• bug: Informar bugs no código
• ci: Propostas de novas funções ou melhorias no sistema de C.I.
• docs: Adição ou melhoria na documentação
• question: Questões sobre o projeo
• easy: Proposta considerada de fácil implementação
• medium: Proposta com dificuldade média
• hard: Proposta de implementação complexa

Milestone

O projeto, hoje, possui os seguintes milestones:

• Integrar API: Integrar a API rails
• Versão de teste: Uma primeira versão do aplicativo, algo que pode ser disponibilizado para beta testers (não precisa ter 100% das funcionalidades)
• 1.0: Coisas que queremos que sejam válidas para uma versão 1.0
• Distribuição: Issues relacionadas à distribuição do app (caso seje relevante)