FerrisOxide

Want to contribute?

Help make waveform evidence easier to review.

FerrisOxide benefits from contributors who care about precise docs, reliable fixtures, clear examples, Rust quality, and honest project boundaries.

Good first contribution areas.

The project is documentation-first and evidence-heavy, so useful contributions are not limited to writing Rust code.

Docs and examples

Improve explanations, add example walkthroughs, make reports easier to understand, and keep source docs aligned with implemented behavior.

Validation fixtures

Add or refine software-only waveforms, expected measurements, edge cases, and golden reports that make criteria behavior inspectable.

Rust implementation

Work on parser behavior, criteria semantics, report clarity, package validation, or no_std-compatible boundaries after the issue scope is clear.

How to approach the project.

Start by reading the main README and the documentation map. Pay close attention to what is in scope and what is explicitly not claimed.

The best contributions keep behavior reviewable: clear requirements, focused implementation, tests or fixtures, and docs that explain the evidence without overstating maturity.

  1. Read the product guide and contributing notes.
  2. Choose a small issue or documentation gap.
  3. Keep changes focused and source-backed.
  4. Run the relevant Cargo checks from the source repository instructions.
  5. Include evidence and known limitations in the PR description.
contribution-checklist.txt reviewable work 
state the requirement
name the affected files
add or update tests
document evidence
avoid unsupported claims
leave clear follow-up notes

Contributor boundaries.

FerrisOxide is open to careful contributions, but some areas require fresh requirements, architecture, dependency, security, and validation gates.

Welcome directions

  • Clearer documentation and examples.
  • More precise software validation fixtures.
  • Bug fixes with targeted tests.
  • Report and rule-package clarity improvements.

Needs a fresh gate

  • New third-party dependencies.
  • Live DAQ SDKs, HALs, or hardware integration.
  • Production RTOS runtime or certification-facing claims.
  • GUI, cloud, accounts, plugin runtime, or cryptographic signing.

Start from the source repository.

The active engineering work lives in kota-wilson/ferrisoxide. Use the contributor, security, code of conduct, license, and README files there as the authority for source-repository contributions.

Open FerrisOxide on GitHub Read CONTRIBUTING.md

This website is a public presentation layer. Source code changes belong in the FerrisOxide source repository workflow, not in the website repository.