B2: Creating new additions/enhancements vs. soley bug fixes. Future direction.
neilsmurphy opened this issue · 5 comments
There was an indicator addition that brought up the discussion of creating enhancements in Backtrader 2 vs. just bug fixes. I'm going to pin this discussion to the top of the issues for a while as this is important and if we are going to build backtrader2 for the future, we should all have input as to what that might look like.
I'm going to add some of the comments below.
@neilsmurphy This might be part of a bigger discussion. The intention originally when branching out from Backtrader was to have a place where fixes, repairs and updates could be implemented in a timely manner. It's my understanding that we are not keen on growing the code base. Perhaps the @backtrader2/admins could chime in?
@vladisld Neil, you're right that our original intention was to focus only on bug fixing, while the reasoning was that we are not fully understand nor master the core of the framework. While being true for the framework core itself - I'm not sure adding new indicator (something that many know not only how to develop but also how to test) qualify as a framework core component.
Another reason for not adding new features was that we have not a lot of dedicated full/partial time developers to support even existing code, so support new half-backed features could be even a bigger problem. Still, not sure it applies to the indicator which is relatively simple and well tested.
So IMHO there is no hard objection to adding new indicator unless you have another view on this of cause.
Another question could be whether or not we would like to maintain all the new indicators withing the current backtrader repository or in the external one.
The agruments in favor keeping the indicators in the original backtrader repository:
there is already existing indicators in the contrib subdirectory in the current backtrader repository (backtrader/indicators/contrib/vortex.py for example)
maintaining the indicators in external repository is prone to the synchronization issues with the changes in the original repository
indicator code will always be tested, ensuring no other changes could break by mistake.
@neilsmurphy I have mixed feelings about this as well. Nothing would make me happier than to have a vibrant community building out backtrader with new developments and the like. But in my view, we would seriously have to make a break with the original fork. As it currently stands, Daniel has moved on and I think he's only been back once since we started Backtrader2 to confirm pull requests into the original repo. Since he wishes to keep that repo in lock down, we may have to consider moving this fork forward with new development if that's something we want to do. That said, I don't think introducing one indicator is the way to start that.
On top of all the issues you mention above, we would also need to open up new documentation and evolve that with the new growth.
So my mixed emotions. I feel like I would love to see backtrader evolve, but at the same time, I don't think there seems to be the momentum for it.
I would vote to pass on this pull request for the time being until we are ready to expand the code base in new directions. Sorry about that @FGU1 we appreciate the work you put into this.
For the time being, I think Backtrader2 is still a bug fix area.
@Jens1989 would having add-ons not motivate people to build and create and will then further attract people? I get your reasoning but just wondering if small additions which are safe to add could still be viable. Alternatively there could be some sort of add-ons folder which would have the additions the core system doesn't have in order to make a differentiation? Then in the future, these could be added to the main folders.
Also, can you actually modify the documentation or is this also locked?
I'd like to contribute to the core system but my level of skill is not good enough at the moment.
I put this here to generate comments. I will close due to inactivity.