Community #
Connect with other velocity.report users and contributors. Discord is for live help and working conversations. GitHub is for anything that needs to be found, reviewed, and fixed later.
Discord
Join the Discord for setup questions, hardware notes, design triage, and live conversations that are still taking shape.
Join Discord →What to expect in Discord #
Discord is the workshop, not the filing cabinet. Use it when a conversation benefits from back-and-forth, screenshots, logs, photos, or the small awkward details that vanish when everyone pretends setup is always tidy.
- Start in
#hello-world- Say what brought you in: a street you want to measure, a sensor you are trying to mount, a report you want to produce, or a technical area you want to improve. - Use
#helpfor setup and report problems - Bring the Pi model, radar sensor, release version, what you tried, what happened, and any logs or screenshots. A few specifics save everyone from guessing in circles. - Use
#hardwarefor sensors, mounting, aiming, enclosures, cables, and field notes - Photos are useful here. So are bad photos with enough context to save someone else an afternoon. - Use
#githubfor repository coordination - Good for “is anyone already working on this?” and PR/release chatter. Bugs, feature requests, and decisions should still end up in GitHub.
If you are not sure where something belongs, post in #hello-world or #help. A small useful server beats a grand taxonomy with nobody in it.
Contributing #
If you want to contribute, start with the Contributing Guide.
The best contributions make the system clearer, safer, easier to operate, or harder to misunderstand.
We are especially interested in people who like inspectable technical problems: tracking drift, foreground extraction, geometry, replayable evaluation, and metrics that hold up outside a slide deck.
For a quick map, read Finding your way in, then browse the backlog and the active plans folder.
Code contributions #
- New features - Build something the product needs, and check the open feature requests first.
- Bug fixes - Remove defects and sharpen rough edges.
- Testing - Add coverage where confidence is thin, and report failures clearly enough to reproduce.
Maths, tracking, and perception work #
- Perception engineering - Work on clustering, tracking, classification, ground modelling, radar-plus-LiDAR fusion, and the geometry around them.
- Current problems - Geometry-coherent tracking, velocity-coherent foreground extraction, interpretable classification, pose anchors, and ground-plane modelling are active areas.
- Data science and evaluation - Help with labelled reference sets, replayable scorecards, threshold studies, drift analysis, and traffic-engineering metrics. The open research queue lives in data/QUESTIONS.md.
- Evidence-first contributions - Bring the artefacts: parameter bundle, validation date, replay pack, scene or run IDs, and the baseline you beat.
If that sounds like your kind of work, the links above will point you to the right documents.
Non-Code contributions #
- Survey - Build a citizen radar and turn local concern into evidence.
- Advocacy - Tell people the project exists and why privacy matters here.
- Feedback - Share use cases, friction points, and feature requests.
- Documentation - Write guides, examples, and explanations.
- Community support - Help answer questions on Discord.
Design feedback #
We are actively shaping the next-generation interface, so this is a good moment to say what works and what does not.
Review the current design prototype here: Project Butterfly Net.
Useful design feedback is concrete. Tell us where the workflow becomes unclear, what information feels missing, and what the interface gets wrong.
Code of conduct #
We want a community that is useful, welcoming, and civil. Please read the Code of Conduct before joining in.
Getting help #
Support channels #
- Discord - Best for real-time questions and discussion.
- GitHub Issues - Best for bug reports, feature requests, and anything that needs a durable paper trail.