Skip to main content
Follow these guidelines when submitting changes to the s&box engine. They exist to keep the review process fast and predictable.
When filing a bug report:
  • Do not report bugs in games or addons — contact the project author instead.
  • Be thorough. Include everything relevant: platform, reproduction steps, expected behaviour, and actual behaviour.
  • Provide a minimal step-by-step to reproduce the issue if you can.
  • Search existing issues before opening a new one.
For Proton/Linux compatibility issues, refer to the Proton compatibility tracker rather than opening a new issue here.
When requesting a feature:
  • Explain the problem it solves and what you’ve already tried.
  • Search existing issues to avoid duplicates.
  • New features need a proposal issue and community discussion before implementation begins. Don’t start coding before the idea is accepted.
Bug fixesReference any applicable bug report in your pull request description. Explain what the problem was and how your change fixes it. Unit tests are strongly encouraged where applicable.New featuresStart from an accepted proposal issue. Keep the implementation scoped to what was discussed.
Your editor should pick up the project’s formatting rules from .editorconfig automatically.To apply formatting from the command line:
dotnet format
Do not submit PRs that mix functional changes with unrelated reformatting. If you need to fix formatting in a file, do it in a separate commit or PR.
ScopeKeep pull requests focused. Avoid bundling unrelated changes together — reviewers should be able to understand and verify each PR on its own.Commits
  • Group related changes into a single commit.
  • Write a concise subject line that describes what the commit does.
  • Add a longer body if the change needs more explanation.
  • Remove noise commits (e.g. “fix typo”, “oops”) by squashing before opening the PR.
SquashingSquash commits together where appropriate so the history stays readable. A PR that fixes one bug should generally land as one commit.

Build docs developers (and LLMs) love