核心开发者指南#

欢迎，新的核心开发者！核心团队感谢您工作的质量，并享受与您合作的过程；因此，我们邀请您加入我们。感谢您迄今为止对该项目的众多贡献。

本文档为您新角色提供指导方针。首先，您应该熟悉项目的使命、愿景和价值观。如有疑问，请始终参考此处。

作为核心团队成员，您有责任引导其他贡献者完成审查过程；以下是一些指导方针。

所有贡献者都受到同等对待#

您现在可以直接将更改推送到主分支，但不应该这样做；相反，应像以前一样并按照一般贡献者指南继续创建拉取请求。

作为核心贡献者，您有权合并或批准其他贡献者的拉取请求。就像核发射密钥一样，这是一种共享权力：您必须仅在另一位核心成员批准该拉取请求且您自己仔细审查后才能合并。（请参阅下面的审查，尤其是仅合并您理解的更改。）为确保干净的 git 历史，请使用 GitHub 的Squash and Merge功能进行合并，除非您有充分的理由不这样做。

审查#

如何进行良好的审查#

始终对贡献者友善。scikit-image 几乎所有的工作都是志愿者完成的，我们对此深表感激。对想法和实现提供建设性的批评，并提醒自己，当您自己的工作作为新手被评估时，您的感受如何。

scikit-image 非常重视代码审查中的指导。新用户通常需要更多帮助，他们几乎没有 git 经验。请反复说明，如果您不认识贡献者，请将其指向我们的开发指南或网络上其他 GitHub 工作流教程。不要假设他们知道 GitHub 的工作原理（例如，许多人没有意识到添加提交会自动更新拉取请求）。温和、礼貌、友善的鼓励可以决定一位新的核心开发者和一个被放弃的拉取请求。

审查时，请关注以下几点

  1. API： API 是用户首次使用 scikit-image 时看到的内容。API 一旦发布就很难更改，因此应该简单、功能化（即不携带状态）、与库的其他部分保持一致，并应避免修改输入变量。请熟悉项目的弃用策略

  2. 文档：任何新功能都应该有一个图库示例，不仅说明而且解释它。

  3. 算法：在批准代码之前，您应该了解正在修改或添加的代码。（请参阅下面的仅合并您理解的更改。）实现应按照其声明的方式执行，并且应该简单、可读和高效。

  4. 测试：对库的所有贡献必须经过测试，并且每一行添加的代码都应至少有一个测试覆盖。好的测试不仅执行代码，而且探索了极端情况。不审查测试是很诱人的，但请务必这样做。

  5. 许可：新贡献应在与scikit-image 许可相同的许可下或与该许可兼容。BSD 兼容许可的示例包括MIT 许可和Apache 许可 2.0。如有疑问，请向团队寻求帮助。如果您（贡献者）不是提交代码的版权持有人，请要求原始作者批准并在 LICENSE.txt 中包含他们的姓名。您可以使用该文件中的其他条目作为模板。

  6. 已建立的方法：一般来说，我们希望包括已建立、文献资料完善且被成像社区广泛使用的算法和方法。虽然这不是硬性要求，但新的贡献应与我们的使命保持一致。

其他更改可能是挑剔的：拼写错误、格式等。不要要求贡献者进行这些更改，而是通过推送到他们的分支或使用 GitHub 的建议 功能来进行更改。（后者是首选，因为它让贡献者可以选择是否接受更改。）

我们的默认合并策略是将所有 PR 提交压缩为单个提交。希望将 main 的最新更改引入其分支的用户应被建议进行合并，而不是变基。即使出现合并冲突，除非您知道贡献者有 git 经验，否则不要要求变基。相反，请您自己变基分支，强制推送到他们的分支，并建议贡献者如何强制拉取。如果贡献者不再活跃，您可以通过提交新的拉取请求并关闭原始拉取请求来接管他们的分支。在此过程中，请确保您传达出您并非抛弃贡献者的工作！

在您推送新更改后，请在拉取请求中添加注释；GitHub 不会为此发送通知。

仅合并您理解的更改#

长期可维护性是一个重要的考虑因素。代码不仅必须工作，还应被多个核心开发者理解。将来必须进行更改，并且原始贡献者可能已经离开。

因此，除非您理解代码更改，否则不要合并它。请随时寻求帮助：我们长期以来一直咨询社区成员，甚至外部开发人员，以在需要时获得更多见解，并将此视为一个很好的学习机会。

虽然我们共同“拥有”任何成为代码库一部分的补丁（和错误！），但您是在为合并的更改提供担保。请认真对待该责任。

在实践中，如果您是第二个审查和批准给定拉取请求的核心开发者，您通常会在批准后立即合并它（再次使用 GitHub 的 Squash and Merge 功能）。此过程有哪些例外情况？如果拉取请求特别有争议或经过多次辩论（例如，涉及 API 更改），那么您可能需要等待几天再合并。此等待时间让其他人有机会在他们对拉取请求的当前状态不满意时发言。另一种特殊情况是第一次批准审查发生在很久以前，并且在此期间发生了许多更改。

压缩提交时，GitHub 会连接所有提交消息。请编辑生成的消息，使其对更改提供简洁、整洁的概述。例如，您可能希望从 PR 本身获取描述，并删除诸如“pep8 fix”、“apply review comments”等行。请保留所有 Co-authored-by 条目。

关闭问题和拉取请求#

有时，必须关闭未完全解决的问题。这可能是由于多种原因造成的

  • 原始帖子背后的人员没有回应澄清要求，并且没有核心开发者能够重现他们的问题；

  • 修复该问题很困难，并且认为它过于小众，无法投入持续的精力或优先于其他问题；或者

  • 核心开发者认为该用例或功能请求不属于 scikit-image，

等等。同样，有时需要关闭拉取请求而不进行合并，因为

  • 拉取请求实现了一个小众功能，我们认为不值得增加维护负担；

  • 拉取请求实现了一个有用的功能，但需要大量精力才能达到 scikit-image 的标准，并且原始贡献者已经离开，并且找不到其他开发者进行必要的更改；或者

  • 拉取请求进行的更改不符合我们的价值观，例如为了实现边际加速而显着增加函数的代码复杂性，

等等。

所有这些都可能是关闭的有效原因，但我们必须注意不要在没有解释的情况下关闭问题或拉取请求而疏远贡献者。关闭时，您的消息应

  • 清楚地解释如何做出关闭决定。当该决定是在社区会议上做出时，这一点尤其重要，该会议不像问题本身的评论线程那样具有可见的记录；

  • 感谢贡献者的工作；并且

  • 为贡献者或任何其他人提供明确的途径来对该决定提出上诉。

这些要点有助于确保所有贡献者都感到受欢迎，并有权继续贡献，无论过去的贡献结果如何。

更多资源#

作为核心成员，您应该熟悉社区和开发者资源，例如：

您不需要监控所有的社交资源。

邀请新的核心成员#

任何核心成员都可以提名其他贡献者加入核心团队。提名在私人电子邮件列表skimage-core@discuss.scientific-python.org上进行。在撰写本文时，关于谁可以被提名没有硬性规定；至少，他们应该：参与该项目至少六个月，贡献了自己的重要更改，为他人工作的讨论和审查做出贡献，并以符合我们社区价值观的方式进行协作。

为本指南做出贡献！#

本指南反映了当前核心开发人员的经验。我们很可能遗漏了一些现在已经成为第二天性的东西——作为新团队成员的您更容易发现这些东西。如果您有任何疑问，请咨询其他核心开发人员，并提交包含您所获得见解的拉取请求。

结论#

我们很高兴您加入！我们期待您为代码库和社区做出贡献。提前感谢！