OrdinateDB

Community

One repository.
Decisions in writing.

Code, discussions and issues all live at github.com/ordinatedb/ordinatedb. There is no members-only tier of the community and no chat channel you must have been in last March to understand a decision.

Working in the open

How to contribute

SPEC 00 §1

Read the spec before the code — specs-first means the spec is the design, so a behaviour change starts as an RFC against the spec, not as a pull request against the implementation. For everything else, the good-first-issue label is real and curated: each one has been checked to be genuinely self-contained before it gets the label.

What contributions look like

Rust in the core, TypeScript in the portals, collectors for protocols we don’t cover yet, documentation, and chaos-rig scenarios — a new way to kill a process, link or disk mid-ingest is as valuable a contribution as a feature, because it either proves the archive holds or finds the place it doesn’t.

Community standards

We have a code of conduct and it is enforced; argue about the data model as hard as you like, and never about the person.

Where to get help

GitHub Discussions. Deliberately not a Discord: chat scrollback is where decisions go to become folklore. Anything decided in a discussion that changes behaviour lands in the specs, so the answer is findable next year by someone who wasn’t there.

Start with the specs, then the issues. The order matters.

github.com/ordinatedb/ordinatedb