Feel like our bot is missing a feature? We welcome your pull requests!
Label issues are a good initial contributions, and will help get you familiar with the codebase.
Few pointers for contributions:
- Create your PR against the
main
. - New features must be checked with black, isort and pylint (PEP8 compliant), a workflow runs automatically on every PR.
- PR's can be declared as
[WIP]
- which signify Work in Progress Pull Requests (which are not finished).
If you are unsure, discuss the feature in a issue before a Pull Request.
Best start by reading the documentation to get a feel for what is possible with the bot.
Ensure that each pull request meets all requirements in the Contributing document.
If an issue is a bug that needs an urgent fix, mark it for the next patch release. Then either fix it or mark as please-help.
For other issues: encourage friendly discussion, moderate debate, offer your thoughts.
All code changes, regardless of who does them, need to be reviewed and merged by someone else. This rule applies to all the core committers.
Exceptions:
- Minor corrections and fixes to pull requests submitted by others.
- While making a formal release, the release manager can make necessary, appropriate changes.
- Small documentation changes that reinforce existing subject matter. Most commonly being, but not limited to spelling and grammar corrections.
- Ensure cross-platform compatibility for every change that's accepted. Windows, Mac & Linux.
- Ensure no malicious code is introduced into the core code.
- Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
- Keep feature versions as small as possible, preferably one new feature per version.
- Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See the Python Community Code of Conduct (https://www.python.org/psf/codeofconduct/).
Contributors may be given commit privileges. Preference will be given to those with:
- Past contributions to HODLv2 and other related open-source projects. Contributions to HODLv2 include both code (both accepted and pending) and friendly participation in the issue tracker and Pull request reviews. Quantity and quality are considered.
- A coding style that the other core committers find simple, minimal, and clean.
- Access to resources for cross-platform development and testing.
- Time to devote to the project regularly.
Being a Committer does not grant write permission on develop
or main
for security reasons (Users trust HODLv2 with their Exchange API keys).
After being Committer for some time, a Committer may be named Core Committer and given full repository access.