For Contributors

TTRPG Forge is an early Rust workspace in public preview / maintainer-led alpha. Contributors should expect the project shape to keep changing while the core model is proven.

The most useful contributions are the ones that strengthen the product’s central promise: a living lore graph with branchable continuities and audience-specific visibility.

Contributor Entry Points

• What works today? summarizes implemented behavior.
• How do I try it? gives the local development commands.
• Product Goals explains what belongs in the core and what should remain outside it.
• Roadmap describes the current product sequence and status.
• Documentation and Test Standards explains how to keep tests and docs meaningful.
• Maintainer-Led Governance explains decision boundaries.
• Architecture Overview explains the major crates and boundaries.
• Recommended Rust Workspace explains the workspace layout.
• API Design describes the HTTP surface.
• Frontend UX Roadmap explains the first frontend workflows.

Current Contribution Focus

The highest-value work is still foundational:

• keeping project and continuity boundaries clear
• making entities, relationships, events, and secrets consistent across API, storage, and UI
• improving search and query behavior
• tightening tests around domain rules and HTTP behavior
• making the frontend answer project questions quickly
• documenting decisions as the model stabilizes

Contribution Runway

The preferred path is intentionally lightweight:

1. Pick work that fits the current roadmap horizon or fixes clearly observable behavior.
2. Keep the patch focused enough to review.
3. Add tests for important behavior when code changes affect behavior.
4. Update docs only for actual behavior, accepted decisions, or clearly marked plans.
5. Run the relevant xtask checks before sharing the patch.

If a change needs product direction first, open the design question before doing a large implementation.

Issue And Pull Request Templates

The repository includes Forgejo templates as optional conveniences for:

• bug reports
• documentation issues
• feature proposals
• maintenance work
• pull requests

Use them when they fit. Blank issues are allowed.

Feature proposals should answer the project fit questions:

• how does this support structured lore, branchable continuities, audience-specific visibility, search, or contributor readiness?
• who benefits?
• what is explicitly not being done?
• what observable behavior would make it complete?
• what docs or tests need to change?

Local Development

The full repository also has root-level README.md and CONTRIBUTING.md files for code-hosting views. In this documentation site, the local setup is covered by How do I try it?.

The short version is:

cargo run -p xtask -- dev

That starts the API and Leptos frontend together. Documentation can be rebuilt with:

cargo run -p xtask -- docs

Collaboration Boundary

User-facing material should describe outcomes and workflows. Contributor-facing material should describe implementation details, tradeoffs, crate boundaries, and unresolved design questions.

When adding new docs, place them according to that audience first. If a page serves both audiences, link to it from both sections but write it in the language of its primary reader.

Maintainer Boundary

Feedback and patches are welcome. Final direction, roadmap priority, and architecture decisions remain maintainer-owned while the project is in alpha.

Security Findings

See the repository SECURITY.md.