为 NumPy 做出贡献#

不是编码员？没问题！ NumPy 是多方面的，我们可以使用很多帮助。这些都是我们希望获得帮助的活动（它们都很重要，因此我们按字母顺序列出）：

代码维护与开发
社区协调
开发运营
开发教育内容和叙述性文档
筹款
营销
项目管理
翻译内容
网站设计与开发
撰写技术文档

本文档的其余部分讨论 NumPy 代码库和文档的工作。我们正在更新对其他活动和角色的描述。如果您对这些其他活动感兴趣，请联系我们！您可以通过numpy-discussion 邮件列表或在GitHub上执行此操作（打开问题或对相关问题发表评论）。这些是我们首选的沟通渠道（开源本质上是开放的！），但是如果您希望首先私下讨论，请通过numpy-team @ googlegroups联系我们的社区协调员。 com或numpy-team.slack.com （首次发送电子邮件至numpy-team @ googlegroups . com以获得邀请）。

开发流程-总结#

这是简短的摘要，完整的目录链接如下：

如果您是首次贡献者：
- 访问https://github.com/numpy/numpy并单击“fork”按钮创建您自己的项目副本。
- 将项目克隆到本地计算机：
```
git clone --recurse-submodules https://github.com/your-username/numpy.git
```
- 更改目录：
```
cd numpy
```
- 添加上游存储库：
```
git remote add upstream https://github.com/numpy/numpy.git
```
- 现在，将显示两个远程存储库，名称为：git remote -v
  - upstream，它指的是numpy存储库
  - origin，指的是你的个人分叉
- 从上游拉取最新的更改，包括标签：
```
git checkout main
git pull upstream main --tags
```
- 初始化 numpy 的子模块：
```
git submodule update --init
```
发展你的贡献：
- 为您想要处理的功能创建一个分支。由于分支名称将出现在合并消息中，因此请使用合理的名称，例如“linspace-speedups”：
```
git checkout -b linspace-speedups
```
- 随着进展进行本地提交（并且）使用格式正确的提交消息，编写在更改之前失败并在更改之后通过的测试，在本地运行所有测试。请务必在文档字符串中记录任何更改的行为，并遵守 NumPy 文档字符串标准。git addgit commit
提交您的贡献：
- 将您的更改推送回 GitHub 上的分支：
```
git push origin linspace-speedups
```
- 输入您的 GitHub 用户名和密码（重复贡献者或高级用户可以通过使用 SSH连接到 GitHub 来删除此步骤）。
- 前往 GitHub。新分支将显示一个绿色的 Pull Request 按钮。确保标题和信息清晰、简洁且不言自明。然后单击按钮提交。
- 如果您的提交引入了新功能或更改了功能，请在邮件列表上发布以解释您的更改。对于错误修复、文档更新等，这通常是不必要的，但如果您没有得到任何反应，请随时要求审核。
审核流程：
- 审阅者（其他开发人员和感兴趣的社区成员）将在您的 Pull Request (PR) 上撰写内联和/或一般评论，以帮助您改进其实现、文档和风格。从事该项目的每个开发人员都会对其代码进行审查，我们逐渐将其视为友好的对话，我们都可以从中学习并获得整体代码质量的好处。因此，请不要让评论阻止您贡献：其唯一目的是提高项目质量，而不是批评（毕竟，我们非常感谢您捐赠的时间！）。有关更多信息，请参阅我们的审稿人指南。
- 要更新您的 PR，请在本地存储库中进行更改、提交、 运行测试，并且仅当它们成功推送到您的分支时。一旦这些更改被推送（到与之前相同的分支），PR 将自动更新。如果您不知道如何修复测试失败，您仍然可以推送更改并在 PR 评论中寻求帮助。
- 每次 PR 更新后都会触发各种持续集成 (CI) 服务，以构建代码、运行单元测试、测量代码覆盖率并检查分支的编码风格。 CI 测试必须通过才能合并您的 PR。如果 CI 失败，您可以通过单击“失败”图标（红十字）并检查构建和测试日志来找出原因。为了避免过度使用和浪费此资源，请在提交之前在本地测试您的工作。
- PR在合并之前必须得到至少一名核心团队成员的批准。批准意味着核心团队成员已经仔细审查了更改，并且 PR 已准备好合并。
文件变更

除了对函数文档字符串和一般文档中可能的描述进行更改之外，如果您的更改引入了任何面向用户的修改，则可能需要在发行说明中提及它们。要将更改添加到发行说明中，您需要创建一个带有摘要的短文件并将其放在doc/release/upcoming_changes.该文件doc/release/upcoming_changes/README.rst详细说明了格式和文件名约定。

如果您的更改引入了弃用，请确保首先在 GitHub 或邮件列表上讨论此问题。如果就弃用达成一致，请按照NEP 23 弃用政策添加弃用。
交叉引用问题

如果 PR 涉及任何问题，您可以将文本（其中问题编号）添加到 github 评论中。同样，如果 PR 解决了问题，请将替换为，或github 接受的任何其他风格。xref gh-xxxxxxxxxrefclosesfixes

在源代码中，请务必在任何问题或 PR 参考前面加上 gh-xxxx.

如需更详细的讨论，请继续阅读并点击本页底部的链接。

`upstream/main`和你的功能分支之间的分歧#

如果 GitHub 指示您的拉取请求的分支无法再自动合并，则您必须将自开始以来所做的更改合并到您的分支中。我们推荐的方法是在 main 上重新建立基础。

指南#

所有代码都应该进行测试（有关更多详细信息，请参阅下面的测试覆盖率）。
所有代码都应该记录在案。
未经核心团队成员审查和批准，不得进行任何更改。如果您的拉取请求在一周内没有得到回复，请在 PR 或邮件列表上礼貌地询问。

风格指南#

设置您的编辑器以遵循PEP 8（删除尾随空格、无制表符等）。使用 pyflakes / flake8 检查代码。
使用 NumPy 数据类型而不是字符串（np.uint8而不是 "uint8"）。
使用以下导入约定：
```
import numpy as np
```
对于 C 代码，请参阅NEP 45。

测试覆盖率#

修改代码的拉取请求 (PR) 应该有新的测试，或者修改现有测试，使其在 PR 之前失败并在 PR 之后通过。您应该在推送 PR 之前运行测试。

在本地运行 NumPy 的测试套件需要一些额外的包，例如 pytest和hypothesis。其他测试依赖项列在test_requirements.txt顶级目录中，可以方便地通过以下方式安装：

$ python -m pip install -r test_requirements.txt

理想情况下，模块的测试应覆盖该模块中的所有代码，即语句覆盖率应为 100%。

要测量测试覆盖率，请运行：

$ spin test --coverage

html这将创建一个格式为的报告build/coverage，可以使用浏览器查看，例如：

$ firefox build/coverage/index.html

构建文档#

要构建 HTML 文档，请使用：

spin docs

您也可以make从doc目录运行。列出所有目标。make help

要获取适当的依赖项和其他要求，请参阅构建 NumPy API 和参考文档。

修复警告#

“未找到引用：R###” 文档字符串第一行中的引用后面可能有一个下划线（例如 [1]_）。使用此方法查找源文件：$ cd doc/build; grep -rin R####
“重复引用 R###，其他实例在...”” 在其中一个文档字符串中可能有 [2] 而没有 [1]

开发流程 - 详细信息#

故事的其余部分

NumPy 特定的工作流程位于numpy-development-workflow中。