审查开放拉取请求（PRs）有助于推进项目。我们鼓励项目之外的人也参与进来；这是熟悉代码库的好方法。
评论可以来自NumPy团队之外——我们欢迎领域专家的贡献（例如， linalg 或 fft )或其他项目的维护者。您不需要是NumPy维护人员（有权合并PR的NumPy团队成员）就可以查看。
如果我们还不认识你，可以考虑介绍一下你自己 the mailing list or Slack 在开始查看请求之前。
每一次公关，无论好坏，都是一种慷慨的行为。以积极的评论开场将有助于作者感受到回报，你随后的评论可能会听得更清楚。你也会感觉很好。
如果可能的话，从大问题开始，这样作者就知道他们已经被理解了。抵制诱惑，不要一行一行地去做，或者以一些小的、普遍存在的问题作为开场白。
你是这个项目的代言人，而NumPy不久前就决定了 the kind of project it will be ：开放、有同情心、热情、友好和耐心。是 kind 致贡献者。
不要让完美成为善的敌人，尤其是在文档方面。如果你发现自己提了很多小建议，或者在风格或语法上过于挑剔，那么当所有重要的问题都得到解决时，可以考虑合并当前的公关。然后，要么直接推送提交（如果您是维护人员），要么自己打开后续PR。
如果你需要帮助写评论中的回复，请查看一些 Standard replies for reviewing .
空数组或nan/inf值等意外输入会发生什么情况？
轴或形状参数是否经过测试 int 或 tuples 是吗？
是不寻常的 dtypes 测试函数是否支持这些？
是否应该改进变量名以提高清晰度或一致性？
是否应该添加评论，或者更确切地说，将其删除为无用或无关的评论？
文档是否遵循 NumPy guidelines ? 文档字符串的格式是否正确？
代码是否遵循NumPy的 Stylistic Guidelines 是吗？
如果您是维护人员，并且从PR描述中看不明显，请在合并消息中添加分支机构所做的简短说明，如果关闭问题，还可以添加“Closes gh-123”，其中123是问题编号。
对于代码更改，至少应该有一个维护人员（即具有提交权限的人员）审查和批准请求。如果您是第一个审核PR并批准更改的人，请使用GitHub approve review 用来标记它的工具。如果PR是直接的，例如它是一个明显正确的bug修复，那么它可以直接被合并。如果它更复杂或更改了公共API，请让它至少打开几天，以便其他维护人员有机会进行检查。
如果你是一个已经批准的公关后续审查，请使用相同的审查方法，为一个新的公关（重点放在更大的问题上，抵制诱惑，只添加一些吹毛求疵）。如果你有提交的权利，认为没有更多的审查是必要的，合并公关。
在合并PR之前，确保所有自动化CI测试都通过，并且 documentation builds 没有任何错误。
如果合并冲突，请PR提交者 rebase on master .
对于添加新功能或在某种程度上复杂的pr，在合并它之前至少要等待一两天。有机会在别人之前得到评论。考虑将其添加到发行说明中。
在合并贡献时，提交者负责确保这些贡献满足 Development process guidelines 为了 NumPy。另外，检查新特性和向后兼容性中断是否在 numpy-discussion mailing list .
挤压提交或清理提交消息的公关，你认为太乱是可以的。记住在做这件事时要保留原作者的名字。确保提交消息遵循 rules for NumPy .
当你想拒绝一个公关：如果它是非常明显的，你可以关闭它，并解释为什么。如果不是这样，那么最好先解释一下为什么你认为公共关系不适合包含在NumPy中，然后让第二个提交人评论或结束。
查看拉取请求时，请酌情使用GitHub上的工作流跟踪功能：
完成审阅后，如果要请求提交者进行更改，请将审阅状态更改为“已请求更改”。这可以在GitHub、PR页、Files changed选项卡、review changes（右上角的按钮）上完成。
如果您对当前状态满意，请将请求标记为已批准（与请求的更改相同）。或者（对于维护人员）：合并pull请求，如果您认为它已经准备好合并的话。
在您自己的机器上签出pull请求代码的副本可能会有所帮助，以便您可以在本地使用它。你可以用 GitHub CLI 单击 Open with 按钮在右上角的公关页。
Open with
假设你有你的 development environment 设置之后，您现在可以构建代码并对其进行测试。