合并和审查策略#

我们合并和审查的策略描述了我们如何审查彼此的工作，以及我们何时允许他人将更改合并到我们的主代码库中。它试图平衡一些目标

  • 迭代 PR 并相对快速地合并它们，以减少与长期 PR 相关的债务。

  • 留出足够的时间让其他人提供他们的意见并指导 PR 本身，并确保我们不会通过 PR 造成问题。

  • 重视迭代改进而不是创建完美的拉取请求，这样我们就不会让贡献者负担繁重的讨论和微小的修改请求。

  • 认识到我们所有人都有有限的时间和资源，因此不能保证每次都进行完整的质量保证流程。

  • 普遍优先考虑 PyData 生态系统中项目的维护者的意见，因为他们是该主题的关键利益相关者群体。

我们遵循以下指南来实现这些目标

  • 假设所有维护者都是善意行事，并将尽其所能做出对存储库最有利的决定。

  • 我们会犯错误，因此鼓励测试和文档的最佳实践以防止这种情况发生。

  • 分享信息很重要，所以尽力告诉其他人你正在做的事情。

  • 最好在实施之前在高层面上讨论并达成一致意见，所以尽力为其他人提供时间和邀请他们提供反馈。

中等变化的策略#

这些是针对新功能或现有功能进行适度更改，但不会显着改变主题的默认行为、用户配置等。这是我们进行的大多数更改。

PR 应该

  • 参考（并理想情况下关闭）描述此更改解决的问题的议题。

  • 具有相关的测试和文档覆盖范围。

当满足上述条件时，它们可以被合并，并且发生以下情况之一

  • PR 至少获得了除 PR 作者以外的核心维护者的一个批准

  • PR 作者已表明他们有意合并，除非有反对意见，并且自该评论发布后已过去 48 小时。

主要新功能和重大更改的策略#

这些是会显着改变用户体验或会给代码库增加大量复杂性的更改。

所有上述内容，但 PR **必须** 在合并之前至少获得另一位核心维护者的批准。此外，PR 作者应该付出额外的努力确保相关利益相关者了解更改，以便他们能够评估其影响并提供反馈。

次要更改和错误修复的策略#

这些是用户可能会注意到的少量更改，但以明显改进的方式进行。它们通常不应该接触太多代码行。

更新相关的测试和文档，但 PR 作者可以随时自合并，无需 PR 批准。