[v0lumehi]

Fix or feature

• Fix
• Feature

A docs and policy change, waits for @LNPANDY.

What and why

I want to try a friendlier and stricter flow for what comes from outside. New features and proposals get discussed first, so we can help people build what fits, avoid wasted work and conflicts (the launcher code is being reorganized and many open PRs will need a rebase), and agree the design before anyone writes code. Fixes stay welcome without asking. Everything here is about outside contributors. We maintainers keep our own rules.

This changes what @LNPANDY and I agreed on 2026-10-31 for outside feature PRs (PR first, issue within 48 hours). @LNPANDY decides.

What changes:

• CONTRIBUTING.md, "Fixes, features and ideas": two kinds, no sizes. A fix is welcome as a PR without asking. Tests that cover a fix, typos and corrections in docs count as fixes. A report that a game works stays a report, not a feature. Anything else is a feature or a proposal and is always discussed first (a new feature, a change to how the launcher works or looks, a new setting, a new dependency, a new way to build or install, a refactor, a new doc page). Use an issue with "Launcher problem or idea" (An idea) or Discussions, Ideas. The discussion ends when a maintainer says yes and puts the issue into a milestone. An issue in a milestone is the go, no label is needed, and the PR links it. A feature PR without it is not reviewed and is closed with a friendly note after 14 days, it can be reopened. A draft PR as a sketch is fine but waits for the go. For a change across several front ends or the architecture, the issue also holds a short design note (what, why, alternatives). If it is unclear whether something is a fix, the contributor asks in an issue and the maintainers decide. An earlier version of this PR had small, medium and large tiers with an exemption list. That is dropped.
• CONTRIBUTING.md, "Where we would love help": the milestones are the plan, anyone can take any open milestone issue nobody has taken, by commenting that they will build it so a maintainer assigns it. README.md and README.zh-CN.md point to it in "For developers".
• Game profiles are engine code (dm/games/<id>/). "Helping with games" now says: send a new profile or an engine fix to seedds/nxnative first, following their CONTRIBUTING.md, and link it in a Game problem issue here. A report that a game works stays welcome and becomes a GAMES.md entry. When upstream is slow and the game is verified here, a maintainer may bridge it as a patch (Upstream-Status: forwarded) and sends the upstream PR if the contributor cannot.
• config.yml: the nxnative contact link says the profile goes there as a PR.
• AGENTS.md, .github/copilot-instructions.md and the "For AI agents" list: check for an issue in a milestone before building a feature for an outside contributor, and send a profile to seedds/nxnative first. AGENTS.md "Here first, upstream in parallel" only gets one sentence: outside contributors start upstream.
• PR template: one line for an outside feature PR.
• Transition: PRs opened before this rule keep the old path (an issue within 48 hours, one maintainer agrees), for example Overcooked! All You Can Eat: profile and Unity shader keys (patches 0100, 0101) #372, South Park: The Fractured But Whole (01008F2005154000): profile for 1.05 #379, l10n: add complete Italian localization #352, Game language: a System language choice, the default when the game has it #282 and The build runs the first dotnet with an SDK 10, and the .NET row follows it #342. One sentence in CONTRIBUTING.md says so. I did not close, label or comment on any existing PR.

Trade-offs:

• Contributors wait for a go before they build. That can discourage some. The fix path (including tests and docs corrections) and the draft sketch soften it.
• Sending a profile upstream first means the contributor waits for seedds/nxnative. The bridge by a maintainer is the answer when that is too slow.

How seedds/nxnative wants it: their CONTRIBUTING.md asks for one change per PR off main, a new game takes its profile, its note and its row in the games table, and an issue first for large changes. The maintainer often takes a PR in as a reworked commit with Co-authored-by and closes it.

Suggestion, not built: a check in pr-scope.yml that comments on a feature PR without a linked issue.
It would need a way to tell a feature from a fix, so I left it out for now.

Checked

• Tests: None, docs only. The commit and push hooks had nothing to check for these files.
• Visual QA: None, no launcher view changed.
• Run on a device or Mac: None.

Screenshots

None, no visible change.

Scope

• No engine file (dm/, scripts/, docs/, ref/) is added to the repository: a change there is a patch in patches/ (a commit in engine/, then tools/engine.py export, and tools/engine.py check passes), with its Upstream-Status
• A fix to the engine or a game profile also goes to seedds/nxnative as a PR in parallel: this PR's patch says forwarded seedds/nxnative#..., or pending until that PR is open
• A change to a launcher view has before and after screenshots above
• No keys, game files or data extracted from a game in the change or the attachments