How to collaborate

Collaboration rules

Before you start, is necessary that you learn some of the rules for a better understanding of the project and to keep it structured, so that everyone can understand it with ease at any moment in time.

PR reviews approach

All changes will be reviewed for merge by creating pull requests into the project, we don't have yet a PR template, but suggestions are welcome, these PR reviews will be targeting to merge the main branches. For now, the general rule is that it should be reviewed by at least one collaborator to be approved, these rules can be more strict or more specific the more the project grows and also the collaborators in it. For the branch and commit conventions, that is explained on the next section.

Committing changes

For this project, there's some rules to follow, specifically with the branches, in this case, will be using a branching strategy, commonly known as a Git Flow. You can learn more about in detail here and here. We're going to be using 2 main branches:

• main
  • Used for stable versions of the project.
• develop
  • Used for all the changes and additions to the project.

Will be using 4 supporting branches:

• feature
  • Used for all features to add into the project.
• bugfix
  • Used to apply any bugs or issues that arise, but that are not critical to tackle right away.
• release
  • Used to prepare production releases (apply changes into main pretty much).
• hotfix
  • Used to address any bugs and issues that arise but are critical and require to be addressed ASAP (since they come from main), these usually doesn't follow implementation rules, since are pretty much a fast patch, and will be refactored to be clean and understandable further down the road on from develop.

feature, bugfix and release branches come from develop, while hotfix comes from main.

Atomic commits and changes

All branches that bring new additions or changes into the project, will be focusing to be atomic, what this means is that it will focus on 1 and only 1 simple thing, you can learn more about this in detail here

Conventional commits

For every commit that you push, please make sure that it follows the rules for conventional commits, which makes them more readable and easier to understand more about the what has been done. This cause is common to find commits more into the how has been done approach, you can find more about these rules here

Creating Pull Requests

Take into account which type of branch your work is, this is mentioned on the Committing changes section above, and point to the branch that it has to merge.

The title of a PR should be as follows:

type(#issue-number-if-any): Description

• type
  • feat, fix, breaking-change, chore, refactor, docs.
• `#issue-number-if-any
  • Self-explanatory, in case that there's no issue related to it, use N/A.
• Description
  • Self-explanatory, the overall general description of the Pull Request in question.

An example of this would be:

feat(#3): Generate the whole map instead on the fly.

You can see a reference of this here.

Testing branches

For any tests or proof of concepts (POC), it is necessary to create a branch prefixed with poc\.... These branches should not be merged into anything related to the main branch. They are solely for creating tests and should be considered as containing dirty code.