VisualHFT is built to make real-time market microstructure visible, explainable, and actionable. Contributions to code, documentation, connectors, and studies are welcome.
- Read Getting started and build the solution locally.
- Check GitHub Issues and GitHub Discussions before opening a new proposal.
- Fork the repository and create a branch from
master. - Keep each pull request focused. Explain the problem, the change, and how you validated it.
| Area | Examples |
|---|---|
| Documentation | Setup fixes, examples, architecture clarification |
| Connectors | Market-data sources, symbol mapping, resilient connection handling |
| Studies | Market-microstructure indicators and visualization improvements |
| Quality | Tests, accessibility, diagnostics, and maintainability |
Use the extension templates for a new market connector or study.
git clone https://github.com/<your-account>/VisualHFT.git
cd VisualHFT
git remote add upstream https://github.com/visualHFT/VisualHFT.git
git fetch upstream
git checkout -b my-branch upstream/masterBefore opening a pull request, build the affected project or solution and run the relevant tests. Keep commit messages clear. Common prefixes include fix:, feat:, docs:, test:, build:, ci:, perf:, and refactor:.
Pull requests should include:
- A concise summary of the user or engineering problem.
- The change made and any important tradeoff.
- Validation performed, including the command when practical.
- Tests for behavior changes.
Do not change established input JSON message formats unless there is a compelling compatibility plan and community agreement. New message types are preferred when they avoid breaking existing installations.
- Ask questions in VisualHFT Discord.
- Discuss ideas in GitHub Discussions.
- Report reproducible bugs in GitHub Issues.
For long-term collaboration, see the Partner Quant Program.