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.

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.

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.

Notes

The Type: Bug label always has to be combined with a Priority: * and 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.

Bounty tiers need to be assigned before a pull request is merged. If no tier is assigned or is assigned to a team member the ArkEcosystem Bot will comment in the affected issue.

For issues that are tasks a Difficulty: * label should be assigned to provide developers a sense of how much work it will be.

The Complexity: * labels should never be assigned manually as the ArkEcosystem Bot will evaluate the complexity of a pull request and assign a label.

Bounty

Tier 0

Custom reward at the discretion of the team, for large projects or changes.

Tier 1

Awarded for big features, important fixes or significant improvements. This is valued at 100 USD.

Tier 2

Awarded for performance, minor features or substantial documentation changes. This is valued at 50 USD.

Tier 3

Awarded for code refactoring, moderate docs changes or full translations. This is valued at 25 USD.

Tier 4

Awarded for adding test coverage or resolving small bugs. This is valued at 10 USD.

Tier 5

Awarded for small documentation updates or minor code refactoring. This is valued a 5 USD.

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.

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 bounty@ark.io.

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.