We are open to many types of contributions, from bugfixes to functionality enhancements. mne-python is meant to be maintained by a community of labs, and as such, we seek enhancements that will likely benefit a large proportion of the users who use the package.
Before starting new code, we highly recommend opening an issue on mne-python GitHub to discuss potential changes. Getting on the same page as the maintainers about changes or enhancements before too much coding is done saves everyone time and effort!
Standard python style guidelines set by pep8 and pyflakes are followed with very few exceptions. We recommend using an editor that calls out style violations automatcally, such as Spyder. From the MNE code root, you can check for violations using flake8 with:
$ make flake
Use numpy style for docstrings. Follow existing examples for simplest guidance.
New functionality must be covered by tests. For example, a
mne.Evoked method in
mne/evoked.py should have a corresponding
After making changes, ensure all tests pass. This can be done by running:
$ make test
To run individual tests, you can also run e.g.:
$ nosetests mne/tests/test_evoked:test_io_evoked -x --verbose
Make sure you have the testing dataset, which you can get by doing:
These are guidelines that are generally followed:
nosetests --with-timeron modified tests.
doc/whats_new.rstfile last, just before merge to avoid merge conflicts.
numpy as np,
scipysubmodules) 3. others 4. mne imports (relative within the MNE module, absolute in the examples)
matplotliband optional modules (
pandas, etc.) within the MNE module should be nested (i.e., within a function or method, not at the top of a file).
mne.vizpackage and use these in the corresponding methods.
showparameter and return a
RdBu_rcolormap for signed data with a meaningful middle (zero-point) and
Redsotherwise in visualization functions and examples.
self, functions should return copies (where applicable).
mapand other functional idioms.
*argsin function signatures.
All changes to the codebase must be properly documented. To ensure that documentation is rendered correctly, the best bet is to follow the existing examples for class and function docstrings, and examples and tutorials.
Documentation is automatically built remotely during pull requests. If
you want to also test documentation locally, you will need to install
sphinx sphinx-gallery sphinx_bootstrap_theme numpydoc, and then within
mne/doc directory do:
$ make html_dev-noplot
If you are working on examples or tutorials, you can build specific examples with:
$ PATTERN=plot_background_filtering.py make html_dev-pattern
Consult the sphinx gallery documentation for more details.