-
Notifications
You must be signed in to change notification settings - Fork 63
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into filter_report
- Loading branch information
Showing
83 changed files
with
3,583 additions
and
1,022 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| # This workflow runs CI tests: it installs Python dependencies and run tests across a variety of Python versions | ||
|
|
||
| name: build | ||
|
|
||
| on: | ||
| push: | ||
| branches: [ main ] | ||
| pull_request: | ||
| branches: [ main ] | ||
|
|
||
| jobs: | ||
| build: | ||
|
|
||
| runs-on: ubuntu-latest | ||
| strategy: | ||
| matrix: | ||
| python-version: [3.6, 3.7, 3.8, 3.9] | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v2 | ||
| - name: Set up Python ${{ matrix.python-version }} | ||
| uses: actions/setup-python@v2 | ||
| with: | ||
| python-version: ${{ matrix.python-version }} | ||
| - name: Install dependencies | ||
| run: | | ||
| python -m pip install --upgrade pip | ||
| pip install pytest | ||
| pip install pytest-cov | ||
| pip install -r requirements.txt | ||
| - name: Test with pytest | ||
| run: | | ||
| pytest --cov=./ | ||
| - name: Upload coverage to Codecov | ||
| uses: codecov/codecov-action@v1 |
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,78 +1,131 @@ | ||
| # Contributing Guidelines | ||
|
|
||
| Thank you for your interest in contributing to NeuroDSP! | ||
| Thank you for your interest in contributing to `neurodsp`! | ||
|
|
||
| We welcome contributions to the project that extend or improve code and/or documentation | ||
| in the module! | ||
| We welcome all contributions to the project that extend or improve code and/or documentation! | ||
|
|
||
| Note that contributors to NeuroDSP are expected to follow the | ||
| [Code of Conduct](https://github.com/neurodsp-tools/neurodsp/blob/master/CODE_OF_CONDUCT.md). | ||
| This page includes information for how to get involved and contribute to the project, and guidelines for how to do so. | ||
|
|
||
| ## How to Contribute | ||
| This project adheres to a | ||
| [code of conduct](https://github.com/neurodsp-tools/neurodsp/blob/main/CODE_OF_CONDUCT.md) | ||
| that you are expected to uphold when participating in this project. | ||
|
|
||
| If you are interested in getting involved in helping with and maintaining `NeuroDSP`, the best place to start is on the [issues](https://github.com/neurodsp-tools/neurodsp/issues) board. Check through if there are any open issues that you might be able to contribute to! | ||
| On this page, you can find information on: | ||
|
|
||
| If you have a new idea you would like to contribute to NeuroDSP, please do the following: | ||
| * [Reporting a problem](#reporting-a-problem) | ||
| * [Getting involved in the project](#getting-involved) | ||
| * [Project scope](#project-scope) | ||
| * [Making a contribution](#making-a-contribution) | ||
| * [Project conventions](#project-conventions) | ||
|
|
||
| 1. Check that your idea is in scope for the project (as discussed below) | ||
| 2. Open an [issue](https://github.com/neurodsp-tools/neurodsp/issues) in the repository suggesting and describing your idea | ||
| 3. Get feedback from project maintainers, and coordinate a plan for the contribution | ||
| 4. Make the contribution (as described below) | ||
| ## Reporting a problem | ||
|
|
||
| To contribute a fix, or add an update of the repository, do the following: | ||
| To report an issue with the code, please submit it to our [issue tracker](https://github.com/neurodsp-tools/neurodsp/issues). | ||
|
|
||
| 1. Make a fork of the NeuroDSP repository | ||
| 2. Update the fork of the repository with any updates and/or additions to the project | ||
| 3. Check that any additions to the project follow the conventions (described below) | ||
| 4. Make a pull request from your fork to the `NeuroDSP` repository | ||
| 5. Address any feedback and/or recommendations from reviewers, until the contribution is ready to be merged | ||
| In doing so, please try to include the following: | ||
|
|
||
| ## Scope | ||
| 1. A short, top-level summary of the issue (usually 1-2 sentences) | ||
| 2. A short, self-contained code snippet to reproduce the issue, ideally allowing a simple copy and paste to reproduce | ||
| - Please do your best to reduce the code snippet to the minimum required | ||
| 3. The actual outcome of the code snippet | ||
| 4. The expected outcome of the code snippet | ||
|
|
||
| All contributions to `NeuroDSP` must be within the scope of the module. | ||
| ## Getting Involved | ||
|
|
||
| The scope of `NeuroDSP` is digital signal processing approaches for neural data, that operate on neural time series. Within this scope, the goal of the module is to provide a collection of useful analyses approaches. These analyses should be agnostic to specific data modalities, and particularities of how the data is organized. Code and utilities that focused on data management are considered out of scope. | ||
| We welcome all kinds of contributions to the project, including suggested features and help with documentation, maintenance, and updates. | ||
|
|
||
| ## Conventions | ||
| If you have a new idea you would like to suggest or contribute, please do the following: | ||
|
|
||
| 1. Check if the idea is already being discussed on the | ||
| [issues](https://github.com/neurodsp-tools/neurodsp/issues) or | ||
| [development](https://github.com/neurodsp-tools/Development) page | ||
| 2. Check that your idea is within the [project scope](#project-scope) | ||
| 3. Open an [issue](https://github.com/neurodsp-tools/neurodsp/issues) describing | ||
| what you would like to see added / changed, and why | ||
| 4. Indicate in the issue if the idea is something you would be willing to help implement | ||
| - if so, project maintainers can give feedback to help make a plan for the contribution | ||
| 5. If you want to work on the contribution, follow the [contribution guidelines](#making-a-contribution) to do so | ||
|
|
||
| If you are interested in getting involved and helping with the project, a great place to start is to visit the | ||
| [issues](https://github.com/neurodsp-tools/neurodsp/issues) or | ||
| [development](https://github.com/neurodsp-tools/Development) page | ||
| and see if there is anything you would be interested in helping with. If so, join the conversation, and project developers can help get you started. | ||
|
|
||
| ## Project Scope | ||
|
|
||
| All contributions must be within the scope of the module. | ||
|
|
||
| `neurodsp` is a module that collects digital signal processing approaches for neural data that operate on neural time series. This includes filtering, spectral estimation, time-frequency analyses, and more. The majority of the methods operate on single time-series, though multivariate approaches may be added on a case-by-case basis. | ||
|
|
||
| This module collects analyses that are broadly agnostic to specific recording modalities, and particularities of how the data is organized, operating on arrays of time-series. Code and utilities that focused on data management are considered out of scope. Algorithms and topics that are already available and well-supported in other Python toolboxes will typically not be added here. | ||
|
|
||
| ## Making a Contribution | ||
|
|
||
| If there is a feature you would like to add, or an issue you saw that you think you can help with, you are ready to make a submission to the project! | ||
|
|
||
| If you are working on a feature, please indicate so in the relevant issue, so that we can keep track of who is working on what. | ||
|
|
||
| Once you're ready to start working on your contribution, do the following: | ||
|
|
||
| 1. [Fork this repository](https://help.github.com/articles/fork-a-repo/), which makes your own version of this project you can edit | ||
| 2. [Make your changes](https://guides.github.com/activities/forking/#making-changes), updating or adding code to add the desired functionality | ||
| 3. [Check the project conventions](#project-conventions), and make sure all new or updated code follows the guidelines | ||
| 4. [Submit a pull request](https://help.github.com/articles/proposing-changes-to-a-project-with-pull-requests/), to start the process of merging the new code to the main branch | ||
|
|
||
| If it's your first time contributing to open source software, check out this free resource on [how to contribute to an open-source project on GitHub](https://app.egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github). | ||
|
|
||
| ## Project Conventions | ||
|
|
||
| All code contributed to the module should follow these conventions: | ||
|
|
||
| 1. Code Requirements | ||
| * All code should be written in Python 3.5+ | ||
| * Adding new dependencies is discouraged, if it can be avoided. | ||
| * If any more dependencies are required, they must be added to the `requirements.txt` file. | ||
| * All code should be written in Python, and run on the minimum required version that is noted in the README | ||
| * New dependencies should be avoided if possible, especially if they are not in the Anaconda distribution | ||
| * If any new dependencies are needed, they should be added to the `requirements.txt` file | ||
|
|
||
| 2. Code Style | ||
| * Code should follow the [PEP8](https://www.python.org/dev/peps/pep-0008/) style guide | ||
| * Docstrings for public functions should be in | ||
| [Numpy docs](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt) format. | ||
| At minimum, there should be a sentence describing what the function does and a list of | ||
| parameters and returns. | ||
| * If you can, add an `Examples` section in the docstring, demonstrating use, that can be run with doctest | ||
| * Private functions should be indicated with a leading underscore, and should still include a | ||
| docstrings including at least a sentence describing what the function does. | ||
| * Use standard casing: | ||
| * Function names in snake_case (all lowercase with underscores) | ||
| * Class names are in CamelCase (leading capitals with no separation) | ||
| * Code should generally follow [PEP8](https://www.python.org/dev/peps/pep-0008/) style guidelines | ||
| * Max line length is 100 characters | ||
| * Merge candidates will be checked using [pylint](https://www.pylint.org) | ||
|
|
||
| 3. API & Naming Conventions | ||
| * The API should be kept consistent within NeuroDSP, using standard naming and parameter ordering, for example: | ||
| * Try to keep the API consistent with existing code in terms of parameter names and ordering | ||
| * Standard naming and parameter ordering in NeuroDSP include: | ||
| * `sig` is commonly the first input, representing the neural time series | ||
| * `fs` is commonly the second input, representing the sampling rate | ||
| * Variables named 'f_...' refer to frequencies (e.g. 'f_range' is a bandpass filter's cutoff frequencies) | ||
| * If code is calling and using external implementations, for example, `scipy.signal`, naming and input ordering, as described in NeuroDSP, should be consistent with the external functions that are being used | ||
|
|
||
| 4. Tests | ||
| * All code within NeuroDSP requires test code that executes that code | ||
| * These tests, at a minimum, must be 'smoke tests' that execute the | ||
| code and check that it runs through, without erroring out, and returning appropriate variables. | ||
| * If possible, including more explicit test code that checks more stringently for accuracy is encouraged, | ||
| but not strictly required. | ||
| * Before a pull request is merged, code coverage must demonstrate that new code is tested, | ||
| and continuous integration checks running this test code must all pass | ||
|
|
||
| 5. Module Documentation | ||
| * Any public facing code updates should included relevant updates to the [documentation site](https://neurodsp-tools.github.io/neurodsp/) | ||
| * If you add any new public functions, note this function in the doc/api.rst file, | ||
| so that this function gets included in the documentation site API listing | ||
| * If a new public function is added, it should should be added and described in the relevant tutorials section, with a quick description and demonstration of using it | ||
| * variables named 'f_...' refer to frequencies (e.g. 'f_range' is a bandpass filter's cutoff frequencies) | ||
| * Use standard casing, for example: | ||
| * function names should be in snake_case (all lowercase with underscores) | ||
| * class names should be in CamelCase (leading capitals with no separation) | ||
| * If passing through arguments to an external function, the naming and ordering of parameters in this module should generally follow that of the external function | ||
|
|
||
| 4. Code Documentation | ||
| * All code should be documented, including in-code comments describing procedures, and detailed docstrings | ||
| * Docstrings should follow the [numpy docs](https://numpydoc.readthedocs.io/en/latest/format.html#docstring-standard) format | ||
| * At minimum, there should be a sentence describing what the function does and a list of parameters and returns | ||
| * Private functions should be indicated with a leading underscore, and should still include a docstring including at least a sentence describing what the function does | ||
| * If possible, add an `Examples` section to the docstrings, that demonstrates a simple use case | ||
| * If so, these examples should be executable, using [doctest](https://docs.python.org/3/library/doctest.html) | ||
| * If examples cannot be run, use the SKIP directive | ||
|
|
||
| 5. Code Tests | ||
| * This project uses the [pytest](https://docs.pytest.org/en/latest/) testing tool for testing module code | ||
| * All new code requires test code, written as unit tests that check each function and class in the module | ||
| * Tests should be, at a minimum, 'smoke tests' that execute the code and check that it runs without raising an error | ||
| * Where possible, accuracy checking is encouraged, though not strictly required | ||
| * Merge candidates must pass all existing tests, and add new tests such as to not reduce test coverage | ||
| * To run the tests locally, pytest needs to be installed (`pip install pytest`) | ||
| * To run the tests on a local copy of the module, move into the folder and run `pytest .` | ||
|
|
||
| 6. Documentation Website | ||
| * This project uses a documentation website, created using [sphinx](https://www.sphinx-doc.org/) | ||
| * Any new public functions or classes should be added to the `doc/api.rst` file, so they get included in the API list | ||
| * Any new functionality should be added and described in the tutorials and/or examples | ||
| * If a new approach is added, a new tutorial or example may be appropriate | ||
| * To build and check the documentation locally: | ||
| * Install the requirements for the docsite (`pip install -r requirements-doc.txt`) | ||
| * Move to the `neurodsp/doc` directory (`cd doc`) | ||
| * Run `make html` to create a local copy of the documentation website | ||
| * The documentation can then be opened in a web browser by opening the file `neurodsp/doc/_build/html/index.html` | ||
|
|
||
| For more guidelines on how to write well formated and organized code, check out the [Python API Checklist](http://python.apichecklist.com). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.