Hello to all the Hummingbot community!
Creating great software is hard. A lot of things (good and bad) happens between having the starting idea and the release of a well-rounded product.
The Hummingbot client has evolved a lot since its inception over two years ago. Today Hummingbot is an open-source trading tool that allows you to connect with 33 different exchange connectors (from spot CEXs to AMMs protocols) and try 11 different built-in algorithmic trading strategies.
A big part of this evolution is due to the amazing community that has been built around this project. Today on our Github page, we have a total of 490 Open Issues and 1081 Closed Issues. A lot of these issues were created by the community, covering from bugs to new strategy ideas.
(Talking about bugs, you can vote on the bugs to help us prioritize what our team should fix next. You can read more about this in this article)
Because community participation and feedback fuels the constant evolution of Hummingbot, today we are publishing our first Dev Diary. Our goal is to talk about what is happening during development cycles what are the plans for the next cycles.
This Development Diary will also be published on our Reddit page, where you can comment and/or suggest anything about its content.
Talking about development cycles, let’s start this first diary with an introduction to how our team works:
A new release every month
As you might have noticed, we aim to push a new release every month.
Planning what features should be included in each release is a constant process of looking through Github Issues, Community Pull Requests, and Discord chat to understand which features would be more useful to traders using the Hummingbot Client.
We defined some priorities to help us on the selection of what should be worked on through the release:
Bugs - Our team aims to fix at least two bugs per release, prioritizing critical bugs and those with the most upvotes.
Core Improvements - Improvements on the core codebase, aiming to improve performance, security, and code readability. These stories usually take a high priority because being an efficient crypto trading tool is one of the main goals.
Existing Strategies and Connectors - We constantly monitor how the strategies and connectors currently available works, monitoring for possible improvements on how they work.
New Connectors and Strategies - We prioritize them based on demand, so let us know what connectors or strategies you would like to see implemented on the codebase.
Two Sprints each month
After defining what will be worked on for the next release, the team starts working on two 15 days sprints. This allows us to break down each feature into smaller implementations and test them as they are concluded, ensuring that they are working as expected.
One developer writes the code, a different one reviews it, and the QA team runs tests trying to find as many bugs as possible before the release.
Code submitted by external developers is a big part of Hummingbot evolution, and we constantly see new pull requests (PRs) submitted to our Github repo.
On the last two releases, we merged some of these PRs (big shout out for zappra, krisj, willzs03, and petioprv), and being an open-source project, these contributions speeds up a lot of new features implementations.
One of the improvements our team is working on is how to handle these community PRs better and reduce the time they stay on the board, awaiting a resolution.
Hummingbot codebase has been growing for a long time, and as this happens, the complexity starts to increase, and new additions/changes to the codebase risk breaking something else.
Because of that, our team has been working on implementing unit tests across the codebase to reduce the risks of new contributions having an unexpected effect.
Currently, we require a minimum of 66% of successful unit tests for a PR to be merged. As we improve these unit tests, we will gradually increase the minimum required success and update the community as needed.
There are many things that go into the mix to define where the engineering and QA effort is spent. This is also a process that is being improved, and one of the goals is to allow better ways for the community to voice their opinions on what should be the development priorities.
Stay tuned for future announcements, where we will talk a bit more about how these improvements will work.
Meanwhile, here is what the team plan to implement on the current sprint (feel free to check the linked Github issues and add your feedback):
Add mode data points to Limit Orders code (#3622)
We reached the end of our first Development Diary, and every two weeks, a new one will be published with what is happening during our development cycles.
We await your feedback about this new way to provide more transparency and collect more feedback from the community to keep improving Hummingbot.