GitHub

Where the code lives, and how to move it

Four repositories, one release process, and a strong preference for small changes that arrive with a failing test. This page is the map; the repositories themselves are the territory.

Repositories

Filing an issue that gets fixed

Maintainer time goes to issues that can be reproduced. Everything below exists to make that possible in one round trip rather than four.

What to include

The version, the exact call or configuration, what you expected, what happened, and a decision or backtest id if one is involved — that id is enough for us to replay the exact inputs the engine saw.

What to leave out

API keys, exchange credentials, account identifiers and full log dumps. Redact before pasting. A public issue is public immediately and permanently.
a good issue
### What happened
`POST /v1/backtests` with a sweep over `threshold` returns 202,
then the job sits in `queued` indefinitely.

### Expected
The job transitions to `running` within a few seconds, as a
single-parameter backtest does.

### Reproduce
- client: tradelogx-nexus 2.4.1, Python 3.12
- backtest id: bt_2f77
- sweep: { "threshold": [68, 70, 72, 74, 76] }
- single-parameter runs on the same strategy work

### Notes
Started after upgrading from 2.3.x. Reverting the client does
not help, so it looks server-side.

Security issues never go in a public issue. A vulnerability in a trading system with connected exchange keys is not something to disclose in a tracker while it is unpatched. The private disclosure route is on the security page.

Pull requests

One change per pull request. A branch that fixes a bug and also renames three files is two reviews wearing one hat.

  1. 1Open an issue first for anything larger than a fix — agreeing on the approach costs a comment and saves a rewrite.
  2. 2Add a test that fails before the change and passes after. For risk semantics this is not optional; the conformance suite is the specification.
  3. 3Keep the diff readable. Formatting changes belong in their own commit, and preferably their own pull request.
  4. 4Sign off your commits (`git commit -s`). There is no CLA; a DCO sign-off is enough.
  5. 5Expect review from two maintainers on risk semantics and one elsewhere. Reviews are public, and disagreement in them is normal rather than a problem.

Releases

How a version is cut

Releases are tagged from main, and the changelog is derived from commits rather than written afterwards — which is why commit messages are reviewed as part of the diff. Packages publish to PyPI, npm, pkg.go.dev and crates.io from the tag, never from a developer machine.

Platform deploys are separate and continuous. A client release never requires a platform upgrade: response shapes are pinned by the Nexus-Version header, described on the API reference.

Open the repository on GitHub