Files
Claude 6a3441b616 Docs: credit ported work and cover today's merged changes
Add CREDITS.md, listing the projects the fork is built on and every
change ported from upstream WiiCompiled and other forks, with author and
source commit, taken from the commit messages. Link it from the README,
THIRD-PARTY-NOTICES.md and a new porting note in CONTRIBUTING.md.

Document adaptive_resolution in OPENXR.md, the 4 KiB page constant and
NEON mixing in the README, the Mozilla CA bundle in the notices, and draft
the frame-beta-3 release notes for what PRs #5 to #10 merged.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Axv1Y43Lu5a5rSSLUyU5BB
2026-10-05 16:22:20 +00:00

2.7 KiB

Contributing to WiiCompiled

Thanks for wanting to help! A few ground rules

The short version

  • Code is judged on quality, not where it came from
  • You must be able understand and be able to explain every line you submit.
  • PR descriptions and responses must be written by you, not generated.
  • Accuracy is the bar for anything touching game behavior.

Code quality

We don't care how your code came into existence. What we care about is whether it meets or improves the project's patterns and standards, and the only way we measure that is by reading it.

Low-quality code won't be merged, regardless of origin. AI slop and human slop get the same treatment.

If you use AI tools

That's ok, but rules apply:

  1. You must be able to explain your changes. If a reviewer asks why a line exists or what a function does and you can't answer, the PR will be closed. "The AI wrote it" is not an explanation.
  2. Write your own PR description. The description exists so reviewers know what you changed and why, in your words. Generated descriptions tend to describe everything and explain nothing, and they will get your PR closed.

Pull requests

  • Keep PRs focused. try and keep it at 1 change per PR. Small PRs get reviewed fast.
  • Explain what and why. Reference the issue if there is one.
  • For anything affecting game behavior: identical behavior to real hardware is the goal. Be prepared to show your change doesn't diverge from the original game (hardware comparison, logs, whatever fits).
  • Review feedback. It's about the code, not about you ;).

Porting from other projects

This fork takes fixes from upstream WiiCompiled and other forks. When you port one:

  • name the source repository and commit in the commit message ("Ported from owner/repo abc1234");
  • keep the original author on the commit when the change is taken as is, and say what you changed when it is adapted;
  • add a line to CREDITS.md, and check the source's license is compatible with GPL v3.0.

Bug reports

See Reporting problems in the README.

WiiCompiled, Wheel Wizard, and other projects in this ecosystem are developed independently and each has its own contribution rules and all have their own rules around AI usage. What applies here does not automatically apply there, and vice versa. Check each project's own CONTRIBUTING file.

  • Never!!! include Nintendo code, assets, or game data in a PR, an issue, or anywhere else in this project. No exceptions.
  • By contributing, you agree your contributions are licensed under GPL v3.0, like the rest of the project.