Contributing to Parcels#

Why contribute?#

Lagrangian Ocean Analysis is one of the primary modelling tools available to oceanographers to understand how ocean currents transport material. This modelling approach allows researchers to model the ocean and understand the movement of water in the ocean itself (or even on other planets), as well as the transport of nutrients, marine organisms, oil, plastic, as well as almost anything else that would be adrift at sea. Since ocean currents play a key role in climate by storing heat and carbon, and also in the formation of the ‘plastic soup’, understanding transport phenomena in the ocean is crucial to support a more sustainable future.

The Parcels code, for which development started in 2015, is now one of the most widely used tools for Lagrangian Ocean Analysis. It’s used by dozens of groups around the world - see this list for a full list of the peer-reviewed articles using Parcels. Its flexibility for users to create new, custom ‘behaviours’ (i.e. let virtual particles be controlled by other mechanics than only the ocean flow) and its compatibility with many different types of hydrodynamic input data are the two key features.

Note

Want to learn more about Lagrangian ocean analysis? Then look at Lagrangian ocean analysis: Fundamentals and practices for a review of the literature.

There are two primary groups that contribute to Parcels; oceanographers who bring domain specific understanding about the physical processes and modelling approaches, as well as software developers who bring their experience working with code. All contributions are welcome no matter your background or level of experience.

Note

The first component of this documentation is geared to those new to open source. Already familiar with GitHub and open source? Skip ahead to the Editing Parcels code section.

What is open source?#

Open source is a category of software that is open to the public, meaning that anyone is able to look at, modify, and improve the software. Compare this to closed source software (e.g., Microsoft Word, or Gmail) where only those working for the company on the product are able to look at the source code, or make improvements.

Software being open source allows bugs in the code to be quickly identified and fixed, as well as fosters communities of people involved on projects. Most open source software have permissible licenses making them free to modify, and use even in commercial settings. Parcels, for example, is open source and licensed under the MIT License.

This visibility of the codebase results in a higher quality, as well as a more transparent and stable product. This is important in research for reproducibility, as well as in industry where stability is crucial. Open source is not some niche category of software, but in fact forms the backbone of modern computing and computing infrastructure and is used widely in industry. A lot of the digital services that you use (paid, or free) depend on open source code in one way or another.

Most open source code is managed through a version control system called Git. Once you get past the Git specific terminology, the fundamental nature of it is quite understandable. To give an overview: Git, which you can install on your local machine, is a tool which allows you to create snapshots (aka., ”commits”) of a codebase. These snapshots each have a custom message attached to it, forming a time-line for the life of the project. This allows you to incrementally make updates to a codebase, while also having full control to undo any changes (you can even use Git to see which line of code was written by who).

A codebase (in Git terms, this is called a “repository” or “repo” for short) can be uploaded to a platform such as GitHub for hosting purposes, allowing for multiple people to be involved in a project. These platforms add a social media and project management aspect, where tasks can be created (these tasks are called “issues”, and can represent bugs, suggested features, or documentation improvements), assigned to people, and be addressed in changes to the codebase (i.e., addressed in a “pull request”, which details exactly which parts of the codebase need to change to fix a particular issue). A common workflow is for an issue to be created, discussed, and then addressed by one or more pull requests.

Exactly how to use Git and GitHub is beyond the scope of this documentation, and there are many tutorials online on how to do that (here are some good ones: Version Control with Git by Software carpentry, Learn Git by freeCodeCamp.org).

Your first contribution#

There are many ways that you can contribute to Parcels. You can:

  • Participate in discussion about Parcels, either through the issues or discussions tab

  • Suggest improvements to tutorials

  • Suggest improvements to documentation

  • Write code (fix bugs, implement features, codebase improvements, etc)

All of these require you to make an account on GitHub, so that should be your first step.

If you want to suggest quick edits to the documentation, it’s as easy as going to the page and clicking “Edit on GitHub” in the righthand panel. For other changes, it’s a matter of looking through the issue tracker which documents tasks that are being considered. Pay particular attention to issues tagged with “good first issue”, as these are tasks that don’t require deep familiarity with the codebase. Once you’ve chosen an issue you would like to contribute towards, comment on it to flag your interest in working on it. This allows the community to know who’s interested, and provide any guidance in its implementation (maybe the scope has changed since the issue was last updated).

If you’re having trouble using Parcels, feel free to create a discussion in our Discussions tab and we’ll be happy to support. Want to suggest a feature, or have encountered a problem that is a result of a bug in Parcels, then search for an issue in the tracker or create a new one with the relevant details.

In the Projects panel, you’ll see the “Parcels development” project. This is used by the core development team for project management, as well as drafting up new ideas for the codebase that aren’t mature enough to be issues themselves. Everything in “backlog” is not being actively worked on and is fair game for open source contributions.

Editing Parcels code#

Development environment setup#

To get started contributing to Parcels:

Now you have a cloned repo that you have full control over, and a conda environment where Parcels is installed in an editable mode (i.e., any changes that you make to the Parcels code will take effect when you use that conda environment to run Python code).

From there:

  • create a git branch, implement, commit, and push your changes

  • create a pull request (PR) into main of the original repo making sure to link to the issue that you are working on. Not yet finished with your feature but still want feedback on how you’re going? Then mark it as “draft” and @ping a maintainer. See our maintainer notes to see our PR review workflow.

If you made changes to the documentation, and want to render a local version, you can run the command sphinx-autobuild --ignore "*.zip" docs docs/_build to create a server to automatically rebuild the documentation when you make changes.

Code guidelines#

Note

These guidelines are here to promote Python best practices, as well as standardise the Parcels code. If you’re not sure what some of these guidelines mean, don’t worry! Your contribution is still appreciated. When you create your pull request, maintainers can modify your code to comply with these guidelines.

  • Write clear commit messages that explain the changes you’ve made.

  • Include tests for any new code you write. Tests are implemented using pytest and are located in the tests directory.

  • Follow the NumPy docstring conventions when adding or modifying docstrings.

  • Follow the PEP 8 style guide when writing code. This codebase also uses flake8 and isort to ensure a consistent code style.

If you’re comfortable with these code guidelines, and want to enforce them on your local machine before pushing, you can install the Git hooks for the repo by running pre-commit install. This will run tools to check your changes adhere to these guidelines as you make commits.

That’s it! Thank you for reading and we’ll see you on GitHub 😁.