Project planning

[bitphage]

Currently I was assigned to the task #517, and the question appeared for me: Why I'm writing tests for the code which will be refactored soon instead of doing refactoring of that code and writing tests immediately? So, I decided to summarize the decisions which I considering as strange:

• Refactoring of strategies (base.py refactor #542, Staggered Orders Refactor #541) before refactoring the core (Core Refactor: Worker, MP asyncio #538) will require refactoring again
• We have unittests tasks in progress for the code which going to be refactored right after (Base Strategy Unit Test #516, Staggered Orders Unit Test #517, Relative Orders Unit Test #518) . So current pipeline is to "write tests for strategies -> refactor strategies -> refactor tests". Why not refactor code and write unittests for the new code in parallel? This would save us huge amount of time.
• External feeds + their tests refactor was started (refactor external feeds to be External Price and Order Engine + fix unit tests  #524), but was interrupted in favor of Staggered Orders Unit Test #517. Isn't it a fail of planning?
• Base strategy unittests Base Strategy Unit Test #516 are being developed without basing it on Strategy Test Interface to omit Real node interaction and API calls. #515 (strategy test interface to use local testnet). This means additional work of refactoring base.py unittests to Strategy Test Interface to omit Real node interaction and API calls. #515
• Plugin infrastructure 500 plugin infrastructure #502 was implemented but didn't used and even merged. Wouldn't it be better to spend time on more priority tasks than?
• KOTH strategy (454 1 sat bot strategy (KOTH) #479) has been implemented covering all initial requirements. The work has not been accepted, unittest requirement added despite it was not present in initial requirements.
• Seems like most of discussions on development planning are happening in private chats, then final decisions are published without letting all interested parties to participate. This is the root of unoptimalities I described above

How would I plan the work:

• Do architecture planning of how all dexbot components should interact together (Core Refactor: Worker, MP asyncio #538)
• Refactor core (Core Refactor: Worker, MP asyncio #538)
• Refactor strategies + write tests in parallel using new testsuite base (Strategy Test Interface to omit Real node interaction and API calls. #515)
• Implement new features, plugins, etc

[PermieBTS]

The unit tests being done prior to the refactor allows us to prove that the code we have now and the code post-refactor behaves the same - to prove that the strategies are uaffected by refactor.

[PermieBTS]

King of the hill and the plugin infrastructure will be used later, but were developed at a time when it could be worked on. Progress wasn't delayed because they were developed earlier.

We're working towards a tested stable release for 1.0.0 pre-refactor

[PermieBTS]

Having you start work on the external feeds/order engine before the SO unit test was complete was a mistake on my part. Sorry for that vvk.

The 524 work isn't wasted though, and can be continued later

[PermieBTS]

DEXBot development July August/Sept

July

Complete ccxt order engine - @thehapax

Complete asyncio development of pybts and pygraphene - @bitfag

Release KOTH - @bitProfessor @bitfag and @joelvai

Release Single Accounts Multiple Workers - @bitProfessor @bitfag @joelvai

Release Stable v1.0.0 to be maintained only with bugfixing not additional features - @joelvai
Separate DEXBot into two versions; 1.0.0 stable and 2.0+ with continuous additional features. The goal being long term bug-reporting for 1.0.0, a particular static version.

Continue Development on SO and RO Visualisation tools - @Jackodb @JRizzly

Begin detailed Video Tutorial commissions - Non-dev

Research into additional strategies. https://blog.alpaca.markets/blog/2018/11/9/full-list-of-automated-trading-strategy-typespartnbsp1
Ta-lib python library(?)

Begin DEXBot Statistics Reporting tool - @dominic22

Improve DEXBot documentation, user feedback from bitcoinsfacil - pedro suggests hummingbot is popular in large part due to its comprehensive documentation

August

Continue DEXBot Stats Reporting tool - @dominic22

Integrate Gabriels existing internal-DEX-arbitrage highlighter tool into DEXBot. Arbitrage-enabling feature issue 583. Scan for best opportunities for inter-gateway arbitrage. - (@thehapax or @bitfag ) + @joelvai

Integrate simple Long Term Average indicators - @thehapax @joelvai

Dollar-Cost-Averaging feature - supply the bot with assets and determine on which market it should buy, what % of the supply per buy, and how frequently. - @bitfag or @thehapax

Hedging feature - is this possible on bts? Insurance/short positions can be created using bts UIAs but they are rare. Functionality to take advantage of them, ready for when they exist, would be good. For example could DEXBot be configured to automatically buy a specified insurance-UIA should the worker’s btc exposure reaches a certain threshold

Forecasting tools to inform for prudent market making - @thehapax

The BitShares DEX needs to be mentioned in articles like this: https://blog.saturn.network/how-profitable-is-market-making-on-different-exchanges/