核心开发者指南#

作为核心开发人员，您应该继续根据 参与者指南 . 您负责指导其他贡献者完成评审过程。你应该熟悉我们的 使命与价值观 . 您还可以合并或批准其他参与者的请求。就像核发射钥匙，它是一种共享的力量：你必须合并 只在之后 另一个核心开发者已经批准了拉取请求， and 在你自己仔细审阅之后。（参见 Reviewing and especially Merge Only Changes You Understand below.) To ensure a clean git history, use GitHub's Squash and Merge 要合并的功能，除非您有充分的理由不这样做。

复习#

如何进行良好的复习#

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

NetworkX非常重视代码评审中的导师制。新用户通常需要更多的手握，几乎没有git体验。自由地重复一遍，如果你不认识某个贡献者，请让他们参考我们的开发指南或其他有关web的GitHub工作流教程。不要假设他们知道GitHub是如何工作的（例如，许多人没有意识到添加提交会自动更新请求请求）。温柔、礼貌、和蔼的鼓励可以让新的核心开发人员和被放弃的请求区别开来。

复习时，注意以下几点：

  1. API: API是用户第一次使用NetworkX时看到的。API一旦发布就很难改变，所以应该很简单， functional （即不携带状态），与库的其他部分一致，并且应避免修改输入变量。请熟悉项目的 政策 .

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

  3. 算法： 在批准之前，您应该了解正在修改或添加的代码。（参见 Merge Only Changes You Understand 实现应该做到它们声称的那样，并且简单、易读、高效。

  4. 测验： 所有对类库的贡献 must 被测试，并且每增加一行代码都应该被至少一个测试覆盖。好的测试不仅可以执行代码，还可以探索转角情况。不检查测试很诱人，但请这样做。

其他变化可能是 挑剔的 ：拼写错误、格式等。不要要求参与者进行这些更改，而是通过 pushing to their branch ，或使用GitHub的 suggestion feature . （后者是首选的，因为它让参与者可以选择是否接受更改。）

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

请在推送新更改后向请求请求添加注释；GitHub可能不会发送这些更改的通知。

只合并您理解的更改#

Long-term maintainability 是一个重要的问题。代码不仅仅是 work ，但应该是 理解 由多个核心开发者开发。将来必须做出改变，而最初的贡献者可能已经离开了。

因此， 不要合并代码更改，除非您理解它 . 免费寻求帮助：我们有很长的历史，咨询社区成员，甚至外部开发人员，在需要的地方提供更多的见解，并将此视为一个很好的学习机会。

当我们集体“拥有”任何补丁（和bug！）您将为合并的更改提供担保，这将成为代码库的一部分。请认真对待这一责任。

关闭问题和拉取请求#

有时，一个没有完全解决的问题必须得到解决。原因有很多：

  • 原帖子背后的人没有回应要求澄清的呼吁，核心开发者也没有一个能够重现他们的问题；

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

  • 核心开发人员认为用例或特性请求不属于NetworkX，

在其他中。类似地，有时需要在不合并的情况下关闭请求，因为：

  • 拉请求实现了一个利基特性，我们认为不值得增加维护负担；

  • pull请求实现了一个有用的特性，但是需要付出很大的努力才能达到NetworkX的标准，并且原始贡献者已经离开了，并且找不到其他开发人员来进行必要的更改；或者

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

在其他中。

所有这些可能都是结束的正当理由，但我们必须警惕，不要在没有解释的情况下关闭问题或拉取请求，从而疏远了贡献者。关闭时，您的邮件应：

  • 清楚地解释如何做出关闭的决定。当在社区会议上做出决定时，这一点尤为重要，因为社区会议的记录不如对问题本身的评论线索那么明显；

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

  • 为投稿人或其他任何人提供一条清晰的途径来上诉。

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

更多资源#

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

你不需要监控所有的社会资源。