导致 NumPy¶

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

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

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

开发过程-总结¶

以下是简短的总结，完整的目录链接如下：

如果你是第一次投稿人：
- 去 https://github.com/numpy/numpy 然后单击“fork”按钮创建您自己的项目副本。
- 将项目克隆到本地计算机：
```
git clone 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 master
git pull upstream master
```
- 为要处理的要素创建分支。由于分支名称将出现在合并消息中，请使用合理的名称，如“linspace speedups”：
```
git checkout -b linspace-speedups
```
- 随着进度在本地提交 (git add 和 git commit )使用 properly formatted 提交消息，编写在更改前失败并在更改后通过的测试，运行所有 tests locally . 请确保在docstring中记录任何更改的行为，并保留NumPy docstring standard .
提交您的贡献：
- 将更改推回到Github上的fork:：
```
git push origin linspace-speedups
```
- 输入您的GitHub用户名和密码（重复此步骤），贡献者或高级用户可以通过使用连接到GitHub来删除此步骤 SSH ）
- 转到GitHub。新的分支将显示一个绿色的请求按钮。确保标题和信息清晰、简洁、不言自明。然后单击按钮提交。
- 如果提交引入了新功能或更改了功能，请在 mailing list 来解释你的变化。对于bug修复、文档更新等，这通常是没有必要的，但是如果您没有得到任何反应，请随时请求审阅。
审查过程：
- 审阅者（其他开发人员和感兴趣的社区成员）将对您的Pull请求（PR）编写内联和/或一般性评论，以帮助您改进其实现、文档和样式。每一个从事这个项目的开发人员都会对他们的代码进行评审，我们把它看作是友好的对话，从中我们都可以学到代码质量的好处。因此，请不要让审查阻碍你的贡献：它的唯一目的是提高项目的质量，而不是批评（毕竟，我们非常感谢你捐赠的时间！）。看看我们的 Reviewer Guidelines 更多信息。
- 要更新PR，请在本地存储库中进行更改，然后提交， 运行测试，并且只有在测试成功时才运行 把叉子往上推。一旦这些更改被推上（与之前相同的分支），PR将自动更新。如果你不知道如何修复测试失败，你可以推送你的更改，并在公关意见寻求帮助。
- 每次PR更新之后，都会触发各种持续集成（CI）服务，以构建代码、运行单元测试、测量代码覆盖率并检查分支的编码样式。CI测试必须通过才能合并PR。如果CI失败，您可以通过单击“失败”图标（红十字）并检查构建和测试日志来找出原因。为了避免这种资源的过度使用和浪费， test your work 在提交之前在本地执行。
- 公关必须 经核准的 在合并之前至少由一个核心团队成员。批准意味着核心团队成员已经仔细审查了变更，PR已经准备好合并。
文件更改

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

如果您的更改引入了贬损，请确保首先在GitHub或邮件列表上讨论这个问题。如果就否决达成一致意见，请遵循 NEP 23 deprecation policy 添加弃用。
交叉引用问题

如果公关涉及任何问题，你可以添加文本 xref gh-xxxx 在哪里？ xxxx 是问题到github的评论数。同样，如果PR解决了问题，则更换 xref 具有 closes ， fixes 或者其他口味的 github accepts .

在源代码中，一定要在任何问题或PR引用之前加上 gh-xxxx .

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

之间的分歧 `upstream/master` 你的特色分支¶

如果GitHub指示不能再自动合并Pull请求的分支，则必须将自启动以来所做的更改合并到分支中。我们推荐的方法是 rebase on master .

指南¶

所有代码都应该有测试（参见 test coverage 详情请参见下文）。
所有代码都应该是 documented .
未经核心团队成员审查和批准，不得进行任何更改。请在公共关系或网上礼貌地询问 mailing list 如果你在一周内没有收到任何回复。

文体指南¶

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

测试覆盖率¶

修改代码的Pull请求（PR）应该有新的测试，或者在PR之前将现有的测试修改为失败，然后通过。你应该 run the tests 在推动公关之前。

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

pip install -r test_requirements.txt

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

要测量测试覆盖率，请安装 pytest-cov 然后跑：

$ python runtests.py --coverage

这将在中创建报告 build/coverage ，可通过以下方式查看：

$ firefox build/coverage/index.html

建筑文档¶

要生成文档，请运行 make 从 doc 目录。 make help 列出所有目标。例如，要构建HTML文档，可以运行：

make html

然后，所有的HTML文件将在 doc/build/html/ . 由于文档是基于docstring的，因此必须在用于运行sphinx的主机python中安装适当版本的numpy。

要求¶

Sphinx 是构建文档所必需的。Matplotlib、SciPy和IPython也是必需的。

中列出了构建文档的这些附加依赖项 doc_requirements.txt 可方便地安装在：

pip install -r doc_requirements.txt

numpy文档还取决于 numpydoc 狮身人面像的延伸以及外部狮身人面像的主题。这些扩展包含在git子模块中，必须在构建文档之前进行初始化。从 doc/ 目录：

git submodule update --init

该文件包括与 Latex 格式的数学公式。一个有效的文档制作系统（例如。 texlive )是文档中正确呈现LaTeX数学所必需的。

修复警告¶

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

开发过程-细节¶

故事的其余部分

NumPy特定工作流处于 numpy-development-workflow .

测试numpy.i类型映射用于开发的Git