Introduction
As mentioned in this thread, Hummingbot Foundation has been reviewing the governance process used during Epoch 1 to allow community members to maintain the Hummingbot codebase and steer its evolution using HBOT token voting.
On one hand, we have been encouraged by the growth in community participation since introducing the HBOT-driven voting process. New initiatives such as HBOT developer grants, monthly community calls, and office hours have resulted in a marked increase in the number of community-submitted pull requests, forum threads, and Discord discussion participants.
In particular, having Tech Review DAO comprised of 5 independent community members reviewing pull requests and issues has significantly reduced the need to rely on engineers at CoinAlpha, our original parent company.
Epoch 1 issues
However, we have also observed a number of issues with the Epoch 1 governance process:
Voting is unwieldy for bugs
The need to have every code change voted upon can delay some urgent changes, like high priority bug fixes. It’s in the interest of every Hummingbot user to have a bug-free codebase, so forcing every bug raised and associated fix to each go through a 7-day voting process is not optimal.
Approved Pull Request Proposals (PRP) are often not mergable without additional work
Currently, all code changes are approved by PRP voting, so the community expects approved PRPs to be merged into the codebase. In reality, these pull requests often contain bugs, architectural issues, lack of documentation, security issues, and merge conflicts that may cause bigger long-term issues if they are merged in. While voting was initially designed to catch these issues, the observed reality has been that often, these issues are only identified by Tech Review DAO and Foundation staff after PRP approval. The need to fix these issues has delayed releases, and in some cases, prevented the pull requests from being merged in, even after PRP approval.
Maintainer model introduces fixed dependencies
Currently, exchange connectors may have a dedicated maintainer who earns a share of fees shared by the exchange based on usage volume. However, in cases where a community maintainer is slow in making fixes despite many users reporting bugs, it’s unclear what recourse the Foundation and the Hummingbot community has. We saw this play out with the Bitmart connector, which had many users reporting issues that remained unresolved until CoinAlpha finally submitted a fix.
Moreover, the fee share-based incentivization model is problematic because the exchanges who need connectors built and maintained tend to be smaller exchanges that the Foundation cannot count on to share sufficient fees to justify the time investment by a community maintainer, given that the bulk of this time investment is front-loaded.
Tech Review DAO makeup is overly rigid
While Tech Review DAO served a necessary function, there was an over-reliance on a smaller subset of the individuals involved, since some of the elected members were busy with their day jobs or didn’t have the experience to review many of the pull requests submitted. Therefore, there was an over-reliance on certain members of the DAO to review PRs, while other developers in the community who may have had the time/experience to contribute were excluded due to the one-time election process.
Unclear developer incentives
We heard from developers that the process designed to incentivize code contributions was unclear. Developers first had to wait for a Dev Grant Budget to be allocated via Hummingbot Governance Proposal (HGP), and then submit an Hummingbot Improvement Proposal (HIP) requesting a share of the budget. Not only was this process cumbersome, developers often didn’t know how much HBOT tokens to request. Furthermore, the grant amount was tied to how much time they spent working on the code, not the value of the code to the Hummingbot community, which unfairly penalized experienced developers.
Improvement proposal process not usable by non-developers
Since the Hummingbot Improvement Proposal (HIP) process was designed for developers submitting code changes to capture a share of a pre-existing, approved HGP budget, it was not usable by non-developers in the Hummingbot community who wanted to see certain changes made in the codebase. Their only recourse was to create forum threads and Discord discussions, but they couldn’t create an HIP that would allow the community to vote and allocate some reward to a developer for making their proposed changes.
Epoch 2 proposal
To address the issues above, we outline below a proposal for a revamped governance process. We believe that this process is more aligned with the community-driven, decentralized ethos that Hummingbot Foundation wishes to cultivate, and we welcome feedback from the community.
To explain this process, we present:
- New artifacts: New boards, diagrams, and other newly created artifacts, maintained by Hummingbot Foundations that help the community understand and utilize the new process
- Key changes: Summary of the key changes proposed
- Sample workflows: Explanation of how the revamped process might work using real-world examples of a bug, an enhancement, and a new component
- Timeline: expected process for getting feedback and approval on process changes
New artifacts
Process diagram
Draft link: Miro | Online Whiteboard for Visual Collaboration
A public set of flowcharts maintained by Hummingbot Foundation that explains how the governance process works for various types of code contributions, as well as the role played by various stakeholders in the Hummingbot ecosystem.
Review board
A Github Project in the Hummingbot code repository that contains columns for:
- Bugs that members of Review DAO (see below) are compensated for assessing level of effort to fix
- Pull requests that members of Review DAO are compensated for reviewing and approving from a technical standpoint
Bounties board
A Github Project in the Hummingbot code repository for community-created issues for bug fixes, enhancements, and new components that have bounties attached to them.
Bounties are commitments from either Hummingbot Foundation or community bounty-givers to pay a developer who submits a valid fix addressing the issue described. Payment occurs when a valid pull request has been approved by Review DAO and merged to the development branch.
New forum
Forum link: https://forum.hummingbot.org/
A new Discourse forum (replacing the old Commonwealth forum) that provides a more developer-friendly, mobile-optimized user experience for the Hummingbot community to discuss proposals, code architecture, and other long-form threads about Hummingbot.
Review DAO
A more flexible iteration on Epoch 1’s Tech Review DAO, this would be an open collective of Hummingbot community members who receive HBOT compensation for assessing bugs, and in the case of bounties, a percentage of the bounty amount.
Key changes
Bounties board allows community members to fund fixes, enhancements, and new features to Hummingbot codebase
- Anyone can create Hummingbot Improvement Proposals (HIP) that, if approved, determines whether Foundation should add an HBOT bounty to Bounties board
- Community members can also fund bounties and add them to Bounties board, skipping the HIP voting process
- Bounties are paid only after code is merged into
development(after PRP approval and Tech Review DAO approval). Bounty payments are split into the following shares, which are governance parameters settable via HBOT voting:- Developer Share: [80]% of bounty goes to the developer who submitted the pull request
- Reviewer Share: [10]% of bounty goes to the reviewer
- Foundation Share: [10]% of bounty goes to Hummingbot Foundation
Expand Review DAO’s responsibilities, and make it more inclusive, decentralized, and flexible
- Members of Review DAO decide whether a pull request can be merged into the codebase, not Hummingbot Foundation
- Approved Pull Request Proposals adds the pull request to Review Board for review by Review DAO, but no longer guarantees that pull request will be merged into the codebase
- Bug fixes automatically trigger reviews by Review DAO and skip the Pull Request Proposal (PRP) process
- Instead of a fixed 5-person squad elected at the beginning, Review DAO is an open collective that any member of the Hummingbot community can apply to join
- Instead of fixed compensation, Review DAO members pull tasks from the To Assess and To Review columns on the Review Board and receive compensation for each assessment and review they perform
- For bug assessments, individual Review DAO members receive a fixed amount of HBOT compensation based on severity (assessed by Foundation QA). For example:
- P1 (bugs that render a component completely unusable, no workaround): [5,000] HBOT
- P2 (bugs that severely affect usage of a component, or a workaround exists): [2,500] HBOT
- P3 (bugs that do not substantially impact the user experience): [1,000] HBOT
- For reviews, individual Review DAO members receive the Reviewer Share (see above)
- Review DAO membership is open to anyone, and they are elected via HGP based on a certain quorum of votes. There is no fixed number of members.
- Initial members set the DAO guidelines, pull request acceptance criteria, membership guidelines, and other rules
- New members can apply to join the DAO, and if accepted, have to prove themselves by performing a review
- Review DAO are expected to resolve conflicts regarding assessments, reviews, member qualifications, and other issues through regular meetings, public forum threads, and discussion/debate
- In the case of conflicts unresolvable through internal debate, Review DAO may ask Hummingbot Foundation to create a Hummingbot Governance Proposal (HGP) that allows HBOT token holders to vote in order to resolve the pertinent issue
Hummingbot Foundation helps Review DAO with coordination, payments, and reporting
- To allow Review DAO to focus on technical assessments and reviews, the Foundation’s role is to provide assistance and coordinating ongoing day-to-day operations. These tasks includ
- Performs QA during voting and review processes
- Managing bounty payouts
- Merging pull requests once approved
- Closing rejected issues and pull requests
- Updating Bounties Board and Review Board
- Providing regular reporting of Review DAO activities to the community
Deprecate the concept of official Maintainers per component
- The new Bounties system replaces the need for dedicated maintainers per component
- If components needs to be fixed, either the Foundation or the community may create a HIP specifying the desired fix and bounty associated with it, and any developer can earn the bounty by submitting a fix that is merged into the codebase
- Foundation keeps all exchange fee share received from exchanges, so that it may spend it and/or HBOT tokens on bounties
- Foundation will honor existing signed agreements with maintainers for the duration of the contract
Sample workflows
In the next few days, we post Part 2 of this thread, that uses a few existing Github issues and pull requests from the Hummingbot repository to explain how this revamped process might work.
Bug
Coming soon in Part 2.
Enhancement
Coming soon in Part 2.
New Components
Coming soon in Part 2.
Timeline
Coming soon in Part 2.