Contributing to NumPy#
Not a coder? Not a problem! NumPy is multi-faceted, and we can use a lot of help. These are all activities we’d like to get help with (they’re all important, so we list them in alphabetical order):
Code maintenance and development
Community coordination
DevOps
Developing educational content & narrative documentation
Fundraising
Marketing
Project management
Translating content
Website design and development
Writing technical documentation
The rest of this document discusses working on the NumPy code base and documentation. We’re in the process of updating our descriptions of other activities and roles. If you are interested in these other activities, please contact us! You can do this via the numpy-discussion mailing list, or on GitHub (open an issue or comment on a relevant issue). These are our preferred communication channels (open source is open by nature!), however if you prefer to discuss in a more private space first, you can do so on Slack (see numpy.org/contribute for details).
Development process - summary#
Here’s the short summary, complete TOC links are below:
If you are a first-time contributor:
Go to numpy/numpy and click the “fork” button to create your own copy of the project.
Clone the project to your local computer:
git clone --recurse-submodules https://github.com/your-username/numpy.git
Change the directory:
cd numpy
Add the upstream repository:
git remote add upstream https://github.com/numpy/numpy.git
Now,
git remote -v
will show two remote repositories named:upstream
, which refers to thenumpy
repositoryorigin
, which refers to your personal fork
Pull the latest changes from upstream, including tags:
git checkout main git pull upstream main --tags
Initialize numpy’s submodules:
git submodule update --init
Develop your contribution:
Create a branch for the feature you want to work on. Since the branch name will appear in the merge message, use a sensible name such as ‘linspace-speedups’:
git checkout -b linspace-speedups
Commit locally as you progress (
git add
andgit commit
) Use a properly formatted commit message, write tests that fail before your change and pass afterward, run all the tests locally. Be sure to document any changed behavior in docstrings, keeping to the NumPy docstring standard.
To submit your contribution:
Push your changes back to your fork on GitHub:
git push origin linspace-speedups
Enter your GitHub username and password (repeat contributors or advanced users can remove this step by connecting to GitHub with SSH).
Go to GitHub. The new branch will show up with a green Pull Request button. Make sure the title and message are clear, concise, and self- explanatory. Then click the button to submit it.
If your commit introduces a new feature or changes functionality, post on the mailing list to explain your changes. For bug fixes, documentation updates, etc., this is generally not necessary, though if you do not get any reaction, do feel free to ask for review.
Review process:
Reviewers (the other developers and interested community members) will write inline and/or general comments on your Pull Request (PR) to help you improve its implementation, documentation and style. Every single developer working on the project has their code reviewed, and we’ve come to see it as friendly conversation from which we all learn and the overall code quality benefits. Therefore, please don’t let the review discourage you from contributing: its only aim is to improve the quality of project, not to criticize (we are, after all, very grateful for the time you’re donating!). See our Reviewer Guidelines for more information.
To update your PR, make your changes on your local repository, commit, run tests, and only if they succeed push to your fork. As soon as those changes are pushed up (to the same branch as before) the PR will update automatically. If you have no idea how to fix the test failures, you may push your changes anyway and ask for help in a PR comment.
Various continuous integration (CI) services are triggered after each PR update to build the code, run unit tests, measure code coverage and check coding style of your branch. The CI tests must pass before your PR can be merged. If CI fails, you can find out why by clicking on the “failed” icon (red cross) and inspecting the build and test log. To avoid overuse and waste of this resource, test your work locally before committing.
A PR must be approved by at least one core team member before merging. Approval means the core team member has carefully reviewed the changes, and the PR is ready for merging.
Document changes
Beyond changes to a functions docstring and possible description in the general documentation, if your change introduces any user-facing modifications they may need to be mentioned in the release notes. To add your change to the release notes, you need to create a short file with a summary and place it in
doc/release/upcoming_changes
. The filedoc/release/upcoming_changes/README.rst
details the format and filename conventions.If your change introduces a deprecation, make sure to discuss this first on GitHub or the mailing list first. If agreement on the deprecation is reached, follow NEP 23 deprecation policy to add the deprecation.
Cross referencing issues
If the PR relates to any issues, you can add the text
xref gh-xxxx
wherexxxx
is the number of the issue to github comments. Likewise, if the PR solves an issue, replace thexref
withcloses
,fixes
or any of the other flavors github accepts.In the source code, be sure to preface any issue or PR reference with
gh-xxxx
.
For a more detailed discussion, read on and follow the links at the bottom of this page.
Guidelines#
All code should have tests (see test coverage below for more details).
All code should be documented.
No changes are ever committed without review and approval by a core team member. Please ask politely on the PR or on the mailing list if you get no response to your pull request within a week.
Stylistic guidelines#
Test coverage#
Pull requests (PRs) that modify code should either have new tests, or modify existing tests to fail before the PR and pass afterwards. You should run the tests before pushing a PR.
Running NumPy’s test suite locally requires some additional packages, such as
pytest
and hypothesis
. The additional testing dependencies are listed
in requirements/test_requirements.txt
in the top-level directory, and can
conveniently be installed with:
$ python -m pip install -r requirements/test_requirements.txt
Tests for a module should ideally cover all code in that module, i.e., statement coverage should be at 100%.
To measure the test coverage, run:
$ spin test --coverage
This will create a report in html
format at build/coverage
, which can be
viewed with your browser, e.g.:
$ firefox build/coverage/index.html
Building docs#
To build the HTML documentation, use:
spin docs
You can also run make
from the doc
directory. make help
lists
all targets.
To get the appropriate dependencies and other requirements, see Building the NumPy API and reference docs.
Development process - details#
The rest of the story
- Setting up and using your development environment
- Building the NumPy API and reference docs
- Development workflow
- Advanced debugging tools
- Reviewer guidelines
- NumPy benchmarks
- NumPy C style guide
- For downstream package authors
- Releasing a version
- NumPy governance
- How to contribute to the NumPy documentation
NumPy-specific workflow is in numpy-development-workflow.