为 NumPy 贡献代码#

不会编程？没问题！NumPy 是多方面的，我们非常需要帮助。以下是一些我们希望得到帮助的活动（所有这些都很重要，所以我们按字母顺序排列）：

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

我们理解每个人都有不同的经验水平，NumPy 也是一个相当成熟的项目，因此很难假设一个理想的“首次贡献者”。这就是为什么我们不使用“good-first-issue”标签标记问题。相反，你会发现标有“Sprintable”标签的问题。这些问题可以：

轻松修复，当你获得经验丰富的贡献者的指导时（非常适合在冲刺中工作）。
学习机会，对于那些准备深入研究的人来说，即使你不是在冲刺中。

此外，根据你之前的经验，“Sprintable”问题可能很简单，也可能对你来说更具挑战性。

本文档的其余部分讨论了 NumPy 代码库和文档的工作。我们正在更新对其他活动和角色的描述。如果你对这些其他活动感兴趣，请联系我们！你可以通过numpy-discussion 邮件列表或GitHub（打开一个 issue 或评论相关的 issue）联系我们。这些是我们首选的沟通渠道（开源本质上是开放的！），但是如果你更喜欢首先在更私密的空间中讨论，你可以在 Slack 上进行讨论（详情请参见numpy.org/contribute）。

开发流程 - 摘要#

这是一个简短的摘要，完整的 TOC 链接在下面

如果你是第一次贡献代码
- 访问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，它指的是你的个人 fork
- 从上游拉取最新的更改，包括标签
```
git checkout main
git pull upstream main --tags
```
- 初始化 numpy 的子模块
```
git submodule update --init
```
开发你的贡献
- 为要处理的功能创建一个分支。由于分支名称将出现在合并消息中，请使用有意义的名称，例如“linspace-speedups”。
```
git checkout -b linspace-speedups
```
- 在开发过程中进行本地提交（git add 和 git commit）。使用正确格式化的提交消息，编写在更改之前失败并在之后通过的测试，运行所有本地测试。务必在文档字符串中记录任何更改的行为，并遵守 NumPy 文档字符串标准。
提交你的贡献
- 将你的更改推送到 GitHub 上的 fork。
```
git push origin linspace-speedups
```
- 转到 GitHub。新的分支将显示一个绿色的“Pull Request”按钮。确保标题和消息清晰、简洁且具有自解释性。然后点击按钮提交。
- 如果你的提交引入了新功能或更改了功能，请在邮件列表上发帖解释你的更改。对于错误修复、文档更新等，通常不需要这样做，但是如果你没有得到任何回应，请随时请求审查。
审查流程
- 评审者（其他开发人员和感兴趣的社区成员）将在你的 Pull Request (PR) 上撰写内嵌和/或一般性评论，以帮助你改进其实现、文档和风格。参与项目的每位开发人员都会对其代码进行审查，我们已经将其视为友好的对话，从中我们都能学习，并能提高整体代码质量。因此，请不要让审查阻止你贡献：它的唯一目的是提高项目质量，而不是批评（毕竟，我们非常感谢你捐献的时间！）。请参阅我们的评审指南了解更多信息。
- 要更新你的 PR，请在本地存储库中进行更改，提交，**运行测试，并且只有在测试成功后**才推送到你的 fork。这些更改一被推送（到与之前相同的分支），PR 将自动更新。如果你不知道如何修复测试失败，你可以推送你的更改并请求在 PR 评论中寻求帮助。
- 每次 PR 更新后都会触发各种持续集成 (CI) 服务，以构建代码、运行单元测试、测量代码覆盖率并检查分支的编码风格。在你的 PR 可以合并之前，必须通过 CI 测试。如果 CI 失败，你可以通过点击“失败”图标（红色叉号）并检查构建和测试日志来找出原因。为了避免过度使用和浪费此资源，请在提交之前在本地测试你的工作。
- PR 必须在合并之前获得至少一位核心团队成员的**批准**。批准意味着核心团队成员已仔细审查了更改，并且 PR 已准备好合并。
记录更改

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

如果你的更改引入了弃用，请确保首先在 GitHub 或邮件列表中讨论此问题。如果达成关于弃用的协议，请遵循NEP 23 弃用策略来添加弃用。
交叉引用问题

如果 PR 与任何问题相关，你可以添加文本xref gh-xxxx，其中xxxx 是 GitHub 评论中问题的编号。同样，如果 PR 解决了一个问题，请将xref替换为closes、fixes或GitHub接受的任何其他类型github accepts。

在源代码中，请务必在任何问题或 PR 引用之前加上gh-xxxx。

有关更详细的讨论，请继续阅读并遵循此页面底部的链接。

指南#

所有代码都应该有测试（有关更多详细信息，请参见下面的测试覆盖率）。
所有代码都应有文档。
在没有核心团队成员审查和批准的情况下，绝不会提交任何更改。如果你在一周内没有收到对你的拉取请求的任何回复，请礼貌地在 PR 或邮件列表上询问。

风格指南#

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

测试覆盖率#

修改代码的拉取请求 (PR) 应该有新的测试，或者修改现有的测试，以便在 PR 之前失败，之后通过。你应该运行测试，然后再推送 PR。

在本地运行 NumPy 的测试套件需要一些额外的包，例如pytest和hypothesis。额外的测试依赖项列在顶层目录中的requirements/test_requirements.txt中，可以使用以下命令方便地安装：

$ python -m pip install -r requirements/test_requirements.txt

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

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

$ spin test --coverage

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

$ firefox build/coverage/index.html

构建文档#

要构建 HTML 文档，请使用：

spin docs

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

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

开发流程 - 细节#

故事的其余部分

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