Epoch 2 proposed governance changes (part 2)

Background

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.

Sample workflows

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.

Bugs

There are many bugs reported in Github by the community and Foundation QA team alike:

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 [80]% going to the developer, [10]% going to the Review DAO, and [10]% going to the Foundation.

Pull Requests

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.

Example: feat/Include drivers for Postgres and MySQL/MariaDB by default by cheemeng · Pull Request #5452 · hummingbot/hummingbot · GitHub

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.

Improvements (Foundation bounty)

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

Existing work

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 development branch.

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.

New work

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 development branch.

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.

Improvements (community bounty)

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.

Larger partnerships

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.

Timeline

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

One of the things I like most in the changes is the opportunity for non-developers to submit a proposed improvement idea.

This may become game changer when experienced traders will propose certain features that can dramatically make Hummingbot more practically useful to other custom trading strategies.

Looking forward for Jelle’s XEMM proposals be implemented soon.

As non-developer myself, I generally get this question in my mind “Is this feature possible, or relatively easy to be implemented in Hummingbot?”

Within Weekly Developer Call, I suggest to allot some few minutes for non-developers to also discuss or ask questions about new or custom features and strategies. Practical answers from experienced devs would help guide us in pursuing the features that we may want implemented.