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 organization 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:
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.
To make everyone's life easier when looking for issues or pull requests of specific types, priority or severity it is important to make proper use of labels so it is possible to identify the status and importance without having to look into it.
Type: Buglabel always has to be combined with a
Severity: *label to indicate how severe the problem caused by the bug is and how many users are affected by it. The combination of those determines how fast the bug needs to be fixed.
Difficulty: *label should be assigned to provide developers a sense of how much work it will be.
Complexity: *labels should never be assigned manually as the ArkEcosystem Bot will evaluate the complexity of a pull request and assign a label.
Has Merge Conflicts
Good First Contribution
Before a developer merges a PR, it is required to assign one of the seven bounty labels. Those labels will be used by the ArkEcosystem Bot to calculate bounty rewards and inform the contributors about those and other activities or requests.
Tier 1 - $100
Tier 1 pull requests cover substantial code changes that usually bring new functionality and have a higher impact on the codebase.
Examples of this include a new API endpoint, resolving structural issues that cause circular dependencies, or adding new bigger features to our codebase (an example would be settings page to the explorer, adding new indenticon package to the desktop wallet or a new small non-essential plugin in the Core).
Tier 2 - $50
This tier covers medium features and improvements to the codebase that bring in new functionality, have a big impact on the performance of the product or significant optimizations and refactors of the code.
An example would be optimizing some parts of the Core for improved performance of a specific function, implementing a medium, non-critical new feature in the desktop wallet or writing large documentation files that require an understanding of the ARK code.
Tier 3 - $25
These pull requests cover smaller refactors or optimizations of the code or small non-essential features.
An example of this would be reducing complexity or improving the performance of existing code, improving the readability of the code or writing new documentation files, full translations of the projects aka desktop wallet or mobile wallet.
Tier 4 - $10
Standard small tier pull requests that fix minor bugs or add a new test.
Examples of this include adding more test coverage for existing functionality or resolving small bugs that usually get reported by users.
Tier 5 - $5
Small documentation updates or improvements that don’t have much code or smaller refactors of the code.
Tier 6 - $1
The lowest tier is for items that don’t usually have much to do with the code, but rather, are considered cosmetics.
An example would be a typo, language corrections, grammar corrections, dependency update, link updates or broken links.
Tier 0 - Custom
If you want to work on much more significant changes or custom projects that you don’t think fit any of the above tiers contact us at email@example.com.
Some examples of what a custom tier 0 could cover — developing new modules for
core that bring in new functionalities (PoW module instead of DPoS), different voting systems, proxy voting, implementing AIPs …
Some issues will also have labels with custom (usually higher) values that you can take on. Labels on those issues will have a defined monetary value, so if you see these available you can request to take point on resolving them. Upon completion and review you will receive payment in ARK.