核心开发者指南#

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

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

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

所有贡献者一视同仁#

你现在可以直接将更改推送到主分支，但绝不应该这样做；相反，继续像以前一样并根据 一般贡献者指南 提交拉取请求。

作为核心贡献者，您获得了合并或批准其他贡献者拉取请求的能力。这就像核发射钥匙一样，是一种共享的权力：您必须在另一位核心成员批准拉取请求之后，并且您自己已经仔细审查之后，才能进行合并。（参见 审核 和下面的 只合并你理解的变化。）为了确保干净的 git 历史记录，请使用 GitHub 的 [Squash and Merge][gh_sqmrg] 功能进行合并，除非您有充分的理由不这样做。

审核#

如何进行一次好的评审#

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

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

在审查时，请关注以下内容：

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

  2. 文档: 任何新功能都应有一个图库示例，这不仅展示了功能，还解释了它。

  3. 算法： 在批准修改或添加的代码之前，你应该理解这些代码。（见下面的 只合并你理解的变化。）实现应该如其所声称的那样，并且应该简单、可读和高效。

  4. 测试： 对库的所有贡献 必须 经过测试，并且每增加一行代码至少应有一个测试覆盖。好的测试不仅执行代码，还探索边缘情况。虽然不审查测试很诱人，但还是请这样做。

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

  6. 已确立的方法： 通常，我们希望包含那些在文献中得到充分记录、被成像社区广泛使用的算法和方法。虽然这不是一个硬性要求，但新的贡献应与 我们的使命 保持一致。

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

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

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

只合并你理解的变化#

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

因此，除非你理解代码更改，否则不要合并。随时寻求帮助：我们有着长期咨询社区成员，甚至在需要时咨询外部开发者的历史，并将此视为一个极好的学习机会。

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

在实践中，如果你是第二个核心开发者审查并批准某个拉取请求，你通常会在批准后合并它（同样，使用GitHub的Squash and Merge功能）。这个过程有哪些例外情况？如果拉取请求特别有争议或引起了很多讨论（例如，涉及API更改），那么你可能希望在合并前等待几天。这段时间给了其他人一个机会，如果他们对拉取请求的当前状态不满意，可以提出意见。另一个例外情况是，第一次批准审查发生在很久以前，期间发生了许多变化。

当压缩提交时，GitHub 会将所有提交信息连接起来。请编辑生成的信息，使其提供简洁、整洁的变更概述。例如，您可能希望从 PR 本身获取描述，并删除诸如“pep8 修复”、“应用评审意见”等行。请保留所有 Co-authored-by 条目。

关闭问题和拉取请求#

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

  • 原始帖子的发布者没有回应澄清的请求，核心开发者中也没有人能够重现他们的问题；

  • 解决这个问题很困难，并且它被认为是一个过于小众的使用案例，不值得投入持续的努力或优先于其他问题。

  • 用例或功能请求是核心开发者认为不属于 scikit-image 的内容。

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

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

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

  • 这个拉取请求做出的更改与我们的价值观不符，例如为了实现微小的速度提升而显著增加函数代码的复杂性。

等等。

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

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

  • 感谢贡献者的工作；以及

  • 为贡献者或其他任何人提供一个清晰的途径来申诉该决定。

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

更多资源#

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

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

邀请新核心成员#

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

为这份指南贡献力量！#

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

结论#

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

On this page
显示源代码