Thanks for your interest in contributing to Fuel Wallet! This document outlines the process for installing dependencies and setting up Fuel Wallet for development, as well as some conventions to improve your contributions.
If you run into any difficulties getting started, you can always ask questions on our Discord.
There are many ways in which you may contribute to the Fuel Wallet project, some of which involve coding knowledge and some which do not. A few examples include:
- Reporting bugs
- Adding new features or bugfixes for which there is already an open issue
- Making feature requests
Check out our Help Wanted or Good First Issues to find a suitable task.
If you are planning something big, for example, related to multiple components or changes current behaviors, make sure to open an issue to discuss with us before starting on the implementation.
This is a rough outline of what a contributor's workflow looks like:
- Make sure what you want to contribute is already tracked as an issue.
- We may discuss the problem and solution in the issue.
- Create a Git branch from where you want to base your work. This is usually master.
- Write code, add test cases where applicable, and commit your work.
- Run tests and make sure all tests pass.
- If the PR contains any breaking changes, add the
breaking
label to your PR. - Push your changes to a branch in your fork of the repository and submit a pull request.
- Use one of the following tags in the title of your PR:
feat:
- A new featurefix:
- A bug fixdocs:
- Documentation only changesstyle:
- Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)refactor:
- A code change that neither fixes a bug nor adds a featureperf:
- A code change that improves performancetest:
- Adding missing tests or correcting existing testsbuild:
- Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)ci:
- Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)chore:
- Other changes that don't modify src or test filesrevert:
- Reverts a previous commit
- Make sure to mention the issue, which is created at step 1, in the commit message.
- Use one of the following tags in the title of your PR:
- Your PR will be reviewed and some changes may be requested.
- Once you've made changes, your PR must be re-reviewed and approved.
- If the PR becomes out of date, you can use GitHub's 'update branch' button.
- If there are conflicts, you can merge and resolve them locally. Then push to your PR branch. Any changes to the branch will require a re-review.
- Our CI system (Github Actions) automatically tests all authorized pull requests.
- Use Github to merge the PR once approved.
Thanks for your contributions!
Pull requests should be linked to at least one issue in the same repo.
If the pull request resolves the relevant issues, and you want GitHub to close these issues automatically after it merged into the default branch, you can use the syntax (KEYWORD #ISSUE-NUMBER
) like this:
close #123
If the pull request links an issue but does not close it, you can use the keyword ref
like this:
ref #456
Multiple issues should use full syntax for each issue and separate by a comma, like:
close #123, ref #456