Epoch Review - Code Base workflow rework

Author: PHBR0 x58B

As mentioned in previous community calls, we are reaching the end of Epoch 1 and next month (July) will Hummingbot Foundation will engage with the community to discuss what went right wrong during the Epoch. During the following weeks, we will start some threads with some ideas for community discussion.

The first topic Hummingbot Foundation wants to bring to community discussion is the workflow of the Hummingbot Client code base.

Altough Foundation team is being able to ship monthly updates as expected, we have noticed some inefficiencies on the process of merging community contributions to the code base.

Currently, we have the following workflow:

  • Dev submits a Pull Request to the development branch
  • Dev creates a PRP (Pull Request Proposal), that is up for voting for 7 days
  • Tech review DAO review and comment on the PR
  • Foundation QA team tests the submission
  • If QA team approves, the PR is merged into development. If issues arise, QA team reaches out to the developer to fix whatever is needed.

We noticed a few issues related to the current process:

  1. PRs can end up without updates from the developer that created it for a long time
  2. QA ensures that the code submitted works, but there is no control of the quality of the submission
  3. Tech review DAO comments is a preliminary evaluation, and the developer that submitted the code isn’t bound to follow the recommendations
  4. Releases end up being chaotic at moments. Some devs taking a very long time to fix their submissions.
  5. The process can delay some urgent changes, like high priority bug fixes
  6. Information about how to participate in the development process isn’t concentrated in the same place, making a bit confusing for new developers how to contribute to the code base

Based on this initial evaluation, Hummingbot foundation is working on the following proposal to change the workflow related to code contributions

1. Bug fixes will have its own workflow

Pull Requests relate to bug fixes need to have its own separated process due to its particular nature.

Another thread will be created detailing the Foundation Team suggestion of the bug fixes workflow, but the key features will be:

  • Foundation QA will still be the main responsible for organizing and classifying the severity of the reported bugs
  • Bug reports will be separated in two main types:

Related to connectors that have an active maintainer -

They will be the final reviewer for accepting/rejecting bug fix PRs targeted to the connector they are responsible for. These bug fixes won’t need to go through a PRP voting process, and it will be up to the connector mantainer accept or reject the communty PR. If the mantainer is the one creating the bug fix PR, they will still need QA approval, and another dev review approval for it to be merged into the code base. Mantainers will still need to publicize their bug fixes to the rest of the community.

Everything else

They will still have to go through a PRP governance vote, but reviews and merge of these PRs will have it’s own workflow (wich will be detailed on a new thread). Along with the code workflow, Foundation will also propose a new Bug Reward program

2. Code base segmentation with dedicated community review teams

Hummingbot client modularity allows us to separate the code base into the main functionalities:

  • Core
  • CEX Connectors
  • Strategies
  • Gateway
  • DEX Connectors

Each part of the code has their own particularities, and learning with the Tech Review DAO, our proposal is to establish a small team of 3 community developers to act as final reviewers of code contributions.

Similar to the Tech Review DAO, the members of these teams will be chosen through governance elections. Their main roles will be:

  • Define and update the contribution guidelines related to its module; NOTE: Contribution guidelines will define what rules the community devs must follow to contribute to the code base, including what can make a PR be rejected (not merged into the code base) even is it was approved by governance vote. Every change to the Contribution Guideline must go through a HIP proposal.
  • Give community developers orientation on how to contribute, and what are the best practices;
  • Execute a final review before approving the PR merge into the development branch
    • NOTE: The review team will be able to reject the PR if it doesn’t follow the contribution guidelines, or the dev that submitted the PR does not respond the review team after a period of time (that will still be defined)

3. Changes in the PRP voting process

To improve the contribution flow for community developers, Hummingbot Foundation proposes a new sequence of actions:

  1. Comunity dev creates a Pull Request targeting development

1.1 The PR description will require having a specific minimum amount of information (to be defined). Failure to do so can lead to invalidate the PRP vote result. 2. The developer can create the PRP (Pull Request Proposal) right away 2.1. Similar to the Pull Request, the body of teh PRP will require having a specific amount of information (to be defined). Failure to do so can lead to invalidate the PRP vote result. 3. Approval/Rejection 3.1. If the PRP is rejected, the respective Pull Request will be immediately closed. 3.2. If approved, the Review team (as established in the section above) with Hummingbot Foundation QA team, will do a final review to check if the Pull Request follows the Contribution Guidelines. 4. If the Tech Review team finds problems with the PR, they will reach out to the developer to do any fixes as needed 5. The PR will only be merged into development once there is an approval by both Foundation QA and the Tech Review team

The goal here is to:

  • Allow the general community to vote on the Idea and/or the implementation through the PRP
  • Improved code quality control, with transparent rules for acceptance (or rejection), defined by community voting

| NOTE: We haven’t discussed yet if connectors that have a defined mantainer should also go through the full process. Further discussion is needed.

4. Releases will have a fixed cut-off date

To avoid disrupting the release process with Pull Requests approved at the last minute, a window of approval will be established. Every month, all PRs that haven’t been fully approved until a certain date (probably 10 days before the end of the month) will not be added to the new release.

This is the initial draft of the Hummingbot Foundation team proposal related to improvements on the Client code base. We ask the community to add any feedback related to it, or any other ideas and suggestions to improve this part of the process.