关于应对无响应 PR 的措施

[dovisutu]

之前在群里提到过的想法，写了一个草案，挂在这里

关于应对审阅后无响应 PR 的措施（“7+7”原则）

内容：

• 向本库提交的 PR 在一般情况下遵循“7+7”原则：
  • 在审阅人提出审核要求后*（不包括使用/add-mapping等指令纯操作CFPABot）*，如果提交者7天内没有做出任何回应，审核者可以ping一次提交者，然后加上“即将被搁置”标签，并转入“7+7”第一阶段；
  • 若进入“7+7”第一阶段后，7天内仍无任何实质回应，则将视作提交者 暂时 无法回应，并转入“7+7”第二阶段。此时，PR将被加上“即将拒收”标签。审核者可以将无需 PR 作者参与的审核意见直接应用，并终止计时，进入合并流程。如果初始要求是必须由提交者参与的，此时审核者可直接关闭该提交；
  • 若进入“7+7”第二阶段后，1天内仍无任何实质回应，则 PR 将被自动关闭。
• 若在任何阶段，提交者做出实质性回应，或表示自己暂无法解决审核要求，可以由审核者协助，则自动终止上述计时，并清除相应标签。
  • 特别的，如果提交者明确声明，在无需提交者参与的情况下可以不启用该计时，由多个审核者直接解决审核要求。

为什么要这么做？

简单地说：有些提交的 PR 审核周期过长了，造成了 PR 挤压现象。

具体而言，由于提交堆积过多，有许多的提交在终于等到审核时，提交者却忘记了还有它的存在；还有的时候，部分“不太负责”的提交者干脆选择将自己的提交 “莳也若子，置也若弃”，使得审核周期根本无法进行。这些都加剧了提交堆积的情况。
因此，或许是时候做出一点改变了。

提交者应该怎么做？

• 如果你有解决审核要求的条件：
  • 直接解决就好。只要你及时回复，一切如常。
• 如果没有这样的条件：
  • 没有关系，其实审核往往也没有时间
    可以在PR中指出自己可能难以参与审核过程；我们会试图解决问题，当然如果实在解决不了可能还是需要提交者协助。
• 如果你的提交被关闭了：
  • 或许你只是突然找到了时间，或者突然想起来还有这个提交。不管怎样，还可以重新打开提交，做出相应的更改，审核周期还可以继续。如果你觉得旧提交不太适合了，也可以创建新提交，只要提及一下旧提交即可。

---

补充一点：审阅人可以在相应阶段适时引用该issue，当然也可以不引用。

此外，7+7的两个阶段会使用相应标签做出区分（need author action和changes required）

关于应对同一模组在 PR 列表存在多个翻译的措施（“3+7”原则）

内容

• 同时有多个翻译同一模组的 PR 时，一般遵循“3+7”原则。
  • PR Open 后1个月内仍未有审阅人前来提出审核要求，且 PR 列表中还存在此模组的另一翻译，且质量更高、基于模组版本更高的情况下，如果提交者3天内没有做出任何回应，审核者可以ping一次提交者，并转入下一阶段；
  • 若 ping 后7天内仍无任何回应，则将视作提交者 暂时 无法回应，此时，此时审阅人可直接关闭该提交。
• 若在任何阶段，提交者做出实质性回应，则自动终止上述计时；若表示自己并无更新的意向，则视为放弃提交，此时，此时审阅人可直接关闭该提交。

为什么要这么做？

有些提交的 PR 搁置周期过长了，造成了 PR 挤压现象。

提交者应该怎么做？

• 如果你有解决的条件：
  • 直接解决就好。只要你及时回复，一切如常。
• 如果没有这样的条件：
  • 没有关系，可以在PR中指出自己可能难以更新已有翻译；我们会试图解决问题，当然如果实在解决不了可能还是需要提交者协助。
• 如果你的提交被关闭了：
  • 或许你只是突然找到了时间，或者突然想起来还有这个提交。不管怎样，还可以重新打开提交，进行翻译的更新或是修改，审核周期还可以继续。如果你觉得旧提交不太适合了，也可以创建新提交，只要提及一下旧提交即可。

---

补充一点：审阅人可以在相应阶段适时引用该issue，当然也可以不引用。

此外，3+7的两个阶段会使用相应标签做出区分（need author action和即将拒收）

[Cactusstudent]

我觉得changes require和need author action还是得稍微分一分使用的情况

[dovisutu]

也可以，只不过得先写个草案出来
目前我的用法是看数目不看名字......
红色的标签甚至还有ready to reject和machine translated（当然后面这个有显著的意义）

[Cactusstudent]

突然想起这个Issue，来说几句 （绝对不是忘了）
我是觉得changes require偏技术性问题（？）例如少标点，路径错误，或者有一些关于打包的之类的问题
need author action就是偏向内容（？）例如全半角符号错误，多个空格少个空格，翻译错误

[dovisutu]

不过这么说的话感觉改一改标签名字/再加几个可能更准确一些？虽然现在标签已经够多了

[Cactusstudent]

虽然现在标签已经够多了

该删的可以删一删，要加的label我觉得可能是outdate（之前那个obsolete简直被咱们忘得干干净净）而且感觉label里面还有不少重复的

[Cactusstudent]

大概整理了下Label，
需删除：hard/laborious duplicate（原因，用处极少，貌似就没用到过）need review re-review
需要更改的是：obsolete->outdated（这样好点，obsolete的意思有点多，不知道指的是那个，这样明确点）
需要斟酌的：Config与configuration MCreator（原因，现在有了sort-key以及diff，审核不再是个难事，留着其实也没啥大必要，主要还是得咱们自己加）
（或许加个不太常用的featurelabel也行）

[Cactusstudent]

如果真的要改，也请多叫几位维护者，询问他们的意见

[dovisutu]

need review和re-review确实暂时用不到，以后用到了再加？
duplicate或许可以标记撞车的pr？（

---

突然想起来，以前那些工单的怎么联系作者......要不有大问题的直接关了

---

如果新的PR里面有这些模组汉化，就Close吧？然后在新的PR合并的时候加个协作

也行，只要找得到工单作者的标记邮箱
如果找不到就只能在commitmsg里手动声明了

[Cactusstudent]

工单交上来的全是巨大无比的……审核起来也很难弄，如果新的PR里面有这些模组汉化，就Close吧？然后在新的PR合并的时候加个协作

[Cactusstudent]

试行了一个月，貌似效果还不错，说不定可以改改然后让这玩意转正？

[dovisutu]

可以改改

那么你有什么意见吗？
我感觉把标签修订实装了就差不多了

[Cactusstudent]

顺便说到神化这个模组的中文，那我觉得加一条，若PR Open后1个月后仍未有审核review且已有相比原先PR更新的PR，那么原先PR（在提醒作者3天后不回应）将会在7天后直接close，若较新的pr打算合并，则应在最新的PR处加上协作（这个简称3+7）

[ChuijkYahus]

顺便说到神化这个模组的中文，那我觉得加一条，若PR Open后1个月后仍未有审核review且已有相比原先PR更新的PR，那么原先PR（在提醒作者3天后不回应）将会在7天后直接close，若较新的pr打算合并，则应在最新的PR处加上协作（这个简称3+7）

我觉得这是好的

[ChuijkYahus]

现在有好几个这样的pr了
Ad Astra Pyromancer 神化都是

[mamaruo]

可以转正，谁来写一份符合CONTRIBUTING格式的文稿，扔到文档更新分支里去

• 贡献方针大修；简化包内 README #2857