维护者指南
内容
维护者指南¶
本页描述了Dask维护者的最佳实践。
感谢您帮助使 Dask 成为一个有用的库，并培养一个热情友好的社区。
合并拉取请求¶
拉取请求应被审查¶
非维护者的拉取请求应在合并前至少由一名维护者审核和批准。
理想情况下，维护者的拉取请求在合并之前也应该经过审查。然而，由于审查者的带宽有限，如果拉取请求的内容被视为无争议（例如，拼写错误修复），维护者有时会自行合并他们的拉取请求。如果维护者有一个重大的拉取请求尚未得到审查，他们应该至少联系一个可能对提议的更改感兴趣的团队或个人维护者。如果在一段时间后没有回应，并且维护者对提议的更改有信心，他们应该发布一条类似“如果48小时内没有进一步回应，将合并”的最终评论，然后在指定的时间段内如果没有进一步的评论，则自行合并。请至少留出48小时，以便其他时区的维护者有时间回应。
维护者不应合并他们未来不感到支持舒适的拉取请求。
CI 应该通过¶
在合并拉取请求之前，维护者应尽一切努力确保 CI 通过。通常这需要查看失败运行的日志以了解出了什么问题，并提醒拉取请求的作者。理想情况下，如果存在 CI 失败，则不应合并拉取请求，因为 main 中的 CI 失败很容易掩盖其他 PR 的问题，并且持续的 CI 失败可能会打击维护者的士气。
然而，在实践中，偶尔会有不稳定的测试、上游依赖的损坏，以及明显与当前PR无关的失败。如果是这种情况，维护者可能会合并一个测试失败的PR，但他们应该准备好跟进任何由此类不安全操作导致的失败。
压缩合并拉取请求¶
在合并拉取请求时使用压缩合并，而不是其他合并策略，如变基合并。为了简化这一过程，在仓库的GitHub设置中已禁用了所有非压缩合并策略。
使用干净的合并提交¶
Dask 旨在拥有一个简单但有意义的 git log。为了实现这一点，维护者确保在合并之前，压缩合并提交的标题和（可选的）消息能够有意义地反映拉取请求的内容。例如，一个合并提交标题为“fix typo”的应该更新为类似“修复 Array.max 文档字符串中的拼写错误”的内容。
请注意，当使用 squash 合并拉取请求时，GitHub 默认会通过连接相应拉取请求中的所有单独提交消息来预填充 squash 提交消息。根据拉取请求作者在开发过程中的谨慎程度，此默认消息可能会非常冗长且不够描述性。例如:
* Fix DataFrame.head bug
* Handle merge conflicts
* Oops, fix typo
如果是这种情况，合并拉取请求的维护者应该：
编写他们自己的合并提交消息，描述拉取请求中的更改（如果他们有可用带宽）。
将合并提交信息留空（再次确保提交标题是有意义的）。