Development

CONTRIBUTING.md

@@ -1,13 +1,25 @@
-# Política de uso de repositório  
+# Guia de Contribuição  
+
+## Como contribuir?
+
+Para contribuir com o projeto é muito fácil e cada pouquinho conta! Basta seguir os seguintes passos:
+
+* *Fork* do repositório (apenas para usuários externos)
+* Criar [*issues*](CONTRIBUTING.md#política-de-issues)
+* Criar [*branchs*](CONTRIBUTING.md#política-de-branches)
+* Seguir a política de [*commits*](CONTRIBUTING.md#política-de-commits)
+* Submeter [*Pull Request*](CONTRIBUTING.md#política-de-merges-e-pull-requests)
+
 
 ### Política de Issues
 
-As *issues* devem possuir título, descrição, no mínimo um assinante responsável pela execução, *labels* indicando o grupo a quem se destina, a tarefa e *milestone* e *estimated* para as *issues* pontuadas e informar a *sprint* que ela deve ser concluída.
+As *issues* devem possuir título, descrição, no mínimo um assinante responsável, *labels*,  *milestone*(a *sprint* que deve ser concluída) e *estimated*(puntuação) para as *issues* pontuadas.
 
 As Labels usadas no projeto estão descritas no tópico [Labels](https://github.com/fga-gpp-mds/AGR-APP-react-native/labels) no Github.
 
 Para criação de issue o [template Issue](docs/ISSUE_TEMPLATE.md) deve ser seguido.
 
+![Issue Example](/docs/img/issue_example.gif)
 ### Política de Branches  
 
 #### *master*
@@ -24,47 +36,27 @@ merges para *development*</a> .
 
 #### Nome das Branches  
 
-##### X_descricao_da_issue
-
-As branchs de desenvolvimento de features serão criadas a partir da branch *development* com a nomenclatura padrão “X_descricao_da_issue”.
-
-Em casos de issues de features de produção, o nome da  branch deve ser “X_nome_da_issue”.
-
-X representa o código de rastreio da issue.
-Para criar a branch, vá para a *development*:
-
-```
-git checkout development
-```
-
-Depois é só criar a branch e está pronto para produzir!
-
-```
-git checkout -b X_nome_da_issue
-```
+As branchs de desenvolvimento de features serão criadas a partir da branch *development* com a nomenclatura padrão `x_nome_da_issue`, onde o `x` representa o código de rastreio da issue.
 
 ### Política de Commits
 
-Todos os commits devem ser feitos usando o parâmetro `-s` para indicar sua assinatura no commit.
+Os commits devem ser feitos usando o parâmetro `-s` para indicar sua assinatura no commit.
 
 ```
 git commit -s
 ```
-
-A issue em questão deve ser citada no commit, para isso, basta adicionar `#<numero_da_issue ao commit>`.
+A issue em questão deve ser citada no commit, para isso, basta adicionar `#<numero_da_issue>`.
 
 ```
-git commit -sm"#5 Fazendo guia de contribuição"
+ #5 Fazendo guia de contribuição
 ```
 
-![Commit individual](docs/img/commit-individual.png)
-
 ** \*\*Por padrão, o caracter `#` define uma linha de comentário no arquivo da mensagem do commit. Para resolver este problema, use o commando:**
 ```
 git config --local core.commentChar '!'
 ```
 
-<p align="justify">Para commits em dupla deve ser usado o comando `-s` igualmente, e deve ser adicionado a assinatura da sua dupla.
+Igualmente, para commits em dupla deve ser usado o comando `-s` , e deve ser adicionado a assinatura da sua dupla.
 
 ```
 git commit -s
@@ -77,49 +69,69 @@ Signed-off-by: João Henrique Egewarth <[email protected]>
 Signed-off-by: Eliseu Egewarth <[email protected]>
 ```
 
-![Commit pareamento](/docs/img/commit-dupla.png)
+Para que ambos envolvidos no commit sejam incluidos como contribuintes no gráfico de commits do GitHub, basta incluir a instrução `Co-authored-by:` na mensagem:
+
+```
+#5 Fazendo guia de contribuição
+
+Signed-off-by: João Henrique Egewarth <[email protected]>
+Signed-off-by: Eliseu Egewarth <[email protected]>
+
+Co-authored-by: João Henrique Egewarth <[email protected]>
+Co-authored-by: Eliseu Egewarth <[email protected]>
+
+```
+
 
-Para commits que encerram a resolução de uma issue, deve-se iniciar a mensagem do commit com `Fix #<numero_da_issue ao commit>`, para que a issue seja [encerrada automaticamente](https://help.github.com/articles/closing-issues-using-keywords/) quando mesclada na `master`.
+Para commits que encerram a resolução de uma issue, deve-se iniciar a mensagem do commit com `Fix #<numero_da_issue> <mensagem>`, para que a issue seja [encerrada automaticamente](https://help.github.com/articles/closing-issues-using-keywords/) quando mesclada na `master`.
 
-Exemplo do comentário do commit:
+Exemplo de comentário do commit:
 ```
-git commit -sm"Fix #5 Finalizando guia de contribuição do projeto"
+Fix #5 Finalizando guia de contribuição do projeto
+```
+
+Para commits que incluem uma pequena mudança em uma issue que já teve sua resolução encerrada, deve-se iniciar a mensagem do commit com `HOTFIX #<numero_da_issue> <mensagem>`
+
+Exemplo de comentário do commit:
+```
+HOTFIX #5 Atualizando guia de contribuição do projeto
 ```
 
 ### Política de Merges e Pull Requests
 
 #### Pull Requests
 
-Os pull requests externos devem ser feitos apenas para a branch development seguindo as regras e os passos do tópico Merges para development. No conteúdo do pull request deve haver uma descrição clara do que foi feito.
-
-Para a equipe interna, os pull requests seram realizados em duas situações, para *development* e para *master* seguindo as regras e passos de merge para ambas branchs.
+Pull requests devem ser feitos para a branch *master* seguindo as regras e os passos do tópico [*Merges para master*](CONTRIBUTING.md#merges-para-master). No conteúdo do pull request deve haver uma descrição clara do que foi feito.
 
-Para ambos os casos deve ser seguido o [template Pull Request](docs/PULL_REQUEST_TEMPLATE.md).
+Deve ser seguido o [template Pull Request](docs/PULL_REQUEST_TEMPLATE.md).
 
 ##### Work in Progress
 
-Caso haja a necessidade de atualizar a branch development antes de concluir a issue, o nome do pull request deve conter WIP:<X_nome_da_branch> para que a branch não seja deletada.
+Caso haja a necessidade de atualizar a branch *master* antes de concluir a issue, o nome do pull request deve conter WIP:<X_nome_da_branch> para que a branch não seja deletada.
 
-#### Merges para development
-Os merges para development deverão ser feitos quando a funcionalidade ou refatoração estiverem de acordo com os seguintes aspectos:  
+#### Merges para *master*
+Os merges para *master* deverão ser feitos quando a funcionalidade ou refatoração estiverem de acordo com os seguintes aspectos:  
 - Funcionalidade ou refatoração concluída;
 - *Build* do Travis passando;
-- Testes feitos;
+- Progredir ou manter a porcentagem de cobertura de teste;
 - Funcionalidade revisada por algum outro membro.
 
-Para fazer um merge para *development* os passos a serem seguidos são:  
+Para fazer um merge para *master* os passos a serem seguidos são:  
 - `git checkout branch_de_trabalho`;
-- `git pull --rebase origin development`;
+- `git pull --rebase origin master`;
 - `git push origin branch_de_trabalho`;
 - Abrir pull request via interface GitHub;
 - Aguardar Code Review
 
-#### Merges para *master*
-Os merges para *master* deveram ser feitos apenas após o término da sprint, quando todas as funcionalidades estiverem entregues. O merge deve ser feito a partir da *development* e apenas quando atingir os seguintes critérios:
-
-- Build Travis passando;
-- Sprint dada como concluída.  
 
 ##### Code Review
 O code review deve ser feito por um ou mais membros da equipe que não participaram das modificações.
 Após pelo menos uma aprovação de Code Review, Status Check (Travis, CodeClimate) o PullRequest poderá ser aceito;
+
+Para aceitar o PullRequest, deve-se usar a opção *merge* no Github.
+
+![Merge](/docs/img/merges.png)
+
+#### Tag's
+
+<!-- Explicar tag's -->

docs/issue_template.md

@@ -1,29 +1,50 @@
 # Issue Template
 
 Uma issue deve ser criada com a finalidade de descrever:
- - Uma tarefa do projeto
- - Um requisito do produto (Feature)
- - Uma nova funcionalidade do produto (Estória de usuário)
- - Um defeito no produto (bug, inconsistência com um requisito já entregue)
+ - Uma tarefa do projeto;
+ - Um requisito do produto (Feature);
+ - Uma nova funcionalidade do produto (Estória de usuário);
+ - Um defeito no produto (bug, inconsistência ou documento que necessite de atualização ou correção).
 
-### Nome da issue
-O nome da issue deve conter uma breve descrição sobre o problema a ser resolvido.
+### Nome da *issue*
 
-### Conteúdo da issue
-O conteúdo da issue deve conter uma descrição detalhada explicando a finalidade para a qual aquela issue foi criada.
+O nome da *issue* deve conter uma breve descrição sobre o problema a ser resolvido e deve ser entitulado no infinitivo.
 
-### Outros campos
-As issues devem estar devidamente organizadas nos seguintes campos adicionais:
- - Pipeline
- - Assignees
- - Labels
- - Milestone
- - Estimate
+### Conteúdo da *issue*
 
+Descrever o que será resolvido e informar atividades necessárias para conclui-la.
 
-Veja um exemplo de issue [aqui neste link](https://github.com/fga-gpp-mds/AGR-APP-react-native/issues/19)
+```
+Nessa issue será realizado:
+- tarefa 1
+- tarefa 2
+- tarefa 3
 
-![Issue Example](/docs/img/issue_example.gif)
+Critérios de aceitação:
+- critério 1
+- critério 2
+- critério 3
 
-### Requisitos
-Para ser uma issue válida, deve ter como conteúdo alguma das finalidade listadas acima e estar de acordo com as politicas de uso do repositório.
+```
+
+### *Pipeline*
+
+Classificar na fase:
+- Product Backlog caso seja de código;
+- Project Backlog caso seja de documentação;
+- Sprint Backlog caso a issue esteja priorizada para sprint;
+- In Progreess caso esteja em desenvolvimento;
+- Code Review caso necessite de revisão de código.
+
+### *Labels*
+
+Você pode utilizar as [*labels*](https://github.com/fga-gpp-mds/AGR-APP-react-native/labels) para organizar as *issues* e *Pull Requests*.
+
+
+### *Milestone*
+
+Selecionar a sprint que a issue é referente.
+
+### *Estimate*
+
+Estimar a pontuação da issue entre 0-21 seguindo a sequência de Fibonacci.

dulce/.babelrc

@@ -0,0 +1,3 @@
+{
+  "presets": ["react-native"]
+}

dulce/.buckconfig

@@ -0,0 +1,6 @@
+
+[android]
+  target = Google Inc.:Google APIs:23
+
+[maven_repositories]
+  central = https://repo1.maven.org/maven2

dulce/.flowconfig

@@ -0,0 +1,54 @@
+[ignore]
+; We fork some components by platform
+.*/*[.]android.js
+
+; Ignore "BUCK" generated dirs
+<PROJECT_ROOT>/\.buckd/
+
+; Ignore unexpected extra "@providesModule"
+.*/node_modules/.*/node_modules/fbjs/.*
+
+; Ignore duplicate module providers
+; For RN Apps installed via npm, "Libraries" folder is inside
+; "node_modules/react-native" but in the source repo it is in the root
+.*/Libraries/react-native/React.js
+
+; Ignore polyfills
+.*/Libraries/polyfills/.*
+
+; Ignore metro
+.*/node_modules/metro/.*
+
+[include]
+
+[libs]
+node_modules/react-native/Libraries/react-native/react-native-interface.js
+node_modules/react-native/flow/
+node_modules/react-native/flow-github/
+
+[options]
+emoji=true
+
+module.system=haste
+
+munge_underscores=true
+
+module.name_mapper='^[./a-zA-Z0-9$_-]+\.\(bmp\|gif\|jpg\|jpeg\|png\|psd\|svg\|webp\|m4v\|mov\|mp4\|mpeg\|mpg\|webm\|aac\|aiff\|caf\|m4a\|mp3\|wav\|html\|pdf\)$' -> 'RelativeImageStub'
+
+module.file_ext=.js
+module.file_ext=.jsx
+module.file_ext=.json
+module.file_ext=.native.js
+
+suppress_type=$FlowIssue
+suppress_type=$FlowFixMe
+suppress_type=$FlowFixMeProps
+suppress_type=$FlowFixMeState
+
+suppress_comment=\\(.\\|\n\\)*\\$FlowFixMe\\($\\|[^(]\\|(\\(<VERSION>\\)? *\\(site=[a-z,_]*react_native[a-z,_]*\\)?)\\)
+suppress_comment=\\(.\\|\n\\)*\\$FlowIssue\\((\\(<VERSION>\\)? *\\(site=[a-z,_]*react_native[a-z,_]*\\)?)\\)?:? #[0-9]+
+suppress_comment=\\(.\\|\n\\)*\\$FlowFixedInNextDeploy
+suppress_comment=\\(.\\|\n\\)*\\$FlowExpectedError
+
+[version]
+^0.65.0

dulce/.gitattributes

@@ -0,0 +1 @@
+*.pbxproj -text

dulce/.gitignore

@@ -0,0 +1,53 @@
+# OSX
+#
+.DS_Store
+
+# Xcode
+#
+build/
+*.pbxuser
+!default.pbxuser
+*.mode1v3
+!default.mode1v3
+*.mode2v3
+!default.mode2v3
+*.perspectivev3
+!default.perspectivev3
+xcuserdata
+*.xccheckout
+*.moved-aside
+DerivedData
+*.hmap
+*.ipa
+*.xcuserstate
+project.xcworkspace
+
+# Android/IntelliJ
+#
+build/
+.idea
+.gradle
+local.properties
+*.iml
+
+# node.js
+#
+node_modules/
+npm-debug.log
+yarn-error.log
+
+# BUCK
+buck-out/
+\.buckd/
+*.keystore
+
+# fastlane
+#
+# It is recommended to not store the screenshots in the git repo. Instead, use fastlane to re-generate the
+# screenshots whenever they are needed.
+# For more information about the recommended setup visit:
+# https://docs.fastlane.tools/best-practices/source-control/
+
+*/fastlane/report.xml
+*/fastlane/Preview.html
+*/fastlane/screenshots

dulce/.watchmanconfig

@@ -0,0 +1 @@
+{}