Pull Request Proposals (PRP)
HBOT token holders have the right to approve all pull requests, or proposed code changes, to the official Hummingbot code repository. All pull requests will only be merged into
development and included in a subsequent release if there is an approved PRP on Snapshot related to it.
Since HGP-10 GC was passed, the current PRP voting period was changed from 4 days pending, 3 days for voting, to 7 days open for voting.
|Proposal Type||Pull Request Proposal|
|Min HBOT Balance to create||1|
|Quorum Percentage||0.1% of HBOT circulating supply|
|Approval Threshold||>50% of tokens approved|
|Vote Duration||7 days|
1. Pull request is created¶
Anyone can submit a new pull request in the Hummingbot repository.
For a pull request to be included in a PRP, it must satisy the following requirements:
- Target the
developmentbranch with no merge conflicts;
- Contain a clear description of what what Pull Request does and why it is needed;
- Enable Allow edits by maintainers;
- Contain unit tests and and they all pass (connectors only);
If the pull request included in a PRP does not meet the requirements described above, the PRP will be removed by Foundation staff.
For more information, see Contribution Guidelines.
2. Proposal is created¶
The next step is to create a proposal on the following Snapshot space: https://snapshot.org/#/hbot-prp.eth. This space is dedicated for Pull Request Proposals (PRP).
The PRP should contain the following information:
- Title: Pull request number and title
Description: Description summary and a link to the pull request in Github
Proposal submitter may promote discussion of the pull request on Discord #governance-chat channels and the Governance Forum
Here is an example of a PRP in Snapshot:
3. Active voting¶
Once the proposal is published, the PRP becomes Active and enables voting for 7 days:
- No code changes should be made to the pull request during this period. A PRP will be considered invalid if the respective Pull Request is changed after it’s creation.
- If the Quorum Percentage (0.1% of the circulating supply) have voted (either directly or via delegation) and the Approval Threshold based on participating votes (currently 50%) is exceeded, the Foundation labels the Github pull request as “approved”;
The Foundation can nullify the proposal if it detects major issues on the pull request. Some examples of what could cause a proposal to be nullified are:
Security issues are detected on the pull request (i.e. exposition of private keys) by the Foundation or any member of the community;
Changes are committed to the pull request that changes the original intent;
Pull request proposed makes the rest of the code unusable or unstable;
Any other major issue with the code.
4. Code merged or rejected¶
If the PRP is approved, the Foundation will attempt to merge the related pull request into the
development branch. During the merge process, the Foundation QA team will test the submitted pull request to ensure that it works properly. If issues are found by the Foundation QA team, the developer will be contacted to fix the problems found before completing the merge.
The Foundation reserves the right to revert an approved pull request if major issues are found during the merge process. In that case, Foundation will publish a public retrospective explaining the reason for this decision.
If the PRP fails to meet the approval thresholds at the end of the Voting Period, it will be rejected. Afterwards, the Foundation will close the related pull request in the Hummingbot repository. However, the developer is free to create a new pull request and a new proposal at a subsequent date.
Development & release cycle¶
After a PRP is approved the Pull Request linked to it will go through the following development cycle, coordinated by the Hummingbot Foundation team:
The Hummingbot code repository has three main branches related to the development cycle of each monthly release:
All pull requests aiming to be included on the
master branch must be targeted to the development branch. They are then promoted from
staging before passing to
master. Pull requests targeting the
development branch will only be merged into
staging only when there is an approved PRP related to it.
staging is used by the Foundation QA team to conduct a thorough test all code changes before adding them to the
master is the main release branch and contains the latest stable version of the Hummingbot software client and is released once per month.
Hummingbot ships a new release approximately every month. Each release is built, tested and released over a two-month cycle that overlaps with the next release.
Month 1: Review and approve¶
During the first month, PRPs approved during this period will be scheduled to be added to the next release. Only PRPs approved before the cutoff date will be added.
Month 2: Test and release¶
During the second month, The Foundation team will merge all remaining PRPs that are approved but not yet merged, merge the
development branch into the
staging branch, and run all tests needed.
A new release can happen anytime during Month 2. There is no fixed date for, and it will heppen as when all approved pull request are merge and the Foundation QA team signs off the new release.