Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Maintainer-Led Governance

TTRPG Forge is currently a public preview / maintainer-led alpha.

The project welcomes issues, patches, questions, and design feedback. Final product direction, architecture decisions, roadmap priority, and release timing are owned by the maintainer.

Who Can Do What

Users and contributors can:

  • report bugs and confusing behavior
  • suggest improvements
  • propose design changes
  • submit patches
  • improve docs and tests
  • ask for clarification when behavior is ambiguous

The maintainer can:

  • accept, request changes to, or decline patches
  • decide roadmap order
  • make final product and architecture decisions
  • defer features that do not fit the current horizon
  • close discussions that are no longer useful

Feedback Loop

Feedback is most useful when it is concrete:

  • describe the workflow or failure
  • explain the expected behavior
  • point to the affected docs, route, UI, or crate
  • separate current bugs from future feature requests

Broad product feedback is welcome, but it may be deferred if it does not support the current roadmap horizon.

Project Fit Test

Feature proposals should answer:

  • 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?

This is not meant to block small ideas. It is meant to keep proposals concrete enough to decide.

Design Boundary

This project is not design-by-committee at this stage.

That boundary exists to protect maintainer time and keep the alpha coherent while the core model is still being proven. Contributors do not need to agree with every decision to participate, but patches should fit the current direction unless a design change has been accepted first.

Decision Notes

When a decision is large enough to affect future contributors, record it in the docs near the affected area. Keep decision notes short:

  • decision
  • reason
  • rejected alternatives if useful
  • what would cause reconsideration