讨论：如何调整 Pull Request 合并策略

[LTCatt]

太长不看版

迄今为止的 PR 合并策略是： 为功能性 PR 提供更高的制作优先级，以至于允许插队既有的开发计划。 但在开发时间有限的大前提下，“插队” 策略会导致 issue 堆积，也会打乱原本的开发路线，低需求的 PR 还能插队更重要的功能……所以，这个看上去友好的方案在长远角度考虑下并非好事。

因此，现对 PR 合并策略的调整收集建议。目前我的计划是，一个功能是否拥有 PR 不再影响开发计划，也不再取代功能投票；部分改进有限的 PR 会被直接 Close。不过这也意味着，优先度不高或需求不大的 PR 会长期无法合并，我也无法再为 PR 提供预期合并时间。当然，如果你有更好的点子也欢迎提出。

问题

迄今为止，包括 #4234 的预告，我对大型 PR 的合并策略都是 每个版本均考虑合并一个大型 PR，并且让它们比 “没有 PR 的其他修改” 具有更高的优先度。这使得大型 PR 能尽快得到合并，让社区贡献者不用等待太久。

但在仔细寻思之后，我觉得这一做法实际上存在着隐患。

首先是两个前提：

1. 许多 PR 并不是想象中的一键 Merge 了就完事的。事实上，出于质量考虑，我通常会参考 PR 的实现思路把代码重构一遍，而不是直接 Merge。所以有 PR 的确能大大减少制作时间，不过合并大型功能的工作量也不算小。
2. 由于我主要在开发独立游戏和其他项目，我能用于开发 PCL 的时间并不多，所以制作一个东西就会挤占另一个东西的时间。

那么，优先合并 PR 的策略可能就会带来这些问题：

1. 因为需要优先合并 PR，所以 PR 实际上插队了原本的开发规划，使原本规划的内容被延期。 并且，由于难以预测下个版本是否需要因为 PR 而延后开发规划，我实际上失去了对开发进程的掌控和预期。
2. 由于我能开发 PCL 的时间量相对固定，把时间用来合并大型 PR，那么能处理其他 issue 的时间就会缩短。如果每个版本都忙于合并 PR，最终很多低优先度的 issue 就得一直拖着，长期没法处理。
3. 如果社区为一个投票制作了 PR，那么我就 不得不去 合并它，毕竟 Close 掉就辜负了大家的努力……即使这个功能原本的票数可能很低，或者应不应该做、值不值得做、要怎么做才更好，都还需要进一步讨论。

所以我认为，“优先合并 PR” 的策略虽然看上去是对社区最友好的美好幻景，但实际上并不利于 PCL 的长远发展。

计划

为了解决这些潜在的问题，我正在考虑采用这些策略：

1. 新功能 PR 不再影响开发路线： 如果开发计划的下一步确实就是制作这个功能，才去合并对应的 PR；如果没有计划，就先推迟。不好的一面是，如果 PR 制作的功能暂时没有安排，那就很长时间都无法合并。这可能影响 完成 #1834 导入/导出启动器设置 #4069、本地化：语言、配置项、时间 #4145、支持下载光影包 #4359 等。

2. 不保证合并 PR： 部分 PR 的改进并不大，若以 “在同等时间下对 PCL 做出更大的改进” 的角度考虑，应该把时间拿去修 bug 或是制作重要的功能，而非审阅这些 PR。不好的一面是，这些 “有改进但改进很有限” 的 PR 就得惨遭 Close 了。这可能影响 让工作流编译支持替换 client_id 和 x-api-key #4228 等。

3. PR 不再关闭功能投票： 拥有 PR 不再使对应的功能投票结束。如果 PR 对应的投票一直无人问津，代表并没有那么多人需要这个功能，合并这个 PR 也就自然不会被纳入开发路线中。

4. 鼓励针对 “处理中” 的 issue 的 PR： 在新的策略下，这些 PR 会有最高的优先级，并且这也能确实地减少我的负荷 =。=……

这些并不是最终决定，我希望先听取社区的看法和建议，如果你有更好的点子也欢迎提出！

[allMagicNB]

先开个 prs 分支然后合掉目前稳定 PR，然后自动编译，最后收集用户反馈？（

[Pigeon0v0]

感觉可能会导致正式版没人用（？

[allMagicNB]

感觉可能会导致正式版没人用（？

应该不会，开源版每次打开都弹窗，没有百宝箱。
如果真这么做的话，声明下不可用于制作整合包……？

[Deep-Dark-Forest]

感觉可能会导致正式版没人用（？

应该不会，开源版每次打开都弹窗，没有百宝箱。
如果真这么做的话，声明下不可用于制作整合包……？

为啥要“不可”，可以说“不建议”，有些人喜欢探索新事物（

[LTCatt]

构建 PR 合集分支

我没有额外精力再维护一个分支，不过我再次修改了协议，以允许更大范围的分发，如果大家想的话.jpg

在整合包中使用开源版本

我在协议中禁止了再次分发。
开源版不适合普通玩家使用，单是如果又出了 Log4j 此类漏洞，普通玩家无法收到更新，就已经很完蛋了。

[allMagicNB]

草，突然想起了烧师傅

[pnpn111]

• 支持3、4
• 2和4是否会有些冲突？例如 所有4月1日发布的版本自动视为愚人节版 #3945 应该能解决一些未来的issue，但现在似乎不会被合并？
• 既然pr可以提高一些效率，那么是否可以将部分龙猫自己的开发计划公布到社区由大家提供pr？

出于质量考虑，我通常会参考 PR 的实现思路把代码重构一遍，而不是直接 Merge。

• 既然这样，也许可以提倡pr作者提供一个实现概述帮助龙猫理解？
• 同时提倡pr追随龙猫码风，让一部分pr可以直接合并，或至少不用大改。

[LTCatt]

应当合并 #3945

抱歉，我在主楼找的例子有所不妥，#3945 确实应当合并，我从主楼里删掉了。
如果我认为有合并价值不大的 PR，我会先向社区征集意见，然后再决定是否 Close。

放出开发路线图

近期而言，重心在于清理长期未处理的 issue（或者说，处理中 且优先度不是 推迟 的那些），而非合并 PR 或添加其他新功能。
在 issue 清理差不多后，会制作 CurseForge/Modrinth 的扩展资源支持（资源包/光影等下载），它们在 B 站投票里取得了压倒性的优势（比第二名高出两倍以上）。
我之后也会更频繁地公开未来版本的开发计划。

关于 PR 的实现思路问题

其实主要原因不是代码风格，而是实现思路不一样，或是 PR 作者做的新功能和我预期的效果不一样……
例如 #4206 (comment) ，我对导出整合包功能的 UI 和细节已经有了一套方案，而 PR 作者的实现和我预期的方案差别很大。
或许 PR 作者在开始写 PR 前先问下我，对这个功能有没有既定的计划，会好很多……

[Pigeon0v0]

不考虑代码质量的情况下，从功能角度出发，确实可以考虑开一个分支用于合并 PR，可供新功能快速预览和测试。

问题：目前加了 Action 的情况下，是否可能影响快照版较快更新这一权益？

从草台班子角度出发，可以考虑对票数较低但存在 PR 的功能直接执行合并，但须不影响其他功能。在这样的情况下可以减少工作量，也可以满足部分玩家需求。

问题：不影响其他功能有时较为困难，有时不可避免针对基础模块进行修改。

确实可以考虑放出开发路线图以供社区参考，同时鼓励处理「处理中」Issues 的 PR。除此之外，应该提高修复 Bug 的 PR 的优先级。

对于部分改进有限的 PR，建议先评估工作量再判断是否进一步审阅。例如 #4228 个人觉得合并是有意义的。

其他意见基本与主楼一致。

---

补充：如果是基本复制现有代码，可以考虑让提交者提供参考来源，或许也能减少一点工作量？

[LTCatt]

是否可能影响快照版更新权益

开源版本的目标群体并非普通玩家。目前它只适合技术测试，而非日常使用，所以我觉得还好？

直接合并不影响其他功能的 PR

进投票并不等于 “肯定要做，只是决定顺序”，而是说 “看看这个功能有必要加吗？”
票数低的功能可能造成冗余，或者使得按钮/选项太多，导致小白理解起来更麻烦，所以做不做是要多加斟酌的。
所以，有的 PR 其实是做了我觉得应该不必加的功能，这也是不鼓励做低票数的新功能 PR 的原因，这会让我很尴尬……

提高修复 Bug 的 PR 的优先级

我会固定以 修复中高优先度的 Bug 为最优先事项。
通常我会在修完这些 Bug 后，再把剩下的时间用来做新功能，所以如果修 Bug 花了太久，这个版本可能就没空整新活了。
所以，修复 Bug 的 PR 实际上自然就是最优先事项 =。=

对改进有限的 PR 的审阅

如果我认为有合并价值不大的 PR，我会先向社区征集意见，然后再决定是否 Close。

[Silverteal]

我其实是把 PR 当可以直接标注一些东西在源代码上顺便自己编译出来先玩玩的高级 Issue用的。对于合并与否，是否用我的代码合并，我其实无所谓。

就我的观点，除非像 #4018 这种显而易见的 Bug 修复，影响位置不超过一个代码块的 Commit，目前已经交过的大部分 PR 都是需要重构才能（或者应该）合并的。尤其对于目前的新功能 PR，交互逻辑和实现方式与原版的一致性，似乎都不尽人意。（这也是我对新功能 PR 不怎么感兴趣的原因）从这一方面看，PR 应该和 Issue 作相同对待（事实上他们也共用同一套ID）。

---

简而言之：

1. 将 PR 当作 Issue

[LTCatt]

“将 PR 当作 Issue” 是一个不错的总结，这实际上是正文 1 & 2 & 3 的等效表述。
我觉得更精确地说，应该是 “将 PR 视作工作量相对更小的 issue” ……？

[Silverteal]

此外关于最新版本的 License ，我看着不太对劲：

如果按照3.3，修改后的版本也使用该文件作为协议，那么这个“修改版本”就同样会变成“允许一次分发而不允许二次分发”，从而与原始版本的3.4矛盾。

主要是我不太明白3.3的意图，如果是为了“不能闭源或附条件分发”的话，直接说“如分发衍生作品的编译产物，则该编译产物及其所有源代码必须允许所有人无条件获得”就可以了？

3.4的表述强调“说明”也有点奇怪，我个人更能理解的表述是：
“该衍生作品（包括编译产物）不能被允许用于再次分发或制作整合包”
“不允许授予其它人衍生作品的改编权”

[LTCatt]

3.3 的意图是为了避免 “解除条件分发”，例如 fork 这个存储库，然后把这个 licence 换成例如 WTFPL，从而导致这个协议实质上失效。如果有更好的表述方式我可以直接改……
3.4 的表述修改了。