英文版：CONTRIBUTING.md（提 issue 要附什么、提 pull request 的规则、补丁队列都在那里）。在终端里手动构建（工具、prod.keys、IPA）见 BUILDING.zh-CN.md。下面是帮忙补充游戏。
每款新游戏都需要单独的 bring-up：profile（build ID、内存布局、纹理槽位）、必要时的 shader 读取器、 以及补丁点。两种帮忙方式，都有用：
- 报告一款能跑的游戏 —— 如果你让验证清单之外的游戏跑起来了，开 issue 附上 title ID、更新版本和 你做的步骤，它会变成一个别人也能用的 profile。
- 提交缺失的着色器 —— 如果游戏能跑但首次使用某个效果时卡顿，说明它的 shader 变体不在映射表里。
宿主可以导出找不到的部分（
DM_NVN_SHDUMP=<dir>）。附上它们，我们把它加进shader_map.tsv， 所有人都受益。
带完整 Documents/log.txt 的 issue 会优先看——那份日志通常能直接指出缺的是什么。
提 pull request 的基本规则（一个 PR 一项改动、PR 模板、截图、引擎与补丁）见英文版。下面是外部贡献者的 PR 如何处理。
修复无需事先询问，直接提交即可。
功能可以直接以 pull request 的形式提交。它需要一个描述该想法的 issue，请在维护者第一次回复后的 48 小时内写好。合并前需要一位维护者认可这个想法。如果始终没有人写这个 issue，PR 会被关闭，并附一条说明，之后可以重新打开。PR 不会因为缺少 issue 而在提交时就被关闭。
想在写代码之前先聊聊想法，请用 Discussions。
来自外部的 pull request 不会自动合并。一位维护者会试用 CI 为这个 PR 构建的应用，也就是 Build Mac app 这次运行的 NX2Apple-macOS-arm64 构建产物。同一位维护者也会审查代码。谁先看到，谁来决定。
如果维护者不想要某项改动，会尽早说明，解释原因，并关闭该 PR。他们可以保留其中一部分，并把你列为共同作者。
PR 如果等待作者回复满 30 天，会被关闭，并附一条说明，之后可以重新打开。
以下对所有 PR 都适用。来自外部的 PR 还要经过上面的维护者检查，检查之前绝不合并。
每个修复都通过 PR 提交。修复在 CI 通过后合并，不需要批准。
维护者提出的、尚未处理的“要求修改”审查会阻止合并。普通的审查评论不会阻止。推送修复后，提出要求的维护者会再次审查，批准或撤回该要求。每位维护者清除自己的异议。如果两位维护者对某个异议有分歧，由 Andy（@LNPANDY）决定。
维护者（v0lumehi 和 LNPANDY）的功能在 48 小时后合并。来自外部的功能不会靠等待合并，要在维护者认可想法、试用应用并审查代码之后才合并。
patches/ 中的补丁在合并时取 main 上 patches/series 的下一个空闲编号。执行合并的人负责重新编号，并在 PR 中注明。你不需要为了追空闲编号而反复 rebase。