ThirdEra

Feedback and contributions

Development approach

This repository is unapologetically being vibe coded by the author. If that makes you not want to use it that’s your call to make, but I will not be accepting feedback that is primarily criticism of the decision to develop this way, or requests that the development process change. Bug reports and practical feedback from people who use the system are very welcome; feedback that amounts to “you shouldn’t do it this way” is not.

Giving feedback

If you’ve tried ThirdEra and have feedback, bug reports, or suggestions, please make use of the repository's GitHub Issues for bugs or feature ideas, but please check existing issues first.

I welcome reports of what works and what doesn’t, especially from GMs and players running games with the system.

Contributing code or content

Contributions (pull requests, patches, or compendium content) may be accepted depending on the project’s current priorities. If you want to contribute:

  1. Open an issue first - Describe what you’d like to do so maintainers can align with the roadmap and avoid duplicate work.
  2. Follow repository conventions - Code style, commit messages, and architecture are described in the Development page on this site and any other contributor-facing docs. When adding content (e.g. compendiums or new items), see Extending for data-driven design and reference rules. The project uses document ID/UUID for references between items; new code should follow that and the existing patterns. Before opening a PR: from the repo root, run npm ci, make test (or npm test), and make test-coverage (Node.js 20+); Validate runs unit-tests (make test) and a separate coverage job (make test-coverage, which fails if scoped coverage falls below configured minimums)—see Development → Automated unit tests. Which modules are covered by unit tests (and which are Foundry-only for now) is documented in test/README.md at the repository root. Changes to covered logic need new or updated tests (see Development — Automated unit tests and test/README.md in the repository root). Documentation: If your change affects what players or GMs can do (or what macros can rely on), update docs-site in the same PR or immediately after—see Development → Published documentation and feature state and keep supported today vs not yet language accurate for partial features.
  3. Expect review - Pull requests will be reviewed for consistency with the codebase and the project’s goals. Not every change may be merged; we’ll do our best to communicate why.

If the README or maintainers state that code contributions are currently paused, that overrides the above; practical feedback and bug reports are still welcome (subject to the development-approach note above).

Where to find conventions