Skip to content
Fera Docs

Search is only available in production builds. Try building and previewing the site to test it out locally.

Contributing to Fera

Источник: dev/fera/community/CONTRIBUTING.md (read-only; сгенерировано scripts/sync-docs.mjs)

Contributing to Fera

Section titled “Contributing to Fera”

Thank you for your interest in contributing! This guide covers the practical path from “I want to help” to a merged change.

Read this first

Section titled “Read this first”

The lay of the land

Section titled “The lay of the land”

The the-fera org holds several repositories:

  • fera — the client itself (launcher, core module).
  • fload / mikkaj / grmrs — the module runtime, search engine, and protocol library (our own libraries, shaped from upstream sources).
  • lattice — the .lttc plugin container format (standalone project, usable outside Fera).
  • rstgcalls / tgcalls / re-call — the calling stack: bindings, the C++ base, and the future pure-Rust reimplementation.

Pick the repo that matches your change; cross-repo changes are separate PRs each, with the dependency order respected (runtime → libraries → client).

Development setup

Section titled “Development setup”

Rust. A pinned toolchain per repo (rust-toolchain.toml in each repo is the source of truth — the pinned version is load-bearing: our module ABI stability strategy relies on it, see the design corpus). Install via rustup.

Clone recursively. Repos reference each other as submodules:

git clone --recursive [email protected]:the-fera/<repo>.git

Build & test. The standard Rust loop:

cargo build
cargo test
cargo bench   # benches are pinned against the fixed benchmark scene

What kind of contributions help

Section titled “What kind of contributions help”
  • Bug reports with reproduction steps (see the issue templates).
  • Fixes — small, focused, with a test that fails before the fix.
  • Contract tests — new cases for existing trait suites are always welcome; they are the project’s load-bearing safety net.
  • Benchmarks — improvements to measurement quality, new scenes proposals (a scene bump is a versioned event, not an edit).
  • Docs — clarity fixes in READMEs and guides.

If you want to work on something architecturally significant (a new module boundary, a new contract, a storage-layer change), open an issue before writing code — the design corpus is the authority on shape, and we want to agree on the shape first.

The practical loop

Section titled “The practical loop”
  1. Fork (once public) or branch off master.
  2. Commit in focused units, per the commit style.
  3. Open a PR; fill in the required contents (see PR guidelines).
  4. Respond to review; iterate.
  5. A maintainer merges once gates pass.

Licensing

Section titled “Licensing”

Each repo’s license is stated in its LICENSE file; by contributing you agree your contributions are licensed under that repo’s license. License texts land before the first public release — until then, code stays in private repos.