核心开发者指南#

作为核心开发者，您应该继续根据 贡献者指南 提交拉取请求。 您有责任引导其他贡献者通过审查流程。 您应该熟悉我们的 使命与价值观 。 您还有能力合并或批准其他贡献者的拉取请求。 就像核弹发射钥匙一样，这是一种共享的权力：您必须在另一位核心开发者批准拉取请求之后才能合并，*并且*在您自己仔细审查过之后才能合并。（请参阅下面的 审查 和特别是 `只合并您理解的更改`_ 。）为确保干净的 git 历史记录，请使用 GitHub 的 压缩并合并 功能进行合并，除非您有充分理由不这样做。

审查#

如何进行良好的审查#

对贡献者要始终友善。NetworkX 几乎全部是志愿者工作，我们对此非常感激。对想法和实现提供建设性批评，并提醒自己在自己的工作作为新手被评估时的感受。

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

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

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

  2. 文档： 任何新功能都应该有一个画廊示例，不仅说明了功能，还解释了它。

  3. 算法： 在批准之前，您应该了解正在修改或添加的代码。实现应该做到它们所声称的，而且应该简单、可读且高效。

  4. 测试： 所有对库的贡献 必须 经过测试，每添加的代码行都应该至少被一个测试覆盖。好的测试不仅执行代码，还探索边缘情况。审查测试可能不那么诱人，但请务必这样做。

其他更改可能是 吹毛求疵的：拼写错误、格式化、 等等。不要要求贡献者进行这些更改，而是通过 推送到他们的分支进行更改 ， 或者使用GitHub的 suggestion

`功能

<https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request>`_ 。 （最好使用后者，因为它让贡献者可以选择是否接受更改。）

我们的默认合并策略是将所有PR提交压缩为单个提交。 希望将 main 的最新更改合并到他们的分支的用户应被建议合并，而不是变基。即使 出现合并冲突，也不要要求变基，除非你知道贡献者对git有经验。相反，重新设置分支， 强制推送到他们的分支，并告知贡献者如何强制拉取。如果贡献者不再活跃，您可以 通过提交新的拉取请求并关闭原始请求来接管他们的分支。在这样做时，请确保您传达 您并没有丢弃贡献者的工作！您应该在提交消息中使用GitHub的 Co-authored-by: 关键字 为原始贡献者署名。

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

仅合并您理解的更改#

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

因此，不要合并您不理解的代码更改。随时寻求帮助：我们有很长时间向社区成员 请教的历史，甚至向外部开发者寻求需要的额外见解，并将其视为一个很好的学习机会。

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

关闭问题和拉取请求#

有时，必须关闭未完全解决的问题。这可能是出于以下几个原因：

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

  • 修复问题很困难，而且被认为是一个过于特定的使用案例，不值得投入持续的努力或优先考虑其他问题；

  • 使用案例或功能请求是核心开发者认为不适合NetworkX的。

同样，有时需要关闭未合并的拉取请求，因为：

  • 拉取请求实现了我们认为不值得的一项特定功能。

增加了维护负担； - 这个拉取请求实现了一个有用的功能，但需要大量工作才能达到NetworkX的标准，原始贡献者已经离开，找不到其他开发人员来进行必要的更改；或者 - 这个拉取请求做出的更改与我们的价值观不符，比如显著增加函数的代码复杂性以实现微小的加速，

等等。

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

  • 清楚解释关闭决定是如何做出的。当决定是在社区会议中做出的时，这一点尤为重要，因为社区会议没有像问题本身的评论线程那样明显的记录；

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

  • 为贡献者或其他人提供一个明确的申诉途径。

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

更多资源#

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

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

On this page