核心开发者指南#

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

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

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

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

您现在有能力直接将更改推送到主分支，但绝不应该这样做；相反，像以前一样继续创建拉取请求，并根据通用贡献者指南进行操作。

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

审查#

如何进行良好的审查#

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

scikit-image非常重视代码审查中的指导。新用户通常需要更多指导，因为他们几乎没有或根本没有 git 经验。请大方地重复自己，并且，如果您不认识某个贡献者，请将他们引导至我们的开发指南或网络上的其他 GitHub 工作流程教程。不要假设他们知道 GitHub 如何工作（例如，许多人没有意识到添加提交会自动更新拉取请求）。温和、礼貌、友善的鼓励可以决定一位新的核心开发者和一个被放弃的拉取请求之间的区别。

审查时，请关注以下内容

API：API 是用户首次使用scikit-image时看到的。API 一旦发布就很难更改，因此应该简单、函数式（即不携带状态）、与库的其他部分保持一致，并且应避免修改输入变量。请熟悉项目的弃用策略
文档：任何新功能都应该有一个图库示例，不仅说明该功能，而且解释它。
算法：在批准代码之前，您应该理解要修改或添加的代码。（请参阅下面仅合并您理解的更改。）实现应该按其声明的那样工作，并且应该简单、可读且高效。
测试：对库的所有贡献都必须进行测试，并且每添加一行代码都应至少包含一个测试。良好的测试不仅执行代码，而且探索极端情况。不审查测试很诱人，但请务必这样做。
许可：新贡献应在与scikit-image 的许可证相同的许可证下可用或与之兼容。BSD 兼容许可证的示例包括MIT 许可证和Apache 许可证 2.0。如有疑问，请咨询团队寻求帮助。如果您（贡献者）不是提交代码的版权所有者，请向原始作者征求许可，并在LICENSE.txt中包含他们的姓名。您可以使用该文件中其他条目作为模板。
已建立的方法：通常，我们希望包含已建立的、在文献中得到良好记录且广泛应用于成像界的算法和方法。虽然这不是一项硬性要求，但新贡献应与我们的使命保持一致。

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

我们的默认合并策略是将所有 PR 提交压缩成单个提交。希望将main中的最新更改引入其分支的用户应被建议合并，而不是重新设置基准。即使发生合并冲突，除非您知道贡献者精通 git，否则不要要求重新设置基准。相反，请自行重新设置基准分支，强制推送到他们的分支，并告知贡献者如何强制拉取。如果贡献者不再活跃，您可以通过提交新的拉取请求并关闭原始请求来接管他们的分支。这样做时，请确保您传达您没有丢弃贡献者的工作！

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

仅合并您理解的更改#

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

因此，除非您理解代码更改，否则不要合并它。请随时寻求帮助：我们有悠久的咨询社区成员甚至外部开发人员以获取必要额外见解的历史，并将此视为一个极好的学习机会。

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

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

压缩提交时，GitHub 会连接所有提交消息。请编辑结果消息，使其简洁明了地概述更改。例如，您可能希望从 PR 本身获取描述，并删除“pep8 修复”、“应用审查意见”等行。请保留所有 Co-authored-by 条目。

关闭问题和拉取请求#

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

原始发帖人未回复澄清请求，并且没有核心开发者能够重现他们的问题；
修复问题很困难，并且认为它是一个太利基的使用案例，不值得投入持续的精力或优先于其他问题；或者
使用案例或功能请求是核心开发者认为不属于 scikit-image 的内容，

等等。同样，拉取请求有时需要在不合并的情况下关闭，因为

拉取请求实现了我们认为不值得增加维护负担的利基功能；
拉取请求实现了有用的功能，但需要付出大量努力才能达到 scikit-image 的标准，并且原始贡献者已离开，并且找不到其他开发者进行必要的更改；或者
拉取请求进行的更改与我们的价值观不符，例如大幅增加函数的代码复杂度以实现边际加速，

等等。

所有这些都可能是关闭的有效理由，但我们必须警惕不要通过在没有解释的情况下关闭问题或拉取请求来疏远贡献者。关闭时，您的消息应

清楚地解释如何做出关闭的决定。当在社区会议上做出决定时，这一点尤其重要，因为社区会议没有像问题本身的评论线程那样可见的记录；
感谢贡献者(们)的工作；以及
为贡献者或任何其他人提供明确的途径来申诉该决定。

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

邀请新的核心成员#

任何核心成员都可以提名其他贡献者加入核心团队。提名通过一个私人的邮件列表进行，skimage-core@discuss.scientific-python.org。截至目前，还没有关于谁可以被提名的硬性规定；至少，他们应该：参与项目至少六个月，做出过重大的贡献，参与讨论和审查其他人的工作，并以符合我们社区价值观的方式进行合作。

为本指南做出贡献！#

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

结论#

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