Skip to content

Contributing

Issues vs Discussions

Channel Use for
Issues Reproducible bugs, concrete feature work, and changes that should close with a PR. Use the templates (Bug, Feature, Idea).
GitHub Discussions Questions, design brainstorming, and community help where there is no single “fix” yet. Good for Q&A and long-running topics. See Community.

Pull requests

  • Prefer small, focused commits (one logical change per commit when possible).
  • Update documentation (docs/) when you change user-visible behavior, cvars, commands, or build steps (see project rules in .cursor/rules/).
  • x64 only for Linux, Windows, and macOS (see Architecture).

Documentation

  • MkDocs (mkdocs.yml, docs/) is the canonical documentation; it is versioned with the code and published via GitHub Actions.
  • The GitHub Wiki is optional; if you use it, avoid duplicating content that already lives in docs/.

Documentation (self-contained handbook)

Summarize CSRetro-relevant facts in docs/components/ and audience pages. Long copyrighted manuals are not copied verbatim; upstream projects are credited in Credits. Do not commit HTML mirrors into the repo. Full maintainer policy (not on the docs site): .github/documentation-policy.md.

Author checklist (docs changes):

  1. No mandatory content only via external links — cvars, commands, install paths, and workflows a user needs to run CSRetro must appear in docs/ (or be clearly marked as out-of-scope for this project), not only on third-party wikis or doc sites.
  2. Run mkdocs build --strict after substantive edits (install deps from requirements-docs.txt); fix broken links and warnings before pushing.
  3. Update Documentation coverage when you add a major new topic or audience-facing surface.