核心开发人员指南

欢迎，新的核心开发人员！核心团队赞赏您的工作质量，并乐于与您合作；因此，我们邀请您加入我们。感谢您到目前为止为该项目做出的众多贡献。

本文档为您的新角色提供了指导原则。首先也是最重要的，您应该熟悉项目的使命、愿景和价值观。如有疑问，请随时参考此处。

作为核心团队成员，您有责任在评审过程中指导其他贡献者；以下是一些指导原则。

对所有贡献者一视同仁

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

作为核心贡献者，您可以合并或批准其他贡献者的Pull请求。就像核发射钥匙一样，它是一种共享的力量：你必须合并 仅在之后 另一个核已经批准了拉取请求， and 在你自己仔细审阅过之后。(见下文的sec：revising，特别是sec：indern。)为了确保干净的Git历史，请使用GitHub的 [挤压和合并] [gh_sqmrg] 功能进行合并，除非您有充分的理由不这样做。

回顾

如何做好复习

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

scikit-image 非常重视代码评审中的指导。新用户通常需要更多的牵手，几乎没有git体验。自由地重复你自己，如果你不认识某个贡献者，把他们指给我们的开发指南，或者网络上的其他GitHub工作流教程。不要假设他们知道GitHub是如何工作的(例如，许多人没有意识到添加提交会自动更新Pull请求)。温和、礼貌、善意的鼓励可以决定一个新的核心开发人员和一个被放弃的拉请求之间的区别。

复习时，重点关注以下几点：

  1. API: API是用户第一次使用时看到的内容 scikit-image 。API一旦发布就很难更改，所以应该简单， [功能] [wiki_functional] (即非进位状态)，与库的其他部分一致，并应避免修改输入变量。请熟悉一下这个项目的 [弃用策略] [dep_pol]

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

  3. 算法如下： 在批准代码之前，您应该了解要修改或添加的代码。(见下文秒：理解。)实现应该做它们声称的事情，并且是简单、可读和高效的。

  4. 测试： 对类库的所有贡献 must 被测试，并且添加的每一行代码都应该由至少一个测试覆盖。好的测试不仅可以执行代码，还可以探索最基本的情况。不复习测试是很有诱惑力的，但请这样做。

Other changes may be nitpicky: spelling mistakes, formatting, etc. Do not ask contributors to make these changes, and instead make the changes by pushing to their branch or using GitHub’s suggestion feature. (The latter is preferred because it gives the contributor a choice in whether to accept the changes.)

我们的默认合并策略是将所有PR提交压缩到一个提交中。希望从以下位置带来最新更改的用户 master 应该建议合并成自己的分支机构，而不是改编基地。即使出现合并冲突，也不要要求更改基础，除非您知道某个贡献者有使用GIT的经验。相反，您可以自己调整分支的基础，强制推送到他们的分支，并建议贡献者如何强制拉动。如果贡献者不再活动，您可以通过提交新的拉取请求并关闭原始分支来接管他们的分支。在这样做的过程中，请确保您没有丢弃贡献者的成果！

请在推送新更改后向推送请求添加备注；GitHub不会为这些更改发送通知。

仅合并您理解的更改

Long-term maintainability 是一个重要的问题。代码不只是必须 work ，但应该是 明白了 由多个核心开发人员提供。未来将不得不做出改变，最初的贡献者可能已经离开了。

所以呢， 除非您了解代码更改，否则不要合并代码更改 。自由地寻求帮助：我们咨询社区成员，甚至外部开发人员，以在需要的地方获得更多的见解，这是一个很好的学习机会。

而我们集体“拥有”任何补丁(和错误！)成为代码库的一部分，您就是在为您合并的更改提供担保。请认真对待这一责任。

在实践中，如果您是审查和批准给定Pull请求的第二个核心开发人员，您通常会在您批准之后将其合并(同样，使用GitHub的Squash and Merge功能)。这一过程有哪些例外？如果Pull请求特别有争议，或者是很多争论的主题(例如，涉及API更改)，那么您可能希望在合并之前等待几天。这段等待时间让其他人有机会在他们对拉请求的当前状态不满意的情况下直言不讳。另一种例外情况是，第一次批准审查发生在很久以前，在此期间发生了许多变化。

结束问题和拉回请求

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

  • 最初帖子背后的人没有回应要求澄清的呼吁，核心开发者也都无法重现他们的问题；

  • 解决这个问题是困难的，而且它被认为是一个太小的用例，无法投入持续的努力或优先于其他问题；或者

  • 用例或特征请求是核心开发者认为不属于SCRKIT-IMAGE的东西，

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

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

  • Pull请求实现了一个有用的功能，但需要付出巨大的努力才能达到SCRIT-IMAGE的标准，而且最初的贡献者已经离开了，并且找不到其他开发人员进行必要的更改；或者

  • Pull请求做出了与我们的值不一致的更改，例如显著增加函数的代码复杂性以实现边际加速比，

还有其他的。

所有这些都可能是关闭的正当理由，但我们必须小心，不要在没有任何解释的情况下关闭问题或拉回请求，从而疏远贡献者。结束时，您的信息应：

  • 清楚地解释是如何做出结案决定的。当决定是在社区会议上作出时，这一点尤其重要，因为社区会议没有关于问题本身的评论帖子那样明显的记录；

  • 感谢投稿人的工作；以及

  • 为投稿人或其他任何人提供一条明确的途径来对决定提出上诉。

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

进一步的资源

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

  • 我们的投稿人指南

  • 我们的 [社区指南] (https://scikit-image.org/community_guidelines.html)

  • [PEP8] (https://www.python.org/dev/peps/pep-0008/)表示PYTHON样式

  • [PEP257] (https://www.python.org/dev/peps/pep-0257/)和 [NumPy文档指南] [数字多克] 用于文档字符串。(NumPy文档字符串是PEP257的超集。这两本书你都应该读一读。)

  • SCRKIT-IMAGE [StackOverflow上的标记] [so_tag]

  • SCRKIT-IMAGE [Forum.Image.sc上的标签] (https://forum.image.sc/tags/scikit-image))

  • 我们的 [邮件列表] [ml]

  • 我们的 [聊天室] (https://skimage.zulipchat.com/))

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

邀请新的核心成员

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

为本指南贡献自己的力量！

本指南反映了当前核心开发人员的经验。到目前为止，我们很可能遗漏了一些已经成为第二天性的东西--作为新团队成员，你会更容易发现的东西。如果您有任何问题，请咨询其他核心开发者，并提交一个拉取请求，并获得洞察。

结论

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