While the following guidelines are not an absolute requirement, writing your code by these standards will ensure greater compatibility with the Ark Ecosystem and increases the likelihood your pull request will be accepted.
Repositories across an organisation should have a consistent basic structure to make it easy to find everything across different repositories.
At a bare minimum a repository should contain the following:
- README.md - Should contain at least a description, installation instructions and a contact address for security issues.
- LICENSE - Should contain the software license of the project, commonly the MIT License for open-source projects.
- .editorconfig - Should contain a configuration that is enforced by everyones editor if an appropriate plugin is installed.
- .gitignore - Should contain a list of files and directories that should not be commited with
- .travis.yml - Should contain a configuration for TravisCI to run tests.
When a new repository is created for a project, the first thing you should do is create a
develop branch and set it as default. This will indicate to developers that this project is not stable yet. This branch should be used until the initial implementation is done, and merged to
master without squashing.
master should then be set as the default branch.
Once the initial implementation is done and merged, only squash merging should be enabled and all future PRs should be squashed with meaningful commit messages.
When working on any project all pull-requests must be squashed.
The goal of doing so first and foremost is to keep PRs small and focused on a single issue. If you think to yourself
all my hard work and organized commits are going to be lost then your PR is most likely out of scope and trying to solve more then one issue at a time which means you should split it up into multiple PRs that are meaningful even after being squashed.
Another benefit of squashing is to have a clean & flat git history which allows to easily blame changes without having to go through 100 commits to finally reach what you were looking for.
We only care about the net effect of the pull-requests, i.e. "feat: wallet integration". We don't care about the 30 commits of "bugfix, added, removed, refactored". We want a clear and concise history without any noise.
How to organize GitHub Issues & Pull Requests
good first issue