You can help improve Trace through reproducible bug reports, documentation corrections and design-workflow feedback.
Report a problem
Use Feedback or contact hello@buildwithtrace.com for private inquiries. Include:
- Product and version: Trace desktop, Trace Plugin or bundled
trace-cli. - OS and CAD host, where relevant.
- The smallest steps that reproduce the problem.
- Expected and actual results.
- A disposable example or redacted screenshot, if you can safely share one.
Do not include tokens, signed links, personal/team designs or private logs without permission. A failed operation may still have effects; retain recovery information rather than repeating it just to produce a report.
KiCad roots and software licenses
Trace's native desktop builds on KiCad. KiCad's licensing and notices apply to the relevant KiCad-derived code; that ancestry does not establish one license or public-source access for every Trace service, SDK, website or companion.
Check the license and notices for the specific component and distribution.
The documentation repository has its own LICENSE, separate from software
licenses. This page grants no license or contribution rights and does not
promise that the full Trace stack is publicly available.
For component licensing or source-access questions, contact hello@buildwithtrace.com. Upstream KiCad development has its own contribution process and source repository.
Before a code or documentation contribution
- Confirm the repository's access, license and submission terms with its maintainers.
- Discuss larger changes before beginning implementation.
- Follow that repository's build, test and formatting instructions.
- Keep the change focused and explain affected user workflows.
- Test supported paths and failure cases; state which platforms were not tested.
- Submit through the review process available for that repository.
Do not assume a public package listing means its source repository accepts forks or pull requests. Preserve existing copyright and license notices; do not assign a blanket GPL license to unrelated files.
Documentation and style
Documentation should name the actual product, prerequisites, user controls and completion evidence. Distinguish a proposed feature, current source and a verified installed release. Avoid guarantees about privacy, conversion fidelity or engineering correctness that the workflow does not prove.
For native C++ conventions, see Code Style. Be respectful and constructive in reports and reviews.