Skip to content

Latest commit

 

History

History
113 lines (84 loc) · 6.51 KB

CONTRIBUTING.md

File metadata and controls

113 lines (84 loc) · 6.51 KB
Raw

Contributing to NeuralProphet

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

Welcome to the Prophet community and thank you for your contribution to its continued legacy. We compiled this page with practical instructions and further resources to help you get started.

For an easy start, check out all open issues with the label good first issue Good for newcomers . They can be done somewhat in isolation from other tasks and will take a couple hours up to a week of work to complete. We appreciate your help!

Please come join us on our Slack, you can message any core dev there.

Process

If this is your first time contributing to NeuralProphet, please read our wiki summary of the steps involved.

Dev Install using Poetry

Prerequisite: install poetry.

  • Start by cloning the repo with git clone <copied link from github>.
  • Make sure you have changed directories to your cloned neuralprophet github cd neural_prophet. There, run poetry shell to (create and) start a (new) poetry virtual environment. If you run poetry env info --path you should see the path to the venv.
  • To complete the venv setup, install neuralprophet (in editable mode by default) with poetry install. Note: poetry will automatically use the specific dependencies in the poetry.lock file for reproducibility. If you want to install the latest dependencies instead, run poetry update. This will update all dependencies and update the poetry.lock file. Be mindful to not track the poetry.lock file with git when commiting, unless the purpose of your pull request is to update it.

Warning, you are still lacking some git hooks to auto-format your code pre-commit and to run pytests pre-push. Currently these need to be self-added. Simplified instructions to follow.

Tutorial Link

Dev Install (old)

Before starting it's a good idea to first create and activate a new virtual environment:

python3 -m venv <path-to-new-env>
source <path-to-new-env>/bin/activate

Now you can install neuralprophet:

git clone <copied link from github>
cd neural_prophet
pip install -e ".[dev]"

Please don't forget to run the dev setup script to install the hooks for black and pytest, and set git to fast forward only:

neuralprophet_dev_setup.py
git config pull.ff only

Notes:

  • Including the optional -e flag will install neuralprophet in "editable" mode, meaning that instead of copying the files into your virtual environment, a symlink will be created to the files where they are.
  • The neuralprophet_dev_setup command runs the dev-setup script which installs appropriate git hooks for Black (pre-commit) and PyTest (pre-push).
  • setting git to fast-forward only prevents accidental merges when using git pull.
  • To run tests without pushing (or when the hook installation fails), run from neuralprophet folder: pytest -v
  • To run black without commiting (or when the hook installation fails): python3 -m black {source_file_or_directory}
  • If running neuralprophet_dev_setup.py gives you a no such file error, try running python ./scripts/neuralprophet_dev_setup.py

Writing documentation

The NeuralProphet documentation website is hosted via GitHub Pages on www.neuralprohet.com. Have a look at the wiki on how to write and build documentation.

Best practices

We follow a set of guidelines and methodologies to ensure that code is of high quality, maintainable, and easily understandable by others who may contribute to the project:

  • Typing: Use type annotations across the project to improve code readability and maintainability
  • Tests and Code Coverage: Run tests using 'PyTest' to ensure that the code is functioning as expected.
  • Continuous Integration: Github Actions is used to set up a CI pipeline
  • Code Style: Deploy Black, so there is no need to worry about code style and formatting.

Prefixes and labels for pull requests and issues

Prefixes for pull requests

All pull requests (PR) should have one of the following prefixes:

  • [breaking] Breaking changes, which require user action (e.g. breaking API changes)
  • [major] Major features worth mentioning (e.g. uncertainty prediction)
  • [minor] Minor changes which are nice to know about (e.g. add sorting to labels in plots)
  • [fix] Bugfixes (e.g. fix for plots not showing up)
  • [docs] Documentation related changes (e.g. add tutorial for energy dataset)
  • [tests] Tests additions and changes (e.g. add tests for utils)
  • [devops] Github workflows (e.g. add pyright type checking Github action)

Those prefixed are then used to generate the changelog and decide which version number change is necessary for a release.

Labels for pull requests

Once your PR needs attention, please add an appropriate label:

Issue labels

Issues should always have a type and a priority. Other labels are optional.

Issue type

bug Something isn't working epic Epic issue, like a group of issues for bigger tasks task Tasks (not an epic, not a bug) (questions should be moved to discussions)

Priorities

P1 High priority P2 Medium priority P3 Low priority

Getting started

good first issue Good for newcomers

Closed for reason

duplicate This issue or pull request already exists wontfix This will not be worked on