Following up on Part 1, this thread uses real-world examples to shed more light on the proposed changes to the Hummingbot Foundation governance process for Epoch 2, starting in August 2022.
In part 1, we outlined proposed changes to make the governance process more flexible, reduce reliance on dedicated maintainers, and give community members more power over the process. Refer to the Miro board for the source of the images below.
Below, we use existing Github issues and pull requests from the Hummingbot repository, as well as discussed proposals with community members, to explain how this revamped process might work.
There are many bugs reported in Github by the community and Foundation QA team alike:
- Order Optimization doesn't work right on Cross-Exchange Market Making strategy · Issue #5437 · hummingbot/hummingbot · GitHub
- Kucoin - Error parsing the trading pair rule · Issue #5423 · hummingbot/hummingbot · GitHub
- Ascendex orders cancelled and no new orders · Issue #5470 · hummingbot/hummingbot · GitHub
In the new proposed process, anyone can create a Github issue with the
bug label. They should also add labels corresponding to the
strategy name and the
cex-connector name and
dex-connector name, if the bug related to a strategy or connector, respectively.
Afterwards, the Foundation will assess all bugs, which entails determining whether it is in fact a real bug and applying a priority label to them. If the issue is a real bug, the Foundation will add the Github issue to the Bounty Board and assign a fixed HBOT amount according to the Bug Bounty Schedule, a document with bounty amounts based on severity and level of effort (LOE).
NOTE: LOE assessments for bugs will be performed by the Foundation in consultation with Review DAO.
NOTE: For bugs, the Foundation proposes that we only undertake the assessment process for Certified Exchanges.
After the bug has been added to Review Board, any developer from the community can apply to be assigned to fix the bug by commenting on the Github issue. Initially, the Foundation will assign bugs, based on the developer’s past experience in general and with Hummingbot in particular. In the future, we aim to decentralize the assignation process by involving the community.
The assigned developer should submit a Github pull request with the fix. The Github PR should reference the bug issue number, describe the fix implemented, and outline steps for QA to test it.
Bug fixes skip the PRP voting process, but they are not automatically merged into the codebase. Instead, they are added to Review Board, where:
- Foundation QA will run tests to assess the fix
- members of Review DAO can self-assign the issue and review the bug on its technical merits.
After the Review DAO approves the fix (which may involve working with the developer on iterations and solving merge conflicts), the Foundation will merge the fix to
development. Afterwards, the Bounty is paid, with % going to the developer, % going to the Review DAO, and % going to the Foundation.
While the new process enables bugs to be fixed without length voting processes, the Foundation believes that community discussion and voting is needed for proposed enhancements, new connectors, and new strategies delivered via a pull request to the Hummingbot codebase.
Here is an example to illustrate how it might work.
In Epoch 1, community member SoothsayerX submitted the pull request above to add additional database dependencies into Docker build script. However, Technical Review DAO did not support the change, and it was unclear what the next step the PR submitter should take.
Under the new process, we would encourage the submitter to first create a forum thread to explain in the motivation behind the proposed improvement in detail, kicking off debate and discussion by the community (for instance Support for external DBs)
In cases like this where the code change is relatively simple and it’s more about whether to make the change or not, if there seems to be a quorum of community members that support the change, the next step would be following the Pull Request process (see Bugs section above( and submitting a Pull Request Proposal.
NOTE: Similar to bugs, the Foundation proposes that we only allocate Foundation resources (i.e. development bounties, extensive QA testing, Review DAO reviews) for issues related to Certified Exchanges.
Many proposed improvements are large, complex, and entail many hours of work by an experienced developer. These are cases where development bounties that compensate the developer for their time are appropriate.
These cases can be divided into 2 categories:
- Harden existing work and merge it into Hummingbot codebase
- Build and contribute new work into Hummingbot codebase
Example: Add Remote Commands Executor Module
Enabling headless mode and controlling Hummingbot instances using 3rd-party modules is one of the most frequently requested features by the community. Long-time community member TheHolyRoger has created a set of components designed to enable this functionality, focused on enabling Hummingbot instances to be controlled by any TradingView PineScript script. Here’s a demo video that he and CoinAlpha solutions engineer Owen created to demonstrate how it works: TradingView Integration with RogerThat Webserver by Owen | Trader Sharing & AMA - YouTube
While the preliminary development work has been done, additional discussion and development work is needed for this code to be merged into the Hummingbot codebase, including:
- Discussion and debate within the community on the architectural merits and maintainability/security implications of this approach vis-a-vis others
- Adding sufficient unit test coverage
- Documentation and in-line code comments
- Other potential changes requested by Review DAO
This additional work is not atypical; generally, many proposed code changes submitted by individual developers need more time/effort to be merged into an widely used open source code base.
In these cases, the Foundation believes that discussion and debate in an forum thread is the best starting point. If there appears to be quorum of community members who support the improvement, anyone can initiate a Hummingbot Improvement Proposal to propose that the Foundation allocate a quantity of HBOT tokens as a bounty, paid to the developer when a pull request containing the improvement is merged into the
If the HIP is approved, the Foundation would assign the developer who did the existing work to complete the work required. If the developer is unavailable, the Foundation would assign the work to another community developer, using Hummingbot development experience as the primary assignation guideline.
After assignation, the process would follow the Pull Requests process above.
Example: XEMM HIP: Auto Rebalancer
In other cases, the proposed improvement is an idea proposed by a community member. For instance, long-time community member Jelle proposed a set of improvements to the Cross-Exchange Market Making strategy. In an informal Discord poll, the Auto-Rebalancer improvement garnered the most votes.
Similar to the Existing work process, a forum thread that enables community discussion and generates enthusiasm for the proposed improvement is the ideal starting point. Afterwards, anyone can create a HIP proposing that the Foundation allocate a quantity of HBOT tokens as a bounty, paid to the assigned developer when a pull request containing the improvement is merged into the
In the case of new work, there is no existing developer, so after the HIP has been approved, the Foundation would add a Github issue specifying the improvement and HBOT bounty to the Bounties Board. Afterwards, any developer can apply to work on the bounty, and the Foundation will assign a developer based on their Hummingbot development experience. In the future, we anticipate shifting to a more decentralized assignation process that entails community voting.
Afterwards, the assigned developer is expected to deliver the improvement as a pull request in a reasonable timeframe. If the developer is uncommunicative or fails to deliver, the Foundation may re-assign the bounty to a different developer. The pull request would follow the Pull Request Process outlined above.
Many improvement proposals come from community members who want to add or improve an existing strategy or add a new exchange connector to the codebase.
Example: new exchange connectors
In particular, Hummingbot Foundation often receives requests from exchanges, both centralized and decentralized, requesting connectors for their exchange to be built and added to the codebase. Often, community members (typically the exchange themselves) are willing to pay a development bounty for building the connector and getting it merged into the codebase.
For a new exchange connector funded by a community member, the process would start with the community member discussing with Foundation staff guidelines for how much bounty is needed to motivate a community developer. This depends on a number of factors, including:
- Exchange type and idiosyncrasies from other exchanges in the codebase
- Quality of exchange API documentation
- Experience level of developer sought
Foundation staff would provide guidance to the bounty funder based on their experience but not control how much bounty amount is funded. Afterwards, the bounty funder sends the bounty amount to a Foundation wallet, and the Foundation adds the bounty to the Bounties board.
Since the development bounty comes from an external 3rd party and not from the Foundation treasury, improvement proposals with a community-funded bounty would skip the HIP process.
Afterwards, the Foundation will undertake the same assignation and pull request approval process as for other bounties.
Hummingbot Foundation may also engage with other DAOs, exchanges, and protocols on larger partnerships. For example, we have started work on a technical partnership with Human Protocol to create on-chain, non-custodial rewards for Hummingbot users who run bots that provide verified liquidity and volume to DEXs: Humming Human: a technical collaboration between Hummingbot and HUMAN Protocol
In cases where HBOT tokens are allocated, for example as matching development grants, the Foundation will propose a Hummingbot Governance Proposal (HGP) that seeks approval from the Hummingbot community to allocate those HBOT tokens.
Overall, Hummingbot Foundation believes that these proposed changes to the governance process make it more decentralized, flexible, and community-oriented. While we expect to continue to iterate on the process, we think it marks a substantial improvement from the process used in Epoch 1.
Below is the timeline for circulating these proposed changes to the broader community and seeking approval via HGPs.
- Community discussion and feedback: July 13 - July 24
- HGP creation: July 24
- HGP voting: July 24 - July 31
- Implementation (if approved): August 1