github.com/mundipagg/boleto-api@v0.0.0-20230620145841-3f9ec742599f/CONTRIBUTING.md (about)

     1  # Contributing
     2  
     3  Este repositório contém informações de como será a política do time One em relação as branches e mensagens de commit, por favor leia antes de começar a utilizar nossos repositórios.
     4  
     5  ## Índice
     6  
     7  [Como eu posso contribuir?](#como-eu-posso-contribuir)
     8  
     9    * [Reportando Bugs](#reportando-bugs)
    10    * [Fluxo de Desenvolvimento](#fluxo-de-desenvolvimento)
    11    * [Fluxo Git](#fluxo-git)
    12    * [Pull Requests](#pull-requests)
    13    * [Pull Request Labels](#pull-request-labels)
    14  
    15  [Styleguides](#styleguides)
    16    * [Git Commit Messages](#git-commit-messages)
    17  
    18  ## Como eu posso contribuir?
    19  
    20  ### Reportando Bugs
    21  
    22  Esta seção mostra como reportar um bug para o BoletoConciliationService. Seguir estes _guidelines_ ajuda o time a entender o seu _report_ :pencil: e reproduzir o comportamento :computer: :computer:.
    23  
    24  Antes de criar um bug report verifique [esta lista](#antes-de-reportar-um-bug). Quando for criar um novo _report_ de bug, inclua [a maior quantidade de detalhes possíveis](#como-eu-crio-um-bom-report-de-bug) por favor. Preencha [o template](#template-for-submitting-bug-reports) para facilitar na resolução dos bugs.
    25  
    26  #### Antes de reportar um Bug
    27  
    28  * Verifique se ele já existe no [quadro de tarefas](https://mundipagg.visualstudio.com/MundiPagg/_backlogs/board/Backlog%20items).
    29  
    30  #### Como eu crio um (Bom) report de Bug?
    31  
    32  Bugs são rastreados como PBI's no quadro de tarefas e basicamente devem possuir uma descrição e um critério de aceite. Opcionalmente, pode-se anexar arquivos que possam auxiliar no entendimento do bug.
    33  
    34  Explique o bug e inclua detalhes adicionais para ajudar na reprodução do problema:
    35  
    36  * **Use um título claro e descritivo** no PBI para a identificação do problema.
    37  * **Descreva os passos exatos que reproduzem o problema** com o máximo de detalhes possível. 
    38  * **Se possível, forneça exemplos específicos para reproduzir os passos**. Inclua links ou arquivos que mostrem onde o problema ocorre.
    39  * **Descreva o comportamento observado após seguir os passos** e aponte exatamente qual o problema nesse comportamento.
    40  * **Explique qual era o comportamento esperado e o por quê.**
    41  
    42  * **Se possível, inclua evidências do erro no SEQ**
    43  
    44  ### Pull Requests
    45  
    46  * Siga os styleguides de código.
    47  * Verifique se todos os testes estão passando.
    48  * Siga o padrão das mensagens de commit.
    49  * No **Título** descreva sucintamente o que o pull request representa, seguido de um dos labels adequados, descritos [aqui](#pull-request-labels).
    50  * Na **Descrição** documente a alteração de acordo com o styleguide:
    51   
    52    - `O que foi feito?`
    53    - `Por que foi feito?`
    54    - `Como foi feito?`
    55    
    56  - Coloque como **Reviewers** o time `MundiPagg Team`, assim todos os membros do time serão selecionados.
    57  
    58  **Exemplo:**
    59  
    60  ```
    61  Title:      [#bug] Correção de erros de validação no login
    62  
    63  Description:  
    64          O que foi feito?
    65            
    66          - Corrige login.
    67          - Implementa validação de campos no login.
    68  
    69          Por que foi feito?
    70            
    71          - Quando se tentava logar com informações erradas a página estava 
    72          recarregando desnecessariamente.
    73  
    74          Como foi feito?
    75  
    76          - No momento do login, no estado não autorizado, foi retirado o
    77           URIEncoded (responsável pelo problema).
    78  ```
    79  
    80  ### Pull Request Labels
    81  
    82  Essa seção lista as labels (etiquetas) usadas na mensagem de pull request.
    83  Cada label representará uma seção no changelog, seguida da mensagem commit dos pull requests que descreverá a alteração.  
    84  
    85  | Label |  Description |
    86  | --- | --- |
    87  | `enhancement` |  Feature nova ou melhorias |
    88  | `bug` | Correção de bugs |
    89  |`documentation`| Adição/alteração de documentação |
    90  | `fire` |  Remoção de código |
    91  
    92  ## Styleguides
    93  
    94  ### Git Commit Messages
    95  
    96  * Use o presente imperativo ("Adiciona feature" não "Adicionada feature"). Dica: pense na ação que o commit está realizando
    97  * Limitar a primeira linha a 72 caracteres ou menos
    98  * Considere iniciar a mensagem de commit com um emoji que se aplique:
    99  
   100  | Código                | Emoji               | Descrição                                       |
   101  |-----------------------|---------------------|-------------------------------------------------|
   102  | `:art:`               | :art:               | when improving the format/structure of the code |
   103  | `:racehorse:`         | :racehorse:         | when improving performance                      |
   104  | `:non-potable_water:` | :non-potable_water: | when plugging memory leaks                      |
   105  | `:memo:`              | :memo:              | when writing docs                               |
   106  | `:checkered_flag:`    | :checkered_flag:    | when fixing something on windows                |
   107  | `:bug:`               | :bug:               | when fixing a bug                               |
   108  | `:fire:`              | :fire:              | when removing code or files                     |
   109  | `:green_heart:`       | :green_heart:       | when fixing CI build                            |
   110  | `:white_check_mark:`  | :white_check_mark:  | when adding tests                               |
   111  | `:lock:`              | :lock:              | when dealing with security                      |
   112  | `:arrow_up:`          | :arrow_up:          | when upgrading dependencies                     |
   113  | `:arrow_down:`        | :arrow_down:        | when downgrading dependencies                   |
   114  | `:shirt:`             | :shirt:             | when removing linter warnings                   |
   115  | `:bulb:`              | :bulb:              | new idea                                        |
   116  | `:construction:`      | :construction:      | work in progress                                |
   117  | `:heavy_plus_sign:`   | :heavy_plus_sign:   | when adding feature                             |
   118  | `:heavy_minus_sign:`  | :heavy_minus_sign:  | when removing feature                           |
   119  | `:speaker:`           | :speaker:           | when adding logging                             |
   120  | `:mute:`              | :mute:              | when removing logging                           |
   121  | `:facepunch:`         | :facepunch:         | when resolving conflicts                        |
   122  | `:wrench:`            | :wrench:            | when changing configuration files               |
   123  
   124  [:arrow_left: Voltar](README.md)
   125      
   126  
   127  # Como lidar com o problema de import path em Projetos Go
   128  
   129  A solução para este problema está [aqui](http://code.openark.org/blog/development/forking-golang-repositories-on-github-and-managing-the-import-path)